Résumé : Dans cette thèse nous étudions le problème d'ordonnancement temps réel multiprocesseur préemptif avec prise en compte du coût exact du système d'exploitation. Ce coût est formé de deux parties : une partie facile à déterminer, correspondant au coût de l'ordonnanceur et une partie difficile à déterminer, correspondant au coût de la préemption. Cette difficulté est due au fait qu'une préemption peut en engendrer une autre, pouvant ainsi créer un phénomène d'avalanche. Dans un premier temps, nous avons étudié l'ordonnancement hors ligne multiprocesseur de tâches indépendantes avec prise en compte du coût exact de la préemption et proposé une analyse d'ordonnançabilité fondée sur une heuristique d'ordonnancement multiprocesseur. Cette heuristique utilise la stratégie d'ordonnancement multiprocesseur par partitionnement. Pour prendre en compte le coût exact de la préemption sur chaque processeur nous avons utilisé la condition d'ordonnançabilité proposée par Meumeu et Sorel. Cette condition d'ordonnançabilité pour des tâches à priorités fixes, est basée sur une opération binaire d'ordonnancement qui permet de compter le nombre exact de préemption et d'ajouter leur coût dans l'analyse d'ordonnançabilité des tâches. L'heuristique proposée permet de maximiser le facteur d'utilisation restant afin de répartir équitablement les tâches sur les processeurs et de réduire leur temps de réponse. Elle produit une table d'ordonnancement hors ligne. Dans un second temps, nous avons étudié l'ordonnancement hors ligne multiprocesseur de tâches dépendantes avec prise en compte du coût exact de la préemption. Puisque la condition d'ordonnançabilité utilisée pour ordonnancer les tâches indépendantes ne s'applique qu'à des tâches à priorités fixes, elle ne permet pas de gérer les inversions de priorités que peuvent entraîner les tâches dépendantes. Nous avons donc proposé une nouvelle condition d'ordonnançabilité pour des tâches à priorités dynamiques. Elle prend en compte le coût exact de la préemption et les dépendances sans aucune perte de données. Ensuite en utilisant toujours la stratégie d'ordonnancement par partitionnement, nous avons proposé pour des tâches dépendantes une heuristique d'ordonnancement multiprocesseur qui réutilise cette nouvelle condition d'ordonnançabilité au niveau de chaque processeur. Cette heuristique d'ordonnancement prend en compte les coûts de communication inter-processeurs. Elle permet aussi de minimiser sur chaque processeur le makespan (temps total d'exécution) des tâches. Cette heuristique produit pour chaque processeur une table d'ordonnancement hors ligne contenant les dates de début et de fin de chaque tâches et de chaque commmunication inter-processeur. En supposant que nous avons une architecture multiprocesseur de type dirigée par le temps (Time-Triggered) pour laquelle tous les processeurs ont une référence de temps unique, nous avons proposé pour chacun des processeurs un ordonnanceur en ligne qui utilise la table d'ordonnancement produite lors de l'ordonnancement hors ligne. Cet ordonnanceur en ligne a l'avantage d'avoir un coût constant qui de plus est facile à déterminer de manière exacte. En effet il correspond uniquement au temps de lecture dans la table d'ordonnancement pour obtenir la tâche sélectionnée lors de l'analyse d'ordonnançabilité hors ligne, alors que dans les ordonnanceurs classiques en ligne ce coût correspond à mettre à jour la liste des tâches qui sont dans l'état prêt à l'exécution puis à sélectionner une tâche selon un algorithme, par exemple RM, DM, EDF, etc. Il varie donc avec le nombre de tâches prêtes à s'exécuter qui change d'une invocation à l'autre de l'ordonnanceur. C'est ce coût qui est utilisé dans les analyses d'ordonnançabilités évoquées ci-dessus. Un autre avantage est qu'il n'est pas nécessaire de synchroniser l'accès aux mémoires de données partagées par plusieurs tâches, car cette synchronisation a été déjà effectuée lors de l'analyse d'ordonnançabilité hors ligne.
Ordonnancement temps r´eel pr´eemptif multiprocesseur
avec prise en compte du coˆut du syst`eme d’exploitation
Falou Ndoye
To cite this version:
Falou Ndoye. Ordonnancement temps r´eel pr´eemptif multiprocesseur avec prise en compte du
coˆut du syst`eme d’exploitation. Other. Universit´e Paris Sud - Paris XI, 2014. French. .
HAL Id: tel-00978366
https://tel.archives-ouvertes.fr/tel-00978366
Submitted on 14 Apr 2014
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of scientific
research documents, whether they are published
or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est
destin´ee au d´epˆot et `a la diffusion de documents
scientifiques de niveau recherche, publi´es ou non,
´emanant des ´etablissements d’enseignement et de
recherche fran¸cais ou ´etrangers, des laboratoires
publics ou priv´es.UNIVERSITÉ PARIS-SUD
ÉCOLE DOCTORALE
Sciences et Technologie de l’Information, des Télécommunications et des
Systèmes
INRIA Paris-Rocquencourt
DISCIPLINE : Génie Informatique
THÈSE DE DOCTORAT
présentée et soutenue publiquement le 03/04/2014
par
Falou NDOYE
Ordonnancement temps réel préemptif
multiprocesseur avec prise en compte du coût du
système d’exploitation
Composition du jury :
Directeur de thèse : Yves SOREL Directeur de recherche (INRIA Paris-Rocquencourt)
Rapporteurs : Emmanuel GROLLEAU Professeur (ISAE-ENSMA Poitiers)
Jean-Luc SCHARBARG Professeur (INPT/ENSEEIHT Toulouse)
Examinateurs : Alain MERIGOT Professeur (Université Paris-Sud Orsay)
Laurent GEORGE Maître de conférences HDR (Université Marne-la-Vallée)2
Résumé
Dans cette thèse nous étudions le problème d’ordonnancement temps réel multiprocesseur
préemptif avec prise en compte du coût exact du système d’exploitation.
Ce coût est formé de deux parties : une partie facile à déterminer, correspondant
au coût de l’ordonnanceur et une partie difficile à déterminer, correspondant
au coût de la préemption. Cette difficulté est due au fait qu’une préemption peut
en engendrer une autre, pouvant ainsi créer un phénomène d’avalanche.
Dans un premier temps, nous avons étudié l’ordonnancement hors ligne multiprocesseur
de tâches indépendantes avec prise en compte du coût exact de la
préemption et proposé une analyse d’ordonnançabilité fondée sur une heuristique
d’ordonnancement multiprocesseur. Cette heuristique utilise la stratégie d’ordonnancement
multiprocesseur par partitionnement. Pour prendre en compte le coût
exact de la préemption sur chaque processeur nous avons utilisé la condition d’ordonnançabilité
proposée par Meumeu et Sorel. Cette condition d’ordonnançabilité
pour des tâches à priorités fixes, est basée sur une opération binaire d’ordonnancement
qui permet de compter le nombre exact de préemption et d’ajouter leur coût
dans l’analyse d’ordonnançabilité des tâches. L’heuristique proposée permet de
maximiser le facteur d’utilisation restant afin de répartir équitablement les tâches
sur les processeurs et de réduire leur temps de réponse. Elle produit une table
d’ordonnancement hors ligne.
Dans un second temps, nous avons étudié l’ordonnancement hors ligne multiprocesseur
de tâches dépendantes avec prise en compte du coût exact de la
préemption. Puisque la condition d’ordonnançabilité utilisée pour ordonnancer
les tâches indépendantes ne s’applique qu’à des tâches à priorités fixes, elle ne
permet pas de gérer les inversions de priorités que peuvent entraîner les tâches
dépendantes. Nous avons donc proposé une nouvelle condition d’ordonnançabilité
pour des tâches à priorités dynamiques. Elle prend en compte le coût exact
de la préemption et les dépendances sans aucune perte de données. Ensuite en
utilisant toujours la stratégie d’ordonnancement par partitionnement, nous avons
proposé pour des tâches dépendantes une heuristique d’ordonnancement multiprocesseur
qui réutilise cette nouvelle condition d’ordonnançabilité au niveau de
chaque processeur. Cette heuristique d’ordonnancement prend en compte les coûts
de communication inter-processeurs. Elle permet aussi de minimiser sur chaque
processeur le makespan (temps total d’exécution) des tâches. Cette heuristique
produit pour chaque processeur une table d’ordonnancement hors ligne contenant
les dates de début et de fin de chaque tâches et de chaque commmunication interprocesseur.
En supposant que nous avons une architecture multiprocesseur de type dirigée
par le temps (Time Trigger TT) pour laquelle tous les processeurs ont une
référence de temps unique, nous avons proposé pour chacun des processeurs un3
ordonnanceur en ligne qui utilise la table d’ordonnancement produite lors de l’ordonnancement
hors ligne. Cet ordonnanceur en ligne a l’avantage d’avoir un coût
constant et facile à déterminer de manière exacte. En effet il correspond uniquement
au temps de lecture dans la table d’ordonnancement pour obtenir la tâche
sélectionnée lors de l’analyse d’ordonnançabilité hors ligne, alors que dans les
“ordonnanceurs classiques” en ligne ce coût correspond à mettre à jour la liste des
tâches qui sont dans l’état prêt à l’exécution puis à sélectionner une tâche selon
un algorithme, par exemple RM, DM, EDF, etc. Il varie donc avec le nombre de
tâches prêtes à s’exécuter qui change d’une invocation à l’autre de l’ordonnanceur.
C’est ce coût qui est utilisé dans les analyses d’ordonnançabilités évoquées
ci-dessus. Un autre avantage est qu’il n’est pas nécessaire de synchroniser l’accès
aux mémoires de données partagées par plusieurs tâches, car cette synchronisation
a été déjà effectuée lors de l’analyse d’ordonnançabilité hors ligne.5
Rémerciements
Je tiens à remercier Yves Sorel, mon directeur de thèse, de m’avoir accueilli
comme stagiaire au sein de l’équipe-projet AOSTE et ensuite m’avoir donné l’opportunité
de faire une thèse. Il a su guider mes travaux tout en me laissant mon
autonomie.
Je remercie également Emmanuel Grolleau et Jean Luc-Scharbarg qui ont accepté
d’être les rapporteurs de cette thèse. De même, un grand merci à Alain
Merigot et Laurent George qui ont accepté de faire partie des membres du jury.
Je remercie aussi tous les membres de l’équipe-projet AOSTE pour les bons
moments passés ensemble.
Enfin, mention spéciale à ma fammille et à mes amis qui m’ont soutenus tout
au long de cette thèse.Table des matières
Liste des figures 7
Liste des tableaux 8
Introduction générale 11
Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Plan de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
I Concepts de base et État de l’art 15
1 Concepts de base 17
1.1 Système temps réel . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.1.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.1.2 Classification des systèmes temps réel . . . . . . . . . . . 17
1.2 Tâche temps réel . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3 Tâches périodiques . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3.1 Tâches concrètes/non concrètes . . . . . . . . . . . . . . 19
1.3.2 Tâches synchrones/asynchrones . . . . . . . . . . . . . . 20
1.4 Contraintes temps réel . . . . . . . . . . . . . . . . . . . . . . . 20
1.4.1 Échéances . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.4.2 Périodicité stricte . . . . . . . . . . . . . . . . . . . . . . 21
1.4.3 Dépendances entre tâches . . . . . . . . . . . . . . . . . 21
1.4.4 Latence . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.5 Ordonnancement des systèmes temps réel . . . . . . . . . . . . . 22
1.5.1 Algorithmes d’ordonnancement . . . . . . . . . . . . . . 22
1.5.2 Analyse de faisabilité . . . . . . . . . . . . . . . . . . . . 24
1.5.3 Analyse d’ordonnançabilité . . . . . . . . . . . . . . . . 24
1.5.3.1 Approche analytique . . . . . . . . . . . . . . . 24
1.5.3.2 Approche par simulation . . . . . . . . . . . . 252 TABLE DES MATIÈRES
1.6 Viabilité d’une condition d’ordonnançabilité . . . . . . . . . . . . 25
1.7 Ordonnanceur . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
1.7.1 Invocation de l’ordonnanceur . . . . . . . . . . . . . . . 26
1.7.2 États et gestion des tâches . . . . . . . . . . . . . . . . . 26
1.8 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2 État de l’art 29
2.1 Ordonnancement monoprocesseur . . . . . . . . . . . . . . . . . 29
2.1.1 Priorités fixes . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.1.1 Priorités fixes aux tâches . . . . . . . . . . . . 29
2.1.1.2 Priorités fixes aux instances . . . . . . . . . . . 30
2.1.2 Priorités dynamiques . . . . . . . . . . . . . . . . . . . . 31
2.2 Ordonnancement multiprocesseur . . . . . . . . . . . . . . . . . 31
2.2.1 Architecture multiprocesseur . . . . . . . . . . . . . . . . 31
2.2.2 Stratégies d’ordonnancement . . . . . . . . . . . . . . . . 32
2.2.2.1 Stratégie par partitionnement . . . . . . . . . . 33
2.2.2.2 Stratégie globale . . . . . . . . . . . . . . . . . 35
2.2.2.3 Stratégie par semi-partitionnement . . . . . . . 37
2.3 Allocation des tâches temps réel dans l’ordonnancement multiprocesseur
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.3.1 Méthodes exactes . . . . . . . . . . . . . . . . . . . . . . 37
2.3.1.1 Branch & Bound . . . . . . . . . . . . . . . . . 38
2.3.1.2 Branch & Cut . . . . . . . . . . . . . . . . . . 38
2.3.1.3 Programmation par contraintes . . . . . . . . . 38
2.3.1.4 Programmation linéaire . . . . . . . . . . . . . 39
2.3.1.5 Programmation dynamique . . . . . . . . . . . 40
2.3.1.6 Les Réseaux de flots . . . . . . . . . . . . . . . 40
2.3.2 Méthodes approchées . . . . . . . . . . . . . . . . . . . . 41
2.3.2.1 Méthodes de recherche non guidées ou métaheuristiques
. . . . . . . . . . . . . . . . . . . 41
2.3.2.1.1 Recuit simulé . . . . . . . . . . . . . 41
2.3.2.1.2 Recherche Tabou . . . . . . . . . . . 41
2.3.2.1.3 Algorithmes génétiques . . . . . . . . 42
2.3.2.2 Méthodes guidées ou heuristiques . . . . . . . . 42
2.3.2.2.1 Heuristiques gloutonnes . . . . . . . . 43
2.3.2.2.2 Heuristiques de listes . . . . . . . . . 44
2.3.2.2.3 Heuristiques de regroupement ou "clustering"
. . . . . . . . . . . . . . . . . 44
2.3.2.2.4 Heuristique de duplication de tâches . 45
2.4 Ordonnancement de tâches dépendantes . . . . . . . . . . . . . . 45
2.4.1 Transfert de données . . . . . . . . . . . . . . . . . . . . 46TABLE DES MATIÈRES 3
2.4.2 Partage de ressources . . . . . . . . . . . . . . . . . . . . 46
2.4.3 Protocoles de synchronisation monoprocesseur . . . . . . 48
2.4.3.1 Priority Inheritance Protocol (PIP) . . . . . . . 48
2.4.3.2 Priority Ceiling Protocol (PCP) . . . . . . . . . 49
2.4.3.3 Stack Resource Policy (SRP) . . . . . . . . . . 49
2.4.4 Protocoles de synchronisation multiprocesseur . . . . . . 50
2.4.4.1 MPCP . . . . . . . . . . . . . . . . . . . . . . 50
2.4.4.2 MSRP . . . . . . . . . . . . . . . . . . . . . . 50
2.5 Ordonnancement avec prise en compte du coût de l’OS . . . . . . 50
2.5.1 Coût de l’ordonnanceur . . . . . . . . . . . . . . . . . . . 51
2.5.2 Coût de la préemption . . . . . . . . . . . . . . . . . . . 51
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
II Ordonnancement temps réel multiprocesseur de tâches
indépendantes avec prise en compte du coût exact de la pré-
emption 55
3 Ordonnancement monoprocesseur de tâches indépendantes 57
3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.2 Modèle de tâches . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.3 Intervalle d’étude de l’ordonnancement . . . . . . . . . . . . . . 58
3.4 Opération binaire d’ordonnancement ⊕ . . . . . . . . . . . . . . 58
3.4.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.4.2 Application . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.5 Analyse d’ordonnançabilité avec ⊕ . . . . . . . . . . . . . . . . . 60
3.6 Facteur d’utilisation du processeur avec coût de la préemption . . 62
3.7 Impact du coût de la préemption dans l’analyse d’ordonnançabilité 62
3.8 Viabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4 Ordonnancement multiprocesseur de tâches indépendantes 69
4.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.2 Modèle de tâches et d’architecture . . . . . . . . . . . . . . . . . 69
4.3 Heuristique d’ordonnancement . . . . . . . . . . . . . . . . . . . 70
4.3.1 Fonction de coût . . . . . . . . . . . . . . . . . . . . . . 70
4.3.2 Principe de l’heuristique . . . . . . . . . . . . . . . . . . 71
4.4 Étude de performances . . . . . . . . . . . . . . . . . . . . . . . 71
4.4.1 Heuristiques BF et W F . . . . . . . . . . . . . . . . . . 73
4.4.2 Algorithme exact B&B . . . . . . . . . . . . . . . . . . 76
4.4.3 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . 764 TABLE DES MATIÈRES
4.4.3.1 Comparaison des temps d’exécution . . . . . . 76
4.4.3.2 Comparaison des taux de succès . . . . . . . . 79
4.4.3.3 Comparaison des temps de réponse de l’ordonnancement
des tâches . . . . . . . . . . . . . . 80
4.4.3.4 Comparaison des moyennes des facteurs d’utilisation
restants . . . . . . . . . . . . . . . . . 81
4.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
III Ordonnancement temps réel multiprocesseur de tâches
dépendantes avec prise en compte du coût exact de la pré-
emption 83
5 Ordonnancement monoprocesseur de tâches dépendantes 85
5.1 Modèle de tâches et notations . . . . . . . . . . . . . . . . . . . . 86
5.1.1 Modèle de tâches . . . . . . . . . . . . . . . . . . . . . . 86
5.1.2 Notations . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.2 Intervalle d’étude de l’ordonnancement . . . . . . . . . . . . . . 88
5.3 Mécanisme de transfert de données . . . . . . . . . . . . . . . . . 88
5.4 Synchronisation de l’accès aux mémoires de données . . . . . . . 91
5.5 Analyse d’ordonnançabilité hors ligne . . . . . . . . . . . . . . . 93
5.5.1 Sélection de la tâche à exécuter . . . . . . . . . . . . . . 94
5.5.2 Durée restant à exécuter avec coût exact de la préemption 96
5.5.3 Échéance relative à une date d’appel de l’ordonnanceur . . 98
5.5.4 Condition d’ordonnançabilité . . . . . . . . . . . . . . . 98
5.5.5 Prochaine date d’appel de l’ordonnanceur hors ligne . . . 100
5.5.6 Algorithme d’analyse d’ordonnançabilité monoprocesseur 101
5.5.7 Application . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.6 Viabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
6 Ordonnancement multiprocesseur de tâches dépendantes 107
6.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.2 Modèle de tâches . . . . . . . . . . . . . . . . . . . . . . . . . . 107
6.3 Modèle d’architecture . . . . . . . . . . . . . . . . . . . . . . . . 108
6.4 Allocation des tâches aux processeurs . . . . . . . . . . . . . . . 109
6.4.1 Condition nécessaire d’ordonnançabilité . . . . . . . . . 109
6.4.2 Fonction de coût . . . . . . . . . . . . . . . . . . . . . . 111
6.4.3 Heuristique d’allocation . . . . . . . . . . . . . . . . . . 112
6.5 Analyse d’ordonnançabilité multiprocesseur . . . . . . . . . . . 113
6.5.1 Communication inter-processeurs . . . . . . . . . . . . . 114TABLE DES MATIÈRES 5
6.5.2 Analyse d’ordonnançabilité des tâches allouées à un processeur
. . . . . . . . . . . . . . . . . . . . . . . . . . . 116
6.5.3 Condition d’ordonnançabilité multiprocesseur . . . . . . . 121
6.5.4 Algorithme d’analyse d’ordonnançabilité multiprocesseur 121
6.6 Heuristique d’ordonnancement multiprocesseur de tâches dépendantes
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
6.7 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
6.8 Étude de performance . . . . . . . . . . . . . . . . . . . . . . . . 128
6.8.1 Générateur de graphes de tâches dépendantes . . . . . . . 133
6.8.2 Graphe de processeurs . . . . . . . . . . . . . . . . . . . 136
6.8.3 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . 136
6.8.3.1 Temps d’exécutions des algorithmes . . . . . . 136
6.8.3.2 Taux de succès . . . . . . . . . . . . . . . . . . 138
6.8.3.3 Makespan . . . . . . . . . . . . . . . . . . . . 139
6.9 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
7 Ordonnanceur en ligne avec prise en compte du coût exact de la pré-
emption 143
7.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
7.2 Principe de l’ordonnanceur . . . . . . . . . . . . . . . . . . . . . 143
7.3 Implantation de l’ordonnanceur . . . . . . . . . . . . . . . . . . . 145
7.4 Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
7.5 Gestion des communications inter-processeurs . . . . . . . . . . . 149
7.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Conclusion générale et perspectives 153
Conclusion générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154Table des figures
1.1 Système réactif temps réel . . . . . . . . . . . . . . . . . . . . . 18
1.2 Paramètres dynamiques de l’instance k de τi
. . . . . . . . . . . . 20
1.3 Exemple de graphe de dépendances . . . . . . . . . . . . . . . . 22
1.4 Illustration de la latence d’un graphe de tâches . . . . . . . . . . 22
1.5 États et transitions d’une tâche . . . . . . . . . . . . . . . . . . . 27
2.1 Illustration des pertes de données . . . . . . . . . . . . . . . . . . 47
2.2 Inversion de priorités . . . . . . . . . . . . . . . . . . . . . . . . 48
2.3 Inter-blocage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.4 Illustration du coût de l’ordonnanceur . . . . . . . . . . . . . . . 51
2.5 Illustration du coût de la préemption . . . . . . . . . . . . . . . . 52
3.1 Illustration du PET de l’instance k de τ2 . . . . . . . . . . . . . . 60
3.2 Opération ⊕ entre deux tâches . . . . . . . . . . . . . . . . . . . 66
3.3 Impact du coût de la préemption . . . . . . . . . . . . . . . . . . 67
4.1 Comparaison des temps d’exécution avec variation du nombre de
tâches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.2 Comparaison des temps d’exécution avec variation du nombre de
processeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.3 Comparaison des taux de succès . . . . . . . . . . . . . . . . . . 79
4.4 Comparaison des temps de réponse de l’ordonnancement des tâches 80
4.5 Comparaison des moyennes des facteurs d’utilisations restants sur
les processeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.1 Graphe G5 de dépendances de données . . . . . . . . . . . . . . . 86
5.2 Illustration des mémoires de données . . . . . . . . . . . . . . . 86
5.3 Graphe G3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.4 Illustration du transfert de données des tâches dans G3 . . . . . . 90
5.5 Motifs d’exécution des tâches de Γ3 . . . . . . . . . . . . . . . . 90
5.6 Illustration du principe d’héritage de priorités . . . . . . . . . . . 92
5.7 Illustration de c1(t) et c2(t) . . . . . . . . . . . . . . . . . . . . . 978 TABLE DES FIGURES
5.8 Illustration de di(t) . . . . . . . . . . . . . . . . . . . . . . . . . 98
5.9 Illustration des dates d’appel de l’ordonnanceur . . . . . . . . . . 102
5.10 Graphe G
′
3
représentant Γ3 . . . . . . . . . . . . . . . . . . . . . 102
5.11 Résultat de l’ordonnancement de Γ3 . . . . . . . . . . . . . . . . 105
6.1 Illustration d’un graphe d’architecture . . . . . . . . . . . . . . . 108
6.2 Illustration de r
(1,k)
j
et Dk
j
. . . . . . . . . . . . . . . . . . . . . . 111
6.3 Illustration de la marge d’exécution de τj
. . . . . . . . . . . . . 112
6.4 Illustration d’un processeur de communication . . . . . . . . . . . 115
6.5 Illustration d’une communication entre deux processeurs . . . . . 116
6.6 Graphe G8 de dépendances de données . . . . . . . . . . . . . . . 124
6.7 Graphe d’architecture de P2 . . . . . . . . . . . . . . . . . . . . 124
6.8 Résultat de l’ordonnancement des tâches sur p1 et sur p2 . . . . . 132
6.9 Comparaison des durées d’exécution des algorithmes . . . . . . . 137
6.10 Comparaison des durées d’exécution des algorithmes . . . . . . . 138
6.11 Comparaison des taux de succès des algorithmes . . . . . . . . . 139
6.12 Comparaison des makespan . . . . . . . . . . . . . . . . . . . . . 140
7.1 Exemple de déroulement de l’algorithme 12 . . . . . . . . . . . . 150
clearemptydoublepageListe des tableaux
5.1 Résumé des notations . . . . . . . . . . . . . . . . . . . . . . . . 87
5.2 Table d’ordonnancement de Γ3 . . . . . . . . . . . . . . . . . . . 104
6.1 Table d’ordonnancement du processeur p1 . . . . . . . . . . . . . 129
6.2 Table d’ordonnancement du processeur p2 . . . . . . . . . . . . . 130
6.3 Table d’ordonnancement du processeur de communication pcom12 131
7.1 Table d’ordonnancement T de τ1 et τ2 . . . . . . . . . . . . . . . 149Introduction générale
Contexte
Cette thèse s’inscrit dans le cadre des recherches menées dans l’équipe-projet
AOSTE (Analyse et Optimisation des Systèmes Temps réel Embarquée) d’INRIA
Paris-Rocquencourt sur les systèmes distribués temps réel embarqués que l’on
trouve dans les domaines applicatifs tels que l’automobile, l’avionique, le ferroviaire,
etc. Ces systèmes étant critiques, il faut assurer que les contraintes temps
réel et les contraintes de ressources sont satisfaites au risque de conséquences
catastrophiques, par exemple de pertes humaines. Satisfaire ces contraintes temps
réel et de ressources est d’autant plus difficile que les architectures cibles actuelles
sont multicomposant (multiprocesseur, distribués, multi/many-core, parallèles).
Les spécifications fonctionnelles et les simulations réalisées par les automaticiens
conduisent à ce que les fonctions, qui deviendront des tâches temps réel, aient des
périodes différentes, des dépendance entre elles, des contraintes d’échéance et de
latence. Afin d’assurer que les conditions d’ordonnançabilités temps réel soient
réellement respectées lorsqu’une application s’exécute en temps réel sur une architecture
cible, il faut prendre en compte dans l’analyse d’ordonnançabilité le
coût du système d’exploitation (OS pour “Operating System”) qui réalise effectivement
l’ordonnancement pendant la vie de l’application, mais qui est en général
approximé, voire négligé. Ceci conduit au mieux à du gaspillage de ressources
et au pire au non respect des contraintes temps réel lors du fonctionnement de
l’application.
Objectifs
Le coût du système d’exploitation est composé de deux parties : une partie
facile à déterminer, correspondant au coût de l’ordonnanceur et une partie dif-
ficile à déterminer, correspondant au coût de la préemption. Cette difficulté est
due au fait qu’une préemption peut en engendrer une autre, pouvant ainsi créer
un phénomène d’avalanche [Yom09]. Meumeu et Sorel [Yom09] ont proposé une12 LISTE DES TABLEAUX
condition d’ordonnançabilité qui permet de prendre en compte le coût exact de la
préemption, donc le coût de l’OS. Mais cette condition d’ordonnançabilité n’est
applicable qu’à des tâches indépendantes à priorités fixes et sur une architecture
monoprocesseur. Notre premier objectif est d’étendre cette condition d’ordonnan-
çabilité pour étudier l’ordonnancement de tâches temps réel indépendantes sur
une architecture multiprocesseur et en tenant compte du coût exact de la préemption.
Les applications temps réel embarquées étant généralement composées de
tâches dépendantes, notre deuxième objectif est d’étudier l’ordonnancement de
tâches dépendantes sur une architecture multiprocesseur et toujours avec prise en
compte du coût exact de la préemption. Pour cela nous allons étudier une nouvelle
condition d’ordonnançabilité pour des tâches dépendantes, qui permet de prendre
en compte le coût exact de la préemption puisque la condition d’ordonnançabilité
proposée par Meumeu et Sorel est applicable uniquement pour des tâches
indépendantes à priorités fixes et ne permet donc pas de gérer les inversions de
priorités que peut entraîner l’ordonnancement de tâches dépendantes. Enfin notre
troisième et dernier objectif est, à partir de l’analyse d’ordonnançabilité que nous
avons proposée, d’utiliser la table d’ordonnancement déterminée hors ligne dans
un nouveau type d’ordonnanceur en ligne prenant mieux en compte le coût de
l’OS que les ordonnanceurs classiques.
Plan de la thèse
Ce manuscrit est constitué de trois parties.
La première partie est consacrée aux concepts de bases de l’ordonnancement
temps réel pour faciliter la compréhension de la suite de la thèse et à l’état de
l’art dans lequel on met l’accent sur les méthodes d’allocation des tâches dans
l’ordonnancement multiprocesseur, sur la prise en compte du coût exact de la
préemption et sur les dépendances de données.
La deuxième partie est consacrée à l’ordonnancement multiprocesseur de tâches
indépendantes avec prise en compte du coût exact de la préemption. Dans le premier
chapitre de cette partie on présente la condition d’ordonnançabilité proposée
par Meumeu et Sorel qui permet de prendre en compte le coût exact de la préemption
en monoprocesseur pour des tâches à priorités fixes. Le deuxième chapitre
de cette deuxième partie présente l’étude d’ordonnancement multiprocesseur de
tâches indépendantes qui étend la condition d’ordonnançabilité de Meumeu et Sorel
en multiprocesseur.
La troisième partie est consacrée à l’ordonnancement multiprocesseur de tâches
dépendantes. Dans le premier chapitre de cette partie, on étudie l’ordonnancement
des tâches dépendantes en monoprocesseur en proposant une nouvelle condition
d’ordonnançabilité qui permet d’ordonnancer des tâches dépendantes en prenantLISTE DES TABLEAUX 13
en compte du coût exact de la préemption et les transferts de données entre tâches
qui conduisent à des inversions de priorités. Dans le deuxième chapitre de cette
partie, on présente l’étude d’ordonnancement multiprocesseur de tâches dépendantes
qui étend cette nouvelle condition d’ordonnançabilité monoprocesseur en
multiprocesseur tout en tenant compte le coût exact de la préemption et les coûts
de communication inter-processeurs. Dans le troisième chapitre de cette partie,
on présente l’ordonnanceur en ligne de chaque processeur qui utilise la table d’ordonnancement
produite hors ligne, pour ce processeur.Première partie
Concepts de base et État de l’artChapitre 1
Concepts de base
L’objectif de ce chapitre est de présenter les concepts de base de l’ordonnancement
temps réel.
1.1 Système temps réel
1.1.1 Définition
Un système réactif doit réagir continûment aux stimuli venant d’un processus
qu’il cherche à commander. Un système temps réel est un système réactif qui
doit respecter des contraintes de temps. Un système temps réel doit être capable
de traiter les informations venant du processus dans un délai qui ne nuit pas à la
commande du processus. Réagir trop tard peut conduire à des conséquences catastrophiques
pour le système lui-même ou le processus. Le respect des contraintes
temporelles est la principale contrainte à satisfaire. La validité d’un système temps
réel dépend non seulement des résultats du traitement effectué mais aussi de l’aspect
temporel (un calcul juste mais hors délai est un calcul non valable). Dans un
système temps réel, les évènements d’entrée sont produits par des capteurs et les
évènements de sortie sont consommés par des actionneurs. La figure 1.1 donne
une illustration d’un système réactif temps réel. On rencontre des applications
temps réel dans le domaine de l’aéronautique, l’automobile, télécommunication,
robotique, etc.
1.1.2 Classification des systèmes temps réel
La criticité des contraintes temporelles conduit à classifier les système temps
réel en trois catégories suivantes :18 Concepts de base
Processus
Évènements entrée
Stimuli
Capteurs
Évènements sortie
Réactions
Actionneurs
SYSTÈME RÉACTIF TEMPS RÉEL
FIGURE 1.1 – Système réactif temps réel
– système temps réel strict : c’est un système soumis à des contraintes temporelles
strictes, c’est-à-dire pour lequel la moindre faute temporelle peut
avoir des conséquences humaines ou économiques catastrophiques. La plupart
des applications dans les domaines avioniques, automobile, etc., sont
temps réel strict;
– système temps réel souple : c’est un système soumis à des contraintes temporelles
souples, un certain nombre de fautes temporelles peut être tolérées.
On parle alors de qualité de service;
– système temps réel mixte : c’est un système soumis à des contraintes temporelles
strictes et à des contraintes temporelles souples.
1.2 Tâche temps réel
Une tâche temps réel est formée d’un ensemble d’instructions pouvant s’exé-
cuter en séquence sur un ou plusieurs processeurs et respecter des contraintes
de temps. Dans la suite nous ferons l’hypothèse qu’une tâche ne s’exécutera pas
en parallèle. Elle peut se répéter un nombre quelconque de fois, éventuellement
infini. Chacune de ses exécutions est appelée instance ou travail ("job"). Un système
temps réel est composé d’un ensemble de tâches temps réel soumises à des
contraintes temps réel (voir la section 1.4).
Une tâche temps réel peut être :
– périodique : ses instances (exécutions) se répètent indéfiniment et il existe
une durée constante entre deux activations d’instances successives appelée
période,
– sporadique : ses instances (exécutions) se répètent indéfiniment et il existe
une durée minimum entre deux instances successives,
– apériodique : il y a pas de corrélation entre deux instances successives.1.3 Tâches périodiques 19
1.3 Tâches périodiques
Le modèle de tâches périodiques classique dit de Liu et Layland de [LL73] est
le plus utilisé dans la modélisation des systèmes temps réel. Ce modèle permet de
définir plusieurs paramètres pour une tâche. Ces paramètres sont de deux types :
paramètres statiques relatifs à la tâche elle-même et les paramètres dynamiques
relatif à chaque instance de la tâche. Les paramètres statiques de base d’une tâche
périodique τi = (r
1
i
, Ci
, Di
, Ti) sont :
– r
1
i
(release time) : date de première activation de la tâche τi
, date à laquelle
τi peut commencer sa toute première exécution,
– Ci (computing time) : durée d’exécution de τi
. Ce paramètre est considéré
dans plusieurs travaux sur l’ordonnancement temps réel comme le pire cas
des temps d’exécution (WCET pour Worst Case Execution Time) sur le
processeur sur lequel elle va s’exécuter;
– Di
: échéance relative ou délai critique relatif à chaque activation de τi
,
– Ti
: période d’exécution de τi
.
D’autres paramètres statiques sont dérivés des paramètre de base :
– ui =
Ci
Ti
: le facteur d’utilisation du processeur par τi
, ui ≤ 1,
– CHi =
Ci
Di
: la densité de la tâche τi
, CHi ≤ 1.
Les paramètres dynamiques d’une tâches déterminent le comportement pendant
l’exécution de la tâche τi
. Ces paramètres sont définis pour chaque instance
k noté τ
k
i par :
– r
k
i
(release time) : date à laquelle τ
k
i peut commencer son exécution appelée
date d’activation ou date de réveil de la tâche,
– s
k
i
, f
k
i
: respectivement la date de début d’exécution effective et date de fin
d’exécution de τ
k
i
,
– Rk
i
: temps de réponse de τ
k
i donné par Rk
i = f
k
i − r
k
i
. Le pire temps de
réponse de τi noté Ri est défini par Ri = max{Rk
i }k≥1;
– d
k
i = r
k
i + Di
: échéance absolue de τ
k
i
relative à r
k
i
, c’est la date dont le
dépassement entraîne une faute temporelle,
– L
k
i
(t) (laxity) : c’est la laxité de l’instance τ
k
i
à la date t, qui représente le
retard maximum pour reprendre l’exécution de la tâche τi quand elle s’exé-
cute seule.
1.3.1 Tâches concrètes/non concrètes
Si toutes les dates de première activation de toutes les tâches sont connues on
dit que les tâches sont concrètes. Au contraire si on ne connaît pas ces dates de
première activation on dit que ces tâches sont non concrètes.20 Concepts de base
r
k s i + Ti
k
i
f
k
i
Rk
i
Ci
Lk
i
(t)
Di
r
k
i
t
Ti
τ
k
i
d
k
i
FIGURE 1.2 – Paramètres dynamiques de l’instance k de τi
1.3.2 Tâches synchrones/asynchrones
Si toutes les tâches sont concrètes et ont les mêmes dates de première activation,
on dit que les tâches sont à activations synchrones. Sinon, elles sont asynchrones.
1.4 Contraintes temps réel
Dans l’ordonnancement temps réel, les tâches peuvent être soumises à plusieurs
contraintes telles que des contraintes d’échéances, de périodicité stricte, de
dépendances et de précédences, etc.
1.4.1 Échéances
Les contraintes d’échéances permettent d’exprimer une condition sur la date
de fin d’exécution au plus tard d’une tâche. Considérons un système de tâches
périodiques, suivant la relation entre la période Ti et l’échéance relative Di de
chaque tâche τi nous distinguons trois types d’échéances :
– Di = Ti
: à chaque activation de τi
, la tâche τi doit être exécutée avant
sa prochaine activation. On parle de tâches à échéances sur activations,
échéances implicites, ou échéances sur requêtes;
– Di ≤ Ti
: à chaque activation de τi
, la tâche τi doit être exécutée au plus
tard à une date inférieure ou égale à la date de sa prochaine activation. On
parle de tâches à échéances contraintes;
– Di 6= Ti
: il n’y a pas de corrélation entre la date de fin d’exécution au plus
tard de τi
lors d’une activation et sa prochaine activation de τi
. On peut avoir
Di ≤ Ti ou Di > Ti
, on parle de tâches à échéances arbitraires.1.4 Contraintes temps réel 21
1.4.2 Périodicité stricte
Considérons une tâche périodique τi dans un système de tâches temps réel, une
contrainte de périodicité stricte impose que le temps qui s’écoule entre deux dates
de début d’exécution consécutives s
k
i
et s
k+1
i
corresponde exactement à la période
de la tâche τi
. L’intérêt de cette contrainte est que la connaissance de la date de
début effective de la première instance s
1
i de τi
implique la connaissance de la date
de début effective de toutes les instances suivantes de la même tâche [Cuc04], cela
s’exprime par la relation s
k+1
i = s
1
i + kTi
, ∀k ≥ 1. C’est une contrainte qui est
utile pour les tâches correspondant aux capteurs et actionneurs et les traitements
réalisant une boucle de commande d’un processus.
1.4.3 Dépendances entre tâches
Une dépendance entre deux tâches τi et τj peut être de deux types : une dépendance
de précédence et/ou une dépendance de données. Une dépendance de pré-
cédence entre (τi
, τj ) impose que la tâche τj commence son exécution après que
la tâche τi ait complètement fini de s’exécuter [Cuc04, HCAL89, CL87, Xu93].
Les contraintes de précédences sont indirectement des contraintes temps réel et
on dit que la tâche τi est un prédécesseur de la tâche τj et τj est un successeur
de τi
. Si τi s’exécute exactement une fois avant une exécution de τj on a
une contrainte de précédence simple sinon une contrainte de précédence étendue
[RCR01, FGPR11, PFB+11].
Une dépendance de données signifie que la tâche τi produit une donnée qui est
consommée par τj [Cuc04, HCAL89], cette dépendance entraîne forcément une
précédence entre les tâches. Les tâches sont dites indépendantes lorsqu’elles ne
sont définies que par leurs paramètres temporels.
L’ensemble des dépendances entre les tâches peut être modélisé par un graphe
orienté où les sommets représentent les tâches et l’ensemble des arcs la relation de
dépendances entre les tâches. Cette relation est antisymétrique et transitive, c’est
donc une relation d’ordre sur l’exécution des tâches. C’est une relation d’ordre
partiel car certaines tâches ne sont pas dépendantes. Un exemple de graphe de
dépendances de tâches est présenté sur la figure 5.1.
On distingue deux types de dépendances de données :
– sans pertes de données : les données, produites par chaque instance de la
tâche productrice sont toutes consommées par l’instance de la tâche consommatrice,
– avec pertes de données : la tâche consommatrice peut perdre des données
qui sont écrasées par d’autres données produites par l’exécution d’autres
instances de la tâche productrice.22 Concepts de base
τ3
τ4
τ1
τ2
FIGURE 1.3 – Exemple de graphe de dépendances
1.4.4 Latence
La latence est définie pour des tâches dépendantes éventuellement par transitivité
dans le cas d’un chemin de tâches. Soient τi et τj deux liées par un chemin
dans un graphe de tâches dépendantes. La latence entre τi et τj notée L(τi
, τj ) est
la durée entre le début d’exécution de τi et la fin d’exécution de τj
. La figure 1.4
donne une illustration de la latence entre deux tâches.
τ1 τ2
τ3
τ4
L(τ1, τ3)
FIGURE 1.4 – Illustration de la latence d’un graphe de tâches
Une contrainte de latence entre τi et τj signifie que L(τi
, τj ) doit être inférieure
ou égale à une certaine valeur.
1.5 Ordonnancement des systèmes temps réel
1.5.1 Algorithmes d’ordonnancement
Un système temps réel est constitué d’un ou plusieurs processeurs et d’un
ensemble de tâches ayant des contraintes temps réel. Un algorithme d’ordonnancement
détermine l’ordre total et les dates de démarrage des exécutions des tâches
sur un ou plusieurs processeurs. Il existe plusieurs classes d’algorithmes d’ordonnancement
temps réel.1.5 Ordonnancement des systèmes temps réel 23
Monoprocesseur/Multiprocesseur
L’ordonnancement est de type monoprocesseur si toutes les tâches s’exécutent
sur un seul processeur. Si les tâches peuvent s’exécuter sur plusieurs processeurs
l’ordonnancement est multiprocesseur.
Préemptif/Non préemptif
Un algorithme d’ordonnancement est préemptif lorsqu’une tâche s’exécutant
sur un processeur peut être suspendue au profit d’une tâche, dite plus prioritaire,
puis reprendre son exécution plus tard. Dans le cas contraire il est non préemptif.
En ligne/Hors ligne
Un algorithme d’ordonnancement hors ligne (“off-line” en anglais) construit
la séquence complète des dates de début d’exécution des tâches sur la base des
paramètres temporels. Cette séquence est connue avant l’exécution de l’ensemble
des tâches. En pratique, l’ordonnancement a la forme d’un plan hors ligne (ou
statique), exécuté de façon répétitive ou cyclique.
Un ordonnancement en ligne (“on-line” en anglais) construit la séquence des
dates de début d’exécution des tâches à partir des paramètres temporels des tâches
pendant l’exécution de l’ensemble des tâches. Les algorithmes en ligne sont plus
robustes vis-à-vis des dépassements des WCETs.
Priorité fixe/dynamique
Un algorithme d’ordonnancement est à priorités fixes, si les priorités des tâches
sont basées sur des paramètres statiques (par exemple la période). Il existe des algorithmes
d’ordonnancement à priorités fixes aux tâches et d’autres qui sont à
priorité fixes aux instances (“job”).
Un algorithme d’ordonnancement est à priorités dynamiques, si les priorités
des tâches sont basées sur des paramètres dynamiques (par exemple la laxité).
Optimal/Non optimal
Par définition, un algorithme d’ordonnancement optimal pour une classe de
problème d’ordonnancement donnée (hors ligne, en ligne, priorités fixes ou dynamiques,
etc.) est tel que : si un système est ordonnançable par au moins un
algorithme de la même classe, alors le système est aussi ordonnançable par l’algorithme
d’ordonnancement optimal. En conséquence, si un système n’est pas24 Concepts de base
ordonnançable par l’algorithme d’ordonnancement optimal d’une classe donnée,
alors il ne l’est pas par aucun autre algorithme d’ordonnancement de la même
classe.
1.5.2 Analyse de faisabilité
Une analyse de faisabilité d’un ensemble de tâches permet de déterminer s’il
existe un algorithme d’ordonnancement qui peut ordonnancer cet ensemble de
tâches. La condition que doit vérifier l’ensemble des tâches pour être faisable est
appelée condition de faisabilité.
1.5.3 Analyse d’ordonnançabilité
Une analyse d’ordonnançabilité d’un ensemble de tâches permet de vérifier si
cet ensemble de tâches est ordonnançable relativement à un algorithme d’ordonnancement,
c’est-à-dire vérifier que toute instance de chaque tâche respecterason
échéance. La condition que doit vérifier l’ensemble des tâches pour être ordonnançable
est appelée condition d’ordonnançabilité.
Définition 1.5.1 Une condition d’ordonnançabilité suffisante est une condition
qui lorsqu’elle est vérifiée par toutes les tâches assure que celles-ci sont ordonnançables.
Dans le cas contraire, elles ne sont pas forcément non ordonnançables.
Définition 1.5.2 Une condition d’ordonnançabilité nécessaire est une condition
qui lorsqu’elle n’est pas vérifiée par toutes les tâches assure que celles-ci ne sont
pas ordonnançables. Dans le cas contraire, elles ne sont pas forcément ordonnan-
çables.
Définition 1.5.3 Une condition d’ordonnançabilité nécessaire et suffisante est
une condition qui lorsqu’elle n’est pas vérifiée par toutes les tâches assure que
celles-ci ne sont pas ordonnançables et dans le cas contraire assure que celles-ci
sont ordonnançables.
Une analyse d’ordonnançabilité peut se faire selon deux approches.
1.5.3.1 Approche analytique
L’analyse d’ordonnançabilité par approche analytique consiste à identifier le
ou les pires cas d’exécution et de déterminer analytiquement une condition d’ordonnançabilité
des tâches. Dans cette approche on peut utiliser :1.6 Viabilité d’une condition d’ordonnançabilité 25
– le facteur d’utilisation des tâches : dans certains cas le facteur d’utilisation
des tâches permet de conclure si un ensemble de tâches est ordonnançable
ou non,
– le pire temps de réponse : le pire temps de réponse d’une tâches est calculé
puis comparé à son échéance. Si une tâche a un pire temps de réponse
inférieur ou égal à son échéance relative alors elle est ordonnançable;
– le temps de demande processeur : c’est le temps requis par le processeur
pour exécuter un ensemble de tâches activées puis terminées dans un intervalle
donné. Si ce temps est inférieur à la longueur de l’intervalle considéré
alors les tâches activées dans cet intervalle sont faisables. Sinon les tâches
ne sont pas faisables.
1.5.3.2 Approche par simulation
L’approche par simulation revient à faire l’analyse temporelle de l’exécution
des tâches temps réel. Lorsque les tâches sont périodiques, cette exécution dure
indéfiniment. Il suffit alors de faire l’analyse temporelle sur un intervalle fini appelé
intervalle d’étude de l’ordonnancement [LM80, Goo99]. Ainsi si toutes les
tâches respectent leurs contraintes sur cet intervalle alors le système de tâches est
ordonnançable.
1.6 Viabilité d’une condition d’ordonnançabilité
Une condition d’ordonnançabilité est dite viable (“sustainable”) si l’ordonnancement
trouvé grace à cette condition d’ordonnançabilité reste valide lors de
l’exécution quand intervient un changement intuitivement positif c’est-à-dire par
exemple la dimunition de la durée d’exécution d’une tâche, l’augmentation de la
période d’une tâche ou de l’échéance relative, etc.
Dans ce travail, on suppose que les périodes et les échéances ne seront pas
modifiées. Donc nous considérons qu’une condition d’ordonnançabilité est viable
(“sustainable”) lorsque l’ordonnancement qu’elle trouve reste valide même si la
durée d’exécution d’une tâche diminue lors de son exécution.
1.7 Ordonnanceur
Un ordonnanceur temps réel est un programme temps réel chargé d’allouer
une ou des tâche(s) à ordonnancer au(x) processeur(s). Il est invoqué à certains
instants. Et ceci suivant un algorithme ordonnancement donné de tel sorte que
toutes les tâches respectent leurs contraintes temps réel.26 Concepts de base
1.7.1 Invocation de l’ordonnanceur
Il existe plusieurs manières d’invoquer un ordonnanceur :
– invocation guidée par les évènements (Event-Trigger ET) [CMTN08] : l’ordonnanceur
est invoqué sur réception d’un évènement tel que l’activation
d’une tâche, la libération d’une ressource (processeur, périphériques d’entrées
et de sorties, etc.), la fin d’exécution d’une tâche. Ce mode d’invocation
est utilisé dans l’ordonnancement en ligne qui prend les décisions
d’ordonnancement en fonction des évènements qui se produisent lors de
l’exécution des tâches;
– invocation guidée par le temps (Time-Trigger TT) [Kop98] : les invocations
sont indépendantes des évènements. Les dates d’invocation de l’ordonnanceur
sont fixées avant l’exécution des tâches et sont généralement
périodiques. Cela définit des tranches de temps (slot) pendant lesquelles
on peut effectuer un traitement, alors que dans les approches dirigées par
les évènements (Event-Trigger) le traitement est directement activé par un
événement. Ce mode d’invocation de l’ordonnanceur est utilisé dans l’ordonnancement
hors ligne où toutes les décisions d’ordonnancement ont été
prises hors ligne.
1.7.2 États et gestion des tâches
Le partage du ou des processeur(s) et des ressources introduit plusieurs états
pour une tâche :
– Inactif : la tâche n’est pas encore activée,
– Prêt : la tâche est activée et elle dispose de toutes les ressources dont elle a
besoin pour s’exécuter,
– Bloqué : la tâche est en attente de ressources,
– Exécution : la tâche s’exécute,
– Passif : la tâche n’a pas de requête en cours, elle a fini son exécution.
L’ordonnanceur est chargé d’assurer la transition d’une tâche d’un état à un
autre. À chaque invocation, l’ordonnanceur met à jour la liste des tâches prêtes
en y ajoutant toutes les tâches activées et qui disposent de leurs ressources et en
supprimant les tâches qui ont fini leurs exécutions ou qui sont bloquées par l’attente
d’une ressource. Ensuite parmi les tâches prêtes, l’ordonnanceur sélectionne
la tâche la plus prioritaire pour s’exécuter. Ainsi, une tâche dans l’état inactif peut
passer à l’état prêt. Une tâche à l’état prêt peut passer à l’état exécution ou à l’état
bloqué. Une tâche à l’état exécution peut revenir à l’état prêt si elle est préemptée
par une autre tâche plus prioritaire, elle peut passer à l’état bloqué si elle attend la1.8 Conclusion 27
libération d’une ressource ou si elle a fini son exécution, elle passe à l’état passif.
Une tâche peut passer de l’état bloqué à l’état prêt. Et enfin une tâche peut passer
de l’état passif à l’état prêt. La figure 1.5 donne une illustration des différents
états et leurs transitions.
ré-activation
blocage
activation
Bloqué Exécution
P assif
Inactif
P rêt
sélection
préemption
terminaison
déblocage
FIGURE 1.5 – États et transitions d’une tâche
1.8 Conclusion
Dans ce chapitre nous avons présenté les concepts de base de l’ordonnancement
temps réel que nous aurons à utiliser dans la suite de cette thèse. Dans le
chapitre qui suit nous allons présenter un état de l’art l’ordonnancement temps
réel.28 Concepts de baseChapitre 2
État de l’art
Après avoir défini les concepts de base de l’ordonnancement temps réel, nous
présentons dans ce chapitre un état de l’art de l’ordonnancement temps réel monoprocesseur
et multiprocesseur.
2.1 Ordonnancement monoprocesseur
2.1.1 Priorités fixes
2.1.1.1 Priorités fixes aux tâches
Une priorité fixe aux tâches est une priorité qui ne varie pas au cours de l’exé-
cution de la tâche. Les algorithmes d’ordonnancement à priorités fixes aux tâche
les plus utilisés sont “Rate Monotonic” et “Deadline Monotonic”.
Rate Monotonic (RM)
L’algorithme d’ordonnancement RM a été introduit par Liu et Layland en 1973
[LL73]. C’est un algorithme d’ordonnancement préemptif qui s’applique à des
tâches périodiques indépendantes, et à échéance sur requête (Ti = Di). La priorité
d’une tâche est inversement proportionelle à sa période, c’est-à-dire que plus
la période d’une tâche est petite, plus sa priorité est grande. Cet algorithme est optimal
dans la classe des algorithmes à priorités fixes pour les tâches indépendantes
préemptibles à échéance sur requête non conrètes ou synchrones. Une condition
suffisante d’ordonnançabilité de l’algorithme d’ordonnancement RM [LL73] pour
un ensemble de tâches périodiques Γn à échéance sur requête est donnée par :
Xn
i=1
Ci
Ti
≤ n(2 1
n − 1)30 État de l’art
Deadline Monotonic (DM)
L’algorithme d’ordonnancement DM a été introduit par Leung et Whitehead en
1982 [LW82] pour des tâches à échéance sur contrainte. La priorité d’une tâche est
inversement proportionelle à son échéance relative, c’est-à-dire que plus l’échéance
relative d’une tâche est petite, plus sa priorité est grande. Cet algorithme est optimal
dans la classe des algorithmes préemptif à priorités fixes pour les tâches
indépendantes préemptibles à échéance contrainte (Di ≤ Ti). La condition suffi-
sante d’ordonnançabilité de l’algorithme d’ordonnancement DM [LW82] pour un
ensemble de tâches périodiques Γn à échéance sur contrainte est donnée par :
∀τi ∈ Γn, Ci +
X
j∈hp(τi)
⌈
Di
Tj
⌉.Ci ≤ Di
avec hp(τi) est l’ensemble de tâches de Γn de priorités supérieures ou égales
à celle de τi
, n’incluant pas τi
.
Analyse du temps de réponse
Le temps de réponse des tâches peut être utilisé pour faire l’analyse d’ordonnançabilité.
Ainsi Joseph and Pandya [JP86] ont proposé une condition d’ordonnançabilité
nécessaire et suffisante basée sur le calcul du pire temps réponse. Si
Γn, un ensemble de tâches, est ordonnancé par un algorithme à priorités fixes aux
tâches, le pire temps de réponse de τi ∈ Γn est donné par le plus petit point fixe
(supérieur à Ci) de :
Ri = Ci +
X
j∈hp(τi)
⌈
Ri
Ti
⌉.Ci (2.1)
avec hp(τi) est l’ensemble de tâches de Γn de priorités supérieures ou égales à
celle de τi
. Déterminer la valeur de Ri pour τi est équivalent à résoudre le point
fixe 2.1. Ainsi dans le cas des échéances contraintes, Γn est ordonnançable par
l’ordonnancement à priorités fixes aux tâches si et seulement si :
∀τi ∈ Γn, Ri ≤ Di
2.1.1.2 Priorités fixes aux instances
Une priorité fixe au niveau des instances est une priorité qui ne varie pas au
cours de l’exécution des instances. L’algorithme d’ordonnancement à priorités
fixes aux instances le plus utilisé est “Earliest Deadline First”.2.2 Ordonnancement multiprocesseur 31
Earliest Deadline First (EDF)
L’algorithme d’ordonnancement EDF a été introduit par Lui et Layland en
1973 [LL73]. C’est un algorithme d’ordonnancement qui peut être préemptif ou
non préemptif et qui s’applique à des tâches périodiques indépendantes à échéance
sur requête (Ti = Di). La plus grande priorité à la date t est allouée à la tâche dont
l’échéance absolue est la plus proche. EDF est optimal pour les tâches indépendantes
préemptibles. Une condition d’ordonnançabilité nécessaire et suffisante de
EDF pour un ensemble de tâches périodiques à échéance sur requête noté Γn est
donnée par :
∀τi ∈ Γn,
Xn
i=1
Ci
Ti
≤ 1
2.1.2 Priorités dynamiques
Une priorité dynamique varie durant l’exécution d’une instance. L’algorithme
d’ordonnancement à priorités dynamiques le plus utilisé est “Least laxity Fisrt”.
Least-Laxity First(LLF)
L’algorithme d’ordonnancement LLF se base sur la laxité. La tâche dont la
laxité est la plus faible comparée à toutes les tâches prêtes aura la plus grande
priorité [Mok83]. Cet algorithme est optimal pour les tâches indépendantes pré-
emptibles. D’après [CDKM00], la condition d’ordonnançabilité de LLF et celle
de EDF sont les mêmes. c’est-à-dire que la condition d’ordonnançabilité nécessaire
et suffisante de LLF pour un ensemble de tâches périodiques à échéance sur
requête Γn est donnée par :
∀τi ∈ Γn,
Xn
i=1
Ci
Ti
≤ 1
Lorsque plusieurs tâches possèdent la même laxité, l’algorithme LLF a l’inconvénient
d’engendrer un grand nombre de préemption ce qui explique qu’il soit
aussi peu utilisé dans le cas monoprocesseur [Bim07].
2.2 Ordonnancement multiprocesseur
2.2.1 Architecture multiprocesseur
Une architecture multiprocesseur est composée de plusieurs processeurs. Plusieurs
tâches peuvent s’exécuter en parallèle sur les différents processeurs. Une32 État de l’art
architecture multiprocesseurs peut être composée de :
– processeurs identiques : processeurs qui ont la même puissance de calcul,
– processeurs uniforme : chaque processeur est caractérisé par sa puissance
de calcul (nombre d’instructions traitées par seconde), avec l’interprétation
suivante : lorsqu’un travail (instance d’une tâche) s’exécute sur un processeur
de puissance de calcul s pendant t unités de temps, il réalise s × t
instructions sur ce processeur. La vitesse de progression d’un travail varie
d’un processeur à un autre;
– processeurs indépendants : un taux d’exécution ri,j est associé à chaque
couple de travail-processeur (τ
k
i
, pj ), avec l’interprétation suivante : si le
travail τ
k
i
s’exécute sur pj pendant t unités de temps alors τ
k
i
réalise ri,j × t
instructions. La vitesse de progression sur un processeur varie d’un travail
à un autre.
Selon le type de mémoire nous pouvons distinguer :
– une architecture multiprocesseur parallèle : les processeurs ont une mémoire
partagée par le bais de laquelle ils communiquent,
– une architecture multiprocesseur distribuée : chaque processeur à sa propre
mémoire et les communications inter-processeurs se font par envoi/réception
de messages.
2.2.2 Stratégies d’ordonnancement
Considérons un ensemble de n tâches temps réel indépendantes préemptibles
à échéances sur requètes noté Γn et une architecture multiprocesseur composée
de m processeurs. Un algorithme d’ordonnancement multiprocesseur détermine
pour chaque tâche, le processeur sur lequel cette tâche doit s’exécuter (problème
d’allocation) et sur chaque processeur, la date et l’ordre de démarrage d’exécution
des tâches (problème d’ordonnancement).
Dans l’ordonnancement temps réel multiprocesseur nous distinguons deux
cas :
– nombre de processeurs non fixé [DL78, OS93, OS95], donc nous pouvons
utiliser autant de processeurs que nécessaire pour l’ordonnancement,
– nombre de processeurs fixé [OB98, BLOS95], donc impossible de dépasser
ce nombre.
Dans le premier cas nous n’avons pas besoins de faire une analyse d’ordonnançabilité
car le système de tâches à ordonnancer sera toujours ordonnançable
(il suffit de prendre un processeur par tâche). Par contre dans le cas où le nombre
de processeurs est fixé il peut arriver que le système ne soit pas ordonnançable, ce2.2 Ordonnancement multiprocesseur 33
qui nécessite une étude d’ordonnançabilité.
L’ordonnancement temps réel multiprocesseur peut être effectué en utilisant
la stratégie d’ordonnancement par partitionnement ou la stratégie d’ordonnancement
globale. Il existe aussi une stratégie d’ordonnancement hybride dite de
semi-partitionnement obtenue par combinaison de la stratégie globale et par partitionnement.
Dans la suite de ce documents nous limiterons à utiliser le terme stratégie par
partitionnement pour désigner la stratégie d’ordonnancement par partitionnement
(respectivement stratégie globale pour désigner stratégie d’ordonnancement global).
2.2.2.1 Stratégie par partitionnement
La stratégie par partitionnement [Goo07, DB09, ZA05, AJ] consiste à partitionner
l’ensemble des n tâches en m sous-ensembles disjoints (Γ
1
, Γ
2
, · · · ,
Γ
m tels que ∪
m
i=1Γ
i=Γn et m étant le nombre de processeurs) puis d’ordonnancer
chaque sous-ensemble de tâches Γ
i
sur un processeur pj avec une stratégie
d’ordonnancement “locale” monoprocesseur. Il y a un ordonnanceur par processeur.
Les tâches allouées aux processeurs ne sont pas autorisées à migrer d’un
processeur à l’autre, la préemption ne peut entraîner de migration. La stratégie par
partitionnement a l’avantage de ramener le problème d’ordonnancement multiprocesseur
en plusieurs problèmes d’ordonnancement monoprocesseur pour lesquels
il existe de très nombreuses solutions dans la littérature. Cependant le partitionnement
des tâches est NP-difficile [GJ79] car équivalent au problème de “Bin
Packing” [CGMV98] qui consiste à ranger un ensemble d’objets de tailles diffé-
rentes dans un nombre minimum de boîtes de tailles identiques.
Les travaux sur l’ordonnancement temps réel multiprocesseur avec un nombre
de processeurs non fixé qui utilisent la stratégie de partitionnement ont principalement
comme objectif de minimiser le nombre de processeurs nécessaires à
l’ordonnancement. Parmi ces travaux nous avons :
– dans la famille des algorithmes d’ordonnancement à priorités fixes aux tâches,
Dhall et Liu [DL78], sont les premiers à proposer deux algorithmes pré-
emptifs avec des tâches indépendantes et périodiques utilisant les heuristiques
de “Bin Packing” (voir 2.3.2.2.1 ) sur processeurs identiques: RateMonotonic-Next-Fit
(RM-NF) et Rate-Monotonic-First-Fit (RM-FF). Ces
deux algorithmes d’ordonnancement multiprocesseur utilisent Rate Monotonic
pour l’ordonnancement des tâches sur chaque processeur et les heuristiques
respectivement “next-fit” et “first-fit” comme heuristiques d’allo-34 État de l’art
cation des tâches aux processeurs. Dans RM-NF et RM-FF les tâches sont
triées dans l’ordre croissant de leurs périodes avant le début de l’allocation.
Oh et Son ont repris dans [OS93] ces deux algorithmes d’ordonnancement
pour corriger une erreur sur l’évaluation des performances et présentent
RM-BF utilisant la méthode d’allocation “best-fit”;
– dans [DD86, OS95] est proposé l’algorithme RM First-Fit Decreasing Utilisation
Factor (RM-FFDUF), un algorithme similaire à “first-fit” où les
tâches sont triées dans l’ordre décroissant de leurs facteurs d’utilisation
avant l’allocation;
– deux autres algorithmes à priorités fixes aux tâches sont proposés dans
[BLOS95]. Ce sont le RM-Small-Tasks (RM-ST) et RM-General-Tasks (RMGT).
Le premier algorithme RM-ST alloue les tâches aux processeurs avec
l’heuristique “next-fit”, mais partitionne les tâches de telle sorte que β (dé-
fini dans le théorème 5 [BLOS95]) ait la plus petite valeur possible. Le
deuxième algorithme RM-GT partitionne l’ensemble des tâches en deux
groupes selon le critère défini dans [BLOS95], ensuite sur les tâches du premier
groupe RM-ST est appliqué, et sur le second groupe de tâches “first-fit”
est appliqué, avec la condition d’ordonnançabilité définie dans [LSD89];
– dans le cas des algorithmes d’ordonnancement préemptifs à priorités fixes
aux instances, Lopez et al. dans [LDG04] présentent EDF-NF,EDF-FF et
EDF-WF, des algorithmes d’ordonnancement multiprocesseur utilisant EDF
pour l’ordonnancement et les heuristiques de “bin packing” pour l’allocation
des tâches.
Au lieu de considérer un nombre infini de processeurs disponibles, d’autres
travaux fixent ce nombre et cherchent des conditions d’ordonnançabité pour le
système de tâches. Parmi ces travaux :
– Oh et Baker [OB98] montrent qu’en appliquant “first-fit” sous RM on peut
ordonnancer n’importe quel ensemble de tâches Γ sur m ≥ 2 processeurs
identiques. Dans ce même article ils ont démontré qu’avec un algorithme
d’ordonnancement multiprocesseur préemptif à priorités fixes aux tâches,
le pire facteur d’utilisation des m processeurs noté Umin est borné par :
m(21/2 − 1) < Umin ≤ (m + 1)/(1 + 2(m+1))
m étant le nombre de processeurs. Le pire facteur d’utilisation des processeurs
Umin est défini tel que si Un =
Pn
i=1
Ci
Ti
≤ Umin alors le système
constitué des n tâches est ordonnançable sur les m processeurs;
– dans [LDG03] Lopez et al. ont amélioré la borne du facteur d’utilisation
définie dans [OB98] et l’ont montrée égale à :
URM−F F (n, m) = (m −1)(2(1/2−1)) + (n− m + 1)(21/(n−m+1) −1) (2.2)2.2 Ordonnancement multiprocesseur 35
Ce résultat est particulièrement intéressant dans le cas ou le nombre de processeurs
est petit. Si les facteurs d’utilisation des tâches sont plus petits
qu’un nombre α alors URM−F F est donné par :
URM−F F (n, m, α) = (m−1)(21/(β+1)−1)β+(n−β(m−1))(21/(n−β(m−1))−1)
(2.3)
Où β = ⌊1/log2(α + 1)⌋. En remplaçant α par 1 dans 2.3 on retrouve 2.2;
– Buchard et Liebeher dans [BLOS95] ont calculé les bornes maximales des
facteurs d’utilisation des algorithmes RM-ST et RM-GT. Avec un système
de m ≥ 2 processeurs, URM−ST = (m − 2)(1 − α) + 1 − ln2, α étant
le facteur d’utilisation maximal de l’ensemble des n tâches. Donc l’algorithme
RM-ST trouve un partitionnement possible sur un ensemble de m
processeurs si la somme des facteurs d’utilisation des tâches périodiques
notée Un reste inférieure à URM−ST . Avec RM-GT le résultat est différent,
URM−GT est donné par URM−GT = 0.5(m − 1.42) et ne dépend pas de α
et si Un ≤ URM−GT alors le systèmes de tâches est ordonnançable. Dans
[LGD04] est récapitulé le calcul des bornes maximales et minimales des
facteurs d’utilisation permettant de garantir les conditions d’ordonnançabilité
d’un ensemble de n tâches sur m processeurs avec RM;
– concernant les algorithmes à priorités fixes aux instances, il existe des algorithmes
préemptifs basés sur EDF qui fournissent des conditions d’ordonnançabilité
utilisant le facteur d’utilisation des processeurs : EDF-FF et
EDF-BF dans [LGDG00] avec UEDF −F F = UEDF −BF =
βEDF m+1
βEDF +1 (avec
βEDF = ⌊
1
α
⌋ et α représentant le facteur d’utilisation maximal des tâches );
– dans [ESHA94, ESHA90], les algorithmes génétiques sont utilisés pour ré-
soudre le problème d’ordonnancement avec des contraintes de précédences.
2.2.2.2 Stratégie globale
Une stratégie gloable applique globalement un algorithme d’ordonnancement
sur l’ensemble de l’architecture multiprocesseur [Goo07, DB09, ZA05]. Toutes
les tâches sont dans la même queue des tâches prêtes qui est partagée par l’ensemble
des processeurs. Dans cette queue les m tâches les plus prioritaires sont
sélectionnées pour être exécutées sur les m processeurs, par exemple en utilisant
globalement RM, EDF, etc. Pour ces stratégies globales outre la préemption des
tâches, les migrations de ces dernières sont autorisées. Une tâche peut commencer
son exécution sur un processeur (soit pj ), être préemptée par l’arrivée d’une
nouvelle tâche plus prioritaire et reprendre son exécution sur un autre processeur
(disons pj
′, j′ 6= j). Dans la stratégie globale, nous avons un seul ordonnanceur et
préempter une tâches revient éventuellement à la faire migrer vers un autre processeur.
C’est ce phénomène de migration de tâches qui caractérise la stratégie36 État de l’art
globale.
L’avantage de la stratégie d’ordonnancement globale est de permettre une
meilleure utilisation des processeurs. Son inconvénient est que le coût de migration
des tâches est non négligeable. Parmi les travaux basés sur la stratégie globale
notons :
– pour les tâches indépendantes, préemptives et périodiques, il existe plusieurs
algorithmes d’ordonnancement à priorités fixes aux instances [SB02,
Bar04, BG03, GFB03] ou fixes aux tâches [ABJ01, RM00] qui reposent
sur la stratégie globale. Dans [SB02] est présenté l’algorithme EDF-US sur
m processeurs identiques (avec des tâches indépendantes et périodiques)
avec comme condition d’ordonnançabilité Un ≤ m2/(2m − 1), Un est la
somme des facteurs d’utilisation des tâches à ordonnancer. Cet algorithme
est une modification de EDF en choisissant les priorités des tâches selon
la règle suivante : si ui > m/(2m − 1) alors aux “jobs” de la tâche τi est
allouée la plus haute priorité, sinon si ui ≤ m/(2m − 1) on applique EDF.
Goossens et al. [GFB03] ont donné la condition suffisante d’ordonnaçabilité
avec EDF pour des tâches périodiques à échéances sur requête, suivante: si
Un ≤ m(1 − α) + α, α = max(ui), 1 ≤ i ≤ n alors le système de tâches Γ
est ordonnançable sur les m processeurs.
– un algorithme à priorités fixes aux tâches RM-US similaire à EDF-US est
présenté dans [ABJ01] avec Umin = m2/(3m − 2). Des algorithmes d’ordonnancement
préemptifs à priorités fixes aux instances avec des tâches
sporadiques sont présentés dans [BG08, AB08, Bar07, BB08]. Dans [Bak03]
nous avons un algorithme à priorités fixes aux tâches avec Deadline Monotonic
qui donne le résultat suivant : avec des tâches périodiques et m ≥
2 processeurs, la condition suffisante d’ordonnançabilité est donnée par:
Un ≤
m
2
(1 − α)α.
– dans [AJ03] nous avons des algorithmes d’ordonnancement basés sur la notion
d’équité proportionnée (proportionate fairness). Ces algorithmes dits
“pfair” diffèrent des algorithmes d’ordonnancement classiques dans la mesure
où il est requis avec ces algorithmes que les tâches s’exécutent à un
taux régulier (quasi constant) en divisant une tâche en série de sous-tâches.
Ces sous-tâches doivent s’exécuter dans des intervalles de tailles identiques
appelés fenêtre.
Il faut noter que les stratégies globales et par partitionnement ne sont pas comparables
d’après Leung et Whitehead [LW82]. Ils ont montré que pour les algorithmes
d’ordonnancement à priorités fixes : i) il y a des systèmes de tâches pé-
riodiques qui sont ordonnançables en utilisant m processeurs identiques à l’aide
d’une approche partitionnée mais pour lesquels aucune stratégie globale existe2.3 Allocation des tâches temps réel dans l’ordonnancement multiprocesseur 37
pour les ordonnancer, ii) il y a des systèmes de tâches périodiques ordonnan-
çables avec une approche globale en utilisant m processeurs mais pour lesquels
aucun partitionnement de m sous-ensembles ordonnançables existe.
2.2.2.3 Stratégie par semi-partitionnement
Elle est obtenue par combinaison de la stratégie par partitionnement et de la
stratégie globale. Chaque tâche est allouée à un processeur pour toute son exé-
cution, cependant si une tâche ne peut s’exécuter entièrement sur aucun processeur,
son exécution est partagée sur deux ou plusieurs processeurs dont la
charge maximale n’est pas atteinte (les migrations sont autorisées pour ce type
de tâches). Différents types d’algorithmes de semi-partitionnement sont présentés
dans [KY08, AT06, KY07]. Cette approche permet de minimiser les migrations
de tâches.
2.3 Allocation des tâches temps réel dans l’ordonnancement
multiprocesseur
Les termes allocation, distribution, partitionnement ou assignation des tâches
sont équivalents dans le vocabulaire de l’ordonnancement temps réel multiprocesseur.
Dans la suite on utilisera le terme allocation. Allouer une tâche à un processeur
signifie l’exécuter sur un processeur de façon à ce que cette tâche et toutes les
autres tâches, qui sont déjà allouées à ce même processeur, soient ordonnançables
selon une condition d’ordonnançabilité qui est précisée. L’allocation d’une tâche
à un processeur se faisant en fonction d’un critère, le problème à résoudre est un
problème d’optimisation. Le critère d’optimisation peut être le nombre de processeurs,
le facteur d’utilisation, la latence, etc. Dans cette partie nous étudions
les différentes méthodes existantes dans la résolution du problème d’allocation
des tâches temps réel. Nous distinguons deux grandes catégories de méthodes de
résolution : celles qui sont dites exactes et les méthodes approchées.
2.3.1 Méthodes exactes
Une méthode exacte est une méthode qui cherche, en parcourant toutes les allocations
possibles, une solution (l’ordonnancement où toutes les contraintes sont
respectées), si jamais celle-ci existe. Par ailleurs si cette méthode ne trouve pas
de solutions, on en déduit que le problème n’a pas de solution. Et puisque le problème
d’allocation inclut une optimisation, la solution trouvée par une méthode
exacte est la meilleure solution possible dite optimale.38 État de l’art
2.3.1.1 Branch & Bound
L’algorithme de “Branch and Bound” (B&B) (séparation et évaluation) [CY90,
Tal09] est basé sur l’énumération de toutes les solutions du problème d’optimisation.
L’espace de recherche est exploré dynamiquement en construisant un arbre
dont la racine représente le problème à résoudre avec son espace de recherche
associé. Les feuilles de l’arbre sont les solutions potentielles au problème et les
noeuds internes les solutions partielles (en ordonnancement c’est une solution ne
contenant pas toutes les tâches). La solution optimale est la meilleure parmi les solutions
potentielles. La construction et l’exploration de cet arbre se font à l’aide de
deux opérations : la séparation et l’évaluation des solutions partielles. L’opération
de séparation détermine l’ordre de parcours de l’espace des solutions partielles
(parcours en profondeur, en largeur, etc.). L’évaluation des solutions partielles se
fait à l’aide d’une fonction coût qui permet d’exclure ou de garder une solution
partielle. La performance d’un algorithme de B&B dépend non seulement de la
méthode de séparation des solutions partielles mais aussi de la fonction de coût
utilisée pour évaluer ces solutions.
L’algorithme de B&B est utilisé dans de nombreux travaux d’ordonnancement
temps réel multiprocesseur comme dans [CY90, Xu93, PSA97].
2.3.1.2 Branch & Cut
L’algorithme de “Branch and Cut” [Mit02] utilise aussi un arbre pour repré-
senter l’espace des solutions mais toutes les solutions ne sont pas énumérées. En
effet pour chaque tâche candidate à l’ordonnancement, l’algorithme teste son ordonnançabilité
sur chaque processeur puis à l’aide d’une fonction de coût il sé-
lectionne le meilleur processeur pour la tâche sélectionnée. Si la tâche τi n’est
ordonnançable sur aucun processeur alors l’algorithme de “Branch and Cut” fait
un retour-arrière (“backtrack”), il revient à la tâche τi−1 qui a été ordonnancée
juste avant et il lui cherche un autre processeur. Si aucun processeur n’est trouvé
pour ordonnancer la tâche τi−1 alors l’algorithme B&C fait un deuxième retourarrière.
Tant qu’une tâche reste non allouée, ces retour-arrières sont itérés jusqu’à
la première tâche qui a été allouée pour lui chercher un autre processeur. Ce qui
permet de trouver une allocation possible si toutefois elle existe.
2.3.1.3 Programmation par contraintes
La programmation par contrainte (PPC) [Ben06, Hla04] est utilisée pour ré-
soudre plusieurs types de problèmes tels que la planification, l’ordonnancement,
etc. Dans la PPC, le problème est modélisé à l’aide de variables de décisions et
de contraintes, où une contrainte est une relation entre une ou plusieurs variables2.3 Allocation des tâches temps réel dans l’ordonnancement multiprocesseur 39
qui limite les valeurs que peuvent prendre simultanément chacune des variables
qui est liée à cette contrainte. Un domaine est associé à chaque variable et celuici
est constitué de l’ensemble des valeurs pouvant être affectées à cette variable.
Lorsque le domaine d’une variable est réduit à une valeur, on dit que la variable
est instanciée. Un ensemble de variables instanciées est une instanciation. Une
solution au problème est alors définie comme une instanciation des variables qui
satisfait la conjonction de toutes les contraintes.
Les algorithmes de recherche de solutions en PPC s’appuient généralement sur
la propagation de contraintes pour réduire l’espace de recherche de solutions. La
propagation de contraintes est le mécanisme qui consiste à déduire de nouvelles
contraintes à chaque fois qu’un domaine de variable est modifié. Les algorithmes
de recherche de solutions garantissent de trouver une solution, si toutefois elle
existe, sinon ils peuvent prouver qu’il n’existe pas une solution qui satisfait toutes
les contraintes.
Cette technique de programmation par contraintes a été utilisée dans plusieurs
travaux [Hla04, PEHDN08, EJ00, CA95] pour résoudre le problème d’ordonnancement
temps réel multiprocesseur.
2.3.1.4 Programmation linéaire
La programmation linéaire (PL) [Van96, DT03] permet de résoudre les problèmes
d’optimisation dont la fonction objective et les contraintes sont linéaires.
C’est un domaine central dans l’optimisation car les problèmes de programmation
linéaire sont les problèmes d’optimisation les plus faciles (toutes les contraintes y
sont linéaires). Dans un problème de PL, il est toujours question de minimiser ou
de maximiser une fonction objectif exprimée à l’aide de variables de décisions.
Les solutions à trouver doivent être représentées par des variables réelles. S’il est
nécessaire d’utiliser des variables discrètes dans la modélisation, on parle de programmation
linéaire en nombre entiers (PLNE). Un problème de PLNE est un
problème de PL dans lequel on ajoute la contrainte supplémentaire que certaines
variables ne peuvent prendre que des valeurs entières. La programmation linéaire
mixte (PLM), permet de traiter des problèmes dans lesquels les variables sont
mixtes (entières et réelles) [She11].
Dans [Sub05] est présenté une formulation sous la forme de PLNE pour le
problème d’ordonnancement des tâches temps réel dépendantes dans un système
multiprocesseur homogène.40 État de l’art
2.3.1.5 Programmation dynamique
La programmation dynamique [Sar84] est basée sur la division récursive d’un
problème en plusieurs sous-problèmes plus simples. Elle applique le principe de
l’optimalité formulée par R. Bellman qui est le suivant : “Dans une séquence optimale
de décisions, quelle que soit la première décision prise, les décisions subséquentes
forment une sous-séquence optimale, compte tenu des résultats de la
première décision”. Ce principe implique que le problème à étudier puisse être
formulé comme l’évolution d’un système. Il est aussi nécessaire de pouvoir dé-
composer le problème en plusieurs étapes qui permet une grande économie de
calculs.
2.3.1.6 Les Réseaux de flots
Un réseau de flots [FJF62] est un graphe dont chaque arc a une capacité et
reçoit une quantité de flots. Le flot reçu par un arc ne doit pas dépasser la capacité
de l’arc. Dans un réseau de flots la quantité de flots entrant par un sommet doit
être égale à la quantité de flot qui ressort par ce même sommet, à l’exception du
sommet source qui n’a pas d’arcs entrants et de sommet puits qui n’a pas d’arcs
sortants. Il est également possible d’avoir plusieurs sources et puits dans un réseau
de flots et d’associer un coût à chaque arc correspondant au coût d’utilisation de
cet arc.
Dans les réseaux de flots, le problème du minimum k-coupe [FJF62] consiste
à déterminer un ensemble d’arcs du graphe de telle sorte que la suppression de ses
arcs sépare le graphe en exactement k composantes connexes (dans une composante
connexe pour deux sommets il existe au moins un chemin qui les relie) et
chaque composante a au moins un sommet puits ou un sommet source.
En représentant les tâches et les processeurs dans un même graphe comme
un réseau de flots dont les puits et sources sont les processeurs, la solution au
problème du minimum k-coupe permet de résoudre le problème d’allocation des
tâches en considérant que k est le nombre de processeurs disponibles pour l’allocation
des tâches.
Généralement les travaux utilisant les réseaux de flots pour résoudre le problème
d’allocation des tâches ne prennent pas en compte les contraintes temps
réel [Sto77, CHMTE80]. Dans [BF97] un modèle de réseau de flots est présenté
pour l’allocation des tâches temps réel avec respect des contraintes de temps dans
le cas de tâches indépendantes.2.3 Allocation des tâches temps réel dans l’ordonnancement multiprocesseur 41
2.3.2 Méthodes approchées
Les méthodes exactes, bien que produisant des solutions optimales ne sont pas
généralement applicables à cause de leur temps de calcul prohibitif pour des problèmes
réalistes. Les méthodes approchées permettent des donner des solutions
qui dans la plupart des cas ne sont pas optimales, mais ont des temps de calcul acceptables
qui les rendent applicables dans les problèmes de grandes tailles. Nous
distinguons deux catégories de méthodes approchées, les méthodes de recherches
non guidées qui ne dépendent pas du domaine étudié appelées aussi métaheuristiques
et les méthodes guidées ou heuristiques qui dépendent du domaine étudié.
2.3.2.1 Méthodes de recherche non guidées ou métaheuristiques
Ce sont des méthodes d’optimisation globales inspirées de plusieurs domaines
tels que l’intelligence artificielle, la biologie, la sidérurgie, etc. Nous distinguons
celles qui sont basées sur la notion de population de solutions [Tal09, CCH+99]
(ensemble de solutions appelées individus) comme les algorithmes génétiques et
celles qui se basent sur la recherche locale [Tal09, VM05, EL97] comme le recuit
simulé. Dans cette dernière, la solution, déterminée à l’aide d’une fonction de
coût, est remplacée par la meilleure solution située dans son voisinage. Le recuit
simulé et la méthode Tabou font parties de ces métaheuristiques qui utilisent la
recherche locale.
2.3.2.1.1 Recuit simulé
L’algorithme de recuit simulé [Tal09] commence par générer de façon aléatoire
une solution initiale unique. À cette solution initiale sont associées une fonction
d’énergie qui caractérise le système et une température pour permettre à l’algorithme
de passer d’une phase à l’autre où la valeur de l’énergie diminue puis
augmente pour diminuer par la suite jusqu’à l’obtention d’une valeur minimale,
qui correspond à l’optimum global. Cette température est appelée “facteur d’agitation
aléatoire”. En ordonnancement temps réel la fonction d’énergie peut être
une combinaison de plusieurs paramètres tels que le temps de réponse, les coûts
de communications inter-processeurs, etc.
Dans [TBW92, CA95], le recuit simulé est utilisé pour résoudre le problème
d’allocation des tâches temps réel avec des contraintes de précédences et des coûts
de communication inter-processeurs.
2.3.2.1.2 Recherche Tabou42 État de l’art
Un algorithme de recherche Tabou [Tal09, GL93] combine une procédure de
recherche locale avec un certain nombre de règles et de mécanismes lui permettant
de surmonter l’inconvénient des optimums locaux, tout en évitant les problèmes
de cycles (visiter plusieurs fois une solution). En effet il possède une mémoire
(une liste tabou) qui garde les mouvements déjà effectués pour éviter d’y revenir
et d’être piégé dans un cycle qui impliquera la convergence vers un optimum local.
Cela permet d’explorer d’autres espaces de solutions et d’améliorer les solutions.
Les algorithmes de recherche tabou peuvent être utilisés dans la résolution du
problème d’ordonnancement temps réel multiprocesseur avec des contraintes de
précédences et des coûts de communication. [KBKP04, FGLM96].
2.3.2.1.3 Algorithmes génétiques
Les algorithmes génétiques [Tal09] s’inspirent de l’évolution biologique des
espèces en exploitant la sélection et la survie de l’espèce la mieux adaptée. Le
principe des algorithmes génétiques repose sur la sélection des individus qui représentent
les solutions. La reproduction se fait dans le but de générer une autre
population avec de meilleurs individus, en leur transmettant certaines de leur caractéristiques.
Une fonction de coût est utilisée afin d’évaluer les individus et de
sélectionner les meilleurs pour constituer une autre population, à laquelle on appliquera
de nouveau la sélection et la reproduction. Ce processus est réitéré jusqu’à
ce qu’un critère d’arrêt soit atteint. La reproduction des individus est réalisée avec
le croisement et la mutation. Le croisement consiste à couper deux individus en
un point qui peut être choisi aléatoirement et à échanger les parties coupées. La
mutation, quand à elle, modifie les gènes des individus afin de produire d’autres
individus (par exemple en ordonnancement on crée d’autres solution à partir d’une
solution existante en modifiant l’allocation des tâches dans cette solution) [Tal09].
Dans [ESHA94, ESHA90], les algorithmes génétiques sont utilisés pour ré-
soudre le problème d’ordonnancement temps réel multiprocesseur avec des contraintes
de précédences.
2.3.2.2 Méthodes guidées ou heuristiques
Les méthodes d’allocation que nous présentons dans cette partie sont guidées
par le domaine de l’ordonnancement temps réel multiprocesseur. Ce qui justifie
l’utilisation par la suite de la notion de tâche, de processeur, de coûts de communication,
etc. Ces méthodes heuristiques sont basées sur l’évolution d’une solution
partielle (solution qui ne contient pas toutes les tâches à allouer). Bien que2.3 Allocation des tâches temps réel dans l’ordonnancement multiprocesseur 43
ces heuristiques soient plus rapides que les métaheuristiques, à fortiori que les
méthodes exactes, expérimentalement les heuristiques fournissent des solutions
moins proches de l’optimal que les métaheuristiques.
2.3.2.2.1 Heuristiques gloutonnes
Les heuristiques gloutonnes construisent la solution incrémentalement. À chaque
étape de l’heuristique gloutonne une tâche est rajoutée selon un critère glouton,
correspondant à une décision locale déterminant le meilleur choix (à court terme)
[Tal09, VM05]. Chaque choix fait est définitif, ces algorithmes n’autorisent pas
les retour-arrières (“backtracking”). Ainsi, les solutions obtenues sont très dépendantes
de l’ordre de considération des tâches. Les heuristiques gloutonnes donnent
très rapidement des solutions qui sont rarement optimales.
Parmi les heuristiques gloutonnes nous avons les heuristiques utilisées dans la
résolution du problème de remplissage de boîtes (“bin packing”). Par la suite nous
utiliserons la terminologie heuristiques de“bin packing” pour désigner ces types
d’heuristiques.
Dans le problème d’ordonnancement multiprocesseur, chaque tâche est modé-
lisée par un objet et la taille de cet objet est modélisée par le facteur d’utilisation
du processeur par cette tâche. Chaque processeur est modélisé par une boîte de
capacité égale à la charge maximale que l’on peut atteindre sur ce processeur avec
un algorithme d’ordonnancement fixé. Voici quelques heuristiques gloutonnes :
– heuristique “next-fit” :
Étape 1: initialiser le compteur des tâches i=1
Étape 2: initialiser le compteur des processeurs j=1
Étape 3: Si τi est ordonnançable sur pj (selon Liu et Layland [LL73] par
exemple) alors allouer τi à pj
; Sinon j = j + 1 et allouer τi à pj
Étape 4: Si i < n alors i = i + 1 et reprendre à partir de l’étape 3, sinon fin
et système ordonnançable avec j processeurs;
– heuristique “first-fit” :
avec “next-fit” si la tâche τi n’est pas ordonnançable sur pj on passe immé-
diatement à pj+1 même si τi est ordonnançable sur l’un des j − 1 processeurs
déjà utilisés. Ce qui a tendance à augmenter le nombre de processeurs.
L’heuristique “first-fit” tente d’abord d’allouer une tâche au processeur, de
plus petit indice j parmi les processeurs déjà utilisés et pouvant l’ordonnancer.
Si cela est impossible on passe à un processeur vide;
– heuristique “best-fit” :44 État de l’art
cette heuristique alloue une tâche au processeur en suivant une fonction
coût f définie pour chaque processeur (par exemple la capacité restante du
processeur). Ainsi une tâche est allouée au processeur de plus petite valeur
de f qui peut l’ordonnancer. Si deux processeurs ont la même valeur de f,
la tâche est allouée au processeur de plus petit indice;
– heuristique de “worst-fit” :
c’est une heuristique similaire à “best-fit”, mais avec “worst-fit”, une tâche
est allouée au processeur ayant la plus grande valeur de la fonction coût f.
Ces heuristiques de type “bin packing”, cherchent uniquement à minimiser le
nombre de processeurs utilisés dans le partitionnement des tâches, à l’exception
de “best-fit” et “worst-fit” avec lesquels nous pouvons optimiser une fonction de
coût définie.
2.3.2.2.2 Heuristiques de listes
Généralement ces méthodes heuristiques utilisent un graphe acyclique orienté
(GAD) pour représenter les dépendances entres les tâches en associant des poids
aux arcs (symbolisant les coûts de communication entre processeurs) qui relient
les sommets (représentant les tâches), ainsi que des poids aux sommets (symbolisant
les durées d’exécution des tâches). Les heuristiques de liste [SS97, ACD74,
MKTM93] définissent une liste de tâches en attribuant à chacune d’elles une priorité.
Cette liste détermine l’ordre du choix d’allocation d’une tâche aux différents
processeurs. À chaque étape de l’heuristique, une tâche est sélectionnée dans la
liste des tâches candidates pour être ordonnancée sur un processeur puis la liste
est mise à jour (suppression de la tâche ordonnancée et ajout des tâches qui n’ont
pas de prédécesseurs dans le graphe des tâches). Ceci est répété jusqu’à ce que la
liste soit vide. Par opposition aux heuristiques gloutonnes, certaines approches des
heuristiques de liste autorisent les retour-arrières [AaR95, Ram90] sur un choix
quand une tâche ne peut pas être allouée à un processeur. Cela a pour consé-
quence d’augmenter considérablement le temps de recherche et selon Adan et al.
[AaR95] et Ramamritham [Ram90] n’améliore pas toujours les résultats. Sans
les retour-arrières les heuristiques de listes sont rapides d’exécution mais, comme
avec toutes les heuristiques, il y a un risque de ne pas trouver une solution alors
qu’il en existe.
2.3.2.2.3 Heuristiques de regroupement ou "clustering"
Les heuristiques de regroupement [CHMTE80, GVY90, KT00] consistent à
regrouper les tâches en différents sous-ensembles appelés “clusters” (groupes)2.4 Ordonnancement de tâches dépendantes 45
en fonction des objectifs du problème (respect des contraintes temps réel, minimisation
des coûts de communication, etc.), les tâches d’un “cluster” devant
être ensuite allouées à un même processeur, ce qui diminue la taille du problème.
La résolution du problème d’allocation par des heuristiques de regroupement est
donc décomposée en deux phases. La première phase constitue le regroupement
proprement dit et la seconde consiste à allouer les tâches sur les processeurs en
fonctions des contraintes temps réel, de précédence entre les tâches, etc. Cette
seconde phase peut être menée, par exemple, par des heuristiques de liste. Les
heuristiques de regroupement ont l’avantage de réduire l’espace de recherche de
solutions en explorant les “clusters” au lieu des tâches elles-mêmes. Par contre
le regroupement des tâches en “clusters” peut engendrer la non satisfaction de
contraintes (temps réel, minimisation du temps de réponse de l’ordonnancement,
etc.).
2.3.2.2.4 Heuristique de duplication de tâches
Ces heuristiques dupliquent les tâches sur les processeurs afin de minimiser
une fonction coût qui peut être le temps de réponse de l’ordonnancement
des tâches. Dans [XTL10] est présentée une heuristique de duplication de tâches
appelée “Heterogeneous Earliest Finish with Duplicator” (HEFD). L’heuristique
HEFD utilise le principe des heuristiques de liste en définissant une liste pour les
tâches candidates à l’ordonnancement. À chaque étape de l’heuristique une tâche
candidate est sélectionnée puis sur chaque processeur la date de démarrage au
plus tôt de la tâche est déterminée par duplication des tâches prédécesseurs immédiats
de cette tâche candidate sur tous les processeurs sur lesquels elles ne sont
pas encore dupliquées. Si la duplication d’une tâche prédécesseur immédiat sur
un processeur entraîne un retard sur la date de démarrage au plus tôt de la tâche
candidate alors cette duplication est supprimée. Ensuite le processeur produisant
la plus petite date de démarrage pour la tâche est sélectionnée pour ordonnancer
la tâche candidate.
2.4 Ordonnancement de tâches dépendantes
Comme nous l’avons vu à la section 1.4.3, une contrainte de dépendance entre
tâches peut être une contrainte de précédence ou une contrainte de dépendances de
données. Dans l’ordonnnancement de tâches avec des contraintes de précédences,
il existe deux approches pour résoudre le problème. La première est basée sur
les sémaphores [FGPR11] : un sémaphore est alloué à chaque précédence (τi
, τj ),
et la tâche successeur τj doit attendre que la tâche prédécesseur τi
libère le sé-
maphore avant de commencer son exécution. La deuxième approche est basées46 État de l’art
sur la modification des priorités et des dates de premières activations des tâches
[CSB90, FBG+10a]. Dans l’ordonnancement des tâches avec des contraintes de
dépendances de données en plus des tenir compte des contraintes de précédences,
il faut gérer le transfert et le partage de données entre tâches.
2.4.1 Transfert de données
Soient τi et τj deux tâches de périodes respectives Ti et Tj
liées par une
contrainte de dépendances de données telle que τi est la tâche productrice et τj
la tâche consommatrice. Dans le cas général le transfert de données entre ces
tâches se fait dans un rapport k relativement à leurs périodes tel que si Ti < Tj
alors Tj = kTi + r, sinon Ti = kTj + r avec k ∈ N
∗
et r ∈ N. Dans le cas où τi a
une période plus petite que τj alors τj consomme k données produites par τi
. Dans
le cas où τi a une période plus grande ou égale à celle de τj alors τj consomme
une ou plusieurs fois la donnée produite par τi
. Si r 6= 0, il peut arriver que la
tâche productrice τi produise k + 1 données avant que la tâche consommatrice τj
ne consomme, sur ces k + 1 données seules les k données sont consommées par
τj et la donnée qui reste est perdue. Ce qui fait qu’au total on perdrait une infinité
de données. Pour illustrer ce cas prenons l’exemple de deux tâches τ1(0, 1, 3, 3) et
τ2(3, 1, 7, 7) telles que τ1 est la tâche productrice de données et τ2 la tâche consommatrice
de données. Nous avons T2 = 7 = 2 ∗ 3 + 1 = 2T1 + 1. Comme le montre
la figure 2.1 ci-dessous, avant que la tâche consommatrice τ2 ne démarre sa 4
ème
exécution, la productrice s’est exécutée trois fois donc a fourni trois données dont
deux seulement sont consommée à la 4
ème exécution de τ2 et la donnée qui reste
est perdue.
Il peut y avoir plusieurs possibilités pour la tâche τj de consommer les données
produites par τi [FBG+10b]. La tâche τj peut consommer la totalité des données
produites par τi ou n’importe quel sous-ensemble des données. Par exemple dans
[RCR01], la tâche τj ne consomme que la dernière donnée produite par τi
. Par
contre dans [Ker09, KS07] toutes les données produites par τi sont consommées
par τj sans qu’aucune données ne soient perdues.
2.4.2 Partage de ressources
Les dépendances de données entraînent des partages de données entre tâches.
Les données produites par les tâches sont sauvegardées dans des mémoires considérées
comme des ressources. Ces mémoires sont partagées entre les tâches productrices
qui écrivent leurs données dans ces mémoires et les tâches consommatrices
qui y lisent des données. Considérons deux taches τi et τj
telles que τi
produit des données que τj consomme. Lorsque τj se fait préempter par τi
, les données
dans la mémoire partagée par ces deux tâches peuvent être dans un état incon-2.4 Ordonnancement de tâches dépendantes 47
0 3 6 9 12 15 18 21 24 27 30 33 36 39 42 45
3 10 17 24 31 38 45
facteur d’utilisation classique :
10/21 = 0.4762
facteur exact permanent d’utilisation :
10/21 = 0.4762
coût exact permanent de la préemption :
0/21 = 0.0000
tâche émission durée PTR période
t1 0 1 1 3
t2 3 1 2 7
priorité : monotone par période (RM)
coût d’une préemption : 0
ORDONNANÇABLE
FIGURE 2.1 – Illustration des pertes de données
sistant car τi risque de modifier les données qui ne seront plus les mêmes à la reprise
de l’exécution de τj
. Donc τi et τj ne doivent pas accéder en même temps à la
mémoire tampon qu’elles partagent. On dit que les deux tâches ont des contraintes
d’exclusions mutuelles [Kai81, SRL90]. Pour traiter ces contraintes d’exclusion
mutuelles, les tâches sont exécutés dans des sections critiques [Kai81]. Une tâche
qui s’exécute en section critique ne pourra pas être préemptée par une autre tâche.
Lorsque la tâche τi
, la plus prioritaire, attend la fin de la section critique de τj pour
pouvoir s’exécuter, on parle d’inversion de priorité [SRL90] et on dit que τi est
bloquée par τj
. Un exemple d’inversion de priorité est présenté à la figue 2.2.
On dit que deux ou plusieurs tâches sont en inter-blocage si chacune des tâches
est bloquée en attente d’une ressource qui est utilisée par une autre tâche parmi
ces tâches [Hav68]. Un exemple d’inter-blocage est présenté à la figure 2.3.
Les section critiques doivent être utilisées convenablement afin d’éviter que
des tâches moins prioritaires bloquent indéfiniment des tâches plus prioritaires48 État de l’art
τ2 = (1, 2, 5, 5)
τ3 = (1, 1, 4, 4)
τ1 = (0.2, 8, 8)
Utilisation de la mémoire buf1
0 1 2 3 4 5 6 7 8 9
1 3 4 2 5 6 7 8
1 2 3 4 5 6 7 8 9
9
t = 1, τ1 est préemptée par τ2
Utilisation de la mémoire buf2
t = 1, τ1 bloque τ3 sur b inversion de priorités
FIGURE 2.2 – Inversion de priorités
Deadlock is formed at t = 3
t = 2, τ1 tentant d’utiliser la mémoire buf2, est préemtée par τ2
3
0 1 3 4 5 6 7
2
2
4 5 6 7
t = 3, τ2 tentant d’utiliser la mémoire buf1, est bloquée parτ1
τ1 = (0, 3, 6, 6)
τ2 = (2, 2, 4, 4)
Utilisation de la mémoire buf2
Utilisation de la mémoire buf1
FIGURE 2.3 – Inter-blocage
mais aussi les inter-blocages. Pour cela plusieurs protocoles de synchronisation
ont été proposés aussi bien en monoprocesseur qu’en multiprocesseur.
2.4.3 Protocoles de synchronisation monoprocesseur
2.4.3.1 Priority Inheritance Protocol (PIP)
Le protocole de synchronisation PIP (Priority Inheritance Protocol) a été proposé
par Sha and al. [SRL90]. Il est basé sur le principe de l’héritage de priorité.2.4 Ordonnancement de tâches dépendantes 49
Pour réduire la durée des inversions de priorités, lorsqu’une tâche τj bloque une
autre tâche τi plus prioritaire qu’elle, τj hérite de la priorité de τi durant toute la
durée de son exécution. Après son exécution τj reprend sa priorité initiale. Ceci
permet d’éviter qu’une tâche de priorité intermédiaire (une tâche plus prioritaire
que τj et moins prioritaire que τi) préempte τj ce qui allongerait le temps de blocage
de τi
. Ce protocole permet de réduire le temps de blocage mais ne permet
pas d’éviter les inter-blocages. Ce protocole est utilisé dans le cas des algorithmes
d’ordonnancement à priorités fixes.
2.4.3.2 Priority Ceiling Protocol (PCP)
Le protocole de synchronisation PCP (Priority Ceiling Protocol) [SRL90] est
une extension de PIP pour éviter les inter-blocages. Il est basé sur le principe de
la priorité plafond . Une priorité plafond est donnée à chaque ressource. Cette
priorité plafond est définie par la plus grande priorité des tâches qui utilisent cette
ressource. À chaque instant t, on définit la priorité du système comme étant la plus
grande priorité plafond parmi les ressources en cours d’utilisation à t. Une tâche
τi ne pourra exécuter sa section critique que lorsque sa priorité est plus grande que
la “priorité du système” qui est égale à la plus grande priorité parmi les priorités
des ressources en cours d’utilisation. Sinon τj continue son exécution et hérite de
la priorité de τi
. Ceci permet d’éviter les inter-blocages.
2.4.3.3 Stack Resource Policy (SRP)
Le protocole SRP (Stack Resource Policy MSRP) [Bak91], est la version de
PCP avec des priorités dynamiques. Chaque instance d’une tâche possède un plafond
de préemption. Une instance de la tâche τi ne pourra préempter une instance
de la tâche τj que lorsque la priorité de l’instance de τi est supérieure au plafond
de préemption de l’instance de la tâche τi
. Chaque ressource a un plafond de pré-
emption qui est le maximum des plafonds de préemption des instances pouvant
utiliser cette ressource. On définit le plafond de préemption du système comme
étant le plus grand plafond de préemption des ressources en cours d’utilisation.
Une tâche τi ne peut exécuter une section critique que lorsque sa priorité est plus
grande que le plafond de préemption de toutes les tâches actives et que son plafond
de préemption est supérieur à celui du système. Les instances actives sont
placées dans une pile dans l’ordre décroissant de leur priorité.50 État de l’art
2.4.4 Protocoles de synchronisation multiprocesseur
2.4.4.1 MPCP
Le protocole MPCP (Multiprocessor Priority Ceiling Protocol) [Raj90] est une
extension en multiprocesseur de PCP. Avec MPCP on distingue deux types de ressources.
Les ressources locales sont partagées entre tâches sur le même processeur
et les ressources globales sont partagées entre tâches allouées sur des processeurs
différents. Chaque ressource globale a une priorité plafond égale à la plus grande
priorité parmi celles des tâches pouvant utiliser cette ressource et la plus grande
priorité du système (la plus grande priorité des ressources en cours d’utilisation
sur les processeurs). Une tâche qui utilise une ressource globale est exécutée à la
priorité de cette ressource. Dans le cas des ressources locales, MPCP fonctionne
de la même manière que PCP.
2.4.4.2 MSRP
Le protocole MSRP (Multiprocessor Stack Resource Policy MSRP) [GLN01]
est une extension en multiprocesseur de SRP. Chaque processeur possède son
propre plafond de préemption. Chaque processeur attribue à une ressource globale
un plafond de préemption supérieur ou égal au plafond de préemption sur ce
processeur. Lorsqu’une tâche utilise une ressource globale sur un processeur, ce
processeur hérite du plafond de priorité de cette ressources globale. Dans le cas
des ressources locales, MSRP fonctionne de la même manière que SRP.
2.5 Ordonnancement avec prise en compte du coût
de l’OS
Le coût du système d’exploitation est composé de deux parties. La première
est appelée coût de l’ordonnanceur. Elle correspond au coût de sauvegarde de
contexte du processeur, au coût de sélection de la tâche à exécuter et au coût de
chargement de la tâche sélectionnée [KAS93]. La seconde partie est appelée coût
de la préemption dû à l’ensemble des préemptions [Yom09]. Le coût d’une pré-
emption correspond au coût de sauvegarde de contexte du processeur, de sélection
de la tâche à exécuter et de restauration de contexte du processeur au moment de
chaque préemption. Les travaux que nous avons présentés jusqu’à présent font
l’hypothèse que le coût de l’OS est négligeable ou est approximé dans le pire
temps d’exécution de chaque tâche.2.5 Ordonnancement avec prise en compte du coût de l’OS 51
2.5.1 Coût de l’ordonnanceur
Le coût de l’ordonnanceur est illustré sur la figure 2.4. Ce coût se décompose
en :
Coût de l’ordonnanceur
τ
k
i
r
k
i r
k
i + Ti
FIGURE 2.4 – Illustration du coût de l’ordonnanceur
– coût de sauvegarde de contexte du processeur,
– coût de sélection de la tâche à exécuter,
– coût de chargement pour exécution de la tâche sélectionnée.
La sauvegarde du contexte de la tâche en cours d’exécution et de chargement
de la tâche sélectionnée ont un coût fixe. Dans le cas d’un ordonnancement en
ligne la sélection d’une tâche s’effectue pendant l’exécution des tâches. Cette sé-
lection de la tâche à exécuter dépend du nombre de tâches dans l’état “Prêt” et
donc son coût varie. Par contre dans le cas d’un ordonnancement hors ligne, la
sélection d’une tâche s’effectue à partir d’une table d’ordonnancement qui a été
déterminée avant l’exécution des tâches. Le coût de sélection est fixe et égal au
coût de lecture dans une table.
Dans la suite comme nous nous intéressons à l’ordonnancement hors ligne,
le coût de l’ordonnanceur devient fixe. Pour le prendre en compte dans l’analyse
d’ordonnançabilité, il suffira de l’ajouter au pire temps d’exécution de chaque
tâche. Dans la suite du manuscrit on expliquera comment prendre en compte le
coût exact de la préemption.
2.5.2 Coût de la préemption
Lorsqu’une tâche se fait préempter par une autre tâche plus prioritaire, son
contexte d’exécution est sauvegardé et celui-ci doit être restauré lors de sa resélection.
Le coût de sauvegarde de contexte est pris en compte dans la durée
d’exécution de la tâche qui préempte plutôt que dans la durée d’exécution de la
tâche préemptée car, le coût de l’ordonnanceur qui est supposé inclus dans la durée
d’exécution des tâches contient aussi la sauvegarde de contexte. Par contre la
restauration du contexte de la tâche préemptée a lieu uniquement lors de sa reprise
d’exécution. Cette restauration du contexte de la tâche préemptée est précédée par52 État de l’art
une sélection de tâche et par une sauvegarde de contexte d’exécution de la tâche
en cours. Cet ensemble de coût de sélection, de sauvegarde de contexte d’exé-
cution de la tâche en cours et de restauration de contexte de la tâche préemptée,
est appelé coût d’une préemption. Ce coût temporel de la préemption rallonge le
temps de réponse de l’exécution de la tâche préemptée et peut causer à son tour
d’autres préemptions pour d’autres tâches moins prioritaires. Cette accumulation
de préemptions peut rendre non ordonnançable un système de tâches qui était initialement
déclaré ordonnançable en négligeant le coût de la préemption. La figure
5.5.2 illustre le coût de la préemption.
Coût d’une préemption
r
k
1
Préemption de τ
k
2
r
k
2
τ
k
2
τ
k
1
r
k
1 + T1
r
k
2 + T2
FIGURE 2.5 – Illustration du coût de la préemption
Pour éviter de prendre en compte le coût de la préemption qui a un impact
sur l’ordonnançabilité, certains travaux proposent de réduire le nombre de pré-
emption [Bur94, WS99, SW00]. Dans [Bur94], un algorithme d’ordonnancement
à priorités fixes et à préemptions différées est proposé. Cet algorithme considère
que chaque exécution ou instance d’une tâche est constituée de plusieurs sousexécutions
et une préemption ne peut avoir lieu qu’entre deux sous-exécutions.
Ceci permet de réduire le nombre de préemptions d’une tâche au cours de son
exécution. Dans [WS99, SW00] un autre algorithme d’ordonnancement avec plafond
de priorité est proposé. Cet algorithme assigne à une tâche deux types de
priorité : un priorité nominale et une priorité plafond. Avec cet algorithme, une
préemption ne peut avoir lieu que lorsque la tâche qui préempte a une priorité
nominale plus grande que la priorité de seuil de la tâche qu’elle veut préempter.
Donc en choisissant comme il faut les priorités de seuil des tâches on peut réduire
le nombre de préemptions. Cependant aucun de ces travaux ne prend en compte
dans l’ordonnancement le coût lié à chaque préemption.
En revanche d’autres travaux ont pris en compte le coût de la préemption.
Dans le modèle de tâche Liu et Layland [LL73] le coût de la préemption est ap-2.6 Conclusion 53
proximé dans le WCET. Cette approximation se fait soit en prenant une marge
faible, ce qui peut rendre un système de tâches non ordonnançables à l’exécution
alors que ce système a été conclu ordonnançable. Ou bien l’approximation
est faite en prenant une marge importante ce qui entraîne le gaspillage de la ressource
processeur. C’est la raison pour laquelle nous devons prendre en compte le
coût exact de la préemption, c’est-à-dire le coût lié à l’occurrence de chaque pré-
emption. A. Burns and al. dans [BTW95] ont essayé de résoudre ce problème en
présentant une analyse d’ordonnançabilité basée sur le temps de réponse qui prend
en compte le coût global lié au nombre maximum de préemptions. Sauf que dans
ce cas on une borne maximum du nombre de préemptions et non pas le nombre
exact. Dans [ERC95], Ripoll and al. se sont eux aussi intéressés au nombre exact
de préemption en faisant l’ordonnancement tâche après tâche et en comptant le
nombre de préemption. Mais ils ne prennent pas en compte les préemption engendrées
par d’autres préemptions car ils n’ajoutent pas le coût lié à l’occurrence de
chaque préemption.
Dans [Yom09] Meumeu et Sorel ont proposé une analyse d’ordonnançabilité
d’un ensemble de tâches indépendantes périodiques qui permet de prendre en
compte le coût exact de la préemption. Cette analyse est basée sur une opération
binaire d’ordonnancement appelée ⊕ qui permet de compter le nombre exact de
préemptions de chaque instance d’une tâche puis ajoute le coût associé à ces pré-
emptions à son WCET ce qui permet d’obtenir une nouvelle durée d’exécution de
la tâche avec prise en compte du coût exact de la préemption. Cette durée appelée
PET (“Préemption Execution Time”) est utilisée dans l’analyse d’ordonnançabilité
des tâches.
Puisque prendre en compte le coût exact de l’ordonnanceur revient à rajouter
son coût fixe dans le WCET de chaque tâche, ceci avant l’exécution des tâches,
on supposera que le coût de l’ordonnanceur est inclus dans le WCET des tâches.
Donc prendre en compte le coût exact de l’OS revient à prendre en compte le coût
exact de la préemption. Donc dans la suite nous concentrerons notre étude sur le
coût exact de la préemption.
2.6 Conclusion
Dans ce chapitre nous avons présenté un état de l’art sur l’ordonnancement
temps réel en mettant l’accent sur les méthodes d’allocation des tâches dans l’ordonnancement
multiprocesseur, sur la prise en compte du coût exact de la pré-
emption et sur les dépendances de données.
Dans la seconde partie de cette thèse nous étudierons l’ordonnancement multiprocesseur
des tâches indépendantes avec prise en compte du coût exact de la
préemption. Pour cela nous réutiliserons les concepts définis dans cet état de l’art.Deuxième partie
Ordonnancement temps réel
multiprocesseur de tâches
indépendantes avec prise en compte
du coût exact de la préemptionChapitre 3
Ordonnancement monoprocesseur
de tâches indépendantes
3.1 Introduction
Comme nous l’avons présenté dans l’état de l’art, la prise en compte du coût
exact de la préemption dans l’analyse d’ordonnançabilité de tâches temps réel est
peu étudiée. Les seuls travaux que nous avons trouvés dans l’état de l’art sont
ceux de Meumeu et Sorel [Yom09] qui ont présenté l’opération d’ordonnancement
⊕ dans le cas de l’ordonnancement monoprocesseur. Ce chapitre donne une
présentation simplifiée de l’opération ⊕. Nous allons aussi dans ce chapitre prouver
la viabilité (“sustainabilty”) de l’analyse d’ordonnançabilité basée sur cette
opération dans le cas d’un ordonnancement à priorités fixes.
3.2 Modèle de tâches
Considérons l’ensemble Γn de tâches temps réel périodiques indépendantes
concrètes. Chaque tâche τi = (r
1
i
, Ci
, Ti
, Di) est caractérisée par une date de première
activation r
1
i
, une pire durée d’exécution Ci n’incluant pas les coûts de
préemption contrairement au modèle classique de Liu et Layland [LL73], une pé-
riode Ti et une échéance relative Di
. Les tâches étant périodiques, la date de la
k
ème activation de τi est donnée par r
k
i = r
k
i + (k − 1)Ti
. La tâche τi doit terminer
son exécution avant la date d
k
i = r
k
i +Di
. Le temps qui s’écoule entre la date d’activation
et la date de fin d’exécution de la k
ème activation de τi désigne le temps
de réponse Rk
i de la k
ème instance de τi
. On suppose que l’inégalité Ci ≤ Di = Ti
est toujours vérifiée.
Nous supposons aussi que le processeur que nous considérons n’a pas de
cache, ni “pipeline” ou d’architecture interne complexe.58 Ordonnancement monoprocesseur de tâches indépendantes
3.3 Intervalle d’étude de l’ordonnancement
L’opération d’ordonnancement ⊕ utilise l’approche par simulation présentée
à la section 1.5.3.2 de l’état de l’art pour faire l’analyse d’ordonnançabilité des
tâches. Cette simulation est réalisée sur un intervalle d’étude défini. Cet intervalle
est déterminé à l’aide du théorème 3.3.1 ci-dessous.
Théorème 3.3.1 [Yom09] Soit Γn = {τ1, τ2, · · · , τn} un ensemble de n tâches pé-
riodiques indépendantes concrètes tel que τi = (r
1
i
, Ci
, Ti
, Di), avec i = 1, · · · , n,
rangées par priorités décroissantes relativement à un algorithme d’ordonnancement
à priorités fixes noté Algo, c’est-à-dire i < j implique que la priorité de τi
est supérieure à la priorité de τj
. Soit (si)i∈N∗ la suite définie par
s1 = r
1
1
si = r
1
i +
(si−1−r
1
i
)
+
Ti
· Ti
, 2 ≤ i ≤ n
S’il existe un ordonnancement valide de Γn jusqu’à la date sn + Hn où Hn =
ppcm{Ti
|i = 1, · · · , n} et x
+ = max(x, 0), alors cet ordonnancement est valide
et périodique de période Hn à partir de sn.
D’après le théorème 3.3.1, l’exécution de l’ensemble des tâches Γn est périodique
à partir de la date sn et sa période est égale à Hn = ppcm{Ti
|i = 1, · · · , n}.
L’intervalle défini par [rmin, sn] avec rmin = min{r
1
i }τi∈Γn
est appelé phase transitoire
et l’intervalle défini par [sn, sn + Hn] est appelé la phase permanente qui
se répète indéfiniment. Donc un intervalle d’étude de l’ordonnancement de Γn est
donné par In = [rmin, sn + Hn]. En considérant uniquement l’ordonnancement
des i premières tâches on parle d’ordonnancement de niveau i et un intervalle
d’étude de l’ordonnancement des i tâches est donné par Ii = [rmin, si + Hi
] avec
Hi = ppcm{Tj
| j = 1, · · · , i}.
3.4 Opération binaire d’ordonnancement ⊕
3.4.1 Principe
L’opération d’ordonnancement ⊕ a été proposée par Meumeu [Yom09]. C’est
une opération binaire, c’est-à-dire qu’elle ne s’applique qu’entre deux opérandes :
un opérande de gauche op1 appelé tâche exécutée et un opérande de droite op2
appelé tâche exécutable telles que le résultat R est donné par R = op1 ⊕ op2.
Par convention l’opérande de gauche est toujours plus prioritaire que l’opérande
de droite. On représente une instance de la tâche exécutable op2 par une séquence3.4 Opération binaire d’ordonnancement ⊕ 59
de symboles de “e2” en gras suivi par une séquence de symbole de “a”. Chaque
symbole de “e2” de la tâche exécutable représente une unité de temps exécutable,
c’est-à-dire une unité de temps que op2, la tâche à exécuter, doit exécuter. Chaque
symbole “a” représente une unité de temps libre. Nous représentons une instance
de la tâche exécutée op1 par de séquences de symbole de “e” suivi par de sé-
quences de symboles de “a” qui ne se suivent pas forcément et qui peuvent se
répéter indéfiniment. Chaque symbole “e1” de la tâche exécutée op1 représente
une unité exécutée par op1, c’est-à-dire une unité de temps que op1 a déjà exécutée.
Le principe de l’opération ⊕ est de remplacer les unités de temps “a” libres
de la tâche exécutée op1 par les unités de temps exécutables “e2” de la tâche op2.
Pour cela, puisque les deux opérandes ne sont pas comparables, on les référence
par rapport à la même origine de temps, puis on répète l’exécution de op1 autant
de fois qu’il y a d’instances de op1 sur l’intervalle d’étude I2. Ensuite on réécrit
le premier opérande op1 en fonction du nombre d’instances du second opérande
op2 sur l’intervalle d’étude I2. Le résultat R = op1 ⊕ op2 est une tâche exécutée,
composée de séquences de symboles de “e1”, de séquences de symboles de “e2”,
suivies de séquences de symboles de “a” qui ne se suivent pas forcément et qui
peuvent se répéter indéfiniment.
Soient deux tâches périodiques concrètes τi = (r
1
i
, Ci
, Ti
, Di) et
τi+1 = (r
1
i+1, Ci+1, Ti+1, Di+1). On suppose que τi est plus prioritaire que τi+1. On
veut ordonnancer τi et τi+1 en utilisant ⊕. τi étant la plus prioritaire on a R = τi⊕
τi+1. On étudie l’ordonnançabilité de τi et τi+1 sur l’intervalle Ii+1 = [rmin, Si+1+
Hi+1] avec rmin = min{r
1
j }τj∈{τi,τi+1} et Si+1, déterminé à l’aide du théorème
3.3.1. L’exécution de τi est périodique de période Ti et se répète indéfiniment à
partir de r
1
i
. Le coût d’une préemption est supposé être une constante donnée par
α.
Définition 3.4.1 La durée d’exécution de la tâche τi+1 sur son instance k avec
prise en compte du coût exact de la préemption appelée “Preemption Execution
Time” (PET) est donnée par :
C
k
i+1 = Ci+1 + npk
i+1 ∗ α
npk
i+1 est le nombre exact de préemption de τi+1 sur son instance k.
La figure 3.1 donne une illustration du PET.
Le nombre npk
i+1 de préemptions de la tâche τi+1 sur son instance k est calculé
selon le principe suivant :
– npk
i+1 est initialisé à zéro au début de l’instance k,60 Ordonnancement monoprocesseur de tâches indépendantes
τ
k
2
r
k r 2 + T2
k
2
Coût d’une préemption
Préemption de τ
k
2
τ
k
1
r
k
1 r
k r
1 + 2T1
k
1 + T1
Ck
2 = C2 + 2α
FIGURE 3.1 – Illustration du PET de l’instance k de τ2
– à chaque fois que τi+1 est préemptée par τi
, npk
i+1 est incrémenté de 1 et on
ajoute α unités de temps à la durée d’exécution qui reste à τi+1 pour finir son
exécution. Ceci permet de prendre en compte les préemptions engendrées
par d’autres préemptions;
– à la fin de l’instance k, npk
i+1 correspond au nombre exact de préemptions
de τi+1.
L’algorithme 1 ci-dessous présente les différentes étapes de l’ordonnancement
de τi et τi+1 utilisant ⊕.
3.4.2 Application
Pour illustrer l’ordonnancement avec ⊕ on considère les tâches τ1 = (1, 2, 4; 4)
et τ2 = (0, 2, 6, 6) avec τ1 plus prioritaire que τ2. L’intervalle d’étude de l’ordonnancement
de τ1 et τ2 est calculé à l’aide du théorème 3.3.1. Cet intervalle est
donné par I2 = [0, 18]. La figure 3.2 ci-dessous donne les différentes étapes de
l’ordonnancement avec ⊕.
3.5 Analyse d’ordonnançabilité avec ⊕
Soit un ensemble de tâches périodiques concrètes Γn = {τ1, τ2 · · · , τn} où les
tâches sont triées dans l’orde décroissant de leurs priorités selon l’algorithme à
priorités fixes noté Algo. Puisque l’opération d’ordonnancement ⊕ ne s’applique
qu’entre deux opérandes à la fois, alors ⊕ est appliquée n − 1 fois et de façon
itérative pour faire l’analyse d’ordonnancement de l’ensemble Γn. Ainsi si Rn est3.5 Analyse d’ordonnançabilité avec ⊕ 61
Algorithme 1 R = τi ⊕ τi+1
1: Calculer l’intervalle d’étude de l’ordonnancement de τi et τi+1 noté Ii+1
2: Référencer τi et τj par rapport à la même origine de temps rmin =
min{r
1
j }τj∈{τi,τi+1}
3: Répéter l’exécution de τi autant de fois qu’il y a d’instances de τi sur l’intervalle
Ii+1. Ceci est possible car τi est la plus prioritaire donc elle peut
s’exécuter sans être préemptée
4: Délimiter toutes les instances de τi+1 sur l’intervalle Ii+1. Soit ni+1 le nombre
d’instances de τi+1 sur Ii+1
5: ordonnançable ← vrai
6: k ← 1
7: tant que (k ≤ ni+1) et (ordonnançable = vrai) faire
8: Calculer C
k
i+1, la durée d’exécution de τi+1 sur son instance k avec le coût
exact de la préemption
9: Compter le nombre d’unités de temps libres ”a” sur l’instance k de τi
. On
note par idlek
ce nombre.
10: si idlek < Ck
i+1 alors
11: ordonnançable ← f aux
12: sinon
13: τi+1 ne rate pas son échéance sur l’instance k
14: Remplacer les C
k
i+1 premières unités de temps libres ”a” par des unités
de temps ei+1 exécutées par τi+1
15: fin si
16: fin tant que
17: si ordonnançable = vrai alors
18: τi et τi+1 sont ordonnançables et R le résultat de l’ordonnancement de τi
et τi+1 est donné par Ii+1 avec des exécutions de τi et de τi+1. Cet ordonnancement
est périodique de période Hi+1 = ppcm(Ti
, Ti+1) et se répète
indéfiniment à partir de si+1 déterminé à l’aide du théorème 3.3.1
19: sinon
20: τi et τi+1 ne sont pas ordonnançables car il existe une instance de τi+1 dans
laquelle τi+1 n’est pas ordonnançable.
21: fin si62 Ordonnancement monoprocesseur de tâches indépendantes
le résultat de l’ordonnancement de Γn, alors Rn est obtenu par :
(
R1 = τ1
Ri+1 = Ri ⊕ τi+1, 1 ≤ i < n
À la fin de l’analyse d’ordonnançabilité, nous pouvons produire la table d’ordonnancement
des tâches qui contient les dates de début et de fin d’exécution de
chaque tâche.
Il faut noter que c’est le choix de priorité qui détermine l’ordre d’application
de ⊕, de la tâche la plus prioritaire à la moins prioritaire.
La complexité de l’analyse d’ordonnançabilité de Γn basée ⊕ est évaluée à
O(n.l) avec l = ppcm{Ti
: τi ∈ Γn}.
3.6 Facteur d’utilisation du processeur avec coût de
la préemption
Le facteur d’utilisation classique du processeur pour l’ensemble de tâches
Γn = {τ1, τ2, · · · , , τn} avec τi = (r
1
i
, Ci
, Ti
, Di) est donné par :
U =
Xn
i=1
Ci
Ti
Lorsque le coût de la préemption est prise en compte, la durée d’exécution
d’une tâche τi avec le coût de la préemption sur une instance k est donnée par
C
k
i ≥ Ci
. C
k
i
est obtenu en ajoutant sur la durée d’exécution Ci
le coût associé
au nombre de préemptions de τi sur l’instance k. On note par ni
le nombre
d’instances de la tâche τi sur les deux phases (transitoire et permanente) de l’ordonnancement.
Définition 3.6.1 Le facteur d’utilisation du processeur avec prise en compte du
coût exact de la préemption noté U
∗
est défini par :
U
∗ =
Xn
i=1
C
∗
i
Ti
avec C∗
i =
Xni
k=1
C
k
i
ni
(3.1)
3.7 Impact du coût de la préemption dans l’analyse
d’ordonnançabilité
Dans cette section nous présentons l’impact du coût de la préemption dans
l’analyse d’ordonnançabilité des tâches. Pour cela nous considérons deux cas.3.7 Impact du coût de la préemption dans l’analyse d’ordonnançabilité 63
Dans le cas 1 on suppose que le coût de la préemption est négligeable (α = 0).
Dans le cas 2 on suppose que le coût de la préemption n’est pas approximé dans
la pire durée d’exécution des tâches (α = 1). Pour montrer l’impact du coût de la
préemption, nous comparons les taux de succès de l’analyse d’ordonnançabilité
dans les deux cas. Soit un ensemble E composé de plusieurs ensembles de tâches,
le taux de succès d’un algorithme A sur E est défini par :
nombre d′
ensembles de tâches ordonnançables avec A
nombre total d′ensembles de tâches dans E (3.2)
Afin de comparer les taux de succès de l’analyse d’ordonnançabilité avec ⊕, nous
générons aléatoirement, en utilisant l’outil FORTAS [CG11] fondé sur l’algorithme
de Bini [BB05], 15 ensembles chacun composé de 10 ensembles de tâches.
Chaque ensemble de tâches est composé de 10 tâches. On calcule le taux de succès
de ⊕ dans les deux cas et sur chaque ensemble d’ensembles de tâches. La courbe
des taux de succès dans chacun des deux cas et les résultats sont présentés par la
figure 3.3. Sur l’axe des ordonnées nous avons les taux de succès et sur l’axe des
abscisses, les moyenne des facteurs d’utilisation des ensembles de tâches. En ce
qui concerne les conditions techniques de test, l’ordinateur utilisé est un DELL
muni d’un processeur IntelCoreTM 2 Duo (2,66 GHz, mémoire RAM 4Go).
Dans la figure 3.3, on observe que jusqu’à un facteur d’utilisation moyen inférieur
à 0.8, dans les deux cas nous avons des taux de succès de 1. Ce qui signifie
que le coût des préemptions éventuelles dans le cas 2 n’affecte pas l’ordonnançabilité
des ensembles de tâches. À partir d’un facteur d’utilisation moyen supérieur
à 0.77, le taux de succès dans le cas 2 décroît jusqu’à 0. Par contre dans le cas 1,
pour les ensembles d’ensembles de tâches avec des facteurs d’utilisation moyens
entre 0.8 et 0.9, le taux de succès reste égal à 1 avant de décroître à 0.8. Ceci
signifie que parmi les ensembles d’ensembles de tâches de facteurs d’utilisation
moyen supérieur à 0.9 aucun ensemble de tâches n’est ordonnançable avec la prise
en compte du coût exact de la préemption par contre sans prise en compte du coût
de la préemption certains ensembles de tâches sont ordonnançables. Cela confirme
le fait qu’en prenant en compte le coût exact de la préemption dans l’analyse d’ordonnançabilité
des tâches, un ensemble de tâches peut être non ordonnançable
alors qu’il a été déclaré ordonnançable en négligeant le coût de la préemption.
Ceci dépend des facteurs d’utilisation des tâches et aussi du coût de chaque pré-
emption. Dans notre exemple ceci semble être vérifié uniquement pour des tâches
qui chargent beaucoup le processeur, mais même dans le cas contraire si le coût
d’une préemption est élevé ce fait reste vérifié.64 Ordonnancement monoprocesseur de tâches indépendantes
3.8 Viabilité
Dans cette section nous allons montrer que l’analyse d’ordonnançabilité basée
sur ⊕ est viable. Cette viabilité est prouvée si un ensemble de tâches est ordonnançable
avec ⊕, alors cet ensemble de tâches reste ordonnançable, même si une
ou plusieurs tâches ont des durées d’exécution plus petites que celles considérées
lors de l’analyse d’ordonnançabilité.
Théorème 3.8.1 Soit un ensemble de tâches périodiques concrètes
Γn = {τ1, · · · , τi
, · · · , τn} où les tâches sont triées dans l’ordre décroissant de
leurs priorités selon l’algorithme à priorités fixes noté Algo avec τi = (r
1
i
, Ci
, Ti
, Di).
Si Γn est ordonnançable avec ⊕, lors de l’exécution en remplaçant τ
′
i = (r
1
i
, C′
i
, Ti
, Di)
par τi avec C
′
i ≤ Ci alors Γ
′
n = {τ1, · · · , τ
′
i
, · · · , τn} est aussi ordonnançable.
Preuve on suppose que Γn = {τ1, · · · , τi
, · · · , τn} est ordonnançable avec ⊕.
Nous allons montrer par contradiction que Γ
′
n = {τ1, · · · , τ
′
i
, · · · , τn} est aussi
ordonnançable avec ⊕. Pour cela supposons que Γ
′
n n’est pas ordonnançable avec
⊕. Ce qui veut dire que ∃τl ∈ Γ
′
n
tel que τl n’est pas ordonnançable. Puisque les
i − 1 premières tâches de Γn sont les plus prioritaires et sont les mêmes que dans
Γn alors leur ordonnancement ne change pas donc i ≤ l ≤ n.
Supposons que l = i ce qui veut dire que c’est la tâche τ
′
i qui n’est pas ordonnançable,
alors il existe une instance k de τ
′
i dans laquelle on ne peut exécuter
toutes les C
′k
i unités de temps de la tâche τ
′
i
. Puisque nous avons des tâches indé-
pendantes avec des priorités fixes et que de plus τi et τ
′
i ont la même priorité donc
si C
′
i ≤ Ci alors C
′k
i ≤ C
k
i ∀k ≥ 1. Il existe alors une instance k de la tâche τi
dans laquelle on ne peut pas exécuter toutes les C
k
i unités de temps de τi
. Ce qui
veux dire que τi n’est pas ordonnançable donc Γn n’est pas ordonnançable. Ce qui
est absurde d’après notre hypothèse de départ disant que Γn est ordonnançable.
De la même manière on montre que si i < l ≤ n alors Γn n’est pas ordonnan-
çable. Donc on a prouvé que si Γ
′
n n’est pas ordonnançable alors Γn ne l’est pas.
D’où Γn ordonnançable entraîne que Γ
′
n
soit aussi ordonnançable.
3.9 Conclusion
Dans ce chapitre nous avons présenté le principe de l’analyse d’ordonnançabilité
basée sur l’opération binaire d’ordonnancement ⊕ qui permet de prendre
en compte le coût exact de la préemption en monoprocesseur. Ensuite nous avons
montré que cette analyse d’ordonnançabilité est viable c’est dire si la durée d’exé-
cution des tâches diminue au cours de leur exécution alors l’ensemble des tâches
reste toujours ordonnançable. Dans le chapitre suivant, nous allons utiliser cette
Caract´erisation locale de fautes dans les syst`emes large
´echelle
Romaric Ludinard
To cite this version:
Romaric Ludinard. Caract´erisation locale de fautes dans les syst`emes large ´echelle. Networking
and Internet Architecture. Universit´e de Rennes 1, 2014. French.
HAL Id: tel-01094191
https://hal.inria.fr/tel-01094191
Submitted on 11 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.ANNEE 2014 ´
THESE / UNIVERSIT ` E DE RENNES 1 ´
sous le sceau de l’Universite Europ ´ eenne de Bretagne ´
pour le grade de
DOCTEUR DE L’UNIVERSITE DE RENNES 1 ´
Mention : Informatique
Ecole doctorale Matisse ´
present ´ ee par ´
Romaric LUDINARD
prepar ´ ee´ a l’unit ` e de recherche INRIA Rennes - Bretagne Atlantique ´
Universite de Rennes 1 ´
Caracterisation locale ´
de fautes dans les
systemes large ` echelle ´
These soutenue ` a Rennes `
le 02 octobre 2014
devant le jury compose de : ´
Ludovic ME´ / President ´
Professeur, Supelec, Rennes ´
Roberto BALDONI / Rapporteur
Full Professor, Sapienza Universita Di Roma, Rome `
Sebastien T ´ IXEUIL / Rapporteur
Professeur, UPMC, LIP6, Paris
Emmanuelle ANCEAUME / Co-encadrante de th`ese
Chargee de recherche CNRS, IRISA, Rennes ´
Marc-Olivier KILLIJIAN / Examinateur
Directeur de recherche CNRS, LAAS, Toulouse
Erwan LE MERRER / Examinateur
Chercheur, Technicolor R&I, Rennes
Bruno SERICOLA / Directeur de th`ese
Directeur de Recherche, Inria, Rennes
Franc¸ois TAIANI / Examinateur
Professeur, Universite de Rennes 1, Rennes ´Remerciements
Les travaux pr´esent´es dans ce manuscrit n’auraient jamais pu voir le jour sans le
concours et le soutien d’un certain nombre de gens, tant durant la th`ese elle-mˆeme
que pendant la (longue) p´eriode de cheminement qui l’a pr´ec´ed´ee. Malheureusement,
la mise en place d’une liste exhaustive de remerciements est une tˆache ardue et je vais
certainement en oublier certains. J’esp`ere ne pas commettre trop de fautes et que les
personnes concern´ees ne m’en tiendront pas rigueur. Afin de simplifier cet exercice et
tenter de limiter mes propres oublis, je vais proc´eder `a des remerciements par ensemble
coh´erent de personnes et de mani`ere `a peu pr`es ant´echronologique.
Pour commencer, je souhaite remercier Ludovic M´e, Professeur `a Sup´elec, pour
avoir accept´e de pr´esider mon jury de doctorat, ainsi que pour les diverses et riches
interactions que nous avons pu avoir au cours des diff´erents projets men´es avant ma
th`ese. Je remercie tr`es chaleureusement Roberto Baldoni, Full Professor `a l’Universit´e
La Sapienza `a Rome, et S´ebastien Tixeuil, Professeur `a l’UMPC / LIP6, pour leurs
lectures que j’imagine nombreuses et attentives, leurs remarques et critiques vis-`avis
de ce manuscrit. Enfin, je souhaite remercier Marc-Olivier Killijian, Directeur de
Recherche CNRS au LAAS, et Fran¸cois Taiani, Professeur `a l’Universit´e de Rennes 1,
d’avoir accept´e le rˆole d’examinateur dans ce jury.
Mes remerciements suivants s’adressent aux personnes avec qui j’ai pu travailler
directement pendant ces trois ans (et quelques mois) qui sont les piliers de ces travaux.
Il est ´evident que sans leur concours, cette th`ese serait tout autre.
Un grand merci `a Erwan Le Merrer et Gilles Straub de Technicolor pour leur travail
en amont de cette th`ese. Merci aussi pour l’accueil au sein de l’´equipe, l’accompagnement,
les discussions, le travail men´e et la souplesse dont ils ont parfois du faire preuve.
Un grand merci aussi `a Erwan pour l’interface avec Willem et Pierre, et `a Gilles pour
l’interface avec d’autres.
Je remercie bien ´evidemment Bruno Sericola, mon directeur de th`ese, pour son
encadrement, son soucis du d´etail et de la pr´ecision ainsi que pour ses nombreuses
remarques pertinentes. Enfin, une reconnaissance infinie `a Emmanuelle Anceaume, non
pas tant pour l’encadrement pendant ces trois ann´ees de doctorat que pour la totalit´e
du travail accompli ensemble depuis 8 ans. Merci pour son soutien, sa compr´ehension
et son enthousiasme communicatif. Mes excuses au passage `a nos voisins de bureau qui
nous ont incit´e plusieurs fois `a fermer la porte du bureau...
J’ai le plaisir d’ˆetre Attach´e Temporaire d’Enseignement et de Recherche `a l’ISTIC
pour l’ann´ee universitaire 2014-2015. Parmi les personnes qui constituent les
12 Remerciements
diff´erentes ´equipes p´edagogiques auxquelles j’appartiens, je souhaite remercier tout particuli`erement
Delphine Demange et Catherine Belleann´ee pour leur compr´ehension, leur
support et leur soutien dans les semaines qui ont pr´ec´ed´e ma soutenance de th`ese.
Je tiens tout particuli`erement `a remercier Yann Busnel et Jean-Louis Marchand que
je connais depuis un certain temps, mais avec qui j’ai eu l’occasion de collaborer pendant
ma th`ese. Cette collaboration a men´e `a l’un des r´esultats centraux de ce manuscrit et
de mes travaux de th`ese.
Pendant la dur´ee de ma th`ese j’ai ´et´e bilocalis´e entre mon bureau au centre de recherche
Inria Rennes - Bretagne Atlantique au sein de l”´equipe Dionysos et Technicolor
R&I `a Rennes. Je remercie chaleureusement les membres de ces deux ´equipes pour leur
accueil et les discussions, s´eminaires, caf´es, sprints... que nous avons pu partager. Un
clin d’œil particulier `a Alexandre Van Kempen et Nicolas Le Scouarnec pour le travail
men´e sur le papier Gateways.
Avant de commencer cette th`ese je suis intervenu dans diff´erents projets de recherche
en tant qu’ing´enieur. Ces exp´eriences se sont montr´ees tr`es riches et font partie du chemin
qui m’a men´e `a cette th`ese. Je remercie les personnes avec qui j’ai pu travailler dans
le cadre de ces projets, et plus particuli`erement Fr´ed´eric Tronel, Michel Hurfin, JeanPierre
Le Narzul, Eric Totel, Fr´ed´eric Majorczyk, Aina Ravoaja, Francisco Brasileiro ´
et Erwan Abgrall.
Cette particularit´e a fait les joies d’un certain nombre de gens qui ont du travailler
`a mettre en place les modalit´es pour que le financement de cette th`ese soit possible. Je
remercie tout sp´ecialement Caroline Lebaron et Thierry G´elin qui ´etaient en premi`ere
ligne pour la mise en place des aspects l´egaux de cette th`ese.
Je dois enfin remercier les gens de mon entourage. Je remercie tout d’abord ma
famille, entre autres pour le support question vignes quand j’´etais pris par la r´edaction
et encore une fois ma m`ere, en particulier pour le support culinaire pour le pot de th`ese.
Un grand merci `a Sara pour sa pr´esence et son soutien, en particulier pour les
moments o`u la recherche d´eborde sur nos moments `a nous. Merci encore `a elle d’avoir
chapeaut´e une bonne part du off du pot de th`ese de mani`ere transparente pour moi, et
merci d’avance pour ce qu’il reste `a venir.
Merci `a ceux qui ont suivi la mˆeme voie et qui ne sont certainement pas ´etrangers `a
ce cheminement : la joyeuse compagnie de la smash-bavette (J´er´emy, Benoit Gronchon,
JPio, Fanfou´e), les (ex-)doctorants Kostas, Antoine, H´everson, Erwan Raffin, Julien
Stainer...
Merci aux amis, ceux pr´esents pour mes 30 ans `a la conf´erence OPODIS 2012 :
Yves-Alexis, Marie, Delf, Alex, Fred, merci aussi `a Pierre-Louis, Julien & Solenn, `a
ceux qui n’ont pu ˆetre l`a : Ben Roux & Sol`ene, Jean-Loup, Nono... et enfin aux adeptes
des chaˆınes de mails infinies : Marie & Alex, Marine & Vincent, J´e, Thom, Mathieu,
Elo. ´Table des mati`eres
Remerciements 1
Introduction 7
Supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Probl´ematique consid´er´ee . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Contexte de cette ´etude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Organisation du document . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1 Terminologie et mod`ele 15
1.1 Terminologie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2 Mod`eles de d´efaillances consid´er´es . . . . . . . . . . . . . . . . . . . . . 17
1.3 Syst`eme large ´echelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2 Travaux connexes 23
2.1 Syst`emes large ´echelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.1 Gestion de la population . . . . . . . . . . . . . . . . . . . . . . . 23
2.1.2 G´erer le dynamisme de la population . . . . . . . . . . . . . . . . 25
2.1.3 G´erer les comportement fautifs . . . . . . . . . . . . . . . . . . . 26
2.2 Organisation des donn´ees . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2.1 Partitionnement de donn´ees statiques . . . . . . . . . . . . . . . 30
2.2.2 Donn´ees dynamiques . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3 Supervision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.1 Etat global du syst`eme . . . . . . . . . . . . . . . . . . . . . . . . ´ 34
2.3.2 Caract´erisation de fautes . . . . . . . . . . . . . . . . . . . . . . 35
Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3 Caract´erisation de fautes 43
3.1 Mod`ele . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.1.1 Pr´eliminaires . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.1.2 Terminologie et notations employ´ees . . . . . . . . . . . . . . . . 44
3.1.3 Mod´elisation de l’impact des fautes . . . . . . . . . . . . . . . . . 48
3.2 Probl`emes ´etudi´es . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
34 Table des mati`eres
3.3 Conditions d’appartenance `a Ik, Mk ou Uk . . . . . . . . . . . . . . . . . 55
3.3.1 Condition n´ecessaire et suffisante pour l’appartenance `a Ik . . . . 57
3.3.2 Condition suffisante pour l’appartenance `a Mk . . . . . . . . . . 57
3.3.3 Condition n´ecessaire et suffisante pour l’appartenance `a Mk . . . 60
3.3.4 Condition n´ecessaire et suffisante pour l’appartenance `a Uk . . . 62
3.3.5 Equivalence de caract´erisations . . . . . . . . . . . . . . . . . . . ´ 62
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4 Mise en œuvre algorithmique et ´evaluation 69
4.1 Algorithmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.1.1 Calcul des ensembles ayant un mouvement r-coh´erent maximal . 69
4.1.2 Caract´erisation des fautes . . . . . . . . . . . . . . . . . . . . . . 76
4.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ´ 80
4.2.1 Param`etres de simulation . . . . . . . . . . . . . . . . . . . . . . 86
4.2.2 Comparaison des algorithmes . . . . . . . . . . . . . . . . . . . . 88
4.2.3 Impact de la fr´equence d’´echantillonnage des ´etats du syst`eme . 92
4.2.4 Pertinence du mod`ele . . . . . . . . . . . . . . . . . . . . . . . . 93
4.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
5 FixMe : Une architecture auto-organisante pour la caract´erisation de
fautes 101
5.1 Probl´ematique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.2 Architecture de l’espace des qualit´es . . . . . . . . . . . . . . . . . . . . 104
5.2.1 El´ements de l’architecture FixMe . . . . . . . . . . . . . . . . . . ´ 104
5.2.2 Op´erations de FixMe . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.3 Gestion interne des seeds . . . . . . . . . . . . . . . . . . . . . . . . . . 110
5.4 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
5.5 Utilisation de FixMe pour la caract´erisation de fautes . . . . . . . . . . 118
5.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
6 Etude locale de PeerCube 131 ´
6.1 Fonctionnement de PeerCube . . . . . . . . . . . . . . . . . . . . . . . . 131
6.1.1 Clusters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
6.1.2 Op´erations de PeerCube . . . . . . . . . . . . . . . . . . . . . . . 133
6.2 Adversaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
6.2.1 Identifiants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
6.2.2 Strat´egie de l’adversaire . . . . . . . . . . . . . . . . . . . . . . . 142
6.3 Mod´elisation d’un cluster . . . . . . . . . . . . . . . . . . . . . . . . . . 144
6.4 Etude de la composition d’un cluster . . . . . . . . . . . . . . . . . . . . ´ 154Table des mati`eres 5
6.4.1 Esp´erance du temps total pass´e dans les ´etats sains et pollu´es . . 155
6.4.2 Temps successifs pass´es dans les ´etats sains et pollu´es . . . . . . 157
6.4.3 Probabilit´es d’absorption . . . . . . . . . . . . . . . . . . . . . . 160
6.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
7 Evaluation de PeerCube 167 ´
7.1 Etude de l’overlay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . ´ 167
7.1.1 Esp´erance de la proportion de clusters sains et pollu´es . . . . . . 168
7.1.2 Instant du premier changement topologique . . . . . . . . . . . . 172
7.2 Routage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
7.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
8 Conclusion 189
Enjeux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Bibliographie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
Liste des publications 197
Revues internationales avec comit´e de lecture . . . . . . . . . . . . . . . . . . 197
Conf´erences internationales avec comit´e de lecture . . . . . . . . . . . . . . . 197
Workshops et conf´erences francophones . . . . . . . . . . . . . . . . . . . . . 198
Brevets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Table des figures 209
Liste des tableaux 213
Liste des algorithmes 2156 Table des mati`eresIntroduction
Internet est un r´eseau de r´eseaux sans centre n´evralgique servant de support `a divers
services tels que les communications ´electroniques, la messagerie instantan´ee, la vid´eo `a
la demande ou le World Wide Web. L’acc`es `a Internet et son utilisation au quotidien se
sont largement d´emocratis´es depuis sa cr´eation. En France, l’autorit´e de r´egulation des
communications ´electroniques et des postes [ARC13] recensait au troisi`eme trimestre
2013, environ 24 millions d’abonnements au haut et tr`es haut d´ebit. Ces abonn´es sont
r´epartis entre quelques fournisseurs d’acc`es `a Internet. Un fournisseur d’acc`es `a Internet,
ou op´erateur de r´eseau, g`ere un r´eseau qui lui est propre et qui est connect´e `a d’autres
r´eseaux au sein d’Internet. Un fournisseur d’acc`es `a Internet fournit `a ses utilisateurs
une connexion `a Internet. Chaque utilisateur se connecte `a Internet au travers d’un
´equipement appel´e ”passerelle de connexion”. Ainsi connect´e, l’utilisateur peut ainsi
utiliser les services bas´es sur Internet.
Exemple 1 La figure 1 repr´esente une interconnexion possible de trois r´eseaux de fournisseurs
d’acc`es `a Internet ( Fai 1, Fai 2 et Fai 3). Chaque utilisateur est connect´e
`a Internet au travers d’une passerelle de connexion Internet repr´esent´e par les ronds
bleus. Les passerelles de connexion sont reli´ees `a des routeurs Ri. Les routeurs sont
reli´ees entre eux.
Les fournisseurs de services d´eploient des serveurs au sein d’Internet afin de d´elivrer
un service aux utilisateurs. La figure 1 illustre un positionnement possible de ces serveurs.
La notation S
y
x repr´esente le serveur x d´elivrant le service sy. Par exemple, le
service s1 est d´elivr´e par les serveurs S
1
1
, S
1
5
et S
1
6
. Notons que le service s1 est d´elivr´e
par un serveur pr´esent dans chacun des trois r´eseaux. A l’inverse le service ` s4 n’est
d´elivr´e que par un unique serveur S
4
4
pr´esent dans le r´eseau g´er´e par Fai 2. Enfin, les
utilisateurs 1 `a 6 peuvent acc´eder au service s2 par le serveur S
2
8
.
Supervision
Malheureusement, chacun des ´el´ements pr´esents dans le r´eseau ou impliqu´es dans les
services consomm´es par les utilisateurs peut potentiellement exhiber des d´efaillances.
Par exemple, un routeur peut omettre de renvoyer temporairement le trafic qu’il re¸coit,
sa bande passante peut ˆetre satur´ee ou il peut dupliquer des messages. De la mˆeme
mani`ere, des messages peuvent ˆetre perdus sur les liens de communication, les serveurs
78 Introduction
R1
R2
R3
R4
R5
R6
R7
R8
R9
1
2
3
5
4
6 7 8
9
10
S
1
1
S
2
2
S
3
3
S
4
4
S
1
5
S
1
6
S
5
7
S
2
8 S
4
9
Fai 1 Fai 2 Fai 3
Figure 1 – Disposition de serveurs au sein d’Internet
peuvent ˆetre temporairement indisponibles et les passerelles de connexions peuvent
avoir un comportement d´egrad´e voire devenir inop´erantes.
La supervision d’un syst`eme est la tˆache qui consiste `a collecter et analyser des
donn´ees du syst`eme de mani`ere continue afin de s’assurer du bon fonctionnement de
celui-ci. La supervision d’un syst`eme permet ainsi de d´eceler si le syst`eme devient
d´efaillant, c’est-`a-dire que le service qu’il d´elivre d´evie du service attendu. Les fournisseurs
d’acc`es `a Internet et de services supervisent le syst`eme afin d’intervenir rapidement
lorsqu’une d´efaillance est d´etect´ee.
Les protocoles de supervision tels que Simple Network Managment Protocol (SNMP)
[CFSD90] ou TR-69 [Bro] d´efinissent le comportement des entit´es supervis´ees ainsi que
leurs interactions avec le superviseur qui collecte et analyse ces donn´ees. Les entit´es
supervis´ees ex´ecutent une supervision locale de leur ´etat interne. Ces donn´ees sont disponibles
`a la demande du superviseur ou lui sont envoy´ees p´eriodiquement. En cas de
d´efaillance, un administrateur peut ex´ecuter des proc´edures locales sur l’entit´e supervis´ee
`a des fins de diagnostic. Le diagnostic est la tˆache d’identification des causes d’une
d´efaillance.
Ces protocoles sont largement employ´es dans le cadre de la supervision d’´el´ements
r´eseaux comme les routeurs. Le service assur´e par ces ´el´ements est local et consiste `a
faire transiter des informations d’une interface vers une autre en fonction d’un ensemble
de r`egles pr´e´etablies appel´ee “politique de routage”. Par exemple, un routeur se montre
d´efaillant s’il ne fait plus transiter les informations, les fait transiter de mani`ere erron´ee
ou s’il met trop de temps `a le faire. D’autre part, les protocoles de routage r´eseau
sont redondants. De cette mani`ere, si un routeur est d´efaillant, le service est d´elivr´e
en empruntant un chemin alternatif. La d´efaillance du routeur est ainsi masqu´ee `a
l’utilisateur et permet `a l’op´erateur de rechercher les causes de cette d´efaillance, sans
rupture de service.Introduction 9
Exemple 2 Revenons `a l’exemple d´ecrit dans la figure 1 et consid´erons que l’utilisateur
4 consomme le service s4. Celui-ci est d´elivr´e par S
4
4
en empruntant les routeurs R2,
R5 et R7. Si le routeur R5 devient d´efaillant, un chemin alternatif est emprunt´e de
mani`ere transparente pour l’utilisateur, par exemple R2, R4 et R7.
Probl´ematique consid´er´ee
A l’inverse des ´equipements r´eseaux qui assurent un service local et dont on peut `
masquer les d´efaillances par l’utilisation de chemins redondants, les passerelles de
connexion constituent un point unique de d´efaillance. En effet, une d´efaillance de la
passerelle de connexion am`ene `a une d´egradation des services consomm´es par l’utilisateur.
Par cons´equent, il est primordial pour l’op´erateur de superviser ces ´equipements
afin de diagnostiquer au plus vite une d´efaillance et assurer la connexion de l’utilisateur
`a Internet.
De mani`ere similaire aux ´equipements r´eseau, on peut imaginer que chaque passerelle
de connexion supervise la qualit´e des services consomm´es. Ainsi, lorsque la passerelle
de connexion est d´efaillante, celle-ci peut notifier l’op´erateur r´eseau. Dans la
pratique cette approche n’est pas employ´ee. L’exemple suivant illustre les limites de
cette approche.
Exemple 3 Revenons `a l’exemple d´ecrit dans la figure 1 et consid´erons que l’utilisateur
5 consomme le service s2.
Cas 1 Supposons que la passerelle de connexion 5 soit d´efaillante, la qualit´e du service
s2 per¸cue par la passerelle diminue, la passerelle envoie une alarme `a l’op´erateur.
Cas 2 Supposons `a pr´esent que le service s2 est d´elivr´e `a l’utilisateur 5 par le serveur
S
2
8
. Consid´erons de plus que le serveur S
2
8
est d´efaillant, le service s2 est d´elivr´e
par le serveur S
2
2
. Dans ce cas, l’utilisateur 5 per¸coit une variation de la qualit´e
du service s2 li´ee au changement de serveur envoie une alarme `a l’op´erateur.
Pourtant, la passerelle de connexion 5 n’est pas d´efaillante, l’alarme est inutile
(faux positif ).
Cas 3 Consid´erons `a pr´esent que les utilisateurs 1, 2, 3, 4, 5 et 6 consomment le service
s2 d´elivr´e par le serveur S
2
8
. De la mˆeme mani`ere, si le serveur S
2
8
est d´efaillant,
le service s2 pourra ˆetre d´elivr´e par le serveur S
2
2
. Dans ce cas, chaque utilisateur
per¸coit une variation de qualit´e du service s2 et envoie donc une alarme
`a l’op´erateur. Pourtant, aucune des passerelles de connexion 1, 2, 3, 4, 5, 6 n’est
d´efaillante, ces alarmes sont inutiles.
Afin d’´eviter de surcharger l’op´erateur avec des alarmes non pertinentes, ce type d’approche
est d´esactiv´e dans la pratique.
Comme l’illustre cet exemple, cette approche peut engendrer de nombreux faux
positifs. Pour cette raison, ce type d’approche pour les passerelles de connexion est
d´esactiv´e dans la pratique. Les protocoles SNMP ou TR-69 ne sont utilis´es que pour
des tˆaches d’administration ou de diagnostic. Les fournisseurs d’acc`es `a Internet pallient10 Introduction
l’absence de d´etection de d´efaillance automatique en d´el´eguant cette tˆache aux utilisateurs
finaux et en utilisant des centres d’appels. Un utilisateur peut ainsi contacter un
centre d’appel s’il per¸coit une d´efaillance et un technicien peut ´eventuellement rechercher
les causes de la d´efaillance per¸cue par l’utilisateur. Bien qu’utilis´ee en pratique,
cette approche n’est pourtant pas satisfaisante pour trois raisons. Tout d’abord, cette
solution n´ecessite une activit´e humaine permanente pour r´epondre aux sollicitations
des utilisateurs et ´eventuellement chercher `a localiser la d´efaillance per¸cue ainsi que les
causes de celle-ci. D’autre part, il peut y avoir un d´elai important entre l’apparition
de la d´efaillance et la notification de l’utilisateur, rendant ainsi plus difficile le travail
de diagnostic. Enfin, les utilisateurs peuvent contacter le centre d’appel de l’op´erateur
pour des raisons ind´ependantes du fonctionnement de la passerelle de connexion, comme
illustr´e dans les cas 2 et 3 de l’exemple 3, nuisant ainsi `a l’efficacit´e d’une telle solution.
Exemple 4 Revenons `a l’exemple d´ecrit dans la figure 1 et consid´erons le cas 3 de
l’exemple pr´ec´edent. Dans ce cas, les utilisateurs 1, 2, 3, 4, 5 et 6 consomment le service
s2 d´elivr´e par le serveur S
2
8
. Si le serveur S
2
8
est d´efaillant, le service s2 pourra
ˆetre d´elivr´e par le serveur S
2
2
. Dans ce cas, chaque utilisateur per¸coit une variation
de qualit´e du service s2 et envoie donc une alarme `a l’op´erateur. Ces alarmes ne sont
pas r´ev´elatrices de d´efaillances des passerelles de connexion 1, 2, 3, 4, 5, 6 et sont donc
consid´er´ees comme des faux positifs. Afin d’´eviter la trop forte proportion de faux positifs,
ce type d’alarmes est d´esactiv´e dans la pratique.
En effet, l’approche actuelle consid`ere que chacune de ces alarmes, prise individuellement,
constitue un faux positif, et donc que celles-ci n’apportent aucune information.
Pour autant, si on consid`ere l’ensemble de ces alarmes, elles sont r´ev´elatrices d’une
d´efaillance per¸cue par un grand nombre d’utilisateurs. Il semble donc int´eressant d’utiliser
ces alarmes afin de faire la distinction entre les d´efaillances per¸cues par un petit
nombre d’utilisateurs et les d´efaillances per¸cues par un grand nombre d’utilisateurs.
L’exemple 4 nous montre que les variations de qualit´es per¸cues par les utilisateurs
sont corr´el´ees lorsqu’ils per¸coivent une d´efaillance due `a une mˆeme cause appel´ee faute.
Il semble donc int´eressant d’exploiter cette corr´elation afin de distinguer d’une part
les d´efaillances per¸cues par un petit nombre d’utilisateurs, comme dans le cas d’une
d´efaillance de passerelle de connexion, de celles per¸cues par un grand nombre d’utilisateurs,
comme dans le cas d’une d´efaillance d’un ´equipement r´eseau ou d’un serveur.
Dans le premier cas, nous parlerons de “faute isol´ee” tandis que dans le second cas
nous parlerons de “faute massive”. La question qui se pose naturellement est alors la
suivante :
Dans quelle mesure et sous quelles conditions est-il possible de distinguer
les fautes isol´ees des fautes massives, en ne se basant que sur les perceptions
des utilisateurs ?Introduction 11
Contexte de cette ´etude
L’exemple 4 illustre l’intuition que nous allons d´evelopper dans ce document : les
utilisateurs ayant per¸cu des variations de qualit´es similaires sont susceptibles d’avoir
per¸cu une mˆeme d´efaillance. Cependant, afin de clarifier cette intuition, l’exemple 4 occulte
certains aspects du contexte consid´er´e. Tout d’abord, cette ´etude se place dans le
contexte d’un r´eseau de fournisseur d’acc`es `a Internet. Par cons´equent, nous consid´erons
ici plusieurs milliers (voire millions) d’utilisateurs connect´es et consommant divers services.
D’autre part, nous consid´erons que plusieurs fautes sont susceptibles d’impacter
le syst`eme dans un intervalle de temps restreint. Dans ce cas, le nombre d’alarmes dues
`a des variations de qualit´es peut ˆetre tr`es grand et toutes les variations de qualit´es
per¸cues ne sont donc pas n´ecessairement corr´el´ees entre elles. Enfin, la figure 1 d´ecrit
repr´esente une interconnexion possible de trois r´eseaux de fournisseurs d’acc`es `a Internet
ainsi que le placement des serveurs et des utilisateurs dans cette interconnexion.
Cette illustration est utile pour d´ecrire la situation de l’exemple 4 mais n’est pas utilis´ee
pour regrouper les variations de qualit´es similaires. Par cons´equent, les travaux d´ecrits
dans ce document ne s’appuient pas sur la connaissance du r´eseau d’interconnexion, la
position des diff´erents serveurs et utilisateurs dans le r´eseau.
Organisation du document
Le reste de ce document est organis´e en huit chapitres.
Chapitre 1 Ce chapitre d´ecrit les concepts n´ecessaires aux travaux d´ecrits dans ce
document. Plus pr´ecis´ement, les notions de faute, erreur et d´efaillance, relatives `a la
sˆuret´e de fonctionnement sont rappel´ees. Dans un second temps, la notion de syst`eme
large ´echelle est pr´esent´ee.
Chapitre 2 Ce chapitre donne un aper¸cu des principales approches employ´ees dans
la conception de syst`emes large ´echelle. Ensuite, ce chapitre d´ecrit diff´erentes familles
d’algorithmes de clustering de donn´ees, le clustering ´etant la tˆache consistant `a regrouper
les donn´ees similaires ensemble. Enfin, les principaux travaux existants sur la
supervision et la caract´erisation de fautes dans les syst`emes large ´echelle sont pr´esent´es
et discut´es.
Chapitre 3 Ce chapitre d´ecrit un cadre id´eal permettant de mod´eliser l’impact des
fautes dans le syst`eme sur les qualit´es des services per¸cues par les entit´es supervis´ees.
Malgr´e ce cadre id´eal, nous montrons qu’il est impossible de d´eterminer de mani`ere
certaine, pour chaque entit´e supervis´ee, si la d´efaillance qu’elle per¸coit est due `a une
faute isol´ee ou `a une faute massive. Cependant, en assouplissant les choix possibles pour
la caract´erisation du type de faute (isol´ee, massive ou ind´etermin´ee), on peut alors
d´eterminer pour chaque variation anormale de qualit´e, le type de faute `a lui associer.
Cette caract´erisation ne n´ecessite la connaissance que d’un sous-ensemble des entit´es12 Introduction
du syst`eme. Celle-ci s’appuie sur la connaissance des entit´es percevant des qualit´es et
des variations similaires et est aussi pr´ecise que celle que ferait un observateur ayant
acc`es `a l’ensemble des entit´es du syst`eme.
Chapitre 4 Ce chapitre fournit les algorithmes n´ecessaires `a la caract´erisation des
fautes d´ecrite au chapitre 3. Nous montrons que ces algorithmes peuvent ˆetre ex´ecut´es
localement et ne requi`erent qu’une connaissance partielle des entit´es du syst`eme. Ces
algorithmes sont ´evalu´es et compar´es au travers de diverses simulations. Enfin, nous
discutons de la pertinence du mod`ele que nous avons mis en place.
Chapitre 5 Ce chapitre d´ecrit la mise en place de FixMe, une architecture autoorganis´ee
permettant aux entit´es de trouver de mani`ere efficace les autres entit´es percevant
des qualit´es similaires et ayant subi les mˆemes variations de qualit´e. Les algorithmes
d´ecrivant les diff´erentes op´erations `a la mise en œuvre de cette architecture
sont d´ecrits, ainsi que la complexit´e algorithmique de ces op´erations. Enfin, la mise en
œuvre des algorithmes d´ecrits dans le chapitre 4 dans le cadre de cette architecture est
d´ecrite.
Chapitre 6 FixMe est form´e de deux niveaux, : le premier permettant g´erer les
entit´es suivant la qualit´e per¸cue et le second, nomm´e PeerCube, g´erant les entit´es percevant
une mˆeme qualit´e. Ce chapitre pr´esente le fonctionnement basique de PeerCube
puis une ´evaluation de performance de ces composants ´el´ementaires. Nous y ´etudions le
comportement de ces composants dans le pire cas d’ex´ecution, c’est-`a-dire en pr´esence
d’un adversaire visant `a corrompre le syst`eme.
Chapitre 7 Ce chapitre pr´esente une ´evaluation de performance de PeerCube dans
son ensemble dans le pire cas d’ex´ecution. En s’appuyant sur l’´etude men´ee au chapitre
6, nous montrons que cette architecture est r´esiliente au churn (i.e., les entr´ees /
sorties du syst`eme ont un impact restreint sur celui-ci) et qu’un adversaire n’a qu’un
pouvoir limit´e sur cette architecture.
Chapitre 8 Ce chapitre termine le pr´esent document. Les diff´erents chapitres et
contributions y sont r´esum´es. Les pistes d’am´eliorations ainsi que les questions ouvertes
et pistes de r´eflexion sont ensuite pr´esent´ees.
Contributions et publications
Les publications relatives au pr´esent document apparaissent dans la section bibliographie
de ce chapitre d’introduction. Plus sp´ecifiquement, les contributions dont je
suis le principal contributeur portent sur :
— Les concepts, la mod´elisation et la mise en œuvre algorithmique abord´es aux
chapitres 3 et 4. Ces travaux ont ´et´e pr´esent´e `a la conf´erence DSN [ABL+14a]Bibliographie 13
et `a AlgoTel [ABL+14b]. De plus, ces travaux ont conduit `a un d´epˆot de brevet
[LLSS13] en collaboration avec Technicolor.
— L’architecture pr´esent´ee dans le chapitre 5. Ce travail a ´et´e pr´esent´e `a OPODIS
en 2012 [ALL+12] puis `a AlgoTel en 2013 [ALL+13b] ainsi que dans une
conf´erence industrielle [ALL+13a]. De plus, ce travail a fait l’objet d’un d´epˆot
de brevet [LLSS12] en collaboration avec Technicolor.
— La mod´elisation probabiliste de PeerCube abord´ee au chapitre 6. Ce travail a
´et´e pr´esent´e en 2011 `a DSN [ASLT11] et `a CFIP [ALST11].
La liste compl`ete de mes publications se situe `a la fin du pr´esent document.
Bibliographie
[ABL+14a] E. Anceaume, Y. Busnel, E. Le Merrer, R. Ludinard, J-L. Marchand
et B. Sericola : Anomaly Characterization in Large Scale Networks.
Dans Proceedings of the 44th International Conference on Dependable
Systems and Networks, DSN, juin 2014.
[ABL+14b] E. Anceaume, Y. Busnel, E. Le Merrer, R. Ludinard, J-L. Marchand,
B. Sericola et G. Straub : Anomaly Characterization Problems.
Dans 16`emes Rencontres Francophones sur les Aspects Algorithmiques des
T´el´ecommunications, AlgoTel, pages 1–4, 2014.
[ALL+12] E. Anceaume, E. Le Merrer, R. Ludinard, B. Sericola et
G. Straub : FixMe : A Self-organizing Isolated Anomaly Detection Architecture
for Large Scale Distributed Systems. Dans Proceedings of the 16th
International Conference On Principles Of Distributed Systems, OPODIS,
pages 1–12, d´ecembre 2012.
[ALL+13a] E. Anceaume, E. Le Merrer, R. Ludinard, B. Sericola et
G. Straub : A Self-organising Isolated Anomaly Detection Architecture
for Large Scale Systems. Dans Nem-Summit, octobre 2013.
[ALL+13b] E. Anceaume, E. Le Merrer, R. Ludinard, B. Sericola et
G. Straub : FixMe : D´etection R´epartie de D´efaillances Isol´ees.
Dans 15`emes Rencontres Francophones sur les Aspects Algorithmiques des
T´el´ecommunications, AlgoTel, pages 1–4, mai 2013.
[ALST11] E. Anceaume, R. Ludinard, B. Sericola et F. Tronel : Mod´elisation
et Evaluation des Attaques Cibl´ees dans un Overlay Structur´e. Dans ´ Colloque
Francophone sur l’Ing´enierie des Protocoles, CFIP, 2011.
[ARC13] ARCEP : Haut et tr`es haut d´ebit sur r´eseaux fixes au 30 septembre 2013.
http://www.arcep.fr/index.php?id=12115, novembre 2013.
[ASLT11] E. Anceaume, B. Sericola, R. Ludinard et F. Tronel : Modeling
and Evaluating Targeted Attacks in Large Scale Dynamic Systems. Dans
Proceedings of the 41rst International Conference on Dependable Systems
and Networks, DSN, pages 347–358, juin 2011.14 Introduction
[Bro] Broadband Forum : TR-069 CPE WAN Management Protocol Issue 1,
Amend.4, 2011.
[CFSD90] J. D. Case, M. Fedor, M. L. Schoffstall et J. Davin : Simple Network
Management Protocol (SNMP). Rapport technique, IETF, 1990.
[LLSS12] E. Le Merrer, R. Ludinard, B. Sericola et G. Straub : Method
for Isolated Anomaly Detection in Large-scale Data Processing Systems.
patent no. 12306237.4, octobre 2012.
[LLSS13] E. Le Merrer, R. Ludinard, B. Sericola et G. Straub : Method for
Isolated Anomaly Detection in Large-scale Audio/Video/Data Processing
Systems. patent no. 13306029.3, juillet 2013.Chapitre 1
Terminologie et mod`ele
Ce chapitre rappelle les d´efinitions que nous utiliserons tout au long de ce document
et pr´esente le contexte dans lequel se place nos travaux, `a savoir les syst`emes large
´echelle.
1.1 Terminologie
Nous rappelons dans cette section les d´efinitions de Jean-Claude Laprie employ´ees
dans [Lap96, ALRL04].
Fautes, erreurs et d´efaillances Un syst`eme est une entit´e qui interagit avec d’autres
entit´es afin de rendre un service. L’utilisateur est une entit´e particuli`ere qui interagit
avec le syst`eme consid´er´e afin d’utiliser le service qu’il d´elivre. Le service est correct
si le service d´elivr´e accomplit la fonction du syst`eme, i.e., ce pour quoi le syst`eme est
destin´e. La sˆuret´e de fonctionnement d’un syst`eme est d´efinie comme ”la propri´et´e qui
permet `a ses utilisateurs de placer une confiance justifi´ee dans la qualit´e du service qu’il
leur d´elivre”.
Un syst`eme est d´efaillant lorsque le service qu’il d´elivre d´evie du service correct
ou attendu. Une d´efaillance est la cons´equence d’une faute dans le syst`eme. Un ´etat
d’erreur d´esigne l’´etat anormal du syst`eme, r´esultant de l’activation d’une faute et
pouvant potentiellement amener `a une d´efaillance. L’erreur permet de lier la faute `a la
d´efaillance per¸cue par l’utilisateur.
Ces notions sont d´ependantes du syst`eme consid´er´e. Ainsi, un mˆeme ´ev´enement
pourra ˆetre une faute, une erreur ou une d´efaillance suivant le point de vue fonctionnel
consid´er´e. Consid´erons un syst`eme constitu´e d’un serveur d´elivrant un service. En cas
de panne ´electrique (faute), le serveur n’est plus aliment´e (erreur) et ne peut plus
d´elivrer son service (d´efaillance).
Un syst`eme est g´en´eralement compos´e de sous-syst`emes qui interagissent entre eux.
Une d´efaillance de l’un de ces sous-syst`emes peut-ˆetre consid´er´ee comme une faute dans
le syst`eme global.
1516 Mod`ele
R1
R2
R3
R4
R5
R6
R7
R8
R9
1
2
3
5
4
6 7 8
9
10
S
1
1
S
2
2
S
3
3
S
4
4
S
1
5
S
1
6
S
5
7
S
2
8 S
4
9
Figure 1.1 – Disposition de serveurs au sein d’Internet
Mod`eles de d´efaillances L’activation d’une faute dans le syst`eme peut avoir des
cons´equences variables. Les d´efaillances peuvent ˆetre cat´egoris´ees suivant deux aspects :
le domaine de d´efaillance et la coh´erence des d´efaillances.
Le premier aspect porte sur le service rendu par le syst`eme et le d´elai n´ecessaire
pour fournir ce service. On parle de d´efaillance en valeur lorsque le syst`eme d´elivre une
valeur ou un service erron´e. Lorsque le service n’est pas d´elivr´e au moment attendu
(trop tˆot ou trop tard), on parle de d´efaillance temporelle. Lorsque le service n’est plus
rendu, on parle de d´efaillance par arrˆet.
D’autre part, on dit d’une d´efaillance qu’elle est coh´erente si tous les utilisateurs
per¸coivent la mˆeme d´eviation du service vis-`a-vis du service attendu. Enfin, si le comportement
d’une entit´e du syst`eme d´evie de mani`ere arbitraire de son comportement
normal ou attendu, on parle de d´efaillance byzantine. Dans un syst`eme de communication
par message, l’absence d’´emission de message par une entit´e peut constituer une
d´efaillance coh´erente. A l’inverse, une entit´e envoyant des messages avec un contenu `
incorrect (d´efaillance en valeur), au mauvais moment (d´efaillance temporelle) ou non
pr´evus constitue une d´efaillance byzantine.
Exemple 5 La figure 1.1 illustre un exemple de syst`eme que nous consid´erons dans
le cadre de ce document. Le syst`eme est constitu´e d’une ensemble de routeurs interconnect´es
par des liens, de serveurs d´elivrant des services et de passerelles utilisateurs.
Chaque utilisateur consomme des services propos´es par le syst`eme de mani`ere transparente
comme illustr´e sur la figure 1.2.
Dans cette figure, le service s2 est d´elivr´e par les serveurs S
2
2
et S
2
8
, tandis que le
service s3 n’est fourni que par le serveur S
3
3
. L’utilisateur 5 consomme ces deux services
s2 et s3.
Consid´erons le serveur S
3
3
comme un sous-syst`eme du syst`eme consid´er´e. Si une
panne ´electrique (faute) se produit au niveau du serveur S
3
3
, celui-ci n’est plus aliment´e
(erreur), le service s3 n’est plus rendu (d´efaillance). Dans le contexte du syst`eme global,
la d´efaillance du serveur S
3
3
constitue une faute. Le serveur S
3
3
est le seul `a d´elivrerMod`eles de d´efaillances consid´er´es 17
1
2
3
5
4
6 7 8
9
10
s1 s2 s3 s4 s5
Figure 1.2 – Acc`es au services
le service s3. Celui-ci n’est plus rendu, il s’agit d’une d´efaillance par arrˆet. Tous les
utilisateurs du syst`eme souhaitant consommer le service s3 per¸coivent cette d´efaillance.
Il s’agit d’une d´efaillance coh´erente.
Consid´erons `a pr´esent le serveur S
2
8
comme un sous-syst`eme du syst`eme consid´er´e.
Dans les mˆemes circonstances, si une panne ´electrique (faute) se produit au niveau du
serveur S
2
8
, celui-ci n’est plus aliment´e (erreur) et ne rend plus le service s2. Dans
le contexte du syst`eme global, la d´efaillance du serveur S
2
8
constitue l’activation d’une
faute. On suppose ici que le serveur S
2
2
prend le relais du serveur S
2
8
, il d´elivre le service
s2 `a l’utilisateur 5. Deux cas se pr´esentent :
— Si ce service est d´elivr´e sans perte de qualit´e, il n’y a pas de d´efaillance.
— A l’inverse, une d´efaillance est pr´esente s’il y a une d´egradation de qualit´e. `
De plus, les entit´es 1, 2, 3, 4, 6 per¸coivent la mˆeme d´efaillance. Il s’agit d’une
d´efaillance coh´erente.
Consid´erons enfin l’ensemble des serveurs S
2
8
et S
2
2
comme un sous-syst`eme du
syst`eme consid´er´e. Dans les mˆemes circonstances, si une panne ´electrique (faute) se
produit au niveau du serveur S
2
8
, celui-ci n’est plus aliment´e (erreur) et ne rend plus le
service s2. Dans le contexte du syst`eme global, la d´efaillance du serveur S
2
8
constitue
l’activation d’une faute. On suppose ici que le serveur S
2
2
prend le relais du serveur S
2
8
,
il d´elivre le service s2 `a l’utilisateur 5. Deux cas se pr´esentent :
— Si ce service est d´elivr´e sans perte de qualit´e, il n’y a pas de d´efaillance.
— A l’inverse, une d´efaillance est pr´esente s’il y a une d´egradation de qualit´e. De `
plus, les entit´es 1, 2, 3, 4, 6 per¸coivent la mˆeme d´efaillance. Cependant, l’entit´e
10 dont le service est d´elivr´e par le serveur S
2
2 ne per¸coit pas de variation de
qualit´e. Il ne s’agit donc pas d’une d´efaillance coh´erente.
1.2 Mod`eles de d´efaillances consid´er´es
Nous nous int´eressons dans le cadre de ce document `a la supervision d’un sousensemble
des entit´es du syst`eme. On s´epare ces entit´es en deux sous-ensembles : d’un18 Mod`ele
cot´e les entit´es supervis´ees, qui consomment des services fournis par le syst`eme tels que
VoIP, VOD, ..., et de l’autre les entit´es qui sont impliqu´ees dans le fonctionnement ou
l’acheminement du service d´elivr´e. Ce second ensemble contient les liens de communication,
les serveurs, les routeurs r´eseau, etc... et est appel´e environnement. Dans la
figure 1.2, les entit´es supervis´ees sont repr´esent´ees par les ronds bleus et l’environnement
par le nuage central.
Nous consid´ererons dans ce document que les fautes activ´ees au sein de l’environnement
peuvent conduire `a des d´efaillances temporelles et coh´erentes. De plus, nous
supposerons que ces d´efaillances v´erifient un ensemble de contraintes d´ecrites au chapitre
3. La validit´e de cette hypoth`ese sera discut´ee lors de l’´evaluation de l’approche
d´ecrite dans ce document au chapitre 4.
D’autre part, nous consid´erons dans les chapitres 3, 4 et 5 que les entit´es supervis´ees
sont sujettes `a des fautes donnant lieu `a des d´efaillances de mˆeme nature : des
d´efaillances temporelles et coh´erentes.
Nous supposons dans ce document que les entit´es supervis´ees effectuent r´eguli`erement
des mesures de qualit´e des services consomm´es. Lorsqu’une faute est activ´ee, sur une
entit´e supervis´ee ou au sein de l’environnement, ces mesures varient de fa¸con anormale.
Nous supposons l’existence d’un m´ecanisme permettant de d´etecter ces variations anormales.
Nous pouvons envisager deux types d’approches pour la mise en œuvre pratique
de ce m´ecanisme de d´etection : les outils de d´etection de changement ou les outils
pr´edictifs. Ces m´ethodes supposent qu’en l’absence de d´efaillances, les valeurs mesur´ees
sont repr´esentatives d’une variable al´eatoire de loi inconnue. La pr´esence d’une
d´efaillance se traduit alors par un changement de distribution des valeurs mesur´ees.
La d´etection de changement est un outil d’analyse s´equentielle visant `a d´etecter les
changements dans la distribution de valeurs d’une s´erie temporelle. Lorsque ces mesures
varient subitement, ces valeurs ne suivent plus cette distribution. Les outils de d´etection
de changement permettent de d´etecter cette variation. Un tel m´ecanisme peut ˆetre par
exemple mis en œuvre au moyen de Cusum (Cumulative Sum control chart) [Pag54].
Les mod`eles pr´edictifs, quant `a eux, estiment `a chaque instant la valeur de la future
mesure. Une diff´erence trop importante entre la mesure effectu´ee `a l’instant suivant et
la mesure pr´edite constitue une d´efaillance. Les m´ethodes de lissage exponentiel [Hol04,
Win60] qui calculent une moyenne (potentiellement pond´er´ee) sur les derni`eres valeurs
mesur´ees et l’utilisent comme pr´evision ou les filtres de Kalman [Kal60] qui permettent
d’estimer l’´etat d’un syst`eme dynamique `a partir d’une s´erie de mesures incompl`etes
ou bruit´ees sont des m´ethodes pr´edictives.
Les chapitres 6 et 7 sont d´edi´es `a la mod´elisation probabiliste et l’´evaluation de
PeerCube qui constitue une partie du syst`eme propos´e. Afin d’´evaluer la pertinence de
cette approche, nous consid´erons un mod`ele de d´efaillances plus fort que celui consid´er´e
au d´ebut de ce document. Dans ces chapitres, nous consid´erons un adversaire contrˆolant
une partie des entit´es supervis´ees du syst`eme. Ces entit´es agissent en collusion et sont
sujettes `a des d´efaillances byzantines. De cette mani`ere, nous ´evaluons ce syst`eme dans
un pire cas.Syst`eme large ´echelle 19
1.3 Syst`eme large ´echelle
Cette section d´efinit la notion de syst`eme large ´echelle et pr´esente les principes
g´en´eraux qui r´egissent la conception de ces syst`emes ainsi que les probl´ematiques associ´ees.
Un syst`eme est dit ”large ´echelle” s’il est compos´e d’un tr`es grand nombre d’entit´es.
On dit qu’un syst`eme ”passe `a l’´echelle”, s’il reste capable de d´elivrer le service pour
lequel il a ´et´e con¸cu, mˆeme lorsque le nombre d’entit´es qui le compose devient tr`es
important. Plus pr´ecis´ement, un syst`eme large ´echelle est un syst`eme dans lequel les
entit´es interagissent au moyen d’algorithmes locaux. Ce type d’algorithmes ne d´epend
que de l’´etat de l’entit´e ainsi que de son voisinage proche. Cette notion de voisinage
varie suivant les syst`emes. Un tel syst`eme passe `a l’´echelle si les complexit´es spatiales
(stockage, m´emoire, ...) et temporelles (nombre de messages, temps de r´eponses, ...) des
algorithmes ex´ecut´es par les entit´es sont sous-lin´eaires en fonction du nombre d’entit´es
pr´esentes dans ce syst`eme.
Les syst`emes pair-`a-pairs sont un exemple de syst`eme large ´echelle dans la mesure o`u
il n’est pas inhabituel qu’ils soient compos´es de plusieurs millions d’entit´es. Le partage
de fichiers est une application bien connue bas´ee sur ce type de syst`eme. Dans ce type
d’application, chaque entit´e joue `a la fois de rˆole de client et de serveur. L’augmentation
du nombre d’entit´es impliqu´ees dans le syst`eme contribue `a faciliter les ´echanges de
fichiers. Ce type de syst`eme passe `a l’´echelle.
Un protocole est un ensemble de r`egles r´egissant les traitements effectu´es par les
entit´es ainsi que la communication entre ces entit´es en vue de rendre le service pour
lequel le syst`eme est con¸cu. Afin que le syst`eme passe `a l’´echelle, il est n´ecessaire
que le protocole consid´er´e utilise des algorithmes locaux. Les entit´es du syst`eme sont
organis´ees logiquement afin que chacune est acc`es `a son voisinage et non `a l’int´egralit´e
du syst`eme. Une architecture ou overlay d´esigne la structure logique issue de cette
organisation logique, permettant ainsi de d´efinir le voisinage d’une entit´e. On distingue
trois enjeux dans la conception de syst`emes large ´echelle :
1. la gestion du grand nombre d’entit´es dans le syst`eme
2. la gestion du dynamisme des entit´es dans le syst`eme
3. la gestion des fautes dans le syst`eme
Gestion de la population Afin d’assurer la propri´et´e de passage `a l’´echelle, les
protocoles de ce type de syst`eme ne s’appuient que sur un sous-ensemble des entit´es
du syst`eme appel´e voisinage. Un protocole d´efinit une structure de r´eseau logique. Ce
r´eseau constitue le substrat n´ecessaire `a la mise en œuvre du service pour lequel le
syst`eme est mis en place. On distingue classiquement deux familles de protocoles : les
protocoles `a architecture non structur´ee et ceux `a architecture structur´ee.
Dans le cas des architectures non structur´ees, le lien logique qui unit deux entit´es
du syst`eme n’a pas de s´emantique. Ces protocoles engendrent g´en´eralement un
graphe de communication proche d’un graphe al´eatoire. Les overlays non structur´es
sont g´en´eralement employ´es dans le cas de protocoles d’agr´egation de donn´ees ou afin20 Mod`ele
de g´erer simplement une grande population d’entit´es. En revanche, ces protocoles ne
sont pas adapt´es `a la recherche de donn´ees. En effet, en l’absence de s´emantique sur
les liens logiques unissant les entit´es du syst`eme, il n’est pas possible d’effectuer une
recherche d´eterministe dans ce type de structure. Par cons´equent, la localisation d’une
entit´e se fait par inondation n´ecessitant ainsi un grand nombre de communications.
A l’inverse, dans le cas des architectures structur´ees, une s´emantique d´efinit le lien `
unissant deux entit´es du syst`eme. Ces protocoles engendrent g´en´eralement des graphe
de communication proches d’un graphe r´egulier. L’exemple le plus courant d’architecture
structur´ee est la table de hachage distribu´ee (DHT). Dans ce type d’architecture,
chaque entit´e se voit attribuer un identifiant unique de m bits issu d’une fonction de
hachage (par exemple MD5 [Riv92] ou SHA-1 [EJ01]). Une entit´e est alors connect´ee `a
une autre si ces deux entit´es satisfont une condition particuli`ere d´efinie par le protocole
concern´e. L’espace des identifiants {0, 1}
m est partitionn´e entre toutes les entit´es du
syst`eme. De la mˆeme mani`ere que pour les entit´es, un identifiant unique de m bits est
attribu´e `a chaque donn´ee g´er´ee par le syst`eme. Chaque donn´ee est g´er´ee par l’entit´e la
plus proche de son identifiant, au sens d’une distance d´efinie par le protocole. Les DHT
offrent ainsi une association (cl´e, valeur) mise en œuvre par les entit´es pr´esentes dans
le syst`eme en utilisant les propri´et´es du graphe de communication. Dans ce document,
nous nous concentrerons sur ce type d’architecture.
Gestion du dynamisme Les entit´es d’un syst`eme large ´echelle peuvent avoir tendance
`a entrer et sortir du syst`eme. N´eanmoins ces entr´ees / sorties ne constituent pas
des d´efaillance par arrˆet, ce type de comportement est usuel dans un syst`eme large
´echelle. A chaque entr´ee ou sortie d’une entit´e du syst`eme, le r´eseau logique d’inter- `
connexion des entit´es doit ˆetre mis `a jour afin d’´eviter un partitionnement du r´eseau
logique ou des incoh´erences. Cette op´eration de mise `a jour peut s’av´erer coˆuteuse et il
est donc n´ecessaire que les protocoles employ´es g`erent ces mises `a jour de mani`ere de
mani`ere locale afin de conserver la propri´et´e de passage `a l’´echelle.
Gestion des comportements fautifs Les entit´es qui composent un syst`eme large
´echelle sont susceptibles de subir des d´efaillances byzantines. Dans ce cas, l’entit´e
n’ex´ecute plus le protocole d´efini et exhibe un comportement arbitraire. Par cons´equent,
une telle entit´e peut fournir des informations erron´ees aux entit´es de son voisinage pouvant
mettre en p´eril la logique du r´eseau d’interconnexion des entit´es ou l’ex´ecution du
protocole d´efini par les entit´es de son propre voisinage. La gestion des comportements
fautifs constitue un ´el´ement cl´e de la conception de ces syst`emes.
Bibliographie
[ALRL04] A. Avizienis, J. C. Laprie, B. Randell et C. Landwehr : Basic Concepts
and Taxonomy of Dependable and Secure Computing. IEEE Transactions
on Dependable and Secure Computing, 1(1):11–33, janvier 2004.Bibliographie 21
[EJ01] D. Eastlake et P. Jones : US Secure Hash Algorithm 1 (SHA1). Rapport
technique, IETF, 2001.
[Hol04] C. C. Holt : Forecasting seasonals and trends by exponentially weighted
moving averages. International Journal of Forecasting, 20(1):5–10, 2004.
[Kal60] R. E. Kalman : A New Approach to Linear Filtering and Prediction Problems.
Transactions of the ASME–Journal of Basic Engineering, 82:35–45,
1960.
[Lap96] J. C. Laprie : Guide de la sˆuret´e de fonctionnement. C´epadu`es-Editions,
1996.
[Pag54] E. S. Page : Continuous Inspection Schemes. Biometrika, 41(1/2):100–115,
juin 1954.
[Riv92] R. Rivest : The MD5 Message-Digest Algorithm. Rapport technique, IETF,
1992.
[Win60] P. R. Winters : Forecasting Sales by Exponentially Weighted Moving
Averages. Management Science, 6:324–342, 1960.22 Mod`eleChapitre 2
Travaux connexes
Nous nous int´eressons dans le cadre de cette th`ese `a distinguer les fautes massives,
donnant lieu `a une d´efaillance per¸cue par un grand nombre d’entit´es du syst`eme, des
fautes isol´ees amenant `a une d´efaillance per¸cue par un nombre restreint d’entit´es. Cette
distinction est fait dans le cadre d’un r´eseau large ´echelle et se base sur la perception
de la qualit´e des services consomm´es par les entit´es supervis´ees sans connaissance de
l’environnement.
Nous pr´esentons dans ce chapitre les approches employ´ees dans la conception des
syst`emes large ´echelle. Nous pr´esentons ensuite diverses approches visant `a regrouper les
donn´ees similaires. Enfin, nous pr´esentons les travaux existants majeurs sur la d´etection
de fautes massives ou isol´ees dans les syst`emes large ´echelle.
2.1 Syst`emes large ´echelle
Comme nous l’avons vu au chapitre pr´ec´edent, on distingue trois enjeux dans la
conception de syst`emes large ´echelle :
1. la gestion du grand nombre d’entit´es dans le syst`eme,
2. la gestion du dynamisme des entit´es dans le syst`eme,
3. la gestion des fautes dans le syst`eme.
Cette section d´etaille les principales approches employ´ees pour la conception de syst`emes
large ´echelle.
2.1.1 Gestion de la population
Les tables de hachage distribu´ees (DHT) sont largement utilis´ees pour la conception
de syst`emes large ´echelle. Ces DHT permettent pour organiser logiquement les entit´es
du syst`eme afin que chacune d’elles ait acc`es `a un sous-ensemble des entit´es du syst`eme
(ce sous-ensemble est appel´e voisinage) et non au syst`eme dans son int´egralit´e. De cette
mani`ere, la propri´et´e de passage `a l’´echelle est assur´ee. Il existe un grand nombre de
DHT, cette partie pr´esente succinctement deux d’entre elles : CAN [RFH+01], con¸cu
en 2001 par Ratnasamy, Francis, Handley, Karp et Shenker, et Chord [SMK+01], con¸cu
2324 Travaux connexes
en 2001 par Stoica, Morris, Karger, Kaashoek et Balakrishnan. Ces DHT font partie
des trois DHT originelles propos´ees en 2001 : Chord, CAN et Pastry [RD01].
Content Addressable Network [RFH+01] (CAN) Dans CAN, les entit´es sont
plac´ees dans un espace virtuel `a d dimensions ayant une structure torique. Chaque entit´e
est responsable d’une zone de cet espace. Un lien logique relie les entit´es g´erant des
zones voisines dans cet espace, assurant ainsi la connectivit´e de l’ensemble du syst`eme.
Lorsqu’une nouvelle entit´e rejoint le syst`eme, celle-ci contacte l’entit´e responsable
de la zone qu’elle doit occuper. Cette zone est s´epar´ee en deux nouvelles zones que
chacune des entit´es va g´erer. A l’inverse, lorsqu’une entit´e quitte le syst`eme, la zone `
dont elle avait la charge est transf´er´ee `a l’entit´e la plus proche. Si les deux zones sont
voisines et de mˆeme surface, celles-ci sont fusionn´ees. La recherche de donn´ees dans
ce syst`eme se fait de proche en proche en contactant l’entit´e voisine la plus proche de
la destination comme l’illustre la figure 2.1. Dans le cas d’un syst`eme compos´e de n
entit´es, une recherche n´ecessite de contacter en moyenne O
n
1/d
entit´es afin de trouver
la donn´ee ou la zone recherch´ee.
1
2
3
4
5 6
7
8
Figure 2.1 – Illustration de CAN pour d = 2
Chord [SMK+01] De mani`ere similaire, Chord organise ses entit´es au moyen de
leur identifiant `a m bits. Ces identifiants sont issus de la fonction de hachage SHA-1
(m = 160). Les entit´es sont ordonn´ees sur un anneau unidimensionnel. Chaque entit´e
g`ere alors la portion de l’anneau entre sa position sur celui-ci et l’entit´e suivante dans
l’anneau. A la diff´erence de CAN qui relie les entit´es voisines dans l’espace virtuel, `
Chord connecte des entit´es `a des distances variables. Ainsi, si une entit´e a pour identit´e
p, alors elle sera reli´ee `a chaque entit´e g´erant les positions p + 2i
, 0 < i < 160 dans
l’anneau. Ces entit´es forment le voisinage de l’entit´e p.
La figure 2.2 illustre un anneau Chord pour m = 4. On a n = 16 entit´es dans
le syst`eme. L’entit´e 0 est li´ee aux entit´es 1, 2, 4 et 8. Ces liens sont repr´esent´es par
les fl`eches pleines. Lors d’une recherche de l’entit´e 11, l’entit´e 0 recherche dans son
voisinage, l’entit´e qui pr´ec`ede 11 dans le sens horaire de l’anneau : l’entit´e 8. Celle-ci
r´eit`ere la recherche, contacte l’entit´e 10 qui contacte `a son tour l’entit´e 11. Le parcours
de cette recherche est repr´esent´e par les fl`eches pointill´ees. Dans un syst`eme comportantSyst`emes large ´echelle 25
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
Figure 2.2 – Illustration de l’anneau Chord pour m = 4
n entit´es, l’utilisation de liens longs permet de d´efinir une notion de voisinage diff´erente
du voisinage physique sur l’anneau. De cette mani`ere, une recherche peut traverser la
moiti´e de l’anneau en un saut et permet ainsi une recherche efficace d’une donn´ee en
contactant O(log n) entit´es en moyenne.
2.1.2 G´erer le dynamisme de la population
Les DHT sont parfaitement adapt´ees pour g´erer de large populations d’entit´es. De
plus elles sont auto-organisantes : l’espace des identifiants est partitionn´e dynamiquement
entre les entit´es pr´esentes dans le syst`eme. D’autre part, ces protocoles offrent
des complexit´es de communication logarithmiques. Cependant, en pr´esence de churn
(fr´equence des entr´ees / sorties) important, la topologie devient tr`es dynamique et de
nombreuses mises `a jours sont n´ecessaires. Des mise `a jours trop fr´equentes peuvent
amener un probl`eme de coh´erence au niveau des entit´es. Dans le pire des cas, la topologie
peut ˆetre scind´ee en plusieurs composantes connexes cr´eant ainsi diff´erentes DHT
s´epar´ees. Cette partie pr´esente succinctement deux DHT r´esilientes aux dynamisme
des entit´es dans le syst`eme : d’une part Kademlia [MM02], con¸cu en 2002 par Maymounkov
et Mazi`eres, et d’autre part eQuus [LSW06], propos´e par Locher, Schmid et
Wattenhofer en 2006.
Kademlia [MM02] Dans Kademlia, la s´emantique du lien unissant deux entit´es est
plus lˆache que dans les DHT telles que CAN ou Chord. Une entit´e dont l’identifiant
`a m bits vaut b0b1 . . . bm−1 est li´ee `a m ensembles de k entit´es appel´es k-buckets. Le
premier bucket contient k entit´es dont l’identifiant d´ebute par b0, le second par b0b1, le
i-eme par b0b1 . . . bi−1.
Une entit´e de Kademlia met `a jour son i-`eme k-bucket d`es qu’elle transf`ere un26 Travaux connexes
message provenant d’une entit´e dont l’identifiant d´ebute par b0b1 . . . bi−1. Ainsi, chaque
k-bucket contient les k derni`eres entit´es du syst`eme vues par l’entit´e courante. De cette
mani`ere, chaque entit´e profite des messages qu’elle fait suivre pour garder une vue `a
jour des entit´es effectivement pr´esentes dans le syst`eme. L’entit´e r´eduit ainsi le nombre
de messages de mise-`a-jour pour maintenir la coh´erence de la topologie.
De la mˆeme mani`ere que Chord, Kademlia emploie des liens de plus en plus ´eloign´es
de l’entit´e courante. Une recherche dans cette architecture n´ecessite de contacter O(log n)
entit´es, dans un syst`eme comportant n entit´es.
eQuus [LSW06] eQuus emploie une m´ethode diff´erente pour g´erer le dynamisme
des entit´es. Contrairement aux architectures pr´ec´edentes dans lesquelles chaque entit´e
g`ere une partie de l’espace des identifiants, eQuus attribue cette gestion `a un ensemble
d’entit´es appel´e clique.
Une clique est un ensemble d’entit´es dont la taille est comprise entre deux param`etres
du syst`eme L et U. De plus, chaque clique est identifi´ee de mani`ere unique
par un identifiant i de d m bits, tel que toutes les entit´es de la clique aient leur
identifiant pr´efix´e par i. Lorsqu’une clique devient sur-peupl´ee, deux nouvelles cliques
sont cr´e´ees en repartissant les entit´es entre elles. A l’inverse, lorsqu’une clique devient `
sous-peupl´ee, elle est fusionn´ee avec une clique existante.
La recherche d’une donn´ee dans eQuus consiste alors `a trouver la clique contenant
l’entit´e ou la donn´ee recherch´ee. L’utilisation des cliques permet de r´eduire le diam`etre
moyen du graphe de communication engendr´e par le protocole, ainsi que le nombre de
liens liant les cliques entre elles. Dans un syst`eme comportant n entit´es, l’utilisation
des cliques identifi´ees par d bits permet ainsi une recherche efficace d’une donn´ee en
contactant O(log2
d n) entit´es en moyenne. Le protocole eQuus absorbe le dynamisme
des entit´es en distinguant deux types de mises-`a-jour des informations maintenues par
celles-ci. La modification de la composition d’une clique est trait´ee imm´ediatement,
toutes les entit´es de la clique mettent `a jour la composition de celle-ci. A l’inverse, les `
entit´es des cliques voisines re¸coivent plus rarement les mises-`a-jour. Une recherche dans
eQuus consiste `a contacter toutes les entit´es pr´esentes dans une clique. Les fr´equences
de mise-`a-jour intra et inter-cliques peuvent alors amener une diff´erence de compositions.
Cette fr´equence des mise-`a-jour inter-clique est param´etr´ee de mani`ere `a ce
que ces compositions soient d’intersection non vide tout en ´evitant les mises-`a-jours
syst´ematiques.
2.1.3 G´erer les comportement fautifs
Les protocoles que nous venons de pr´esenter sont capables de g´erer de grandes populations
d’entit´es et tol`erent de mani`ere variable le dynamisme des entit´es au sein
du syst`eme. N´eanmoins, ces protocoles ne fonctionnent qu’en l’absence de fautes byzantines.
Une entit´e sujette `a une faute byzantine ou entit´e byzantine ne suit pas
n´ecessairement le protocole. Elle se comporte de mani`ere arbitraire. Ce comportement
peut mettre en p´eril la connectivit´e de l’architecture ou amener `a des recherches inabouties.
Cette partie pr´esente succinctement deux DHT r´esilientes aux comporte-Syst`emes large ´echelle 27
ments byzantins : S-chord [FSY05], propos´e par Fiat, Saia et Young en 2005, et PeerCube
[ABLR08], con¸cu par Anceaume, Brasileiro, Ludinard et Ravoaja en 2008.
S-Chord [FSY05] Une am´elioration de Chord visant `a rendre celui-ci tol´erant aux
fautes byzantines est d´ecrite dans [FSY05]. Pour chaque entit´e p de l’anneau est d´efini
l’ensemble S(p) contenant les entit´es q du syst`eme dont la distance de q `a p n’exc`ede
pas C(ln(n))/n, o`u n d´esigne le nombre d’entit´es dans le syst`eme et C est un param`etre
du syst`eme. L’id´ee de S-Chord est de remplacer toutes les communications entre deux
entit´es p et q par des communications entre les ensembles S(p) et S(q). La figure 2.3
illustre un anneau S-Chord pour m = 4 et C(ln n)/n = 2. On a n = 16 entit´es dans
le syst`eme. Comme dans Chord, l’entit´e 0 est li´ee aux entit´es 1, 2, 4 et 8. Lors d’une
recherche de l’entit´e 11, l’entit´e 0 contacte l’ensemble S(0) afin de contacter l’ensemble
S(q) de l’entit´e li´ee la plus proche de 11 tout en la pr´ec´edent. L’ensemble S(0) contacte
alors l’ensemble S(8). Cet ensemble r´eit`ere la recherche contacte l’ensemble S(10) qui
contacte `a son tour l’entit´e S(11). Le parcours de cette recherche est repr´esent´e par les
fl`eches pointill´ees. La figure 2.4 illustre toutes les communications engendr´ees par cette
recherche. Cette approche pour tol´erer les comportements byzantins est sensiblement
plus coˆuteuse en communications que le protocole Chord classique. En pr´esence de
fautes byzantines ind´ependantes, c’est-`a-dire qui ne r´esultent pas d’entit´es malveillantes
agissant en collusion, S-Chord assure ainsi qu’une recherche dans l’overlay compos´e de
n entit´es n´ecessite en moyenne O
log2 n
messages. Cependant, ce type d’approche
engendre O
log3 n
messages lors des entr´ees et sorties des entit´es du syst`eme.Cela
signifie donc que ce type d’approche n’est pas adapt´e dans un contexte tr`es dynamique.
PeerCube [ABLR08] De mani`ere similaire, PeerCube remplace la communication
entre deux entit´es du syst`eme par une communication entre groupes d’entit´es. La topologie
engendr´ee par ce protocole s’approche d’un hypercube parfait dans lequel les
sommets sont constitu´es d’un groupe d’entit´es appel´es cluster. Chaque cluster est en
charge d’une partie de l’espace des identifiants. Contrairement `a S-Chord dans lequel
pour chaque entit´e p du syst`eme il existe un ensemble S(p) lui correspondant, PeerCube
partitionne l’espace des identifiants entre les clusters. Ainsi plusieurs entit´es correspondent
au mˆeme cluster. La communication au sein de l’architecture est assur´ee par
les clusters. Afin de tol´erer le churn naturel pr´esent dans les syst`emes peer-to-peer, les
clusters sont d´ecompos´es en deux sous-ensembles core et spare. Le premier forme une
clique de taille constante γ et assure la connectivit´e du graphe tandis que le second agit
comme un tampon et absorbe les entit´es entrantes dans le cluster de mani`ere transparente
vis-`a-vis du reste du syst`eme. D’autre part, la faible taille γ permet de mettre
en œuvre des algorithmes [CFNV04, KAD+07] de consensus tol´erants au byzantins
afin de g´erer les mises `a jours de la composition du cluster. Les op´erations basiques de
cette architecture n´ecessitent en moyenne O(log n) messages, avec n le nombre d’entit´es
pr´esentes au sein du syst`eme. Enfin, bien que cette approche soit r´esiliente `a la pr´esence
d’entit´es byzantines, celles ci peuvent prendre le contrˆole d’un cluster et mettre en p´eril
l’ex´ecution de recherches dans le syst`eme. PeerCube emploie alors une technique de recherche
redondante sur des chemins ind´ependants assurant ainsi un haut taux de succ`es28 Travaux connexes
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
S(0)
S(8)
S(10)
S(11)
Figure 2.3 – Illustration de l’anneau S-Chord pour m = 4 et C(ln n)/n = 2
0
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
S(0)
S(8)
S(10)
S(11)
Figure 2.4 – Illustration de l’anneau S-Chord pour m = 4 et C(ln n)/n = 2Organisation des donn´ees 29
000
100
001
101
010
110
011
111
1
2
3
4
5
6
7
8
9
10
11
12
Core du cluster de taille γ.
Spare du cluster.
Figure 2.5 – Illustration de l’architecture PeerCube. A gauche, l’organisation en hy- `
percube des clusters, `a droite la composition d’un cluster particulier.
des recherches malgr´e la pr´esence de ces entit´es malveillantes. Une ´etude approfondie
de cette architecture est fournie dans les chapitre 6 et 7 du pr´esent document.
Nous avons pr´esent´e dans cette section un aper¸cu des travaux existants permettant
de g´erer de grandes population d’entit´es au sein d’un syst`eme, ainsi que leur dynamisme
et la pr´esence de fautes impactant ces entit´es. La section suivante traite des donn´ees
g´en´er´ees par ces entit´es et porte plus particuli`erement sur les techniques visant `a regrouper
les donn´ees similaires.
2.2 Organisation des donn´ees
Les entit´es d’un syst`eme g´en`erent de mani`ere continue diverses donn´ees. Il peut
s’agir de donn´ees applicatives ou de donn´ees relatives `a l’´etat interne des entit´es. En
particulier, nous supposons dans le cadre de ce document que les entit´es effectuent
r´eguli`erement des mesures de qualit´es des services consomm´es. De plus, nous supposons
que l’activation d’une faute dans le syst`eme se traduit par une variation de ces mesures
de qualit´e.
Nous nous int´eressons dans le cadre de ce document `a distinguer les fautes pr´esentes
dans le syst`eme suivant le nombre d’entit´es percevant les d´efaillances qui en r´esultent.
Plus pr´ecis´ement, nous nous int´eressons aux fautes ayant un impact sur la qualit´e des
services consomm´es par les entit´es supervis´ees. Nous faisons ici l’hypoth`ese suivante :
l’activation d’une faute dans le syst`eme a un impact similaire sur la qualit´e du service
per¸cue par les entit´es supervis´ees. Afin de distinguer une faute menant `a une d´efaillance30 Travaux connexes
per¸cue par un grand nombre d’utilisateurs de celle per¸cue par un petit nombre d’entre
eux, il est n´ecessaire de regrouper ensemble les variations similaires de qualit´es. On peut
d´etecter les perceptions similaires en partitionnant les entit´es supervis´ees en fonction
des qualit´es mesur´ees par celles-ci.
Nous pr´esentons dans cette section divers travaux existants permettant de regrouper
des donn´ees similaires. On distingue deux approches principales. Les approches bas´ees
sur le partionnement des donn´ees statiques sont pr´esent´ees dans la sous-section 2.2.1.
Les approches travaillant sur des donn´ees dynamiques sont pr´esent´ees dans la soussection
2.2.2.
2.2.1 Partitionnement de donn´ees statiques
La clustering est la tˆache qui consiste `a diviser un ensemble de donn´ees D en
sous-ensembles appel´es clusters de sorte que chaque donn´ee d’un sous-ensemble soit
regroup´ee avec les donn´ees qui lui ressemblent le plus.
La similarit´e est le crit`ere central pour l’identification de clusters dans l’ensemble
de donn´ees D. On distingue diff´erentes notions de similarit´e qui engendrent plusieurs
familles de m´ethodes de partitionnement. S’il existe une distance δ entre les donn´ees
de D, celle-ci peut ˆetre utilis´ee pour partitionner l’ensemble D.
Partitionnement hi´erarchique Les m´ethodes `a partitionnement hi´erarchique cherchent
`a r´epartir les donn´ees d’un ensemble D parmi κ clusters, κ ´etant un param`etre
d’entr´ee de l’algorithme. Initialement, ce type d’algorithme attribue `a chaque donn´ee
x l’ensemble {x}. Ensuite, `a chaque ´etape, l’algorithme fusionne les ensembles les plus
proches au sens d’une distance ∆ sur ces ensembles, et s’arrˆete lorsqu’il ne reste que
κ ensembles. La diff´erence principale entre les diff´erents algorithmes `a partitionnement
hi´erarchique se situe dans la mesure de distance entre ensemble de donn´ees. Par
exemple, l’algorithme SLINK [Sib73] fusionne deux ensembles X, Y lorsque la distance
∆ inter-ensemble ∆(X, Y ) = minx∈X,y∈Y δ(x, y) est minimale. A l’inverse, l’algorithme `
CLINK [Def77] cherche `a minimiser le diam`etre de la r´eunion des ensembles X, Y en minimisant
∆(X, Y ) = maxx∈X,y∈Y δ(x, y). La complexit´e de ces algorithmes est O
|D|
2
,
ces algorithmes sont donc trop coˆuteux pour ˆetre utilis´es dans le contexte des syst`emes
large ´echelle.
Partitionnement orient´e distance Les m´ethodes `a partitionnement hi´erarchique
n´ecessitent de travailler sur l’ensemble des donn´ees D induisant ainsi une complexit´e de
calcul importante. Afin de r´eduire cette complexit´e, des algorithmes [HW79, DLR77]
travaillant sur un sous-ensemble des donn´ees ont ´et´e propos´es.
De la mˆeme mani`ere que les m´ethodes `a partitionnement hi´erarchique, le but de
l’algorithme des κ-moyennes [HW79] est de partitionner les donn´ees de l’ensemble D
en κ sous-ensembles. Cet algorithme est identique `a l’algorithme de quantification de
Lloyd [DLR77]. Les donn´ees de D sont plac´ees dans un espace m´etrique E. L’algorithme
est initialis´e avec un ensemble Σ = {σ1, . . . , σκ}.Organisation des donn´ees 31
Deux m´ethodes principales, d´ecrites dans [HE02], existent pour l’initialisation de
l’algorithme des κ-moyennes. La m´ethode al´eatoire consiste `a choisir uniform´ement κ
donn´ees de D afin de construire l’ensemble initial Σ. A l’inverse, la m´ethode Forgy `
consiste `a choisir uniform´ement κ points de l’espace E.
L’algorithme associe ensuite `a chaque donnn´ee x ∈ D, l’´el´ement de Σ le plus proche
au sens de la distance δ. Les ensembles Σi sont d´efinis par :
∀i ∈ {1, . . . , κ}, Σi = {x ∈ D | δ(x, σi) ≤ δ(x, σj )∀j ∈ {1, . . . , κ}}.
Ces ensembles forment une partition de D. Les ´el´ements de Σ sont replac´es `a la position
de l’isobarycentre des entit´es de Σi
. On a :
∀1 ≤ i ≤ κ, σi =
1
|Σi
|
X
j∈Σi
j.
Ce processus est r´ep´et´e jusqu’`a ce que les ´el´ements de Σ soient stables.
Trouver un partitionnement d’un ensemble de donn´ees D en κ clusters se fait en
appliquant l’algorithme des κ-moyennes. En revanche, trouver la partition qui minimise
la distance au sein des parties est un probl`eme NP-difficile. Un probl`eme NP-difficile
est un probl`eme de d´ecision pour lequel on ne sait pas v´erifier une solution en temps
polynomial.
Par cons´equent, on utilise des heuristiques pour le crit`ere d’arrˆet de l’algorithme.
Une solution courante consiste `a fournir un nombre I d’it´erations et de consid´erer
les parties Σi comme une partition valable. Dans un espace de dimension d, la complexit´e
de cet algorithme est O(Idκ|D|)), avec I le nombre d’it´erations, κ le nombre
sous-ensembles de la partition et D l’ensemble des donn´ees initial. Bien que cet algorithme
ait une complexit´e lin´eaire en nombre de donn´ees trait´ees, celui-ci est facilement
parall´elisable.
D’autre part, l’algorithme heuristique construit it´erativement une partition minimisant
la distance au sein des clusters. Cet algorithme converge donc vers un minimum
local. Afin de pallier le biais introduit pas le choix initial de l’ensemble Σ, cet algorithme
est ex´ecut´e `a diverses reprises afin d’´eviter un minimum local et ne conserver que la
meilleure partition finale. L’algorithme des κ-moyennes est d´etaill´e dans le chapitre 5.
Diff´erentes variantes de cet algorithme ont ´et´e propos´ees. A la diff´erence de l’algo- `
rithme des κ-moyennes qui calcule les ensembles Σi
, 1 ≤ i ≤ κ centr´es sur l’isobarycentre
de cet ensemble, l’algorithme κ-medoids [KR87] centre ces ensembles sur une donn´ee
x ∈ D. De plus, cet algorithme utilise la norme 1 comme distance, le rendant plus
robuste `a la pr´esence de donn´ees anormales.
L’algorithme des c-moyennes [BEF84] quant `a lui n’effectue pas un partitionnement
de l’ensemble des donn´ees D. A l’inverse, cet algorithme attribue `a chaque donn´ee `
x ∈ D, un degr´e d’appartenance `a chaque ensemble Σi
, 1 ≤ κ.
L’inconv´enient majeur de ces approches est le param´etrage de κ. En effet, il n’est
pas possible de connaˆıtre a priori la valeur id´eale de ce param`etre. Des m´ethodes [PM00]
visent `a estimer la valeur id´eale de ce param`etre pour l’ensemble de donn´ees D consid´er´e,
n´ecessitant ainsi un pr´etraitement de l’ensemble des donn´ees.32 Travaux connexes
Partitionnement orient´e densit´e Afin de s’affranchir des contraintes d’initialisation
et du nombre κ de clusters recherch´es, d’autres approches ont ´et´e envisag´ees.
L’algorithme DBSCAN [EKSX96] divise l’ensemble de donn´ees D en sous-ensembles
de forte densit´e s´epar´es par des espaces de faible densit´e. L’algorithme DBSCAN est
d´etaill´e dans le chapitre 4. Cet algorithme requiert deux param`etres, ε et m, et une
distance δ. Le param`etre ε permet de d´efinir le voisinage d’une entit´e tandis que le
param`etre m d´efinit un seuil de densit´e sur ce voisinage. Deux donn´ees x, y ∈ D sont
voisines si δ(x, y) ≤ ε. Le voisinage Nε(x) d’une donn´ee x ∈ D est dense s’il contient
plus de m donn´ees, la donn´ee x est alors dite centrale. L’algorithme DBSCAN parcourt
l’ensemble des donn´ees D. Pour chaque donn´ee centrale non visit´ee, l’algorithme
cr´ee un nouveau sous-ensemble et lui ajoute cette donn´ee ainsi que son voisinage. Si
ce voisinage contient des donn´ees centrales, le voisinage de celles-ci est ajout´e au sousensemble
courant. Les donn´ees sont ainsi trait´ees de proche en proche et le calcul
du sous-ensemble courant s’arrˆete lorsque toutes les donn´ees centrales et leur voisinage
ainsi atteignables ont ´et´e trait´ees. Cet algorithme n´ecessite de traiter toutes les donn´ees
et pour chacune d’elle de construire son voisinage. Par cons´equent, la complexit´e de cet
algorithme est O
|D|
2
. L’utilisation de structure d’indexation de donn´ees spatiales du
type R*-tree [BKSS90] permet de r´eduire cette complexit´e `a O(|D| log |D|).
A la diff´erence de l’algorithme des ` κ-moyennes qui n´ecessite de sp´ecifier le nombre de
sous-ensembles recherch´es, DBSCAN construit lui-mˆeme le nombre de sous-ensembles
n´ecessaires. De plus, il n’y a pas de probl`eme d’initialisation, toute ex´ecution de l’algorithme
m`ene globalement aux mˆemes sous-ensembles : une seule ex´ecution de l’algorithme
est suffisante pour les construire. Cependant, il arrive que deux ex´ecutions
attribuent une mˆeme donn´ee `a des sous-ensembles diff´erents. Cela arrive lorsqu’une
donn´ee n’est pas centrale mais qu’elle appartient `a l’intersection des voisinages de deux
donn´ees centrales appartenant `a des sous-ensembles diff´erents. Suivant l’ordre de traitement
des donn´ees, celle-ci est class´ee dans l’un ou l’autre des sous-ensembles.
L’algorithme DBSCAN d´efinit une notion de densit´e fonction de deux param`etres
ε et m et construit des clusters `a partir de celle-ci. Si l’ensemble des donn´ees D est
constitu´e de divers sous-ensembles de densit´es diff´erentes, DBSCAN ´echoue `a les retrouver.
D’autres approches, par exemple OPTICS [ABKS99], ont ´et´e propos´ees afin de
pallier cette limite. OPTICS suit la mˆeme id´ee que DBSCAN en distinguant les donn´ees
centrales. Cependant, en introduisant une seconde distance ε
0 d´efinie comme la plus petite
distance entre une donn´ee x ∈ D et une donn´ee y ∈ Nε(x), OPTICS peut g´erer
des sous-ensembles de densit´es diff´erentes ε
0/m. D’autre part, GDBSCAN [SEKX98]
est une g´en´eralisation de DBSCAN. Dans GDBSCAN, les deux param`etres ε et m sont
remplac´es par des fonctions plus g´en´erales d´efinissant la notion de voisinage ainsi que la
notion de densit´e. Cette g´en´eralisation permet alors de partitionner des donn´ees pour
lesquelles il n’y a pas de notion de distance.
2.2.2 Donn´ees dynamiques
Initialement, les techniques de clustering ont ´et´e utilis´ees sur des donn´ees statiques.
Elles ont ´et´e ensuite ´etendues sur des donn´ees ayant une ´evolution temporelle. PlutˆotSupervision 33
que de consid´erer les donn´ees `a chaque instant et d’y appliquer les techniques de clustering
que nous venons de voir, les approches [JYZ+08, JLO07] ´etudient l’´evolution,
l’apparition et la disparition des clusters au cours du temps en fonction de l’´evolution
temporelle des donn´ees.
Cependant, comme nous l’avons vu, le clustering cherche `a regrouper des donn´ees
similaires. La notion de similarit´e est centrale dans ce regroupement. Aucun des travaux
que nous avons pr´esent´e ne borne l’´ecart de similarit´e entre deux donn´ees d’un mˆeme
sous-ensemble. Par exemple, dans le cas de l’algorithme κ-moyennes, une donn´ee x ∈ D
est associ´ee au plus proche ´el´ement σi
, 1 ≤ i ≤ κ. C’est donc la position des σi qui
d´etermine la distance maximale entre deux ´el´ements d’un mˆeme cluster Σi
. Ainsi, la
distance entre deux donn´ees x, y ∈ Σi peut ˆetre arbitrairement grande.
De la mˆeme mani`ere dans le cas des algorithmes bas´es sur la densit´e des donn´ees,
deux donn´ees appartiennent `a un mˆeme cluster s’il existe suffisamment de donn´ees
centrales entre elles de sorte que ces donn´ees soient connect´ees de proche en proche par
un chemin dense. Cette fois encore, deux donn´ees peuvent donc appartenir `a un mˆeme
cluster tout en ayant une similarit´e tr`es faible.
L’utilisation de la notion de groupe est une autre approche visant `a regrouper des
donn´ees dynamiques. Un groupe est d´efini comme un ensemble contenant plus de τ
donn´ees dont la distance maximale entre deux donn´ees n’exc`ede pas un param`etre fix´e
r dans un intervalle de temps donn´e. Ces travaux portant sur la recherche de groupe
tels que [BGHW06, BGHW08, BBG08, VBT09], s’int´eressent `a exhiber les donn´ees
formant un groupe le plus longtemps possible sans contrainte de partitionnement des
donn´ees. La recherche de mouvements de groupes d´ecrite se diff´erencie du clustering
par trois aspects.
1. Ce type d’approche s’int´eresse `a exhiber l’ensemble des groupes auquel une
donn´ee appartient, sans cependant imposer le partitionnement (appartenance `a
un unique cluster) pr´esent dans le clustering.
2. A l’inverse du clustering, o`u l’on cherche `a construire des clusters, la recherche `
de mouvements de groupes est centr´ee sur les donn´ees et leur potentielle appartenance
`a diff´erents ensembles.
3. Des donn´ees ayant une similarit´e trop faible ne peuvent ˆetre regroup´ees ensemble.
On observe alors `a des instants discrets l’ensemble des donn´ees D et
celles-ci sont regroup´ees en sous-ensembles dont la distance maximale entre deux
´el´ements n’exc`ede pas un seuil pr´ed´efini r `a chaque instant discret.
Nous avons pr´esent´e dans cette section les diff´erents travaux existants permettant
de regrouper ensemble des donn´ees similaires d’un ensemble de donn´ees. La section suivante
pr´esente l’utilisation de ces techniques dans le contexte de la supervision d’entit´es
et la caract´erisation de fautes.
2.3 Supervision
Nous avons pr´esent´e dans les sections pr´ec´edentes diff´erents travaux existants permettant
de g´erer un grand ensemble d’entit´es ainsi que les donn´ees qu’elles sont sus-34 Travaux connexes
ceptibles de g´en´erer. Nous pr´esentons `a pr´esent l’utilisation de ces techniques dans le
contexte de la supervision d’entit´es et la caract´erisation de fautes.
2.3.1 Etat global du syst`eme ´
Les entit´es supervis´ees g´en`erent de mani`ere continue un ensemble de donn´ees qui
sont ensuite mises en forme au sein d’une interface de supervision au niveau d’une entit´e
appel´ee superviseur. Ces donn´ees sont variables et peuvent par exemple repr´esenter
l’´etat interne de l’entit´e, une qualit´e de service, etc...
Les syst`emes de supervision sont des ´el´ements cl´es pour la caract´erisation des fautes
dans le syst`eme. Le but de ces syst`emes est de rendre compte de mani`ere continue de
l’´etat du syst`eme consid´er´e. Il est donc n´ecessaire pour ces syst`emes d’ˆetre capable
d’appr´ehender le syst`eme supervis´e dans son ensemble, de mani`ere r´eactive et avec un
faible surcoˆut afin de ne pas perturber le bon fonctionnement du syst`eme supervis´e.
On distingue alors deux types d’approches dans la supervision : celles fournissant
une vue agr´eg´ee du syst`eme et celles cherchant `a avoir une vision de l’´etat de chacun
des ´el´ements du syst`eme supervis´e. Astrolabe [VRBV03] et SDIMS [YD04] organisent
de mani`ere distribu´ee les entit´es du syst`eme supervis´e. Les entit´es sont organis´ees
de mani`ere hi´erarchique en fonction des donn´ees g´en´er´ees qu’elles g´en`erent. Cette
hi´erarchie permet alors de collecter et d’agr´eger les informations relatives aux entit´es
du syst`eme. De cette mani`ere, ces syst`emes fournissent une vue r´esum´ee de la sant´e de
l’ensemble du syst`eme. Les travaux d´ecrits dans ce document portent sur la supervision
d’un ensemble d’entit´es et la caract´erisation de fautes, ces approches ne sont donc pas
adapt´ees dans notre contexte.
A l’inverse, Ganglia [MCC03], CoMon [PP06] et InfoTrack [ZTG ` +09] supervisent
chacune des entit´es du syst`eme. Ces approches exploitent les similarit´es entre les donn´ees
g´en´er´ees par les entit´es supervis´ees afin de r´eduire la communication entre les entit´es
et l’interface de supervision. Par exemple, InfoTrack repose sur deux principes : autocorr´elation
et clustering. Les entit´es supervis´ees sont regroup´ees en κ clusters (issus de
l’ex´ecution de l’algorithme κ-moyennes) par rapport `a une mesure de similarit´e sur les
donn´ees g´en´er´ees.
Au sein de chaque cluster, l’entit´e dont les donn´ees g´en´er´ees sont les plus proches
de la valeur m´ediane des donn´ees g´en´er´ees par l’ensemble des entit´es du cluster prend
en charge la communication avec l’ext´erieur du cluster. Cette entit´e est appel´ee leader
du cluster. Afin de diminuer la communication entre les entit´es, celles-ci sont munies
d’outils de pr´ediction [Kal60]. Les leaders sont munis du mˆeme outil de pr´ediction.
Ainsi, `a chaque instant le leader a acc`es aux mˆeme pr´edictions que chacune des entit´es
du cluster. Par cons´equent, lorsque la donn´ee effective est proche de la donn´ee pr´edite,
aucune communication entre l’entit´e et le leader n’est n´ecessaire. Dans le cas contraire,
l’entit´e communique la donn´ee effective au leader. Le mˆeme m´ecanisme est mis en place
entre les leaders de chaque cluster et le superviseur.
Le leader maintient de plus un compteur pour chaque entit´e du cluster. Ce compteur
est incr´ement´e lorsque le leader effectue une pr´ediction en accord avec la donn´ee
g´en´er´ee par l’entit´e, et d´ecr´ement´e dans le cas contraire. Lorsque le compteur d’uneSupervision 35
entit´e est inf´erieur `a un seuil pr´ed´efini θ1, les donn´ees qu’elle g´en`ere ne sont plus en
ad´equation avec les donn´ees g´en´er´ees par les autres entit´es du cluster. Cette entit´e est
alors replac´ee dans un autre cluster plus appropri´e. A l’inverse, si un nombre ` θ2 d’entit´es
du cluster doivent ˆetre replac´ees, cela signifie que le leader n’est plus repr´esentatif des
entit´es du cluster. Un nouveau leader est alors choisi. Ces op´erations de maintenance
sont effectu´ees de mani`ere centralis´ee par le superviseur. Les r´esultats exp´erimentaux
montrent ainsi une diminution des coˆuts de communication de 50 `a 90% tout en conservant
une haute `a pr´ecision (de 1 `a 5% d’erreur).
Cependant, ce type d’approche n’est applicables qu’aux mesures locales (comme
la charge CPU, consommation m´emoire, temps de fonctionnement sans red´emarrage,
etc...). Ce type de mesure est continu et ne d´epend pas de l’activit´e utilisateur. De
plus, la stabilit´e et pr´edictibilit´e de ce type de mesure permet de r´eduire efficacement
les communications n´ecessaires `a la supervision.
L’initialisation de ce type de solution repose sur l’ex´ecution d’algorithme de clustering
par le superviseur. Cette ex´ecution initial est effectu´ee hors-ligne. Le partitionnement
ainsi calcul´e est mis-`a-jour lorsqu’une entit´e doit ˆetre replac´ee. D’autre part,
les variations dans ces mesures peuvent ˆetre symptomatiques d’une faute au niveau
d’une entit´e supervis´ee. Ce type d’approche permet donc de d´etecter des d´efaillances
par le replacement d’une entit´e mais ne permet pas de caract´eriser le type de faute
sous-jacent. Les d´efaillances qui impactent un grand nombre d’entit´es sont donc tr`es
coˆuteuses d’un point de vue algorithmique. L’absence de caract´erisation ne fournit donc
pas d’indice sur les causes qui ont provoqu´e la d´efaillance.
2.3.2 Caract´erisation de fautes
Lorsqu’une faute est activ´ee dans le syst`eme, celle-ci peut induire une d´efaillance.
Cette d´efaillance se traduit par une d´egradation de la qualit´e du service rendu par le
syst`eme. Les outils de supervision que l’on vient de pr´esenter sont destin´es `a fournir
une vision globale de la sant´e du syst`eme. En revanche, ces outils ne permettent pas
de localiser la faute qui a impact´e le syst`eme. La localisation de fautes [MA04] consiste
`a d´eduire la cause effective d’une d´efaillance `a partir d’un ensemble d’observations.
On distingue trois types d’approches pour la localisation de fautes. Le recours `a des
syst`emes experts qui consiste `a mettre en place des r`egles ou des arbres de d´ecisions ;
les mod`eles de propagation de fautes qui s’appuient sur des graphes de d´ependances,
et enfin la connaissance du graphe de communication entre les entit´es.
La connaissance suppl´ementaire requise dans le cadre de la localisation de fautes
n’est pas envisageable dans le cadre de la supervision de syst`emes large ´echelle. Dans le
cadre de cette th`ese, nous souhaitons caract´eriser les fautes qui induisent une d´efaillance
dans le syst`eme suivant le nombre d’entit´es qui per¸coivent cette d´efaillance. Cette
caract´erisation permettra ensuite de r´eduire la connaissance additionnelle n´ecessaire
`a la localisation de fautes.
Tiresias [HCDW12], Argus [YFG+12] et CEM [CBG10] sont trois approches li´ees `a
la caract´erisation de fautes dans les r´eseaux large ´echelle. Ces trois approches reposent
sur la perception de d´efaillances par les utilisateurs du syst`eme.36 Travaux connexes
Tiresias Cette approche [HCDW12] classifie des donn´ees op´erationnelles d’apr`es six
´etapes. Ces donn´ees sont issues des appels des clients au service de support d’un FAI
ainsi que de l’analyse des donn´ees de journalisation des pannes sur les ´equipements
clients. Ces donn´ees sont horodat´ees et associ´ees `a un niveau hi´erarchique du r´eseau. Ces
donn´ees proviennent de divers endroits dans le r´eseau, arrivent en masse et de mani`ere
continue au niveau du serveur Tiresias. Le serveur maintient une fenˆetre temporelle
divis´ee en diff´erents intervalles de temps. Une donn´ee est affect´ee `a l’intervalle de temps
au cours duquel elle a ´et´e produite. Chaque donn´ee est ensuite plac´ee dans un arbre
en fonction du niveau hi´erarchique qui lui est associ´e et un poids lui est attribu´e. Un
traitement math´ematique est effectu´e sur les donn´ees dont le poids associ´e est situ´e au
dessus d’un seuil pr´ed´efini θ. Ce traitement permet d’exhiber les donn´ees anormales
traduisant l’activation d’une faute impactant un grand nombre d’utilisateurs.
Cette approche souffre de trois limitations. Tout d’abord, Tiresias s’appuie sur
les appels des utilisateurs et d´eporte donc la tˆache de d´etection de faute au niveau
de l’utilisateur. Il n’y a donc pas de garantie sur le d´elai entre la d´etection de la
faute par l’utilisateur et la notification au centre de support. D’autre part, chaque
donn´ee est trait´ee manuellement par un technicien qui choisit le niveau hi´erarchique
`a associer `a la donn´ee op´erationnelle. Ce traitement humain est donc source d’erreurs
et est incompatible avec un traitement des donn´ees `a la vol´ee. Enfin, cette approche
s’appuie sur la connaissance du r´eseau d’interconnexion et se limite de plus aux r´eseaux
`a structure hi´erarchique (comme les r´eseaux IPTV).
Argus De mani`ere similaire `a Tiresias, Argus [YFG+12] a une approche centralis´ee.
Cette approche s’appuie sur le d´eploiement par les fournisseurs d’acc`es `a Internet de
leurs propre r´eseaux de services CDN, VoIP, IPTV afin de mutualiser la tˆache de supervision.
Ainsi, Argus tire parti des informations relatives `a la topologie r´eseau, au
routage, `a la g´eographie, et aux mesures de performance de bout en bout. Comme la
totalit´e de l’environnement est maˆıtris´e, Argus peut superviser les mesures de performance
du point de vue serveur et non du point de vue du client. Ainsi, les utilisateurs
sont clusteris´es de mani`ere hi´erarchique par rapport `a leur localisation dans la topologie
r´eseau. Argus g´en`ere ensuite pour chaque groupe d’utilisateurs, une s´erie temporelle correspondant
aux mesures de performances agr´eg´ees sur le groupe d’utilisateur concern´e.
Ces s´eries temporelles sont ensuite utilis´ees pour d´etecter des fautes qui impactent tout
ou partie du groupe d’utilisateur concern´e.
L’approche centralis´ee d’Argus n´ecessite de traiter l’ensemble des donn´ees g´en´er´ees
par l’ensemble des utilisateurs consommant les services propos´es au sein du r´eseau du
FAI. Par cons´equent, il se pose un probl`eme clair vis-`a-vis du passage `a l’´echelle de cette
solution. De plus, Argus adopte un point de vue totalement omniscient vis-`a-vis de la
caract´erisation des fautes qui impactent le syst`eme : la topologie, le positionnement des
diff´erents serveurs et des clients sont connus et utilis´es pour caract´eriser les fautes.
CEM De la mˆeme mani`ere, CEM [CBG10, Cho10] cherche `a distinguer les fautes
impactant un petit nombre d’entit´es supervis´ees des fautes dont la d´efaillance est per¸cueSupervision 37
par un grand nombre d’entit´es. Dans le cas d’une d´egradation anormale de la qualit´e
d’un service consomm´e par une entit´e, celle-ci incr´emente un compteur situ´e une table
de hachage distribu´ee [MM02]. La cl´e utilis´ee pour l’´ecriture dans la table de hachage
distribu´ee correspond `a l’identifiant du syst`eme autonome auquel l’entit´e supervis´ee
appartient. Un Syst`eme Autonome est un r´eseau au sein d’Internet dont la politique
de routage est coh´erente. Les syst`emes autonomes sont interconnect´es et forment ainsi
Internet. Le r´eseau d’un fournisseur d’acc`es `a Internet est g´en´eralement un Syst`eme
Autonome. Chaque syst`eme autonome est identifi´e de mani`ere unique par une valeur
utilis´ee lors du routage par BGP (Border Gateway Protocol [RLH06]) entre les diff´erents
syst`emes autonomes.
Plusieurs entit´es peuvent percevoir une d´efaillance mais cela ne suffit pas `a assurer
qu’il s’agit d’une mˆeme d´efaillance induite par une mˆeme faute. Deux cas sont
envisageables :
Cas 1 diverses fautes concomitantes et ind´ependantes m`enent aux d´efaillances per¸cues
par les entit´es,
Cas 2 une unique faute provoque une d´efaillance per¸cue par ces mˆemes entit´es.
Les auteurs de CEM proposent une mesure de vraisemblance not´ee LR. Cette mesure
est utilis´ee comme un seuil permettant de faire la distinction entre ces deux cas. Cette
mesure correspond au rapport LR = Pe/Pu entre la probabilit´e Pe que n entit´es distinctes
per¸coivent des d´efaillances dues `a n fautes distinctes dans un intervalle de temps
donn´e (permier cas) et la probabilit´e Pu que n entit´es per¸coivent une d´efaillance due
`a une mˆeme faute dans ce mˆeme intervalle de temps (second cas). Une valeur de vraisemblance
LR > 1 tend `a indiquer une d´efaillance li´ee au r´eseau tandis que LR ≤ 1
tend `a indiquer des d´efaillances individuelles.
Cette approche est ensuite compar´ee aux donn´ees op´erationnelles de divers fournisseurs
d’acc`es `a Internet. La valeur de LR est centrale dans la caract´erisation des fautes
impactant le syst`eme. Celle-ci est positionn´ee statiquement `a partir des donn´ees issues
des donn´ees op´erationnelles des divers fournisseurs d’acc`es `a Internet. Cette approche
est ensuite appliqu´ee sur des mesures de qualit´e collect´ees `a partir de clients BitTorrent.
Le r´esultat de la caract´erisation est ensuite compar´ee `a la vision des diff´erents
fournisseurs d’acc`es `a Internet pendant la p´eriode consid´er´ee.
Les r´esultats de cette comparaison sont difficiles `a interpr´eter. Sur l’ensemble des
d´efaillances que les fournisseurs d’acc`es `a Internet attribuent `a des fautes massives,
CEM en attribue 80% `a des fautes massives. Cependant, cette proportion repr´esente
seulement 30% des d´efaillances attribu´ees `a des fautes massives par CEM. Les op´erateurs
n’ont pas connaissance des 70% restant de d´efaillances d´ecel´ees par cette approche. Par
cons´equent, il est impossible de savoir s’il s’agit de faux positifs de cette approche
ou d’une tr`es forte proportion de d´efaillances ignor´ees par les fournisseurs d’acc`es `a
Internet.
Bien que cette approche soit une premi`ere approche vers la caract´erisation des fautes
impactant le syst`eme en fonction du nombre d’entit´es percevant la d´efaillance induite,
celle-ci pr´esente des limitations. Tout d’abord, celle-ci requi`ere une connaissance du
r´eseau afin de regrouper ensemble les perceptions des entit´es d’un mˆeme syst`eme auto-38 Travaux connexes
nome. Ensuite, le seuil de classification LR est fix´e de mani`ere empirique par l’analyse
statistique de donn´ees issues de diff´erents fournisseurs d’acc`es `a Internet. Enfin, bien
que cette approche soit un premier permettant de caract´eriser une faute en fonction de
son impact, la validation de cette approche n’est pas tout `a fait convaincante dans la
mesure o`u l’on ne sait pas si les 70% de d´efaillances suppl´ementaires d´ecel´ees constituent
de r´eelles d´efaillances ou des faux positifs.
Nous avons pr´esent´e dans ce chapitre les concepts n´ecessaires aux travaux d´ecrits
dans ce document. De plus, nous avons d´ecrit les techniques classiques utilis´ees dans
les syst`emes distribu´es large ´echelle ainsi que dans le cadre du clustering de donn´ees.
Enfin, ces techniques nous ont permis de pr´esenter les travaux connexes existants sur
la supervision et la caract´erisation de fautes dans les r´eseaux large ´echelle.
Bibliographie
[ABKS99] M. Ankerst, M. M. Breunig, H. P. Kriegel et J. Sander : OPTICS :
Ordering Points To Identify the Clustering Structure. Dans Proceedings
of the ACM SIGMOD International Conference on Management of Data,
pages 49–60, 1999.
[ABLR08] E. Anceaume, F. Brasileiro, R. Ludinard et A. Ravoaja : Peercube :
A hypercube-based p2p overlay robust against collusion and churn. Dans
Proceedings of the IEEE International Conference on Self-Adaptive and
Self-Organizing Systems, SASO, pages 15–24, 2008.
[BBG08] K. Buchin, M. Buchin et J. Gudmundsson : Detecting Single File Movement.
Dans Proceedings of the 16th ACM SIGSPATIAL International
Conference on Advances in Geographic Information Systems, pages 1–10,
2008.
[BEF84] J. C Bezdek, R. Ehrlich et W. Full : FCM : The Fuzzy C-Means
Clustering Algorithm. Computers & Geosciences, 10(2):191–203, 1984.
[BGHW06] M. Benkert, J. Gudmundsson, F. Hubner ¨ et T. Wolle : Reporting
flock patterns. Dans Proceedings of the 14th European Symposium on Algorithms,
ESA, pages 660–671, 2006.
[BGHW08] M. Benkert, J. Gudmundsson, F. Hubner ¨ et T. Wolle : Reporting
Flock Patterns. Computational Geometry Theory and Applications, 41(3):
111–125, novembre 2008.
[BKSS90] N. Beckmann, H. P. Kriegel, R. Schneider et B. Seeger : The R*-
tree : An Efficient and Robust Access Method for Points and Rectangles.
Dans Proceedings of the ACM SIGMOD International Conference on Management
of Data, pages 322–331, 1990.
[CBG10] D. R. Choffnes, F. E. Bustamante et Z. Ge : Crowdsourcing Servicelevel
Network Event Monitoring. Dans Proceedings of the ACM SIGCOMM
Conference, pages 387–398, 2010.Bibliographie 39
[CFNV04] M. Correia, N. Ferreira Neves et P. Ver´ıssimo : How to Tolerate
Half Less One Byzantine Nodes in Practical Distributed Systems. Dans
Proceedings of the 23rd International Symposium on Reliable Distributed
Systems, SRDS, pages 174–183, 2004.
[Cho10] D. R. Choffnes : Service-Level Network Event Detection from Edge Systems.
Th`ese de doctorat, Northeastern University, 2010.
[Def77] D. Defays : An efficient algorithm for a complete link method. The
Computer Journal, 20(4):364–366, 1977.
[DLR77] A. P. Dempster, N. M. Laird et D. B. Rubin : Maximum Likelihood from
Incomplete Data via the EM Algorithm. Journal of the Royal Statistical
Society : Series B, 39:1–38, 1977.
[EKSX96] M. Ester, H. P. Kriegel, J. Sander et X. Xu : A Density-Based Algorithm
for Discovering Clusters in Large Spatial Databases with Noise. Dans
Proceedings of the 2nd International Conference on Knowledge Discovery
and Data Mining, KDD, pages 226–231, 1996.
[FSY05] A. Fiat, J. Saia et M. Young : Making Chord Robust to Byzantine
Attacks. Dans Proceedings of the 13rd European Symposium on Algorithms,
ESA, pages 803–814, 2005.
[HCDW12] C. Y. Hong, M. Caesar, N. Duffield et J. Wang : Tiresias : Online
Anomaly Detection for Hierarchical Operational Network Data. Dans Proceedings
of the 32nd IEEE International Conference on Distributed Computing
Systems, ICDCS, pages 173–182, 2012.
[HE02] G. Hamerly et C. Elkan : Alternatives to the K-means Algorithm That
Find Better Clusterings. Dans Proceedings of the 11th International Conference
on Information and Knowledge Management, CIKM, pages 600–607,
2002.
[HW79] J. A. Hartigan et M. A. Wong : Algorithm AS 136 : A K-Means Clustering
Algorithm. Journal of the Royal Statistical Society. Series C (Applied
Statistics), 28(1):100–108, 1979.
[JLO07] C. S. Jensen, D. Lin et Beng-Chin O. : Continuous Clustering of Moving
Objects. Knowledge and Data Engineering, IEEE Transactions on, 19(9):
1161–1174, 2007.
[JYZ+08] H. Jeung, M. L. Yiu, X. Zhou, C. S. Jensen et H. T. Shen : Discovery
of Convoys in Trajectory Databases. Proceedings VLDB Endowment, 1(1):
1068–1080, aoˆut 2008.
[KAD+07] R. Kotla, L. Alvisi, M. Dahlin, A. Clement et E. Wong : Zyzzyva :
Speculative Byzantine Fault Tolerance. Dans Proceedings of the 21st ACM
SIGOPS Symposium on Operating Systems Principles, SOSP, pages 45–58,
2007.
[Kal60] R. E. Kalman : A New Approach to Linear Filtering and Prediction
Problems. Transactions of the ASME–Journal of Basic Engineering, 82:35–
45, 1960.40 Travaux connexes
[KR87] L. Kaufman et P. Rousseeuw : Clustering by Means of Medoids. Reports
of the Faculty of Mathematics and Informatics. Delft University of
Technology. 1987.
[LSW06] T. Locher, S. Schmid et R. Wattenhofer : eQuus : A Provably Robust
and Locality-Aware Peer-to-Peer System. Dans Proceedings of the 6th
IEEE International Conference on Peer-to-Peer Computing, P2P, pages
3–11, 2006.
[MA04] S. Malgorzata et S. S. Adarshpal : A survey of fault localization
techniques in computer networks. Science of Computer Programming,
53(2):165–194, 2004.
[MCC03] M. L. Massie, B. N. Chun et D. E. Culler : The Ganglia Distributed
Monitoring System : Design, Implementation And Experience. Parallel
Computing, 30:2004, 2003.
[MM02] P. Maymounkov et D. Mazieres ` : Kademlia : A Peer-to-Peer Information
System Based on the XOR Metric. Dans Revised Papers from the First
International Workshop on Peer-to-Peer Systems, IPTPS, pages 53–65,
2002.
[PM00] D. Pelleg et A. Moore : X-means : Extending K-means with Efficient
Estimation of the Number of Clusters. Dans Proceedings of the 17th International
Conference on Machine Learning, pages 727–734, 2000.
[PP06] K. Park et V. S. Pai : CoMon : A Mostly-scalable Monitoring System for
PlanetLab. SIGOPS Operating Systems Review, 40(1):65–74, janvier 2006.
[RD01] A. Rowstron et P. Druschel : Pastry : Scalable, Decentralized Object
Location, and Routing for Large-Scale Peer-to-Peer Systems. Dans Proceedings
of the IFIP/ACM International Conference on Distributed Systems
Platforms, Middleware, pages 329–350, 2001.
[RFH+01] S. Ratnasamy, P. Francis, M. Handley, R. Karp et S. Shenker : A
Scalable Content-addressable Network. Dans Proceedings of the Conference
on Applications, Technologies, Architectures, and Protocols for Computer
Communications, SIGCOMM, pages 161–172, 2001.
[RLH06] Y. Rekhter, T. Li et S. Hares : RFC 4271 : A Border Gateway Protocol
4 (BGP-4). Rapport technique, IETF, 2006.
[SEKX98] J. Sander, M. Ester, H.P. Kriegel et X. Xu : Density-Based Clustering
in Spatial Databases : The Algorithm GDBSCAN and Its Applications.
Data Mining and Knowledge Discovery, 2(2):169–194, 1998.
[Sib73] R. Sibson : SLINK : an optimally efficient algorithm for the single-link
cluster method. The Computer Journal, 16(1):30–34, 1973.
[SMK+01] I. Stoica, R. Morris, D. Karger, M. F. Kaashoek et H. Balakrishnan
: Chord : A Scalable Peer-to-peer Lookup Service for Internet Applications.
SIGCOMM Computer Communication Review, 31(4):149–160,
aoˆut 2001.Bibliographie 41
[VBT09] M. R. Vieira, P. Bakalov et V. J. Tsotras : On-line Discovery of
Flock Patterns in Spatio-temporal Data. Dans Proceedings of the 17th
ACM SIGSPATIAL International Conference on Advances in Geographic
Information Systems, GIS, pages 286–295, 2009.
[VRBV03] R. Van Renesse, K. P. Birman et W. Vogels : Astrolabe : A Robust
and Scalable Technology for Distributed System Monitoring, Management,
and Data Mining. ACM Transactions Computer Systems, 21(2):164–206,
mai 2003.
[YD04] P. Yalagandula et M. Dahlin : A Scalable Distributed Information
Management System. Dans Proceedings of the Conference on Applications,
Technologies, Architectures, and Protocols for Computer Communications,
SIGCOMM, pages 379–390, 2004.
[YFG+12] H. Yan, A. Flavel, Z. Ge, A. Gerber, D. Massey, C. Papadopoulos,
H. Shah et J. Yates : Argus : End-to-End Service Anomaly Detection
and Localization From an ISP’s Point of View. Dans Proceedings of the
IEEE INFOCOM Conference, INFOCOM, pages 2756–2760, 2012.
[ZTG+09] Y. Zhao, Y. Tan, Z. Gong, X. Gu et M. Wamboldt : Self-correlating
Predictive Information Tracking for Large-scale Production Systems. Dans
Proceedings of the 6th International Conference on Autonomic Computing,
ICAC, pages 33–42, 2009.42 Travaux connexesChapitre 3
Caract´erisation de fautes
Nous d´efinissons dans ce chapitre un mod`ele permettant de prendre en compte
l’impact des fautes sur les perceptions des utilisateurs sans connaissance du r´eseau
d’interconnexion. L’activation d’une faute dans le syst`eme peut induire une d´efaillance
per¸cue par les utilisateurs. Cette d´efaillance est per¸cue au travers d’une variation anormale
de la qualit´e d’un service consomm´e. Nous repr´esentons un sc´enario possible de
fautes impactant le syst`eme au travers d’une partition d’anomalies.
Cette mod´elisation va nous permettre de d´eterminer ce qui est discernable du point
de vue des entit´es supervis´ees. Nous montrons qu’il est impossible de d´eterminer de
mani`ere certaine pour chaque entit´e ayant per¸cu une d´efaillance si cette d´efaillance
est due `a une faute locale (faute isol´ee) ou si cette d´efaillance est per¸cue par d’autres
entit´es (faute massive).
En assouplissant le crit`ere de faute (faute isol´ee, faute massive ou ´etat ind´etermin´e),
il est possible de d´eterminer pour chaque variation de qualit´e anormale per¸cue, le
type de faute `a lui associer. De plus, nous montrons que la seule connaissance du
voisinage, en termes de qualit´es, de chaque entit´e est suffisante pour d´eterminer pour
chaque entit´e le type de faute ayant induit la d´efaillance per¸cue. Une connaissance
plus importante, telle que celle qu’aurait un observateur global du syst`eme, n’apporte
pas plus d’informations permettant de caract´eriser de mani`ere certaine l’ensemble des
fautes impactant le syst`eme.
3.1 Mod`ele
Cette section pr´esente les notations et les concepts que nous utilisons pour la
mod´elisation de l’impact des fautes sur les mesures de performances effectu´ees par
les entit´es supervis´ees. Nous utilisons dans la suite de ce document les conventions
suivantes :
— les variables sont not´ees en lettres minuscules : j, `, p, q
— les ensembles sont not´es en lettres majuscules : S, E
— les familles d’ensemble sont not´ees en lettres majuscules calligraphi´ees : P
— les intervalles discrets {1, . . . , n} sont not´es [[1, n]].
4344 Caract´erisation de fautes
L’ensemble des notations utilis´ees dans cette section est r´esum´e dans le tableau 3.1.
3.1.1 Pr´eliminaires
On consid`ere un ensemble [[1, n]] d’entit´es supervis´ees. Chacune de ces n entit´es
consomme des services au travers du r´eseau choisis parmis d services not´es s1, . . . , sd.
A chaque instant discret ` k, l’entit´e j ∈ [[1, n]] ´evalue une mesure de performance qi,k(j)
du service si `a valeurs dans [0, 1]. Si l’entit´e j ∈ [[1, n]] ne consomme pas le service si `a
l’instant k, qi,k(j) vaut 0. On mod´elise les mesures effectu´ees `a l’instant k par l’entit´e j
par un point pk(j) = (q1,k(j), . . . , qd,k(j)) de l’espace m´etrique E = [0, 1]d
. On parlera
aussi d’espace des qualit´es pour d´esigner cet espace.
On mod´elise l’ensemble des mesures effectu´ees par les n entit´es par l’ensemble des
points Sk de E, Sk = (pk(1), . . . , pk(n)). Cet ensemble de points Sk est appel´e ´etat
du syst`eme ou configuration du syst`eme `a l’instant k. De plus, chaque entit´e est munie
d’une fonction de d´etection de d´efaillance ak(j) qui retourne VRAI si une variation
dans la mesure de performance d’un service consomm´e par l’entit´e j `a l’instant k
peut ˆetre consid´er´ee comme une d´efaillance. La notion de d´efaillance est tr`es fortement
d´ependante du type de mesure effectu´e et du service consomm´e. Des m´ethodes
(par exemple [Pag54, Hol04, Win60]) permettant cette d´etection de d´efaillance ont ´et´e
´evoqu´ees auparavant et ne seront pas trait´ees ici.
Des fautes peuvent apparaˆıtre dans le syst`eme et leur impact peut ˆetre per¸cu par
diff´erentes entit´es. Nous nous int´eressons `a distinguer les fautes suivant le nombre d’entit´es
supervis´ees impact´ees.
D´efinition 1 (fautes isol´ees / massives) Etant donn´es ´ k ≥ 1, Sk−1, Sk et τ ∈
[[1, n − 1]], une faute impactant strictement plus de τ entit´es supervis´ees est appel´ee
faute massive. Dans le cas contraire, on parle de faute isol´ee.
Les entit´es observant des variations de performances similaires sont susceptibles
de percevoir les mˆemes d´efaillances. On consid`ere ici qu’une mˆeme faute a un impact
similaire sur les mesures effectu´ees par les entit´es.
Nous traduisons cette intuition par l’hypoth`ese suivante : si les mesures effectu´ees
par les entit´es avant la perception de la d´efaillance sont proches et qu’elles le sont
encore apr`es la perception de celle-ci, alors la d´efaillance est due `a la mˆeme faute.
Cette hypoth`ese est mod´elis´ee par une distance seuil entre les positions des entit´es
dans l’espace des qualit´es : s’il existe une boule de rayon r contenant les positions de
ces entit´es dans l’espace des qualit´es `a l’instant k−1 et une autre contenant les positions
de ces mˆemes entit´es `a l’instant k alors ces entit´es ont per¸cu la mˆeme d´efaillance. On
appellera ce rayon r le rayon de coh´erence.
3.1.2 Terminologie et notations employ´ees
Afin de mod´eliser de l’impact des fautes sur le syst`eme, nous introduisons les notions
que nous utiliserons tout au long de ce chapitre. Tout d’abord, dans un soucis de
simplicit´e, nous utilisons la norme infinie k · k d´efinie pour tout x = (x1, . . . , xd) ∈ EMod`ele 45
par kxk = max{x1, . . . , xd}. D’autre part, la distance entre deux points x, y ∈ E est
d´efinie par la norme du vecteur kx−yk. L’espace E ´etant de dimension finie d toutes les
normes sont ´equivalentes et donc les r´esultats fournis restent valables `a des constantes
pr`es.
D´efinition 2 (Ensemble r-coh´erent) Pour tout r ∈ [0, 1/4), un sous-ensemble B ⊆
[[1, n]] est dit r-coh´erent `a l’instant k ≥ 0 si la distance maximale entre tous points
i, j ∈ B est inf´erieure ou ´egale `a 2r :
∀(i, j) ∈ B
2
, kpk(i) − pk(j)k ≤ 2r.
Propri´et´e 1 Pour tout k ≥ 0, pour tout r ∈ [0, 1/4) et pour tout B ⊆ [[1, n]], on a
l’´equivalence suivante :
∃o ∈ E, ∀j ∈ B, kpk(j) − pk(o)k ≤ r ⇐⇒ B est r-coh´erent `a l’instant k.
Preuve (⇒) Soient B ⊆ [[1, n]] et o ∈ E tels que pour tout j ∈ B, nous ayons
kpk(j) − pk(o)k ≤ r. Cela implique que tous les ´el´ements de B sont contenus dans
une boule de rayon r centr´ee en o. On a donc ∀(i, j) ∈ B2
, kpk(i) − pk(j)k ≤ 2r. Par
cons´equent, B est un ensemble r-coh´erent.
(⇐) Soit B = [[1, `]] ⊆ [[1, n]] un ensemble r-coh´erent `a l’instant k. D’apr`es la
d´efinition 2 cela signifie que ∀(i, j) ∈ B2
, kpk(i) − pk(j)k ≤ 2r. De plus, d’apr`es
la d´efinition de la norme employ´ee, la distance entre deux points (x, y) ∈ E2
est
d´efinie par kx − yk = max{|x1 − y1|, . . . , |xd − yd|}. On a donc ∀(i, j) ∈ B2
, ∀m ∈
[[1, d]], |qm,k(i) − qm,k(j)| ≤ 2r. Soit le point o = (o1, . . . , od) ∈ E. On consid`ere la m-
`eme coordonn´ee qm,k(j) de chaque point j ∈ B. Ces coordonn´ees sont toutes incluses
dans le segment [min{qm,k(1), . . . , qm,k(`)}, max{qm,k(1), . . . , qm,k(`)}]. On d´efinit alors
om comme le milieu de ce segment. On a :
∀m ∈ [[1, d]], om =
max{qm,k(1), . . . , qm,k(`)} − min{qm,k(1), . . . , qm,k(`)}
2
.
L’ensemble B ´etant r-coh´erent `a l’instant k, on a ∀(i, j) ∈ B2
, |qm,k(i) − qm,k(j)| ≤ 2r.
Par cons´equent, on a ∀j ∈ B, ∀m ∈ [[1, d]], |om − qm,k(j)| ≤ r et donc ∀j ∈ B, kpk(j) −
pk(o)k ≤ r. 2
D´efinition 3 (Ensemble r-coh´erent maximal) Pour tout r ∈ [0, 1/4), un sousensemble
B ⊆ [[1, n]] est dit maximal r-coh´erent `a l’instant k si les deux conditions
suivantes sont v´erifi´ees :
— B est un ensemble r-coh´erent `a l’instant k,
— ∀j ∈ [[1, n]] \ B, B ∪ {j} n’est pas un ensemble r-coh´erent `a l’instant k.46 Caract´erisation de fautes
Sk
2 1
4 3 5
6
2r
2r
Figure 3.1 – Les ensembles maximaux r-coh´erents B1 = {1, 2, 3, 4} et B2 =
{1, 2, 3, 5, 6} contenant le point 1. Tout sous-ensemble de B1 ou B2 est aussi r-coh´erent.
Exemple 6 La figure 3.1 illustre ces deux notions. On consid`ere un ensemble de 6 entit´es
labellis´ees {1, 2, 3, 4, 5, 6} `a l’instant k. Ces entit´es consomment un unique service
(donc d = 1) et mesurent la performance de celui-ci. On place ces entit´es dans l’espace
des qualit´e E qui se r´eduit alors au segment [0, 1] et les points correspondent `a la
position de chaque entit´e supervis´ee dans E. La distance entre tout couple d’´el´ements
de B1 = {1, 2, 3, 4} ou tout couple d’´el´ements de B2 = {1, 2, 3, 5, 6} est inf´erieure `a
2r. Ces ensembles sont donc r-coh´erents. De plus, ces ensembles B1 et B2 sont maximaux
: en effet, tout ajout `a B1 d’un ´el´ement de B2 augmente la distance maximale
entre les ´el´ements de B1 au del`a de 2r brisant ainsi la condition de r-coh´erence. Le
mˆeme raisonnement s’applique `a B2.
Ces deux notions nous permettent d’introduire la notion de mouvement permettant
de capturer les variations de perception des entit´es fortement corr´el´ees.
D´efinition 4 (Mouvement r-coh´erent) Pour tout k ≥ 1, pour tout r ∈ [0, 1/4),
un sous-ensemble B ⊆ [[1, n]] a un mouvement r-coh´erent dans l’intervalle de temps
[k − 1, k] si B est un ensemble r-coh´erent aux instants k − 1 et k.
D´efinition 5 (Mouvement r-coh´erent maximal) Pour tout k ≥ 1, pour tout r ∈
[0, 1/4), un sous-ensemble B ⊆ [[1, n]] a un mouvement r-coh´erent maximal dans l’intervalle
de temps [k − 1, k] si les deux conditions suivantes sont v´erifi´ees :
— B a un mouvement r-coh´erent dans l’intervalle de temps [k − 1, k],
— ∀j ∈ [[1, n]] \ B, B ∪ {j} n’a pas de mouvement r-coh´erent dans l’intervalle de
temps [k − 1, k].
Remarque 1 Si un sous-ensemble B ⊆ [[1, n]] a un mouvement r-coh´erent dans l’intervalle
de temps [k − 1, k], alors soit ce mouvement est maximal, soit il existe B0 ⊆
[[1, n]], B ⊆ B0
tel que B0 ait un mouvement maximal r-coh´erent.
Exemple 7 La figure 3.2 illustre la notion de mouvements r-coh´erents. A gauche, sur `
la figure 3.2(a), sont repr´esent´ees les positions de six entit´es {1, 2, 3, 4, 5, 6} consommant
un unique service aux instants k −1 et k ainsi que les ensembles r-coh´erents maximaux
contenant chacune d’elles. La figure 3.2(b) repr´esente ces mˆemes entit´es dans l’espace
des trajectoires T = E ×E. La variation de qualit´e per¸cue par l’entit´e j est repr´esent´ee
par le point (q1,k−1(j), . . . , qd,k−1(j), q1,k(j), . . . , qd,k(j)).Mod`ele 47
Sk
Sk−1
2 1
3
4
5 6
2r
2r
1
2 3
5 4
6
2r
2r
2r
(a) Deux ensembles r-coh´erents maximaux `a
l’instant k − 1 : {1, 2, 3, 5} et {1, 2, 3, 4, 6}.
On a trois ensembles r-coh´erents maximaux
`a l’instant k : {1, 2, 3, 5}, {1, 2, 3, 4}, {3, 4, 6}.
Sk
Sk−1
1
2
3
4
5
6
B1
B2
B3
(b) Trois ensembles ayant des mouvements rcoh´erents
maximaux : B1 = {1, 2, 3, 5}, B2 =
{1, 2, 3, 4}, B3 = {3, 4, 6}.
Figure 3.2 – Repr´esentation des variations de qualit´e dans l’espace des trajectoires.
La droite y = x est trac´ee en pointill´es, les points situ´es sur cette droite traduisent
l’absence de variation de qualit´e mesur´ee par les entit´es dans l’intervalle de temps
[k−1, k] : pour chacune d’elles on a pk(j) = pk−1(j). Les points situ´es au dessus de cette
droite traduisent une am´elioration de la qualit´e mesur´ee par les entit´es dans l’intervalle
de temps [k − 1, k] tandis que ceux situ´es en dessous traduisent une d´egradation de la
qualit´e per¸cue par les entit´es dans l’intervalle de temps [k −1, k]. Ici, les six entit´es ont
per¸cu une d´egradation de leur qualit´e.
Les mouvements r-coh´erents correspondent aux points contenus dans le produit
cart´esien d’une boule de rayon r `a l’instant k − 1 avec une autre boule de rayon r
`a l’instant k. Ces mouvements sont repr´esent´es par les carr´es gris´es B1, B2 et B3.
Nous utiliserons cette repr´esentation dans le reste de ce document.
Finalement, nous classifions les mouvements r-coh´erents suivant le nombre d’entit´es
supervis´ees qui les composent. Cette classification est au centre de la distinction que
nous ´etablissons entre les fautes isol´ees et les fautes massives.
D´efinition 6 (Mouvement τ -dense) Pour tout r ∈ [0, 1/4), pour tout τ ∈ [[1, n−1]],
et pour tout sous-ensemble B ⊆ [[1, n]] ayant un mouvement r-coh´erent dans l’intervalle
de temps [k − 1, k], on dit que B a un mouvement r-coh´erent τ -dense dans l’intervalle
de temps [k − 1, k] si |B| > τ , sinon on dit que B a un mouvement r-coh´erent non
τ -dense dans cet intervalle.
Dans la suite, on utilisera ”mouvement τ -dense” (respectivement ”mouvement non
τ -dense”) au lieu de ”mouvement r-coh´erent τ -dense” (respectivement ” mouvement
r-coh´erent non τ -dense”) lorsque le contexte est clair.48 Caract´erisation de fautes
3.1.3 Mod´elisation de l’impact des fautes
Chaque entit´e supervis´ee j consomme un sous-ensemble des d services. Pour chaque
service consomm´e, l’entit´e j effectue localement une mesure de performance de bout-enbout.
Ces mesures de performances sont utilis´ees en entr´ee de la fonction de d´etection de
d´efaillance ak(j). Si une variation de performance est consid´er´ee comme une d´efaillance
par la fonction de d´etection de d´efaillance ak(j), celle-ci retourne VRAI. On d´efinit
la trajectoire anormale d’une entit´e du syst`eme dans l’espace des qualit´es comme la
cons´equence sur les mesures de performance d’une faute dans le syst`eme.
D´efinition 7 (Trajectoire anormale) Une entit´e j ∈ [[1, n]] a une trajectoire anormale
dans l’intervalle de temps [k − 1, k] si ak(j) = VRAI. L’ensemble des entit´es ayant
une trajectoire anormale dans l’intervalle de temps [k−1, k] est not´e Ak. Formellement,
on a :
Ak = {j ∈ [[1, n]] | ak(j) = VRAI} .
Nous cherchons `a d´eterminer pour chaque entit´e percevant une d´efaillance dans
l’intervalle de temps [k − 1, k] si la faute qui a caus´e cette d´efaillance a impact´e un
grand nombre d’entit´es ou seulement quelques unes. Pour cela, nous d´eterminons pour
chaque entit´e la pr´esence d’autres entit´es dans son voisinage dans l’espace des qualit´es
aux instants k−1 et k. Par exemple, si plus de τ entit´es ayant des trajectoires anormales
restent proches les unes des autres, nous consid´erons que ces trajectoires anormales sont
dues `a une mˆeme faute et donc que ces entit´es per¸coivent une d´efaillance due `a une faute
massive. Nous pouvons alors restreindre la recherche des causes de cette d´efaillance `a
ces seules entit´es impact´ees. Cependant, si l’intervalle de temps entre les instants de
mesure est trop important, il est possible que ces mˆemes entit´es per¸coivent diff´erentes
d´efaillances, rendant impossible toute reconstruction de sc´enario d’explication. Nous
imposons donc trois restrictions n´ecessaires `a la reconstruction de ces sc´enarios :
R1 : Dans l’intervalle de temps [k −1, k], la trajectoire anormale de l’entit´e supervis´ee
j ∈ Ak n’est due qu’`a une unique faute.
R2 : Une faute a un impact similaire sur toutes les entit´es supervis´ees qui la per¸coivent.
En particulier, si un ensemble B d’entit´es supervis´ees forme un ensemble rcoh´erent
avant la perception de la d´efaillance (i.e. `a l’instant k−1), alors celles-ci
forment encore un ensemble r-coh´erent `a l’instant k et donc par la d´efinition 4,
cet ensemble a un mouvement r-coh´erent dans l’intervalle de temps [k − 1, k].
R3 : Si une faute impacte strictement plus de τ entit´es alors pour chacune d’elles
il existe un ensemble ayant un mouvement τ -dense. Celui-ci ne contient pas
n´ecessairement l’ensemble des entit´es impact´ees par cette faute massive.
R´eciproquement, dans un ensemble ayant un mouvement τ -dense, il existe au
moins une entit´e ayant ´et´e effectivement impact´ee par une faute massive.
Ces restrictions imposent que les entit´es percevant une d´efaillance due `a une faute
massive aient un mouvement r-coh´erent. Cependant, une faute peut engendrer plusieursMod`ele 49
mouvements r-coh´erents `a des positions diff´erentes dans l’espace des qualit´es. Ces restrictions
sont formalis´ees par le partitionnement de l’ensemble Ak en sous-ensembles
ayant des mouvements r-coh´erents. Ce partitionnement est tel que :
(i) tous les mouvements r-coh´erents non τ -denses sont suffisamment ´eloign´es les uns
des autres, de sorte qu’il soit impossible de reconstituer un mouvement τ -dense
`a partir de ces ´el´ements. En d’autres termes, la probabilit´e que plus de τ fautes
ind´ependantes impactent des entit´es supervis´ees dont les mesures effectu´ees `a
deux instants cons´ecutifs sont similaires est n´egligeable.
Cette condition traduit le fait qu’il est impossible de distinguer une faute impactant
un ensemble d’entit´es supervis´ees d’un ensemble de fautes impactant
chacune une entit´e supervis´ee de mani`ere similaire aux autres fautes.
Par exemple, des passerelles de connexion utilisateurs subissant chacune une
faute isol´ee impactant la connexion r´eseau percevraient les mˆemes variations de
mesure de performance qu’un ensemble de passerelles de connexion utilisateurs
percevant une mˆeme d´efaillance r´eseau.
(ii) tout mouvement r-coh´erents non τ -dense est suffisamment ´eloign´e d’un mouvement
r-coh´erent τ -dense, de sorte qu’il soit impossible de les regrouper au sein
d’un unique ensemble ayant un mouvement r-coh´erent τ -dense. En d’autres
termes, la probabilit´e que plusieurs fautes ind´ependantes impactent plus de τ
entit´es supervis´ees dont les mesures effectu´ees sont similaires est n´egligeable.
Cette condition traduit le fait qu’il est impossible de distinguer une faute impactant
un ensemble d’entit´es supervis´ees, de deux fautes impactant l’une un faible
nombre (inf´erieur `a τ ) d’entit´es et la seconde le reste des entit´es. Consid´erons
par exemple d’une part une passerelle utilisateur sujette `a une faute isol´ee et
d’autre part un ensemble de passerelles de connexion utilisateurs percevant une
mˆeme d´efaillance r´eseau, et supposons que toutes ces entit´es per¸coivent une
mˆeme variation de qualit´e. Dans ce cas, l’entit´e sujette `a une faute isol´ee exhibe
alors une trajectoire anormale similaire `a celles des autres entit´es. Il est donc
impossible de discerner l’entit´e impact´ee par la faute isol´ee des autres entit´es
percevant une faute massive.
Afin de prendre en compte ces restrictions, nous partitionnons l’ensemble Ak des
entit´es de [[1, n]] ayant une trajectoires anormales dans l’intervalle de temps [k − 1, k]
en sous-ensembles appel´es anomalies. Les anomalies ont des mouvements r-coh´erents
dans l’espace des qualit´es. Les entit´es d’une anomalie per¸coivent donc une d´efaillance
de mani`ere coh´erente.
Une partition d’anomalies Pk repr´esente un sc´enario possible de fautes, respectant
les restrictions R1, R2 et R3, qui impactent le syst`eme. On dit que la partition d’anomalies
a fait ´evoluer le syst`eme de l’´etat Sk−1 `a l’´etat Sk. Ce partitionnement de Ak
est formellement d´efini comme suit.
D´efinition 8 (Partition d’anomalies Pk) Pour tout k ≥ 1, pour tout τ ∈ [[1, n − 1]]
et pour tout r ∈ [0, 1/4), la partition Pk de Ak est une partition d’anomalies `a l’instant
k si elle est constitu´ee d’ensembles C1, . . . , C`
, non vides et deux `a deux disjoints, ayant50 Caract´erisation de fautes
des mouvements r-coh´erents et v´erifiant les conditions C1, C2 suivantes. Les ensembles
C1, . . . , C` sont appel´es anomalies.
C1 : ∀B ⊆
S
|Ci|≤τ Ci
, B a un mouvement r-coh´erent non τ -dense ou B n’a pas de
mouvement r-coh´erent.
C2 : ∀i ∈ [[1, `]], Ci a un mouvement r-coh´erent τ -dense ⇒ ∀B ⊆
S
|Cj |≤τ Cj , B ∪ Ci
n’a pas un mouvement r-coh´erent.
Par extension, pour tout ´el´ement j ∈ Ak on notera Pk(j) l’unique partie de Pk
contenant l’´el´ement j.
Finalement on distingue les anomalies isol´ees des massives suivant le cardinal des
parties C1, . . . , C` de Pk.
D´efinition 9 (Anomalies Massives / Isol´ees ) Soit Pk une partition d’anomalies.
Un ´el´ement C ∈ Pk est appel´e anomalie massive de Pk dans l’intervalle de temps
[k − 1, k] si |C| > τ . Dans le cas contraire, on l’appelle anomalie isol´ee de Pk.
L’ensemble des entit´es supervis´ees impact´ees par une anomalie massive de Pk dans
l’intervalle de temps [k−1, k] est not´e MPk
. De la mˆeme mani`ere on note IPk
, l’ensemble
des entit´es supervis´ees impact´ees par une anomalie isol´ees de Pk dans l’intervalle de
temps [k − 1, k].
Formellement on a :
MPk = {j ∈ Ak | |Pk(j)| > τ},
IPk = {j ∈ Ak | |Pk(j)| ≤ τ}.
Ces ensembles sont compl´ementaires dans Ak et induisent une d´ecomposition naturelle
de Ak. On a :
Ak = MPk ∪ IPk
et MPk ∩ IPk = ∅. (3.1)
Bien que la d´efinition de partition d’anomalie puisse sembler complexe, le lemme 1
montre qu’on peut toujours construire une partition d’anomalies, et qu’en g´en´eral celleci
n’est pas unique.
Lemme 1 Pour tout k ≥ 1, pour tout Ak 6= ∅, pour tout τ ∈ [[1, n − 1]], pour tout
r ∈ [0, 1/4) et pour tous ´etats cons´ecutifs Sk−1, Sk du syst`eme, il existe toujours une
partition Pk de Ak qui est une partition d’anomalies. Cette partition n’est en g´en´eral
pas unique.
Preuve On montre dans un premier temps l’existence de partitions d’anomalies, puis
on illustrera sur un exemple que celles ci ne sont pas n´ecessairement uniques.
(Existence) L’algorithme 1 d´ecrit une mani`ere simple de construire une partition
d’anomalies Pk de Ak. On initialise l’ensemble des entit´es `a traiter S avec les ´el´ements
de Ak et le r´esultat Pk avec l’ensemble vide. Tant qu’il reste des ´el´ements `a traiter
(i.e. S n’est pas vide), on choisit al´eatoirement un ´el´ement j dans S. On choisit alors
un sous-ensemble C de S tel que j appartienne `a ce sous-ensemble C et que C aitMod`ele 51
Algorithme 1 : Construction d’une partition d’anomalie de Ak.
Donn´ees : Sk−1, Sk, τ ∈ [[1, n − 1]], r ∈
0,
1
4
.
Entr´ees : Ak
Sorties : Une partition d’anomalie
1 d´ebut
2 S ← Ak;
3 Pk ← {};
4 tant que S 6= ∅ faire
5 Choisir j ∈ S;
6 Choisir C ⊆ S tel que j ∈ C, C 6∈ Pk et C a un mouvement
r-consistent maximal dans S;
7 S ← S \ C ;
8 Pk ← Pk ∪ {C};
9 fin
10 retourner Pk;
11 fin
un mouvement maximal r-coh´erent parmi les ´el´ements de S. Cet ensemble C est alors
ajout´e `a Pk et ses ´el´ements sont retir´es de S. A chaque it´eration, on supprime donc des `
´el´ements de S. La taille de S est donc strictement d´ecroissante, l’algorithme termine.
Montrons `a pr´esent par r´ecurrence qu’`a chaque it´eration Pk satisfait les conditions
C1 et C2 de la d´efinition 8. Le premier ´el´ement ajout´e `a Pk a un mouvement r-coh´erent
maximal par d´efinition. Comme il s’agit du premier ´el´ement, il n’existe pas d’autre
partie de Pk permettant ´eventuellement de lui adjoindre des ´el´ements.
Supposons `a pr´esent, qu’`a la fin de la `-i`eme it´eration, Pk = {C1, . . . , C`} satisfait les
conditions C1 et C2 de la d´efinition 8. Montrons alors qu’`a la fin de l’it´eration suivante,
Pk les satisfait encore. On choisit un ´el´ement j de S. On choisit ensuite C ⊆ S tel que j
appartienne `a C et que C ait un mouvement maximal r-coh´erent parmi les ´el´ements de
S. Par construction, ∀i ∈ [[1, `]], Ci ∈ Pk a un mouvement r-coh´erent maximal parmi les
´el´ements restants S \∪1≤i≤`Ci
. Donc, d’apr`es la d´efinition 5, ∀j ∈ S \∪1≤i≤`Ci
, Ci∪ {j}
n’a pas un mouvement r-coh´erent. En particulier, ∀j ∈ C, ∀i ∈ [[1, `]], Ci ∪ {j} n’a pas
un mouvement r-coh´erent et donc les conditions C1 et C2 sont satisfaites par Pk. Par
hypoth`ese de r´ecurrence, Pk satisfait donc C1 et C2 `a chaque it´eration.
Enfin, Ak n’est pas vide et donc pour tout ´el´ement j ∈ Ak, il existe une unique
partie C ∈ Pk contenant j. A la fin de l’ex´ecution de l’algorithme, tous les ´el´ements de `
Ak appartiennent `a une partie de Pk et donc Pk est bien une partition de Ak.
(Non unicit´e) Etant donn´es ´ Ak, Sk−1 and Sk, on illustre la possibilit´e de construire
diverses partitions d’anomalies. Consid´erons l’exemple de la figure 3.3. Celle-ci illustre
les mesures de performances prises par dix entit´es supervis´ees `a l’instant k en fonction
de celles mesur´ees `a l’instant k−1, ainsi que les mouvements r-coh´erents maximaux possibles.
Supposons qu’on a τ = 3 et que toutes les entit´es supervis´ees ont une trajectoire
anormale dans l’intervalle de temps [k − 1, k].
Indexation de bases d’images : Evaluation de l’impact ´
´emotionnel
Syntyche Gbehounou
To cite this version:
Syntyche Gbehounou. Indexation de bases d’images : Evaluation de l’impact ´emotionnel. ´
Signal and Image Processing. Universit´e de Poitiers, 2014. French.
HAL Id: tel-01089308
https://tel.archives-ouvertes.fr/tel-01089308
Submitted on 1 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’UNIVERSITE DE POITIERS
(Faculté des Sciences Fondamentales et Appliquées)
(Diplôme National - Arrêté du 7 août 2006)
École Doctorale: Sciences et Ingénierie pour l’Information,
Mathématiques (S2IM)
Secteur de recherche : Traitement du Signal et des images
Présentée par:
Syntyche GBEHOUNOU
************************
Indexation de bases d’images :
Évaluation de l’impact émotionnel
************************
Directrice de thèse: Christine FERNANDEZ-MALOIGNE
Co-Directeur de thèse: François LECELLIER
************************
Soutenue le 21 Novembre 2014
devant la Commission d’Examen composée de:
************************
Membres du jury
Pr. Ludovic MACAIRE, LAGIS, Université de Lille, Rapporteur
Pr. Denis PELLERIN, GIPSA-lab, Polytech’Grenoble, Rapporteur
Pr. Theo GEVERS, Université d’Amsterdam, Pays-Bas, Examinateur
MCF. Emmanuel DELLANDRÉA, LIRIS, École Centrale de Lyon, Examinateur
Pr. Christine FERNANDEZ-MALOIGNE, XLIM-SIC, Université de Poitiers, Directrice de thèse
MCF. François LECELLIER, XLIM-SIC, Université de Poitiers, Co-directeur de thèseRemerciements
Je tiens tout d’abord, à remercier, les membres de mon jury de thèse : Messieurs
Ludovic Macaire et Denis Pellerin qui m’ont fait l’honneur d’accepter de rapporter
ce manuscrit, Messieurs Emmanuel Dellandréa et Theo Gevers qui ont accepté de
participer à ce jury.
Ensuite, concernant mon encadrement, je remercie ma directrice de thèse Madame
Christine Fernandez-Maloigne, pour sa présence malgré un emploi du temps
très chargé et ses remarques constructives durant toutes ces années. Un grand merci
à Monsieur François Lecellier, mon co-directeur de thèse, pour ses conseils, le temps
passé à débugguer mes codes et sa spontanéité. Encore merci à tous les deux pour
votre confiance et tous vos conseils. J’ai découvert grâce à vous une passion pour
l’enseignement et approfondi mon goût de la recherche.
Je remercie toutes les personnes avec lesquelles j’ai travaillé et surtout collaboré
pendant ma thèse : Vincent Courboulay, Enrico Calore, Daniele Marini, Ton Le Huu
et Thierry Urruty. Merci Thierry pour nos discussions sur l’indexation et ses problématiques
et surtout pour cette collaboration fructueuse.
Je remercie tous les membres du laboratoire avec une pensée particulière pour
tous les doctorants, post-doctorants, ingénieurs de recherche anciens et nouveaux
avec lesquels nous avons discuté de la recherche, de la science et de nombreux autres
sujets.
J’aimerais également exprimer toute ma sympathie au personnel administratif
de l’Université de Poitiers et du département XLIM-SIC pour leur disponibilité. Je
souhaite remercier les étudiants qui ont créé chez moi l’envie d’enseigner au cours
de ces 2 années de partage.
Ce travail n’aurait pas pu être possible sans toutes les personnes qui ont pris le
temps de participer aux différentes évaluations subjectives. Je leur exprime ici toute
ma gratitude.
J’aimerais exprimer toute ma gratitude à mes amis pour leur présence et leur
patience pendant ces 3 années. Merci à Françoise, à Dimitri, à mes "cousins" pour
leur soutien infaillible.
J’aimerais finir en remerciant mes parents pour leur soutien infaillible et leur bienveillance.
Merci d’avoir toujours été là pour moi malgré la distance, de m’avoir
remonté le moral quand il fallait. Perside et Fabien merci de votre patience pendant
toutes ces années et tout votre soutien pendant les dernières semaines de ma
rédaction.
iRemerciements
iiTable des matières
Remerciements i
Tables des figures ix
Liste des tableaux xi
Notations et acronymes xiii
Introduction générale 1
I Recherche d’images par le contenu 5
1 Solutions de recherche d’images par le contenu 9
1.1 Descripteurs d’images . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.1.1 Exemples de caractéristiques globales . . . . . . . . . . . . . . 11
1.1.2 Caractérisation locale : l’alternative aux insuffisances des descripteurs
globaux . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2 Recherche des images les plus ressemblantes . . . . . . . . . . . . . . 20
1.2.1 Création du dictionnaire de mots visuels . . . . . . . . . . . . 21
1.2.2 Quelques méthodes de création de la signature visuelle d’une
image . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.2.3 Recherche des images similaires à partir de leurs signatures
visuelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.3 Saillance visuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
1.3.1 Qu’est-ce que l’attention visuelle ? . . . . . . . . . . . . . . . . 28
1.3.2 Différents modèles de saillance visuelle . . . . . . . . . . . . . 34
1.3.3 Modèle de saillance de Itti et Koch . . . . . . . . . . . . . . . 35
1.3.4 Évaluation des modèles de saillance visuelle . . . . . . . . . . 37
1.4 Quelques travaux intégrant la saillance visuelle en recherche d’images
par le contenu . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2 Notre approche pour l’indexation 39
2.1 Bases d’images utilisées . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.2 Nos choix de descripteurs . . . . . . . . . . . . . . . . . . . . . . . . . 42
iiiTable des matières
2.3 Nouvelle méthode de construction du dictionnaire visuel : Iterative
Random visual words Selection (IteRaSel) . . . . . . . . . . . . . . . 42
2.4 Évaluations de IteRaSel . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.4.1 Sélection aléatoire des mots . . . . . . . . . . . . . . . . . . . 45
2.4.2 Sélection aléatoire des mots visuels couplée à un processus
itératif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.4.3 Stabilisation du processus aléatoire . . . . . . . . . . . . . . . 48
2.4.4 Évaluation de IteRaSel avec la combinaison des dictionnaires . 49
2.4.5 Comparaison avec l’état de l’art . . . . . . . . . . . . . . . . . 50
2.4.6 Discussions autour des résultats . . . . . . . . . . . . . . . . . 52
2.5 Pondération des vecteurs de descripteurs par la saillance . . . . . . . 53
2.6 Évaluation de la saillance de certains détecteurs de points clés . . . . 55
2.6.1 Saillance visuelle des caractéristiques locales . . . . . . . . . . 55
2.6.2 Discussions autour de ces premiers résultats . . . . . . . . . . 61
2.7 Étude de l’importance des points clés saillants . . . . . . . . . . . . . 62
2.7.1 Impact de la suppression des points clés en fonction de leur
saillance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
2.7.2 Ajouts de points saillants . . . . . . . . . . . . . . . . . . . . . 64
2.7.3 Discussions autour des travaux sur la saillance . . . . . . . . . 65
II Reconnaissance de l’impact émotionnel des images 71
3 Reconnaissance des émotions dans la littérature 75
3.1 Définition et théories de l’émotion . . . . . . . . . . . . . . . . . . . . 76
3.2 Modélisations des émotions . . . . . . . . . . . . . . . . . . . . . . . . 77
3.3 Émotions et couleurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.4 Reconnaissance de l’impact émotionnel traitée comme une tâche de
reconnaissance d’image dans la littérature . . . . . . . . . . . . . . . 83
3.4.1 Bases d’images de la littérature . . . . . . . . . . . . . . . . . 83
3.4.2 Systèmes de reconnaissance d’images basée émotion . . . . . . 86
4 Notre approche pour la reconnaissance des émotions 91
4.1 Proposition d’une nouvelle taxonomie de description des bases d’images
pour l’étude des émotions . . . . . . . . . . . . . . . . . . . . . . . . 93
4.1.1 Critères d’évaluation des informations intrinsèques à la base . 93
4.1.2 Critères d’évaluation des informations extrinsèques à la base . 93
4.1.3 Critères d’évaluation de disponibilité de tests physiologiques
effectués sur la base . . . . . . . . . . . . . . . . . . . . . . . . 94
4.1.4 Comparaison des bases de données évoquées dans le chapitre
précédent avec nos critères . . . . . . . . . . . . . . . . . . . . 95
4.2 Nouvelle base pour l’étude de l’impact émotionnel : SENSE . . . . . . 97
4.3 Évaluations subjectives de notre base d’images . . . . . . . . . . . . . 98
4.3.1 Évaluations SENSE1 . . . . . . . . . . . . . . . . . . . . . . . 100
4.3.2 Évaluations SENSE2 . . . . . . . . . . . . . . . . . . . . . . . 102
4.3.3 Récapitulatif de la base SENSE à partir des critères proposés . 105
ivTable des matières
4.4 Évaluation de descripteurs bas-niveau pour la reconnaissance de l’impact
émotionnel d’une image . . . . . . . . . . . . . . . . . . . . . . . 107
4.4.1 Descripteurs globaux . . . . . . . . . . . . . . . . . . . . . . . 107
4.4.2 Descripteurs locaux . . . . . . . . . . . . . . . . . . . . . . . . 109
4.4.3 Protocole expérimental . . . . . . . . . . . . . . . . . . . . . . 110
4.4.4 Étude de l’impact du dictionnaire visuel . . . . . . . . . . . . 111
4.4.5 Évaluation de l’impact de la signature visuelle . . . . . . . . . 114
4.4.6 Récapitulatif des premiers résultats . . . . . . . . . . . . . . . 116
4.4.7 Présentation de nos résultats . . . . . . . . . . . . . . . . . . . 117
4.4.8 Comparaison de nos résultats avec la littérature . . . . . . . . 120
4.5 Prise en compte de la saillance visuelle . . . . . . . . . . . . . . . . . 121
4.5.1 Sélection dense des caractéristiques locales . . . . . . . . . . . 122
4.5.2 Classification des images de SENSE2 . . . . . . . . . . . . . . 123
4.6 Récapitulatif des différents résultats de l’évaluation des descripteurs
de recherche d’images par le contenu . . . . . . . . . . . . . . . . . . 125
Conclusion générale et perspectives 131
A Calcul des CMI 137
Annexes 137
B Couleurs utilisées pour l’étude des émotions de couleurs 139
C Influence du genre sur l’évaluation de l’impact émotionnel des images
de la base SENSE 143
D Résultats des évaluations EEG sur quelques images de SENSE 147
E Configuration des ensembles d’apprentissage et de test des bases
SENSE et IAPS 151
Références bibliographiques 172
Liste des publications 175
vTable des matières
viTable des figures
1.1 Exemple d’images présentant des variations géométriques et/ou des
changements de plan de photographie. . . . . . . . . . . . . . . . . . 10
1.2 Principe de la différence de gaussiennes. . . . . . . . . . . . . . . . . 14
1.3 Voisinage du noyau considéré pour déterminer la caractéristique locale
avec les algorithmes SUSAN et FAST. . . . . . . . . . . . . . . . . . 15
1.4 Illustration des caractéristiques locales détectées par les différents dé-
tecteurs présentés dans cette sous-section. . . . . . . . . . . . . . . . 16
1.5 Différentes étapes de la description d’un point clé avec l’algorithme
SIFT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.6 Illustration de la création de la signature visuelle d’une image à partir
de ses descripteurs et d’un vocabulaire visuel. . . . . . . . . . . . . . 21
1.7 Exemple de quantification en 2D. . . . . . . . . . . . . . . . . . . . . 22
1.8 Illustration des différentes hypothèses de l’algorithme GMM. . . . . . 23
1.9 Illustration de la mise en œuvre de l’algorithme BoVW. . . . . . . . . 24
1.10 Illustration de la pyramide spatiale proposée par Lazebnik et al. . . . 27
1.11 Illustration de la structure de l’œil. . . . . . . . . . . . . . . . . . . . 29
1.12 Structure de la rétine. . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.13 La distribution des réponses rétiniennes au niveau du cortex. . . . . . 31
1.14 Différentes aires visuelles corticales. . . . . . . . . . . . . . . . . . . . 31
1.15 Traitement des informations provenant du cortex visuel primaire selon
la modélisation de deux voies dorsale et ventrale . . . . . . . . . . . . 32
1.16 Architecture du modèle de saillance de Itti et Koch. . . . . . . . . . . 36
1.17 Exemple de carte de saillance. . . . . . . . . . . . . . . . . . . . . . . 37
2.1 Exemple de 4 images similaires de la base UKB. . . . . . . . . . . . . 41
2.2 Quelques images de la base Pascal VOC2012. . . . . . . . . . . . . . 41
2.3 Illustration d’une carte de saillance. . . . . . . . . . . . . . . . . . . . 43
2.4 Sélection aléatoire des mots visuels vs K-means. . . . . . . . . . . . . 45
2.5 Construction du dictionnaire final de façon itérative en partant de
plusieurs dictionnaires visuels de 2048 mots choisis de façon aléatoire. 46
2.6 Étude de l’impact de la taille du dictionnaire visuel aléatoire initial. . 47
2.7 Score moyen obtenu après la combinaison des dictionnaires dans plusieurs
configurations : β = {2, . . . , 9 , 10}. . . . . . . . . . . . . . . . . 48
2.8 Score moyen obtenu avec des dictionnaires finaux de plusieurs tailles
générés à partir d’un dictionnaire de taille 4096. . . . . . . . . . . . . 50
viiTable des figures
2.9 Impact de la normalisation sur le score moyen. . . . . . . . . . . . . . 52
2.10 Étude du rang des images ressemblantes en pondérant les vecteurs de
descripteurs par la saillance du point décrit. . . . . . . . . . . . . . . 54
2.11 Illustration du test de quelques seuils de saillance sur l’image. . . . . 56
2.12 Répartition des valeurs de saillance visuelle des images des 4 bases
choisies. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
2.13 Pourcentage des pixels ayant une saillance visuelle ≥ 0.4. . . . . . . . 58
2.14 Exemple d’une image par base pour illustrer la non corrélation entre
le nombre de pixels ayant une saillance ≥ 0.4 dans l’image et celui de
caractéristiques locales. . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.15 Illustration de la répartition des points clés saillants des 4 bases choisies. 60
2.16 Impact de la suppression des points clés en fonction de leur saillance. 63
2.17 Étude de la dépendance des résultats de l’importance des caracté-
ristiques locales saillantes de la méthode de détection des caractéristiques
: détection dense. . . . . . . . . . . . . . . . . . . . . . . . . . 64
2.18 Remplacement des points détectés les moins saillants par les points
les plus saillants issus de la détection dense. . . . . . . . . . . . . . . 65
3.1 Circumplex de Plutchik. . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.2 Circumplex de Russell. . . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.3 Illustration des bases d’images de Machajdik et Hanbury. . . . . . . . 84
3.4 SAM utilisé durant les évaluations de IAPS. . . . . . . . . . . . . . . 85
3.5 Différentes classes reconstituées par Liu et al. pour l’évaluation de
leur approche sur IAPS. . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.1 Quelques images de SENSE. . . . . . . . . . . . . . . . . . . . . . . . 97
4.2 Application de test. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.3 "Imagettes" correspondant aux images 4.1(a)-4.1(c) évaluées pendant
SENSE2. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.4 Illustration de l’hétérogénéité des expérimentations SENSE1. . . . . . 101
4.5 Résultats des évaluations SENSE1 selon les 3 classes d’émotions. . . . 101
4.6 Architecture du modèle d’attention visuelle de Perreira Da Silva et al. 103
4.7 Taux de bonne classification au cours de SENSE2 en fonction de la
taille des régions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
4.8 Taux de classification moyen des images durant SENSE2. . . . . . . . 104
4.9 Exemple de casque utilisé pour récupérer le signal EEG. . . . . . . . 106
4.10 Positionnement des électrodes dans le système international 10-20. . . 106
4.11 Illustration de la segmentation en région couleurs. . . . . . . . . . . . 108
4.12 Partition spectrale des images de coefficients des transformées en ondelettes
et en Wave Atoms . . . . . . . . . . . . . . . . . . . . . . . . 109
4.13 Illustration de la décomposition en Wave Atoms sur une image synthétique.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.14 Taux de classification moyens pour SENSE1 et IAPS. . . . . . . . . . 112
4.15 Taux de bonne classification dans chacune des classes d’émotions pour
chaque descripteur. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
4.16 Taux de classification moyens pour les bases SENSE1 et IAPS. . . . . 115
4.17 Taux de bonne classification dans chaque classe d’émotions. . . . . . 116
viiiTable des figures
4.18 Résultats de l’étude de l’impact de la sélection des caractéristiques
locales. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
4.19 Taux de classification moyens obtenus sur SENSE2 et SENSE1. . . . 123
4.20 Taux de classification moyens pour les descripteurs locaux obtenus
sur SENSE2 et SENSE1. . . . . . . . . . . . . . . . . . . . . . . . . . 124
4.21 Résumé de l’approche que nous avons utilisée pour la reconnaissance
de l’impact émotionnel des images. . . . . . . . . . . . . . . . . . . . 125
B.1 Système colorimétrique de Munsell. . . . . . . . . . . . . . . . . . . . 140
C.1 Répartition des désaccords entre hommes et femmes lors de l’évaluation
de l’impact émotionnel sur notre base. . . . . . . . . . . . . . . . 145
ixTable des figures
xListe des tableaux
1 Liste des notations utilisées. . . . . . . . . . . . . . . . . . . . . . . . xiii
2 Liste des acronymes utilisés. . . . . . . . . . . . . . . . . . . . . . . . xiv
1.1 Comparaison des temps de calcul des détecteurs Harris, SUSAN et
FAST. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.1 Scores moyens sur UKB. . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.2 Comparaison de notre meilleur score moyen avec quelques uns de la
littérature. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1 Comparaison des bases d’images de Machajdik et al. et IAPS. . . . . 96
4.2 Description de SENSE avec les critères proposés dans la Section 4.1. . 105
4.3 Matrice de confusion des couleurs IAPS_I . . . . . . . . . . . . . . . 114
4.4 Matrice de confusion des couleurs IAPS_S . . . . . . . . . . . . . . . 114
4.5 Taux moyens des classifications pour chaque descripteur. . . . . . . . 118
4.6 Comparaison des taux de classification avant et après une fusion MV. 119
B.1 Différentes couleurs évaluées au cours des expérimentations de Kaya
et al. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
B.2 Différentes couleurs évaluées au cours des expérimentations de Ou et
al. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
C.1 Nombre d’images dans chaque classe d’émotions en fonction du genre. 144
C.2 Différentes couleurs moyennes au sein des désaccords entre genre relevés
sur notre base. . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
D.1 Corrélation entre les différentes sessions de tests dans la première
configuration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
D.2 Corrélation entre les différentes sessions de tests dans la seconde confi-
guration. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
D.3 Corrélation entre la réponse SSVEP et la luminance. . . . . . . . . . 149
E.1 Nombre d’images dans les ensembles d’apprentissage et de test. . . . 151
xiListe des tableaux
xiiNotations et acronymes
Tableau 1: Liste des notations utilisées.
Notation Signification
I Image en niveaux de gris ou composante d’un plan couleur
(x,y) Coordonnées d’un pixel en 2D
det(M) Déterminant de la matrice M
trace(M) Trace de la matrice M
Ω Une région de l’image
D Un ensemble de descripteurs de caractéristiques locales
K Taille du dictionnaire visuel
NI Nombre de caractéristiques locales par image
NB Nombre de caractéristiques locales dans une base d’images
NS Taille d’une suite binaire
ND Taille d’un descripteur (Dimensionnalité)
N Nombre d’images dans la base
W Dictionnaire visuel
d
L2
A,B Distance euclidienne entre deux vecteurs A et B
d
Hamming
A,B Distance de Hamming entre deux suites binaires A et B
d
χ
2
A,B Distance de χ
2
entre deux vecteurs A et B
xiiiNotations et acronymes
Tableau 2: Liste des acronymes utilisés.
Acronyme Signification
ACP Analyse en Composantes Principales
BoVW Bag of Visuals Words (Sac de mots visuels)
CBIR Content Based Image Retrival
CM Colour Moments
CMI Colour Moment Invariants
DoG Difference of Gaussians
EEG Électro-encéphalographie
EM Expectation-Maximisation
FAST Features From Accelerated Segment Test
FV Fisher Vector (Vecteur de Fisher)
GLOH Gradient Location and Orientation Histogram
GMM Gaussian Mixture Model
IA Intelligence Artificielle
IAPS International Affective Picture System
IG Information Gain (Gain d’information)
KNN K Near Neighbours (K plus proches voisins)
KP Keypoint (Point clé ou plus généralement une caractéristique locale)
LoG Laplacian of Gaussian
MSER Maximally Stable Extremal Regions
MV Majoriting Voting
NdG Niveau de gris
OpSIFT Opponent-SIFT
SENSE Studies of Emotions on Natural image DatabaSE
SIFT Scale-Invariant Feature Transform
SSVEP Steady-State Visually Evoked Potential
SURF Speeded Up Robust Feature
SUSAN Smallest Univalue Segment Assimiliating Nucleus
SVH Système Visuel Humain
SVM Support Vector Machine
tf-idf term frequency-inverse document frequency
UKB University of Kentucky Benchmark (Base d’images)
VLAD Vector of Loccally Aggregated Descriptors
WA Transformée en Wave Atoms
WA4 Échelle 4 de la transformée en Wave Atoms
WA5 Échelle 5 de la transformée en Wave Atoms
xivIntroduction générale
L’idée de doter des machines d’"intelligence" fut évoquée pour la première fois
par Turing [Turing 50] en 1950. Depuis, plusieurs travaux de recherche prometteurs
ont été menés avec des résultats très encourageants. Par exemple, l’intelligence artificielle
(IA) a été utilisée durant la guerre du Golfe, pour améliorer les systèmes
d’aide à la décision et les systèmes autonomes tels que les drones [His ]. Mais un évé-
nement en particulier a marqué les esprits : la victoire en 1996 du "super-ordinateur"
Deep Blue de IBM aux échecs face à Garry Kasparov, alors champion du monde.
La performance a été qualifiée d’inédite. On découvre alors qu’une IA peut être plus
performante que l’homme dans certains domaines précis. Depuis les recherches continuent
et des solutions de plus en plus intelligentes sont proposées dans de différentes
branches : la reconnaissance de formes, la vision par ordinateur, . . . . Aujourd’hui
certains appareils photo sont capables de se déclencher dès que le sujet sourit. Ceci
est rendu possible grâce à un logiciel embarqué de détection de visages. Nous pourrions
citer d’autres exemples d’applications mais la branche qui nous intéresse le
plus particulièrement dans cette thèse est la vision par ordinateur. Elle apporte des
solutions en robotique, en système d’aide au diagnostic ou en recherche d’images,
en tentant d’imiter la vision humaine ou animale. Malgré des résultats très encourageants,
certains aspects lui résistent encore. Il s’agit des aspects de notre système
de vision qui sont couplés à des processus cognitifs. La reconnaissance des émotions
en est un exemple. C’est à cette tâche que nous nous sommes intéressés au cours de
nos travaux de recherche.
S’intéresser à la reconnaissance des émotions est loin d’être une tâche facile.
En effet, les émotions sont des réactions complexes qui engagent à la fois le corps et
l’esprit. Il faut ensuite se confronter à une littérature hétéroclite, de la définition de la
notion d’émotion, aux solutions, en passant par les bases d’images. Une proposition
de définition consensuelle a été proposée, en 2013 seulement, par David Sander
[Sander 13]. Il définit alors l’émotion comme un phénomène rapide, déclenché par
un événement. Le défi des solutions de reconnaissance de l’impact émotionnel des
images est alors de trouver les caractéristiques de ces dernières qui déclenchent
l’émotion. Plusieurs travaux ont été menés dans cette direction. Une première partie
de la littérature est consacrée aux relations entre les émotions et les couleurs. Dans
ces travaux l’émotion associée à une couleur [Beresniak 90, Boyatziz 93, Kaya 04,
Ou 04a, Ou 04b, Ou 04c] ainsi qu’à des combinaisons de plusieurs couleurs [Ou 06,
Solli 09, Ou 11] a été étudiée.
Une autre partie a été consacrée à la reconnaissance des émotions à partir :
1Introduction générale
– De la détection de visages [Tomkims 62, Scherer 84, Ekman 92, De Silva 97,
Busso 04] associant alors une émotion à des traits du visage (sourcils, lèvres
entre autres) ;
– De la description sémantique des couleurs [Wang 05, Hong 06] ;
– Des caractéristiques bas-niveau (couleurs, texture, formes, . . . ) des images
[Yanulevskaya 08, Solli 10, Machajdik 10, Liu 11a].
Nous avons choisi d’inscrire nos travaux dans la famille des approches basées sur
l’extraction de caractéristiques bas niveau, l’idéal étant qu’un ensemble d’entre elles
soit suffisamment discriminant. Cette notion cependant dépend également des bases
d’images. Les résultats de Machajdik et Hanbury [Machajdik 10] montrent que les
couleurs sont très déterminantes pour la reconnaissance des émotions des images
abstraites. Les descripteurs que nous avons retenus sont des caractéristiques de couleurs,
textures, formes, objets. Ils sont, pour la plupart, traditionnellement utilisés
en indexation. C’est d’ailleurs cette tâche de vision par ordinateur qui a inspiré nos
travaux d’où la première partie ce manuscrit.
Recherche d’images par le contenu
L’idée est de retrouver des images partageant un contenu qui peut être associé
à différentes caractéristiques. On peut rechercher des images à partir d’une couleur
globale, d’une texture ou plus généralement des objets qu’elles contiennent. Les solutions
doivent être le plus souvent robustes aux transformations géométriques et
aux modifications des conditions d’éclairage et de prise de vue. On décrit alors les
images à partir d’un ensemble de caractéristiques qui peuvent être locales (variations
de la géométrie locale par exemple) [Harris 88, Lowe 99, Mikolajczyk 01, Matas 02]
ou globales (couleurs) [Swain 91, Oliva 01, Hays 07, Li 08, Douze 09]. Ces dernières
peuvent être directement mises en correspondance ou utilisées pour créer des signatures
visuelles [Sivic 03, Perronnin 07, Jégou 10b]. La littérature sur le sujet
est assez diversifiée et de nouvelles solutions sont fréquemment proposées notamment
en termes de descripteurs, de méthodes de recherche des signatures visuelles
pour s’adapter aux exigences des bases d’images de plus en plus grandes. Le domaine
est également très actif proposant régulièrement des challenges pour évaluer
les différentes solutions. Parmi les challenges les plus connus et qui se renouvellent
souvent, on peut citer PASCAL Visual Object Classes challenge. Il est constitué de
plusieurs bases d’images, fonction des années, Pascal VOC2007 [Everingham 07] et
Pascal VOC2012 [Everingham 12] par exemple. Chacune de ces bases est divisée en
ensembles d’apprentissage, de test et d’objets segmentés. En fonction de la tâche
choisie, catégorisation ou segmentation en objets d’intérêt, on peut évaluer les ré-
sultats de son système et se comparer efficacement à l’état de l’art.
On ne peut pas parler de recherche d’images par le contenu sans évoquer le descripteur
phare de ce domaine proposé par David G. Lowe en 1999 [Lowe 99] :
SIFT (Scale-Invariant Feature Transform). C’est un descripteur de 128 dimensions
dont la robustesse à plusieurs variations (translation, changement d’échelle, rotation)
en fait l’un des descripteurs les plus utilisés et efficaces de la littérature
[Lowe 99, Lowe 04, Ke 04, Nistér 06, van de Sande 10, Jégou 10b, Jégou 11].
Tout comme SIFT, une méthode de création de signature visuelle est très plébis-
2Introduction générale
citée dans la littérature : la technique "Bag of Visual Words" (BoVW) ou "Sac de
mots visuels". L’idée de cette solution, proposée, dans un premier temps, par Sivic
et Zisserman [Sivic 03], est de s’inspirer de la méthode "Sac de mots" utilisée en
catégorisation de texte, pour créer une signature visuelle pour la recherche d’images
et de vidéos. Pour ce faire, on crée d’abord un dictionnaire visuel. On construit ensuite
un histogramme des occurrences des mots de ce dernier dans chaque image.
La toute première solution apportée dans ce manuscrit concerne la construction du
vocabulaire visuel, souvent réalisée à partir d’un algorithme K-means. Ce dernier est
sensible à la dimensionnalité : ses résultats tendent à baisser avec une dimensionnalité
élévée, produisant même des résultats proches de l’aléatoire comme l’indiquent
Parsons et al. [Parsons 04]. Nous proposons alors une construction du dictionnaire
qui n’est pas sensible à ces problèmes de dimensionnalité combinant une sélection
aléatoire des mots visuels à un processus itératif. Nos travaux ont été menés essentiellement
sur les bases University of Kentucky Benchmark [Nistér 06] et Pascal
VOC2012 [Everingham 12]. Nous avons utilisé la seconde pour construire nos mots
visuels et la première pour tester notre approche.
Reconnaissance de l’impact émotionnel des images
Notre réflexion s’inspire de la recherche d’images par le contenu. Nous avons émis
l’hypothèse que les descripteurs existants pourraient être utiles et tout aussi performants
pour la reconnaissance des émotions. Dans ces travaux nous avons donc évalué
leur pertinence pour la tâche en les comparant aux résultats de la littérature. Nous
proposons également une nouvelle base d’images pour l’étude de l’impact émotionnel
en nous inspirant des insuffisances de la littérature évoquées par Machajdik et
Hanbury [Machajdik 10]. En effet, l’une des problématiques récurrentes concerne les
bases d’images et leur évaluation. La plupart des auteurs construisent de nouvelles
bases pour leurs travaux mais ne les publient pas ou ne donnent aucune information
concernant les conditions d’évaluation. Une base apparaît néanmoins comme étant
un consensus d’évaluation des solutions de recherche d’images basée émotion : IAPS
[Lang 08]. C’est une base très bien évaluée mais qui présente quelques restrictions
en termes d’utilisation nous obligeant à construire notre propre base d’images, entre
autres pour étudier l’apport de la saillance visuelle. Ce phénomène de sélection de
notre système visuel pourrait en effet permettre de réduire l’interprétation sémantique
au cours des évaluations subjectives, par exemple en réduisant la taille de la
zone observée à la région saillante. Ceci est impossible à faire avec les images de
IAPS à cause des clauses d’utilisation.
Plan
Ce document est divisé en deux parties : une première sur la recherche d’images
par le contenu et la seconde sur la reconnaissance de l’impact émotionnel des images.
Dans le Chapitre 1, nous présentons quelques solutions de la littérature pour la recherche
d’images par le contenu et nous finissons par une brève présentation de la
saillance visuelle. Il ne s’agit pas d’un état de l’art exhaustif mais axé sur les travaux
qui ont constitué le point de départ à notre réflexion. Une nouvelle méthode
de construction du vocabulaire visuel est présentée et discutée dans le Chapitre 2.
3Introduction générale
Toujours dans ce même chapitre, nous avons évalué l’importance des caractéristiques
locales en fonction de leur valeur de saillance visuelle. Cette étude conclut la première
partie de ce manuscrit.
Dans la seconde partie, le Chapitre 3 est consacré à l’état de l’art sur la reconnaissance
des émotions. Dans le dernier chapitre, nous proposons d’abord une taxonomie
de comparaison des bases d’images avant de présenter notre base d’images et ses différentes
évaluations subjectives. Nous avons ensuite comparé notre approche basée
sur une architecture de recherche d’images par le contenu avec les résultats de la
littérature.
4Première partie
Recherche d’images par le contenuIntroduction Partie 1
De tous les progrès accomplis en informatique, il y en a un qui a particulièrement
révolutionné notre façon de travailler : le stockage. De la première carte perforée de
IBM en 1928 1
, aux supports de stockage actuels (les clés USB, les cartes mémoires,
. . . ) en passant par les disques durs, les disquettes, les CD, des avancées notoires
ont été constatées. Dieny et Ebels [Dieny 08] les évoquent également en affirmant
que depuis le premier disque dur en 1956 2
, la capacité de stockage de ces disques
n’a cessé de croître à un rythme moyen de 45% par an, conduisant en un demi-siècle
à une augmentation de la densité de stockage de 8 ordres de grandeur. Ceci a entre
autres contribué à l’explosion des bases multimédia. Les réseaux sociaux de partage
de contenus multimédia se multiplient et la nécessité d’avoir des solutions de plus en
plus intelligentes s’impose. Prenons l’exemple de deux réseaux de partage de photos
phare, Flickr et Google+ dont les capacités de stockage sont impressionnantes :
– Sur Flickr, en 2013, 586 millions d’images publiques ont été mises en ligne
contre 518 millions en 2012 3
;
– Pas moins de 1.5 milliards de photos sont mises en ligne chaque semaine sur
Google+ par les 300 millions d’utilisateurs actifs 4
.
La reconnaissance d’images par le contenu appelée en anglais CBIR (Content Based
Image Retrieval) se retrouve donc au cœur des besoins des moteurs de recherche
et offrirait des solutions de choix pour les utilisateurs. Pour citer un exemple de
solution très attractive, Google+ propose à ses utilisateurs des images animées de
type "GIF" construites à partir d’un ensemble d’images représentant la même scène.
Ce genre d’applications intéresse bien évidemment les abonnés qui n’y voient que des
avantages. Nous ne visons pas ce type d’applications dans ces travaux qui cependant
illustrent bien le potentiel d’un système de recherche d’images. Si nous nous en
tenons à un système de reconnaissance d’images dit "basique"
5
, parmi les solutions
"grand public" existantes, la plus connue est le moteur de recherche d’images de
Google. D’autres moteurs de recherche d’images beaucoup moins connus mais tout
aussi efficaces existent. Il s’agit, par exemple, de Bigimbaz 6 mis en place par les
chercheurs Jégou et al. [Jégou 10a].
1. La carte perforée 80 colonnes de IBM standardisée pour l’informatique
2. IBM 350
3. https://secure.flickr.com/photos/franckmichel/6855169886/in/photostream/
4. http://www.techhive.com/article/2058687/google-wants-you-and-your-photos-to-never-ever-leave.html
5. Nous appelons ainsi tous les systèmes qui retrouvent un ensemble d’images ayant un ou
plusieurs critères bas-niveau en commun
6. http://bigimbaz.inrialpes.fr/demo/
7Introduction Partie 1
Les solutions existantes sont constamment améliorées pour s’adapter aux différents
supports d’affichage et de travail. Les performances de ces systèmes d’indexation
sont alors variées puisqu’ils ne répondent pas aux mêmes exigences :
– Ceux qui ont des contraintes de rapidité ou des limites en termes de mémoire
(par exemple, les applications sur les mobiles) se contenteront d’une solution
algorithmique légère et peut-être un peu moins précise mais acceptable ;
– Ceux qui ont des objectifs de précision (le cas de Bigimbaz) pourront s’octroyer
des délais de réponses plus longs certes mais acceptables.
Avec ces différentes applications en constante amélioration, on assiste à un domaine
en perpétuelle évolution. Ceci explique le grand nombre de stratégies de travail
proposées dans la littérature. De ce fait, nous ne proposerons pas un état de l’art
exhaustif. Il sera axé sur les propositions qui ont constitué un point de départ à nos
travaux. Cette partie comportera deux chapitres :
– Un premier qui présentera quelques solutions à la problématique de recherche
d’images par le contenu ;
– Un second dans lequel nous exposerons nos axes d’amélioration de certaines
solutions existantes.
8Chapitre 1
Solutions de recherche d’images
par le contenu
Sommaire
1.1 Descripteurs d’images . . . . . . . . . . . . . . . . . . . . . 10
1.1.1 Exemples de caractéristiques globales . . . . . . . . . . . 11
1.1.2 Caractérisation locale : l’alternative aux insuffisances des
descripteurs globaux . . . . . . . . . . . . . . . . . . . . . 11
1.2 Recherche des images les plus ressemblantes . . . . . . . 20
1.2.1 Création du dictionnaire de mots visuels . . . . . . . . . . 21
1.2.2 Quelques méthodes de création de la signature visuelle
d’une image . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.2.3 Recherche des images similaires à partir de leurs signatures
visuelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.3 Saillance visuelle . . . . . . . . . . . . . . . . . . . . . . . . 28
1.3.1 Qu’est-ce que l’attention visuelle ? . . . . . . . . . . . . . 28
1.3.2 Différents modèles de saillance visuelle . . . . . . . . . . . 34
1.3.3 Modèle de saillance de Itti et Koch . . . . . . . . . . . . . 35
1.3.4 Évaluation des modèles de saillance visuelle . . . . . . . . 37
1.4 Quelques travaux intégrant la saillance visuelle en recherche
d’images par le contenu . . . . . . . . . . . . . . . 38
Introduction
Une tâche d’indexation se décompose généralement en deux étapes :
1. Transformer l’image en matrice de valeurs : l’image est alors représentée par
un ensemble de valeurs susceptibles d’être le plus robustes possible aux transformations
géométriques, de point de vue entre autres ;
2. Comparer les matrices de représentation des images.
Dans ce chapitre nous évoquerons quelques solutions de la littérature concernant ces
deux étapes dans un système de recherche d’images par le contenu.
9Chapitre 1. Solutions de recherche d’images par le contenu
1.1 Descripteurs d’images
Dans l’idéal les descripteurs doivent être robustes à un ensemble de variations
notamment :
– Les transformations géométriques de type rotation, translation, etc ;
– Les changements de point de vue ;
– Les changements d’échelle.
Quelques-unes de ces variations sont illustrées sur la Figure 1.1. La robustesse à
un changement de plan ou à toute modification de couleur est le plus souvent très
complexes à obtenir. En effet, un changement de plan peut entraîner une occlu-
(a) (b) (c)
(d) (e) (f)
Figure 1.1: Exemple d’images présentant des variations géométriques et/ou des changements
de plan de photographie. Ces images sont issues de la base proposée par Nistér et al.
[Nistér 06]. L’image 1.1(e) illustre l’occlusion des autres chiffres induite par le changement
d’angle de prise de vue.
sion, induisant ainsi un objet (une scène) incomplet (incomplète) comme on peut le
voir sur l’image 1.1(e). D’ailleurs, sur cette même illustration, on peut constater un
changement de luminosité. Le phénomène de "cropping" illustré sur la figure 1.1(f)
peut être le résultat d’un changement d’échelle ou de point de vue. Malgré leur complexité,
toutes ces variations doivent être au mieux intégrées dans la représentation
des images afin que la tâche d’indexation exécutée par l’ordinateur se rapproche au
mieux des vérités terrains proposées par l’humain.
Deux types de solutions sont proposées dans la littérature pour la description des
images :
– Les descripteurs globaux qui permettent de définir la scène dans sa géné-
ralité. Ils sont la plupart du temps relatifs à des informations de type couleurs,
textures ;
– Les descripteurs locaux qui décrivent le comportement local d’un point ou
d’une région. Ces attributs peuvent être relatifs à la couleur, à la texture, à la
géométrie ou à une combinaison de ces informations bas niveau.
10Chapitre 1. Solutions de recherche d’images par le contenu
1.1.1 Exemples de caractéristiques globales
Plusieurs solutions ont été proposées en matière de description globale des images.
La première solution et la plus répandue est l’utilisation des histogrammes "couleur"
introduit par Swain et Ballard en 1991 [Swain 91]. Ils proposent d’utiliser une
méthode de mise en correspondance nommée "intersection d’histogrammes". Cette
dernière informe sur le nombre de pixels de l’histogramme de l’image requête qui
sont présents dans l’image en cours d’analyse. Leur méthode est robuste à de nombreuses
transformations qui induisent, la plupart du temps, en erreur les systèmes
de recherche d’images par le contenu telles que :
– Les "distractions" dans le fond de l’objet ;
– Les changements des angles de prise de vue ;
– Les occlusions ;
– Les changements de résolution de l’image.
Les résultats qu’ils obtiennent sont intéressants surtout pour des images dont les
couleurs sont très discriminantes.
Une autre représentation globale de l’image qui a obtenu de très bons résultats
dans la littérature est le descripteur "GIST". Il a été introduit par Oliva et Torralba
en 2001 [Oliva 01]. Il permet de représenter la structure dominante spatiale
de la scène à partir d’un ensemble de dimensions perceptives (la naturalité de la
scène, son ouverture, sa rugosité, son expansion et sa robustesse). Ces 5 dimensions
"perceptives" ne sont pas calculées mais plutôt estimées à partir des informations
spectrales et des informations grossièrement localisées. La première étape de l’algorithme
est d’opérer un filtrage sur les images avec un banc de filtre de Gabor.
Ensuite, des histogrammes d’orientations sont calculés sur des imagettes (régions locales)
de dimensions paramétrables afin d’obtenir le descripteur final. Le descripteur
GIST a été largement utilisé dans la littérature donnant des résultats satisfaisants
[Hays 07, Li 08, Douze 09]. Malgré ces résultats ce descripteur n’est robuste qu’à
très peu de variations. Il présente des limites face à une translation par exemple.
Les descripteurs globaux donnés en exemple ci-dessus permettent d’obtenir des
résultats intéressants dans la littérature. Ils présentent néanmoins des limitations
majeures qui expliquent l’utilisation massive des descripteurs locaux. Se baser uniquement
sur des informations globales ne permet pas toujours de distinguer le fond
de l’objet, de gérer les problèmes d’occlusion, de "cropping", etc . . .
1.1.2 Caractérisation locale : l’alternative aux insuffisances
des descripteurs globaux
Contrairement aux descripteurs précédents, ces descripteurs s’intéressent aux
structures locales. L’objectif est de capturer toutes les particularités locales afin
d’augmenter la robustesse aux différentes transformations évoquées précédemment.
Il faut, dans un premier temps, détecter les structures locales et ensuite les décrire.
Notons quand même qu’on retrouve de plus en plus dans la littérature des solutions
utilisant une détection dense [Perronnin 08, Gordoa 12]. Dans ce cas, tous ou qua-
11Chapitre 1. Solutions de recherche d’images par le contenu
siment tous les pixels (choisis à l’aide d’une fenêtre) sont décrits afin de capturer
beaucoup plus de variations. Nous n’aborderons pas ces propositions. Il n’y a pas de
convention et les schémas d’échantillonnage dépendent essentiellement des applications
(recherche dans de très grandes bases d’images, reconnaissance et classification
d’objets, . . . ).
Détection des caractéristiques locales
Nous présenterons ici une sélection non exhaustive de détecteurs locaux. Le lecteur
intéressé pourrait se référer au travail de Tuytelaars et al. [Tuytelaars 08], publié
en 2008, pour plus de détails.
La détection des caractéristiques locales est souvent la première étape de nombreux
systèmes de vision par ordinateur, par exemple, pour du suivi ou de la reconnaissance
d’objets. L’idée est de pouvoir détecter les mêmes régions/points après des transformations,
comme un changement de perspective, une translation, une rotation ou
encore un changement d’éclairage. Ceci est primordial pour avoir des résultats satisfaisants
et proches de ceux de l’être humain. Cette propriété de robustesse leur
confère d’être abusivement traitées d’invariantes comme le soulignent Mikolajczyk
et al. [Mikolajczyk 05b]. Ils estiment que ces régions devraient être justement qualifiées
de "covariantes". Elles devraient changer de façon covariante en fonction des
différentes transformations.
Les détecteurs de caractéristiques locales peuvent être classés de plusieurs manières.
Schmid et al. [Schmid 00] proposent, par exemple, une catégorisation en 3
groupes contre une version plus détaillée en 8 groupes pour Tuytelaars et Mikolajczyk
[Tuytelaars 08]. Nous utiliserons dans ce manuscrit la classification compacte
en trois familles 1
:
– Les méthodes "basées contour" qui extraient dans un premier temps des
contours. À partir de ceux-ci, une recherche de la courbure maximale ou des
points d’inflexion est faite pour détecter les caractéristiques locales. La recherche
des points d’inflexion ou de courbure maximale peut être remplacée
par une approximation polygonale. Les caractéristiques locales correspondent
dans ce cas aux différents points d’intersection ;
– Les méthodes "basées intensité" qui utilisent une mesure basée sur le
niveau de gris du pixel pour indiquer si oui ou non on est en présence d’une
caractéristique locale. La plupart des détecteurs que nous aborderons dans
cette partie sont dans cette catégorie ;
– Les méthodes de modèle paramétrique qui adaptent un modèle paramé-
trique d’intensité au signal.
Quelle que soit la famille des méthodes, les détecteurs peuvent être classés en trois
groupes :
– Les détecteurs de coins qui détectent les points possédant une courbure
élevée dans une image 2D. Les coins se trouvent par exemple à différents types
de jonctions, sur des surfaces très texturées ;
– Les détecteurs de blobs qui produisent des ensembles cohérents de pixels
ayant des propriétés constantes. Tous les pixels d’un blob peuvent être consi-
1. Les que nous avons testés entre dans l’une des 3 familles.
12Chapitre 1. Solutions de recherche d’images par le contenu
dérés comme étant semblables les uns aux autres ;
– Les détecteurs de régions qui sont basés directement ou indirectement sur
des extractions de régions.
Les caractéristiques locales doivent répondre à un ensemble de contraintes qui dé-
pendent des besoins de l’application. Tuytelaars et Mikolajczyk [Tuytelaars 08] dé-
crivent un ensemble de propriétés qu’elles doivent posséder dans l’idéal :
– La répétabilité : si on prend deux images de la même scène prises dans des
conditions de vue différentes, elles doivent partager un nombre important de
caractéristiques détectées dans la partie commune de la scène ;
– Le caractère distinctif/informatif : il est lié à la description de la caractéristique.
Les modèles à l’origine des caractéristiques détectées doivent intégrer
beaucoup de variations permettant ainsi de les distinguer et de les mettre en
correspondance ;
– La localité : pour réduire les probabilités d’occlusions et pour être robuste aux
variations, les caractéristiques doivent être les plus locales possibles ;
– La quantité : il faut un nombre de caractéristiques suffisant. Elles doivent
refléter l’information contenue dans l’image afin d’en avoir une représentation
compacte ;
– La précision : plusieurs méthodes ont été proposées dans la littérature pour
évaluer la précision locale des caractéristiques. Ces dernières doivent être localement
précises aussi bien au regard de la position dans l’image qu’en respectant
l’échelle et la forme si possible ;
– L’efficacité : la détection des caractéristiques locales doit être adaptée aux
applications critiques en temps.
Cette liste de propriétés des caractéristiques locales n’est pas exhaustive. L’importance
de ces propriétés dépend des applications. Si on considère par exemple
l’efficacité, elle est intrinsèquement liée aux exigences de l’application et pourrait
conditionner les autres. La précision quant à elle sera indispensable dans des applications
de mise en correspondance de caractéristiques sur de grandes bases d’images.
Tous les détecteurs que nous évoquerons par la suite ont été définis à la base
pour des images en niveaux de gris. Ces dernières peuvent correspondre à l’image
couleur convertie en niveaux de gris ou aux images de chaque composante couleur
si on décide de faire des opérations marginales. Ceci implique que le terme "niveau
de gris" que nous employons n’est rien d’autre que la valeur du pixel dans une représentation
"uni-plan".
L’un des détecteurs retrouvé le plus souvent dans la littérature est un détecteur de
coins, proposé par Harris et Stephen en 1988 [Harris 88]. Ce détecteur comme beaucoup
d’autres de la littérature [Tomasi 91, Förstner 94, Mikolajczyk 01] se base sur la
matrice de la fonction d’auto-corrélation utilisée par Moravec en 1977 [Moravec 77].
En effet, Moravec a été le premier à développer un détecteur de caractéristiques locales
basé sur le signal. Son détecteur s’appuie sur la fonction d’auto-corrélation. Il
mesure les différences de niveaux de gris entre une fenêtre et des fenêtres glissantes
changeant de directions. Harris et Stephen, dans leur amélioration du détecteur
de Moravec, proposent d’utiliser la matrice d’auto-corrélation MHarris définie par
13Chapitre 1. Solutions de recherche d’images par le contenu
l’équation (1.1), autour d’un pixel (x,y) dans une fenêtre F d’une image I.
MHarris(x, y) =
P
F
Ix(xk, yk)
2 P
F
Ix(xk, yk)Iy(xk, yk)
P
F
Ix(xk, yk)Iy(xk, yk)
P
F
Iy(xk, yk)
2
, (1.1)
où Ix correspond à la dérivée première suivant x et Iy la dérivée première suivant y.
Les points ayant une grande valeur de C calculé avec l’équation (1.2) sont considérés
comme étant des coins.
C = det(MHarris) − k ∗ trace(MHarris)
2
(1.2)
Ce détecteur est invariant à la rotation mais n’est pas très robuste aux changements
d’échelle [Schmid 00].
En se basant sur le même principe que Harris et Stephen, Mikolajczyk et Schmid
[Mikolajczyk 01] ont proposé un détecteur invariant à la rotation et aux changements
d’échelle : le détecteur Harris-Laplace. Les points sont dans un premier temps
détectés par une fonction de Harris sur plusieurs échelles. Ensuite, seuls ceux ayant
une réponse maximale à la mesure locale (ici le laplacien) sont sélectionnés dans
l’espace d’échelle.
Lowe [Lowe 99], quant à lui, obtient l’invariance à l’échelle en convoluant l’image
par un noyau issu de la différence des gaussiennes à plusieurs échelles. La Figure
1.2 illustre l’algorithme. Il a introduit en plus une pyramide spatiale avec plusieurs
Figure 1.2: Principe de la différence de gaussiennes.
niveaux appelés "octaves". D’une octave à une autre, l’image est sous-échantillonnée
d’un facteur de 2. Cette méthode appelée DoG (Difference of Gaussians) est une
approximation rapide de la méthode LoG (Laplacian of Gaussian) dont le noyau est
particulièrement stable dans l’espace de l’échelle [Mikolajczyk 02]. La recherche des
extrema locaux se fait dans un voisinage dont on définit la taille dans 3 échelles. Les
extrema locaux permettent de détecter des structures de type blob.
De ces trois détecteurs, Harris-Laplace a une meilleure répétabilité selon les travaux
14Chapitre 1. Solutions de recherche d’images par le contenu
de Mikolajczyk et Schmid [Mikolajczyk 01] pour des scènes planes.
Les détecteurs cités ci-dessus ne répondent pas toujours aux besoins des applications
temps-réels ou avec des contraintes temporelles exigeantes. Des solutions
ont donc été proposées parmi elles, le détecteur FAST (Features From Accelerated
Segment Test) mis au point par Rosten et Drummond [Rosten 05, Rosten 06]. La
version [Rosten 06] inclut l’utilisation de l’apprentissage pour rendre le détecteur
plus rapide 2
. Ce détecteur se base sur le détecteur SUSAN (Smallest Univalue Segment
Assimiliating Nucleus) introduit par Smith et Brady [Smith 97]. Pour chaque
pixel de l’image, on considère un voisinage circulaire de rayon fixe. Le pixel central
est appelé "noyau". Tous les pixels contenus dans le disque fermé ainsi défini,
illustré sur la Figure 1.3(a), dont le niveau de gris se rapproche de celui du noyau
sont affectés d’une grande pondération. Les pixels dans l’image, dont la valeur de
niveau de gris correspond à un minimum local et est inférieure à un certain seuil
sont désignés comme étant les caractéristiques locales. Elles correspondent en fait à
des coins dans l’image. Le détecteur FAST reprend la même idée en ne considérant
que les pixels sur le cercle. Le rayon du cercle est fixé à 4 et seulement les 16 voisins
du noyau, définis suivant la Figure 1.3(b), sont traités. Le pixel central est désigné
comme étant une caractéristique locale si au moins 12 pixels contigus ont des valeurs
de niveau de gris inférieures à celle du noyau et à un certain seuil. Ce changement
induit des gains en temps de calcul considérables comme le montre le Tableau 1.1.
(a) SUSAN (b) FAST
Figure 1.3: Voisinage du noyau considéré pour déterminer la caractéristique locale avec les
algorithmes SUSAN (a) et FAST (b).
Tous les détecteurs que nous avons décrits sont illustrés sur la Figure 1.4 dans les
configurations suivantes :
– Le détecteur de Harris (b) avec : k=0.06, le seuil de Harris est défini égal à
0.05 multiplié par la meilleure valeur de C calculée avec l’équation (1.2) et une
taille de voisinage de 3x3. Ce détecteur a été calculé avec la librairie Opencv ;
– Le détecteur Harris-Laplace (c) avec : k=0.06, le seuil de la fonction de Harris
est égal à 10−9
et le seuil pour le laplacien est égal 0.03. Il a été obtenu avec
2. C’est d’ailleurs cette version qui est intégrée dans la bibliothèque Opencv que nous avons
testée.
15Chapitre 1. Solutions de recherche d’images par le contenu
Tableau 1.1: Comparaison des temps de calcul des détecteurs Harris, SUSAN et FAST. Les
résultats présentés dans ce tableau sont ceux présentés dans [Rosten 05] pour une image
de taille 768*288 pixels.
Détecteurs FAST SUSAN Harris
Temps (ms) 2.6 11.8 44
(a) Image originale (b) Harris : 47 points (c) Harris-Laplace : 914 points
(d) DoG : 650 points (e) FAST : 759 points
Figure 1.4: Illustration des caractéristiques locales détectées par les différents détecteurs
présentés dans cette sous-section.
le logiciel de van de Sande [van de Sande 10] ;
– Le détecteur DoG (d) calculé avec la librairie Opencv à partir du détecteur du
descripteur SIFT dans sa configuration par défaut ;
– Le détecteur FAST (e) pour lequel le seuil de comparaison des niveaux de
gris entre le "nucleus" et ses voisins fixé à 30. Il a été également calculé avec
Opencv.
On remarque que le nombre de caractéristiques locales varie d’un détecteur à l’autre
en analysant les images de la Figure 1.4. Pour l’image 1.4(a) le détecteur qui propose
le moins de caractéristiques locales est celui de Harris mais ceci ne généralise en rien
la quantité de caractéristiques locales qu’il détecte. Ce comportement est avant tout
lié au contenu de l’image.
Comme nous l’avons dit en introduction à cette section, les détecteurs ne sont
que la première étape d’une tâche de recherche d’images. L’étape suivante consiste
à décrire les caractéristiques locales. Il existe dans la littérature un grand nombre de
descripteurs répondant à des contraintes applicatives très différentes. Dans la section
suivante, nous présenterons quelques-uns de ceux qui sont le plus souvent utilisés
depuis une dizaine d’années environ en insistant sur ceux que nous avons retenus.
16Chapitre 1. Solutions de recherche d’images par le contenu
Quelques descripteurs de caractéristiques locales
Nous ne pouvons pas parler des descripteurs de caractéristiques locales utilisés en
recherche d’images basée contenu sans évoquer le descripteur SIFT (Scale-Invariant
Feature Transform). C’est l’un des descripteurs les plus utilisés dans la littérature
[Lowe 99, Lowe 04, Ke 04, Nistér 06, van de Sande 10, Jégou 10b, Jégou 11] du fait
de son efficacité. Il a été proposé par David G. Lowe en 1999 [Lowe 99] et répond à
une bonne partie des contraintes d’une tâche de recherche d’images par le contenu
évoquées précédemment. C’est un vecteur de caractéristiques locales qui décrit un
pixel et qui est robuste :
– À la translation ;
– Au changement d’échelle ;
– À la rotation ;
– Aux changements d’éclairage ;
– Aux projections affines ou 3D.
Dans l’algorithme proposé par Lowe [Lowe 99] les caractéristiques locales sont dé-
crites avec un détecteur de type DoG. Ensuite chaque caractéristique que nous appellerons
"point clé" pour simplifier la lecture est décrite à l’aide d’un ensemble
d’histogrammes des orientations comportant 8 intervalles. Pour ce faire, on définit
une région de taille 16*16 autour du point clé. Cette région est ensuite divisée en
4 sous-régions de taille 4*4 dans lesquelles on calcule l’orientation et l’amplitude
du gradient. À partir de ces informations on décrit le point par une concaténation
de tous les histogrammes des 8 orientations du gradient dans chaque sous-région.
L’histogramme de chaque sous-région de taille 4*4 est obtenu en faisant la somme
des amplitudes du gradient en chaque point pondérée par une gaussienne centré sur
le point clé, d’écart type égal à 1.5 fois le facteur d’échelle du point clé. L’orientation
du gradient détermine l’intervalle à incrémenter dans l’histogramme. Toutes ces
différentes étapes de l’algorithme de calcul du descripteur SIFT sont illustrées par
la Figure 1.5. Le descripteur final est de taille 128=4*4*8.
Figure 1.5: Différentes étapes de la description d’un point clé avec l’algorithme SIFT. Le
point à décrire est représenté en rouge. Le cercle sur la figure du milieu illustre la gaussienne
utilisée pour pondérer les amplitudes du gradient avant de construire l’histogramme final.
L’algorithme initial utilise une image en niveaux de gris. Plusieurs extensions couleurs
ont donc par la suite été proposées :C-SIFT [Abdel-Hakim 06, Burghouts 09]
ou encore Opponent-SIFT [van de Sande 10] par exemple. Cette dernière serait
plus adaptée à la reconnaissance d’images par le contenu selon van de Sande et al.
17Chapitre 1. Solutions de recherche d’images par le contenu
[van de Sande 10] quand on ne dispose d’aucun a priori sur les bases d’images.
C-SIFT, dans sa version actuelle, a été formalisé par Burghouts et Geusebroek
[Burghouts 09] et prend en compte des informations relatives aux invariants couleur
introduits par Geusebroek et al. [Geusebroek 01]. Ces invariants couleur sont
obtenus à partir d’un modèle de couleurs antagonistes qui peut être approximé par
l’équation :
Ê
Êλ
Êλλ
=
0.06 0.63 0.27
0.30 0.04 −0.35
0.34 −0.6 0.17
∗
R
G
B
, (1.3)
λ correspond à la longueur d’onde.
L’idée d’intégrer les invariants couleur a été, dans un premier temps, suggérée par
Abdel-Hakim et Farag [Abdel-Hakim 06] qui n’utilisaient alors que la seule propriété
de réflectance correspondant au ratio entre Eb
λ et Eb
λλ. Burghouts et Geusebroek
[Burghouts 09] proposent d’utiliser l’invariant photométrique sur l’intensité (ici la
première composante du nouvel espace couleur) Wcw obtenu avec l’équation (1.4) et
les invariants à l’ombre et à l’ombrage Cb
λw et Cb
λλw qui sont donnés respectivement
par les équations (1.5) et (1.6).
Wcw =
Eb
w
Eb
avec Eb
w =
q
Eb2
x + Eb2
y
(1.4)
Eb
x et Eb
y désignent respectivement les dérivées spatiales de Eb suivant x et y.
Cb
λw =
q
Cb2
λx + Cb2
λy avec Cb
λj =
Eb
λjEb − Eb
λEb
j
Eb2
, (1.5)
Cb
λj =
Eb
λjEb − Eb
λEb
j
Eb2
avec Cb
λλj =
Eb
λλjEb − Eb
λλEb
j
Eb2
, (1.6)
j ∈ {x, y} et désigne les dérivées spatiales suivant x et y.
Ce descripteur est plus robuste que SIFT en respectant les couleurs et les variations
photométriques. Sa performance a été prouvée par van de Sande et al.
[van de Sande 10] sur la base de données PASCAL VOC 2007 [Everingham 12] pour
une tâche de classification d’images. Il vient en seconde position derrière OpponentSIFT
pour les bases de données sans a priori.
L’idée des Opponent-SIFT est de calculer un descripteur décrivant tous les canaux
couleurs dans un espace "antagoniste" (01, 02, 03) défini par l’équation (1.7) créant
ainsi un descripteur de taille 384=128*3 comme C-SIFT. Le nouvel espace est défini
à partir des valeurs R (Rouge), G (Vert) et B (Bleu) des pixels de l’image.
01
02
03
=
R
√−G
2
R+G
√−2B
6
R+
√
G+B
3
(1.7)
Dans la littérature, on retrouve beaucoup d’autres descripteurs dérivés de SIFT et
de son fonctionnement. En effet, le descripteur SIFT n’est pas adapté à toutes les
applications malgré ses bons résultats du fait de sa grande dimensionnalité. L’une
18Chapitre 1. Solutions de recherche d’images par le contenu
des premières solutions a été apportée par Ke et Sukthankar qui proposent PCASIFT
[Ke 04] un descripteur de 36 dimensions. Ce descripteur est certes plus rapide
lors de l’étape de la mise en correspondance des vecteurs mais est moins distinctif
que SIFT d’après l’étude comparative de Mikolajczyk et Schmid [Mikolajczyk 05a].
Toujours dans l’optique de créer un descripteur plus rapide mais tout aussi efficace
que SIFT, Bay et al. ont proposé SURF (Speeded Up Robust Features) [Bay 06], un
descripteur de 64 dimensions. SURF existe aussi en 128 dimensions mais la version
en 64 dimensions donne des résultats très satisfaisants. Il ne s’agit pas seulement
d’un nouveau descripteur mais d’un nouveau schéma détecteur/descripteur. Les caractéristiques
locales sont détectées avec une matrice hessienne et l’algorithme utilise
des images intégrales pour gagner en rapidité. Dans leurs travaux, les auteurs
montrent que SURF est meilleur que SIFT ou encore PCA-SIFT pour de la reconnaissance
d’objets d’art. On peut citer plusieurs autres descripteurs qui ont été
proposés pour améliorer les résultats connus des SIFT, par exemple GLOH (Gradient
Location and Orientation Histogram). Il a été proposé par Mikolajczyk et
Schmid [Mikolajczyk 05a]. Il s’agit d’une variante de SIFT de dimension 128 mais
qui compense sa grande dimensionnalité par une meilleure précision d’après leurs
résultats. Les différences principales entre ce descripteur et SIFT sont les suivantes :
– Le descripteur est calculé sur une grille "log-polaire" contrairement à la grille
rectangulaire utilisée pour SIFT ;
– La quantification de l’orientation du gradient est plus précise (16 orientations
au lieu des 8 utilisées dans SIFT) ;
– Pour réduire la dimensionnalité du descripteur GLOH à 128, les auteurs utilisent
une ACP (Analyse en Composantes Principales).
Hormis les extensions couleurs de SIFT de la littérature, tous les descripteurs
évoqués ci-dessus ne considèrent que des images en niveaux de gris. Il existe néanmoins
quelques solutions pour prendre en compte l’information couleur. Il s’agit
entre autres des moments couleur et des invariants de moments couleur calculés
dans une région dont on définit la taille autour du point clé.
Les moments couleurs, que nous abrégerons CM (Colour Moments), permettent de
mesurer la similarité couleur entre deux images. Ils sont basés sur les moments couleur
généralisés proposés par Mindru et al. [Mindru 04] sur des patchs de l’image.
Ils se calculent à partir des valeurs R, G, et B des pixels des régions considérées.
L’ensemble des moments couleur généralisés M d’ordre p+q et de degré a+b+c d’une
caractéristique locale dans une région Ω est obtenu grâce à l’équation (1.8).
Mabc
pq =
ZZ
Ω
x
p
y
q
[R(x, y)]a
[G(x, y)]b
[B(x, y)]c
dxdy (1.8)
La plupart du temps, on ne considère que les moments de premier ordre et du second
degré : Mabc
00 , Mabc
10 et Mabc
01 , ce qui correspond à 27 moments avec :
(a, b, c) ∈
(1, 0, 0),(0, 1, 0),(0, 0, 1)
(2, 0, 0),(0, 2, 0),(0, 0, 2)
(1, 1, 0),(1, 0, 1),(0, 1, 1)
.
On peut ajouter les 3 moments d’ordre 0 ; M000
00 , M000
10 et M00
01 qui sont des constantes.
On obtiendrait alors 30 moments.
19Chapitre 1. Solutions de recherche d’images par le contenu
Les invariants de moments couleur, abrégés CMI (Colour Moment Invariants) dans
ce manuscrit, ont été également proposés par Mindru et al. [Mindru 04]. Ces derniers
sont calculés à partir des CM. Pour considérer les trois canaux couleur, il faut
utiliser les invariants "3-bandes" définis dans l’Annexe A.
Tous les descripteurs évoqués précédemment ne sont pas facilement utilisables
sur des systèmes embarqués du fait des contraintes en termes de mémoire de calcul
posés par ces derniers. L’autre famille de propositions de la littérature concerne donc
les descripteurs binaires. L’idée est de pouvoir résumer la plupart des informations
d’un patch avec une suite binaire obtenue uniquement à partir de la comparaison des
valeurs des pixels des images. L’utilisation de suites binaires a des avantages considérables.
Lors de la comparaison de plusieurs images, on peut utiliser des distances
de similarité très simples et rapides à mettre en œuvre : la distance de Hamming
par exemple. Elle est définie par l’équation (1.9) entre deux suites binaires a et b de
taille NS.
Définition
Soient deux suite binaires a et b de taille NS, leur distance de Hamming est donnée
par :
d
Hamming
(a,b) =
N
XS−1
i=0
ai ⊕ bi
, ⊕ désignant le ou exclusif. (1.9)
Comme exemple de descripteurs binaires, nous pouvons citer :
– BRIEF (Binary Robust Independent Elementary Features) [Calonder 10] ;
– FREAK (Fast Retina Keypoint) [Alahi 12] ;
– BRISK (Binary Robust Invariant Scalable Keypoints) [Leutenegger 11].
Une fois les descripteurs calculés, l’étape suivante est la comparaison des images à
partir de leurs vecteurs de descripteurs.
1.2 Recherche des images les plus ressemblantes
Pour la recherche des images les plus ressemblantes, deux solutions intuitives
existent :
– Comparer les vecteurs de descripteurs entre eux en évaluant la répétition d’une
ou de plusieurs caractéristiques locales ;
– Créer une nouvelle signature de l’image facilement exploitable à partir des
vecteurs de descripteurs.
Dans la littérature, les deux solutions sont proposées et leur utilisation dépend le plus
souvent des applications. Nous nous focaliserons sur la seconde solution. En effet,
les vecteurs de descripteurs ne peuvent pas toujours être utilisés tels quels puisqu’ils
sont de grandes dimensions (nombre de caractéristiques locales ∗ dimensions du
descripteur), entraînant la nécessité d’une certaine mémoire de stockage pour la
comparaison. La solution la plus répandue dans cette seconde famille de méthodes est
communément appelée "Sac de mots visuels" que nous noterons BoVW (Bag of Visual
Words) pour faciliter la lecture et la présentation des résultats. Cette solution a été
20Chapitre 1. Solutions de recherche d’images par le contenu
initialement proposée par Sivic et Zisserman [Sivic 03] pour la recherche d’images
et de vidéos. Elle s’inspire de la méthode "Sac de mots" utilisée en catégorisation
de texte. L’idée est de créer une signature plus facilement exploitable pour chaque
image à partir des mots visuels. On décidera alors que deux images sont visuellement
proches si leurs signatures le sont. Le principe général est décrit sur la Figure 1.6.
On notera d’ailleurs que la création du dictionnaire visuel doit se faire de préférence
sur une(des) base(s) de données indépendante(s) de la base de tests pour inclure le
plus de variabilité possible.
Figure 1.6: Illustration de la création de la signature visuelle d’une image à partir de ses
descripteurs et d’un vocabulaire visuel.
1.2.1 Création du dictionnaire de mots visuels
L’idée sous-jacente à cette notion de "dictionnaire de mots visuels" est de disposer
d’un ensemble de mots visuels le plus variés possible afin d’avoir une bonne
représentation des images proches. La solution de la littérature est d’utiliser un algorithme
de quantification pour définir les mots visuels. Un exemple est illustré sur
la Figure 1.7.
Il existe plusieurs choix de quantifications possibles. La solution la plus utilisée est
l’algorithme K-means [Jégou 10b, van de Sande 10]. On effectue un clustering des
différents vecteurs de descripteurs de la base "d’apprentissage" des mots en K clusters
dont les centres constitueront les mots du futur dictionnaire visuel.
Soient :
– D l’ensemble des vecteurs de descripteurs de la base de construction des mots ;
D est de taille NB∗taille du descripteur : par exemple, NB∗128 pour des descripteurs
SIFT ou encore NB ∗ 24 pour des CMI, NB est le nombre de descripteurs
dans toute la base.
– W l’ensemble des mots visuels ; W est de taille K∗taille du descripteur.
Le principe est le décrit par l’Algorithme 1.
21Chapitre 1. Solutions de recherche d’images par le contenu
Figure 1.7: Exemple de quantification en 2D. Les points en rouge correspondent aux centroïdes
des différentes régions qui seront retenus. Si on se place dans un contexte de
construction de dictionnaire visuel ces points correspondraient aux mots visuels.
Algorithme 1 : Algorithme de K-means
Entrées : D, K
Sorties : W
Initialiser de façon aléatoire W;
répéter
Affecter à chaque centroïde tout vecteur de descripteurs tel que la
distance entre le vecteur et le centroïde soit la plus petite;
Modifier le centroïde des groupes qui se forment;
jusqu’à Le centroïde de chaque groupe ne change plus;
La distance entre le vecteur de descripteurs et le centroïde se fait le plus souvent
avec une distance euclidienne dont la relation est donnée par l’équation (1.10).
Définition
Soient deux vecteurs A = [a1, a2, . . . , aND−1, aND
] et B = [b1, b2, . . . , bND−1, bND
]
de taille ND (ND est le dimensionnalité du descripteur : pour SIFT, ND=128), la
distance euclidienne entre A et B notée d
L2
A,B est donnée par :
d
L2
A,B =
vuutX
ND
i=1
(ai − bi)
2
. (1.10)
Dans la mise en œuvre du K-means on peut jouer sur la distance de comparaison
entre les vecteurs de descripteurs et les centroïdes. Ce qui peut donner lieu à des
distributions uniformes ou encore gaussiennes. Le principal inconvénient de cette
méthode est l’initialisation des mots visuels. Le dictionnaire final est très dépendant
de la répartition des mots germes. Si les germes ne respectent pas la distribution des
caractéristiques on a peu de chance d’avoir un dictionnaire final représentatif.
Il existe plusieurs variantes de cet algorithme par exemple :
– K-medians qui calcule la médiane au lieu de la moyenne et compare les vecteurs
entre eux avec une distance L1 ;
– K-medoids qui calcule un medoïde qui est un point du groupe de points qui
minimise la dissimilarité avec les autres points du cluster. La dissimilarité
22Chapitre 1. Solutions de recherche d’images par le contenu
entre les points peut être calculée avec une distance euclidienne, une distance
de Manhattan ou une distance de Minkowski.
Une autre solution de la littérature qui donne de très bons résultats pour la création
du dictionnaire est l’algorithme GMM (Gaussian Mixture Model) [Perronnin 06,
Perronnin 08]. L’idée dans ce cas est d’utiliser un modèle statistique pour trouver les
différents mots visuels. L’ensemble des vecteurs de descripteurs est modélisé comme
étant la somme de plusieurs gaussiennes pondérées par un poids π dont il faut déterminer
la covariance et la moyenne. Les hypothèses suivantes, illustrées par la Figure
1.8, sont nécessaires pour définir le dictionnaire visuel à partir d’un GMM :
1. L’ensemble de vecteurs comporte K groupes qu’on note G ;
2. Chaque groupe gk est associé à une moyenne µk, une covariance σ
2
k
et un poids
πk ;
3. Les éléments de chaque groupe suivent une loi normale de moyenne µk et de
covariance σ
2
k
.
Figure 1.8: Illustration des différentes hypothèses de l’algorithme GMM.
Chaque vecteur di appartient donc à un groupe gk paramétré par θk = (µk, σ2
k
).
L’ensemble des groupes G peut donc s’écrire comme étant une fonction de mélange
de densité donnée par l’équation :
G(D, Φ) = X
K
k=1
πkf(D, θk), (1.11)
avec Φ = (π1, . . . , πk, θ1, . . . , θk) et f(D, θk) la loi normale multivariée paramétrée
par θk.
Φ est estimé avec un algorithme EM (Expectation-Maximisation) en trouvant le
paramètre qui maximise la vraisemblance L(D, Φ) donnée par l’équation :
L(D, Φ) = X
N
i=1
log X
K
k=1
πkf (Di
, θk)
!
. (1.12)
On affecte pour finir chaque vecteur de descripteur di au groupe gk auquel il appartient
si la probabilité a posteriori P(di∈gk
) calculée avec l’équation (1.13) est la plus
grande.
P(di ∈ gk) = πkf(di
, θk)
PK
l=1 πlf(di
, θl)
(1.13)
23Chapitre 1. Solutions de recherche d’images par le contenu
Les deux solutions de création de dictionnaire visuel présentées ci-dessus sont
ensuite utilisées dans la représentation de chaque image pour la phase de recherche.
Nous présenterons dans la sous-section suivante trois solutions de la littérature :
– La première solution que nous avons évoquée au début de cette sous-section
est la méthode BoVW [Sivic 03] qui est souvent utilisée après avoir construit
le dictionnaire visuel avec un algorithme de type K-Means ;
– La seconde technique, le vecteur de Fisher [Perronnin 07], se base sur le dictionnaire
généré avec un GMM ;
– La troisième solution que nous présenterons s’appelle VLAD (Vector of Loccally
Aggregated Descriptors) [Jégou 10b]. C’est une approximation de la technique
précédente avec un dictionnaire visuel construit avec un algorithme KMeans.
1.2.2 Quelques méthodes de création de la signature visuelle
d’une image
Sac de mots visuels
Pour cette signature visuelle, l’idée est de compter dans chaque image l’occurrence
des mots du dictionnaire visuel afin d’obtenir un histogramme de répartition.
Le principe est illustré sur la Figure 1.9.
Figure 1.9: Illustration de la mise en œuvre de l’algorithme BoVW.
Au lieu de simplement représenter les images par un comptage des occurrences de
chaque mot, on peut pondérer le "Sac de mots visuels". Le schéma de pondération
standard s’appelle tf-idf (term frequency-inverse document frequency) [Sivic 03] et
provient de la catégorisation de texte. Si on suppose que l’on dispose d’un dictionnaire
de K mots, chaque document est alors représenté par un vecteur Hd =
24Chapitre 1. Solutions de recherche d’images par le contenu
(h1, . . . , hk . . . , hK)
⊤ de fréquences pondérées obtenues avec l’équation (1.14).
hk =
nkd
nd
log N
nk
, (1.14)
avec nkd le nombre d’occurrences du mot k dans le document d, nd le nombre total
de mots dans le document d, nk le nombre d’occurrences du mot k dans la base et
N le nombre de documents dans la base.
Ce schéma de pondération permet de diminuer le poids des mots fréquents.
La signature visuelle BoVW est de taille K. Elle présente notamment deux inconvénients
qui dépendent surtout de sa mise en œuvre. Le premier est directement
lié au dictionnaire utilisé. La plupart du temps on utilise un dictionnaire issu d’un
algorithme K-Means. Cette quantification introduit des pertes d’information et a
pour conséquence de nécessiter l’utilisation d’un dictionnaire de grande taille pour
assurer la variabilité des mots [Perronnin 07]. La seconde insuffisance est la repré-
sentation sous forme d’histogrammes. Compter les occurrences d’un mot visuel pour
représenter une image beaucoup plus complexe introduit potentiellement un manque
à gagner en précision au moment de la recherche. Ce sont ces deux raisons qui ont
motivé Perronnin et Dance [Perronnin 07] à proposer l’utilisation des noyaux de Fisher
pour la reconnaissance d’images en utilisant un dictionnaire visuel obtenu avec
un GMM.
Vecteur de Fisher
Soient D = {dn, n=1,...,N } un ensemble représentant les descripteurs d’une image,
uλ une fonction de densité de probabilité qui modélise un processus avec [λ1, . . . , λK]
′
le vecteur de K paramètres de uλ. L’idée est d’utiliser les outils statistiques pour
calculer une fonction de score notée GD
λ donnée par l’équation (1.15) qui calcule le
gradient du log-ressemblance des données par rapport au modèle. Elle décrit ainsi
la contribution de chaque paramètre au processus généré, en indiquant comment les
paramètres du modèle généré uλ devraient être modifiés pour coller au mieux aux
données D.
G
D
λ = ∇λ log uλ (D) (1.15)
Une fois ce gradient défini, on associe alors à chaque image un vecteur de Fisher
G
Dλ grâce à l’équation :
G
Dλ = LλG
D
λ = Lλ∇λ log uλ (D) = X
N
n=1
Lλ∇λ log uλ (dn), (1.16)
dans laquelle Lλ est la racine carrée de la matrice d’information de Fisher Fλ définie
par l’équation :
Fλ = ED∼uλ
G
D
λ G
D
′
λ
= Lλ
′
Lλ. (1.17)
Le lecteur intéressé peut se référer au rapport de recherche publié en 2013 par Sánchez
et al. [Sánchez 13] pour plus de détails. Dans les travaux, de Perronnin et Dance
[Perronnin 07], uλ est un modèle de mélange gaussien (GMM) de K composantes qui
correspond au vocabulaire visuel. En comparaison avec les résultats de la méthode
25Chapitre 1. Solutions de recherche d’images par le contenu
BoVW, le vecteur de Fisher requière très peu de mots du fait de sa représentation.
Dans leurs travaux Perronnin et Dance [Perronnin 07] n’ont eu besoin que de 100
mots pour la catégorisation d’images.
VLAD (Vector of Locally Aggregated Descriptors)
VLAD est une technique de représentation des images qui a été introduite par
Jégou et al. [Jégou 10b] et peut être vue comme une version simplifié du vecteur de
Fisher qui ne considère pas les statistiques d’ordre supérieures.
Considérons :
– un dictionnaire visuel W = {w1, . . . , wK} composé de K mots visuels générés
avec un algorithme K-Means ;
– un ensemble de descripteurs D = {d1, . . . , dNB
} d’une base d’image.
Chaque descripteur dn est associé à son plus proche mot visuel wk avec la relation :
NN(dn) = argmin kdn − wkk. (1.18)
Ensuite on calcule la valeur du VLAD avec l’équation :
vk =
X
dn:NN(dn)=wk
(dn − wk). (1.19)
L’accumulation dans le calcul du VLAD de la différence dn − wk permet de caracté-
riser la distribution du vecteur par rapport au centre. Les auteurs préconisent une
normalisation L2 du VLAD avant de l’utiliser. Comme dans le cas de l’utilisation
d’un noyau de Fisher, les VLAD ne nécessitent pas beaucoup de mots. Les auteurs
ont d’ailleurs de très bons résultats avec 256 mots. La signature visuelle finale est
de taille K∗dimensionnalité du descripteur : K*128 pour le descripteur SIFT par
exemple.
Toutes les techniques présentées ici permettent de créer une signature visuelle des
images afin d’effectuer la comparaison des différentes signatures. Plusieurs travaux
de la littérature [Grauman 05, Lazebnik 06, van de Sande 10] montrent qu’on peut
optimiser l’étape de création des signatures en utilisant des pyramides spatiales.
L’idée est de subdiviser l’image en plusieurs imagettes et de calculer une signature
par subdivision. La signature finale peut être la concaténation de toutes les signatures
pondérées différemment en fonction de leur niveau dans la pyramide spatiale.
Il existe plusieurs options de pyramides spatiales. Celle proposée par Lazebnik et
al. [Lazebnik 06], et également utilisée par van de Sande et al. [van de Sande 10],
est illustrée par la Figure 1.10. Dans ce cas, le poids associé à chaque niveau de
pyramide est donné par l’équation (1.20) :
πl =
1
2
(L−l)
, (1.20)
avec L le nombre total de niveau et l=0, . . ., L-1.
Que l’on utilise des signatures avec ou sans pyramides spatiales, l’étape suivante est
la recherche des images similaires.
26Chapitre 1. Solutions de recherche d’images par le contenu
(a) Niveau 0 (b) Niveau 1 (c) Niveau 2
Figure 1.10: Illustration de la pyramide spatiale proposée par Lazebnik et al. [Lazebnik 06].
1.2.3 Recherche des images similaires à partir de leurs signatures
visuelles
Nous ne détaillerons pas les solutions de la littérature. En effet, la plupart est
implémentée et facilement accessible 3
.
Plusieurs solutions sont utilisables pour la recherche des images similaires à partir
des signatures visuelles. On peut les classer en deux grands groupes :
– Les solutions avec apprentissage pour la catégorisation ;
– Les solutions sans apprentissage pour la recherche d’images ressemblantes par
leur contenu.
Nous n’aborderons pas la première classe de solutions puisqu’il existe une panoplie
de classifieurs efficaces. Nous soulignerons juste que les SVM (Support Vector Machine)
sont très utilisés [van de Sande 10] et offrent de très bons résultats. Les trois
solutions de création de signatures des images présentées plus tôt dans ce manuscrit
s’adaptent très bien à ces différents classifieurs. Une mention spéciale est faite pour
les vecteurs de Fisher qui offrent de très bons résultats avec des classifieurs linéaires
[Perronnin 07].
Pour des signatures visuelles BoVW et VLAD, la recherche des signatures les plus
proches se fait traditionnellement avec l’équation :
NN(S1) = argmin dist(S1, S2), (1.21)
avec S1 la signature dont on recherche la plus proche voisine dans l’ensemble des
signatures S des images de la base, S2 une signature de la base et dist la distance
entre les deux signatures. Le plus souvent, on utilise la distance euclidienne mais on
peut également utiliser la distance χ
2 dans le cas d’une signature visuelle de type
"Sac de mots visuels" dont la relation est donnée par l’équation (1.22).
Définition
La distance χ
2
entre deux signatures visuelles S1 et S2 de taille K, notée d
χ
2
S1,S2
, est
donnée par :
d
χ
2
S1,S2 =
X
K
i=1
(S1(i) − S2(i))2
S1(i) + S2(i)
. (1.22)
3. https://gforge.inria.fr/projects/yael/, http://www.cs.umd.edu/~mount/ANN/,
http://www.cs.ubc.ca/research/flann/
27Chapitre 1. Solutions de recherche d’images par le contenu
Cette méthode de recherche n’est pas toujours adaptable pour des recherches dans
de grandes bases d’images (≥ 1 million d’images). En effet, le nombre de distances
à calculer peut vite devenir problématique et induire des temps de recherche importants.
Il existe plusieurs solutions de la littérature qui tentent de résoudre les
différentes problématiques liées à la recherche des voisins dans de très grandes
bases de données. Une solution au traditionnel algorithme de KNN est l’estimation
des plus proches voisins les plus probables. Cette stratégie de recherche ne
garantit pas toujours les voisins les plus proches mais les voisins le plus souvent
proches. Dans la littérature plusieurs travaux ont été consacrés à cette solution dont
[Arya 98, Indyk 98, Muja 09].
Si les signatures visuelles sont des vecteurs de Fisher, on pourrait également utiliser
la mesure de similarité M proposée par Sánchez et al. [Sánchez 13] définie par
l’équation :
M (S1, S2) = G
S1
′
λ G
S2
λ
. (1.23)
Nous venons de présenter quelques solutions de la littérature pour la reconnaissance
d’images par le contenu. Ces solutions peuvent être classées dans la catégorie
de "solutions classiques". En effet, d’autres solutions voient le jour en intégrant des
informations de notre système visuel humain dans l’une des deux étapes que nous
avons répertoriées au début de ce chapitre. On peut citer entre autres, l’utilisation de
la saillance visuelle. Nous proposons alors, pour mieux appréhender son utilisation,
de faire un état de l’art bref sur cette notion qui peut paraître simple, mais qui peut
être ambigüe dans sa définition si on ne pose pas correctement le cadre. Si nous le
qualifions de bref c’est parce que pour être complet, il devrait intégrer le point de
vue biologique du système visuel humain ; ce que nous ne ferons que succinctement
dans cet état de l’art.
1.3 Saillance visuelle
Si on se réfère à la définition du Larousse en ligne, est saillant quelque chose qui
"ressort" ; qui attire l’attention. Quand on parlera de saillance visuelle on s’intéressera
alors à la notion d’attention visuelle.
1.3.1 Qu’est-ce que l’attention visuelle ?
L’une des plus anciennes définitions de l’attention visuelle a été donnée par
Williams James en 1890 [James 90] :
"Everyone knows what attention is. It is the taking possession by the
mind, in clear and vivid form, of one out of what seem several simultaneously
possible objects or trains of thought. Focalization, concentration,
of consciousness are of its essence. It implies withdrawal from some things
in order to deal effectively with others."
L’attention visuelle pourrait donc être définie comme étant la capacité du cerveau
à sélectionner l’information visuelle pertinente en rejetant ce qui ne l’est pas dans
un contexte particulier. Pour mieux comprendre ce phénomène, on devrait donc
28Chapitre 1. Solutions de recherche d’images par le contenu
s’intéresser à ce qui se passe au niveau de notre système visuel humain (SVH).
Plusieurs documents de la littérature abordent le système visuel humain. Nous ne
ferons pas une description complète de ce système. Nous présenterons brièvement ce
qui se passe au niveau de la rétine et le traitement du signal post-rétinien. Le lecteur
intéressé pourra se référer à [Le Meur 05a, Perreira Da Silva 10a, Boujut 12].
Comment fonctionne le système visuel humain ?
Comme le dit Boujut [Boujut 12], l’œil humain peut être comparé à un appareil
photo numérique. Sur une caméra, l’image est projetée sur le capteur à travers la
lentille. Pour prendre une bonne photo, l’image projetée doit être dans le focus du
capteur, avec une luminosité adéquate (ni trop claire, ni trop foncée). La mise au
point est effectuée en ajustant la distance entre la lentille et le capteur. La quantité
de lumière est contrôlée par le diaphragme. L’œil humain a à peu près le même
comportement. Une illustration de la structure de l’oeil est faite par la Figure 1.11.
Figure 1.11: Illustration de la structure de l’œil [Oei ].
La mise au point est assurée par la cornée et le cristallin. L’iris commande l’ouverture.
La partie photo-réceptrice de l’œil est appelée la rétine. L’image est projetée
sur la rétine, qui est située à l’arrière de l’œil. Cette dernière est peuplée de cellules
photosensibles. Lorsqu’une lumière arrive au niveau de l’œil, elle passe en premier
par la cornée. Elle traverse ensuite la chambre antérieure pour atteindre le muscle
de l’iris. Ce muscle contrôle la taille de la pupille, régulant ainsi la quantité de lumière
rentrant. Enfin, la lumière passe à travers le cristallin, traverse le corps vitré
et atteint la rétine. Cette dernière est un tissu neuronal très fin d’une épaisseur
de 0.1 à 0.5 mm tapissant le fond de l’œil. C’est à ce niveau que s’effectue le premier
traitement de l’information. Il consiste à traduire le message lumineux venant
de l’extérieur en signaux nerveux utilisables et interprétables par les neurones des
aires visuelles du cerveau. Comme on peut le voir sur la Figure 1.12, la rétine est
constituée de plusieurs couches de cellules. Les cellules photoréceptrices constituent
la couche la plus profonde de la rétine et sont de deux types : les cônes et les bâ-
tonnets. Leur distribution n’est pas uniforme au niveau de la rétine. En effet, les
cônes se concentrent au centre, dans la fovéa, alors que les bâtonnets sont situés à
29Chapitre 1. Solutions de recherche d’images par le contenu
Figure 1.12: Structure de la rétine [Ret ].
la para fovéa et à la périphérie. Les cônes sont dédiés à la perception d’informations
de moyennes à fortes luminances. Ces deux cellules photoréceptrices ne sont
également pas sensibles à la même information. Les bâtonnets sont uniquement sensibles
à la luminance alors que les cônes à la longueur d’onde. Comme le dit Le
Meur [Le Meur 05a], comparativement aux bâtonnets, les cônes permettent d’avoir
une représentation fine d’une scène observée en conservant l’essentiel de sa résolution
spatiale et temporelle ; l’acuité visuelle est élevée dans la fovéa. Cette meilleure
efficacité est liée à la façon dont l’information est distribuée par les cônes. Contrairement
aux bâtonnets qui distribuent l’information à plusieurs cellules réceptrices,
les cônes sont reliés uniquement à une cellule, en l’occurrence une cellule bipolaire.
Une fois le signal lumineux arrivé au niveau de la rétine, un processus post-rétinien
est mis en place. Les nerfs optiques venant des deux yeux se croisent pour former le
chiasma optique illustré sur la Figure 1.13. Notons que ce phénomène est en partie
responsable de la perception de la profondeur.
En quittant le chiasma optique le traitement de l’information se fait de façon parallèle
au niveau du cerveau. Elle circule à travers deux voies optiques pour atteindre le
cortex visuel. Ce dernier occupe le lobe occipital du cerveau et est chargé de traiter
les informations visuelles.
L’étude du cortex visuel en neurosciences a permis de le découper en une multitudes
de sous-régions fonctionnelles (V1, V2, V3, V4, MT, . . . ), illustrées sur la
Figure 1.14, qui traitent chacune ou collectivement les multiples propriétés des informations
provenant des voies visuelles (formes, couleurs, mouvements, etc.). Selon
Jauzein [Jauzein 10], il existe quatre systèmes qui traitent en parallèle les diverses
caractéristiques d’un objet. L’un détecte le mouvement, un autre la couleur, et les
deux autres la forme :
– La couleur est perçue lorsque les cellules sensibles, présentes dans les colonnes
de l’aire V1 (cortex visuel primaire), envoient des signaux vers l’aire spécialisée
V4 et vers les bandes minces de l’aire V2 qui sont connectées à cette dernière ;
30Chapitre 1. Solutions de recherche d’images par le contenu
Figure 1.13: La distribution des réponses rétiniennes au niveau du cortex [Chi ].
Figure 1.14: Différentes aires visuelles corticales [Air ].
– La détection des formes colorées résulte d’échanges de signaux entre les régions
inter-taches de V1, les régions inter-bandes de V2 et l’aire V4 ;
– La détection du mouvement et des formes en mouvement se fait lorsque les
aires V3 et V5 reçoivent des signaux en provenance directe de la couche 4B de
l’aire V1 ou par l’intermédiaire des bandes larges de V2.
Le processus complexe qui se déroule au niveau du cortex visuel n’est pas complètement
défini. Plusieurs modèles ont été proposés dont celui à deux voies de traitement
des informations issues du cortex visuel primaire [Perreira Da Silva 10a, Boujut 12].
Ce dernier (Figure 1.15) comprend :
– La voie dorsale qui est associée à l’estimation de mouvement et la localisation
31Chapitre 1. Solutions de recherche d’images par le contenu
d’objets. Elle entraîne les fonctions oculomotrices des yeux ;
– La voie ventrale qui gère la perception visuelle. En utilisant les propriétés
visuelles telles que la forme, les couleurs, etc, elle permet la reconnaissance et
l’identification des objets. Elle est également liée au stockage dans la mémoire
à long terme.
Figure 1.15: Traitement des informations provenant du cortex visuel primaire selon la
modélisation de deux voies dorsale et ventrale [Cor ]. La voie dorsale est représentée en
vert, la voie ventrale en violet et le cortex visuel primaire en bleu.
La complexité du SVH est en partie maîtrisée pour les parties rétiniennes et pour le
cortex visuel primaire. À partir d’études neurophysiologiques et d’expérimentations
psychophysiques, de nombreux mécanismes inhérents aux premiers traitements mis
en jeu dans l’analyse visuelle peuvent être reproduits via des modèles mathématiques.
Mais la connaissance des aires corticales supérieures (V2, V3, . . . ) et de leurs
interactions reste encore très faible. Au mieux, est-on capable de leur affecter un type
de tâches sans vraiment pouvoir définir et caractériser précisément les mécanismes
mis en jeux [Le Meur 05a].
Cette brève présentation du SVH a pour but de sensibiliser le lecteur au fait que le
cerveau n’est pas capable de considérer tous les détails. Ce système intrinsèquement
limité, traite une quantité considérable d’informations visuelles en partie grâce à un
mécanisme passif de réduction de la redondance des informations incidentes (champs
récepteurs des cellules rétiniennes et corticales) [Le Meur 05a]. C’est là qu’entre en
jeu le mécanisme de l’attention visuelle qui nous permet de sélectionner des informations
visuelles spatio-temporelles pertinentes du monde visible. Ce mécanisme
nous permet d’utiliser de façon optimisée nos ressources biologiques. Ainsi, seule
une petite partie des informations incidentes est transmise aux aires supérieures de
notre cerveau [Ballard 91]. Un mécanisme actif, est donc nécessaire [Le Meur 05a] :
les mouvements oculaires. Bien que nous n’en ayons pas conscience, ces différents
types de mouvements prennent la forme de mouvements de poursuites, de convergences,
de saccades ou encore de fixations. Nous n’aborderons que les fixations et les
saccades qui sont les deux mouvements oculaires principaux entrant en jeu lorsque
nous essayons de fixer un objet.
32Chapitre 1. Solutions de recherche d’images par le contenu
Les mouvements oculaires de saccades et de fixation
Les définitions que nous donnons de ces mouvements oculaires sont celles de Le
Meur [Le Meur 05a].
Les saccades sont des mouvements oculaires balistiques dont la vitesse est comprise
entre 100 et 700 degrés par seconde. Ce type de mouvement permet de déplacer
l’attention visuelle d’un endroit à un autre (un saut d’un point à un autre) afin
de les inspecter par la partie la plus performante (en termes de résolution spatiale)
de la rétine : la fovéa. Les saccades sont souvent considérées comme un mécanisme
favorisant la sélection des informations visuelles pertinentes de notre champ visuel.
La scrutation de notre monde visuel se fait donc par une série de sauts permettant le
déplacement rapide de nos ressources sensorielles d’un point à un autre. Lorsqu’une
saccade est effectuée en direction d’une cible particulière, la précision de la visée
peut être soit très bonne soit mauvaise ; dans ce dernier cas, une seconde saccade
ajuste le déplacement. Durant ces déplacements, notre pouvoir d’analyse est très
faible signifiant que quasiment aucune information visuelle n’est traitée. Notons
que le passage d’un point à un autre ne se fait pas forcément par le plus court
chemin, c’est à dire la ligne droite. La trajectoire peut en effet être incurvée. Enfin,
les saccades sont séparées par des phases de fixations. Ces dernières se produisent
lorsque l’œil fixe une zone de notre environnement. À première vue, l’œil a donc
une position stationnaire d’où le terme de fixation. Pourtant et paradoxalement, les
fixations sont considérées comme des mouvements oculaires. L’explication est en fait
très simple : lors d’une phase de fixation, l’œil est animé d’un mouvement résiduel.
Ces légers mouvements permettent de décaler la zone examinée par la fovéa afin
que cette dernière soit constamment excitée. Si l’œil était réellement stationnaire,
c’est à dire en vision stabilisée, la perception visuelle disparaîtrait progressivement
en raison du mécanisme inhibiteur de l’attention. Ce dernier consiste à inhiber une
zone inspectée afin d’éviter que notre attention visuelle se porte continuellement sur
cette même zone.
L’attention visuelle
Dans le mécanisme de l’attention visuelle, la notion de sélection est très importante.
Cette dernière peut se faire de manière passive ou active. La première
sélection se fait naturellement grâce au système visuel humain et à sa physiologie.
La deuxième sélection dite active englobe les différentes focalisations. D’ailleurs, on
distingue deux sortes de focalisations :
– La focalisation "ouverte" qui correspond à un déplacement de la fovéa sur le
stimulus par le biais d’un mouvement oculaire ;
– La focalisation "couverte" qui est une faculté à focaliser notre attention sur
une cible (objet ou position) sans déplacer nos yeux.
L’attention visuelle peut également être exogène/endogène [Le Meur 05a, Boujut 12].
L’attention exogène (ou encore ascendante ou bottom-up) représente l’ensemble des
processus automatiques déclenchés par les stimuli externes et captés par notre système
visuel. C’est un mécanisme relativement éphémère piloté par les données de
notre champ visuel et faisant référence à l’attention involontaire [Le Meur 05a]. Les
modélisations computationnelles de la littérature pour ce genre d’attention visuelle
33Chapitre 1. Solutions de recherche d’images par le contenu
essaient de reproduire ce qui se fait au niveau de la rétine et du système visuel humain.
L’attention endogène (également appelée descendante ou top-down), quant à
elle, est volontaire et dépend, par exemple, de nos objectifs.
Beaucoup de modèles informatiques ont vu le jour pour approximer ce mécanisme
d’attention visuelle. On les appelle plus généralement les modèles de saillance
visuelle. Dans un état de l’art, Borji et Itti [Borji 13a] détaillent 65 des modèles de
la littérature et les évaluent selon 13 critères. Nous présenterons leur taxonomie de
classification des modèles de saillance. Nous ne détaillerons par contre pas les diffé-
rentes métriques utilisables pour évaluer un modèle de saillance. Le lecteur intéressé
pourra se référer aux travaux de [Le Meur 05a, Boujut 12, Borji 13b].
1.3.2 Différents modèles de saillance visuelle
Quand on parle des différentes modèles de saillance on se réduit souvent aux
attentions Bottom-up et Top-down. On peut également distinguer dans la littérature
des modèles qui utilisent l’information spatiale seule [Itti 98, Perreira Da Silva 12]
ou combinée avec une information temporelle [Le Meur 05b, Marat 09, Borji 11].
Les modèles peuvent être également classés selon qu’ils soient orientés "espace" ou
"objet" [Borji 13b]. Ceux basés "objet" essaient de segmenter ou de détecter les objets
pour prédire les régions saillantes. En ce qui concerne les modèles basés "espace",
l’idée est de prédire les endroits dans l’image ayant une forte probabilité d’attirer
l’attention.
Quel que soit le modèle de saillance visuelle, il peut être classé dans l’une des 8
catégories que proposent Borji et Itti :
– Les modèles cognitifs qui s’inspirent des concepts cognitifs et essayent de
mimer le fonctionnement du SVH [Le Meur 06, Kootstra 08].
– Les modèles bayésiens dans lesquels les connaissances a priori (par exemple
le contexte de la scène) sont combinées avec les informations sensorielles (par
exemple les caractéristiques de la scène) avec une règle bayésienne [Zhang 09,
Li 10a].
– Les modèles décisionnels qui sous-entendent que les systèmes de perception
évoluent pour produire des décisions sur les états de l’environnement qui sont
optimales au sens d’une décision théorique (par exemple, la probabilité d’erreur
minimum). Le point fondamental est que l’attention visuelle devrait être guidée
par l’optimalité par rapport à la tâche finale [Gu 07, Mahadevan 10].
– Les modèles informationnels basés sur l’hypothèse que le calcul de la
saillance localisée sert à maximiser l’information échantillonnée à partir de son
environnement. Ils sélectionnent les parties les plus informatives de la scène
[Li 10b, Wang 11].
– les modèles graphiques qui traitent des mouvements oculaires comme une
série de temps. Puisqu’il existe des variables cachées qui influencent la génération
des mouvements oculaires, des approches telles que les modèles de Markov
cachés, les réseaux bayésiens dynamiques et les champs aléatoires conditionnels
ont été intégrées [Chikkerur 10, Liu 11b].
– les modèles d’analyse spectrale pour lesquels le modèle de saillance est
34Chapitre 1. Solutions de recherche d’images par le contenu
calculé dans le domaine fréquentiel [Achanta 09, Bian 09].
– les modèles construits à partir de système d’apprentissage [Judd 09,
Kienzle 09].
– les autres modèles qui regroupent toutes les propositions qui ne correspondent
à aucune des 7 précédentes catégories [Ramström 02, Garcia-Diaz 09,
Rosin 09, Goferman 12].
À partir de ces catégories, on note que différents outils ont été testés pour modéliser
l’attention visuelle. Certains modèles sont basés sur des opérations simples telles
que des filtres de couleur, alors que d’autres effectuent un raisonnement complexe
de haut niveau basé sur les réseaux bayésiens, modèles de Markov cachés ou des
SVM [Boujut 12].
Le premier modèle d’attention visuel est le modèle Feature Integration Theory
(FIT) [Treisman 80] proposé par Treisman et Gelade en 1980. Les auteurs avaient
alors sélectionné un ensemble de caractéristiques pertinentes pour l’attention visuelle
humaine. Cinq ans plus tard, Koch et Ullman [Koch 85] proposaient le concept de
carte de saillance qui n’était rien d’autre qu’une carte topographique de l’attention
visuelle. Ils ont alors utilisé la technique "winner-take-all" pour prédire le balayage
du regard. Une zone d’inhibition est alors définie autour du point saillant permettant
ainsi de passer au prochain point saillant de la carte. Ce modèle n’a été complétement
développé qu’en 1998 par Itti [Itti 98]. C’est l’un des modèles qui a souvent servi
de base dans la littérature et qui a été amélioré sous plusieurs aspects et que nous
expliquons brièvement ci-après.
1.3.3 Modèle de saillance de Itti et Koch [Itti 98]
Il s’agit d’un modèle de saillance bio-inspiré. Il est en effet basé sur le fonctionnement
du système visuel humain. Son architecture est illustrée par la Figure
1.16. À partir d’une image, un ensemble de caractéristiques visuelles pré-attentives
sont calculées. Ces dernières sont liées aux couleurs, à l’intensité et aux différentes
orientations. Des cartes de caractérisation sont alors générées à partir de ces caractéristiques
et leur fusion permet d’obtenir la carte de saillance.
Pour générer les différentes caractéristiques visuelles pré-attentives, 3 canaux sont
définis à partir d’une image (R,G,B) [Le Meur 05a] :
– Le canal intensité obtenu grâce à l’équation :
intensite =
R + G + B
3
; (1.24)
– Le canal couleur composé de quatre composantes C1, C2, C3 et C4 issues de la
35Chapitre 1. Solutions de recherche d’images par le contenu
Figure 1.16: Architecture du modèle de saillance de Itti et Koch.
théorie des couleurs antagonistes :
C1 = R −
(G + B)
2
, (1.25)
C2 = G −
(R + B)
2
, (1.26)
C3 = B −
(G + R)
2
, (1.27)
C4 =
(G + R)
2
−
|R − G|
2
− B; (1.28)
– Le canal dédié aux composantes orientées est obtenu à partir d’une pyramide
de Gabor orientée O(θ), où σ indique le niveau de la pyramide et θ ∈
{0˚, 45˚, 90˚, 135˚}.
Une fois les différents canaux définis, une décomposition hiérarchique sur 9 niveaux
via des pyramides gaussiennes est effectuée sur chaque composante. Ces pyramides
36Chapitre 1. Solutions de recherche d’images par le contenu
sont censées représenter une approximation du pavage fréquentiel des cellules visuelles.
Un mécanisme de centre/pourtour permet ensuite d’extraire des différents
niveaux de la pyramide les informations pertinentes contrastant avec leur voisinage.
Les cartes obtenues sont normalisées indépendamment les unes des autres
et permettent de construire une carte de saillance par canal. La carte de saillance
finale provient de la combinaison des différentes cartes. Les différents calculs de
contraste ne sont pas détaillés ici mais le lecteur intéressé pourrait se référer à
[Itti 98, Le Meur 05a]. Un exemple de carte de saillance est donnée sur la Figure
1.17.
(a) Image originale (b) Carte de saillance
Figure 1.17: Exemple de carte de saillance. Cette carte (b) est obtenue avec le logiciel
GBVS (Graph-Based Visual Saliency) [Harel ] qui permet de calculer les cartes obtenues
avec le modèle de Itti.
1.3.4 Évaluation des modèles de saillance visuelle
L’évaluation des modèles de saillance visuelle se fait le plus souvent par rapport à
une vérité-terrain. On compare alors les résultats du modèle aux fixations récupérées
lors d’expériences oculométriques, ou dans le cas d’une saillance visuelle orienté objet
à des segmentations en objets des images.
Il existe plusieurs métriques dans la littérature [Perreira Da Silva 10a, Boujut 12,
Borji 13b, Le Meur 13] mais elles peuvent être classées en trois groupes :
– Les métriques basées valeurs : on peut citer la métrique NSS (Normalized
Scanpath Saliency) qui correspond à la moyenne des valeurs de réponse à
des positions de l’œil humain dans la carte de saillance, normalisée à une
moyenne nulle et un écart-type de 1 d’un modèle. Une valeur de NSS égale
à 1 indique que les positions des yeux des sujets tombent dans une région
dont la saillance prédite est un écart-type au-dessus de la moyenne. Si cette
valeur est supérieure à 1 alors cela signifie que le modèle de saillance indique
une valeur de saillance élevée aux positions fixées par l’humain comparée à
d’autres positions. En revanche, si elle est nulle alors le modèle ne fonctionne
pas mieux qu’une prédiction aléatoire du regard ;
– Les métriques basées positions : la métrique AUC (Area Under Curve) en
est un exemple ;
– Les métriques basées sur la distribution : la divergence de Kullback Leibler
est par exemple une métrique de cette catégorie utilisée dans la littérature.
Elle mesure la dissimilarité entre les distributions des positions réelles de l’œil
et celles qui ont été prédites par le modèle de saillance visuelle.
37Chapitre 1. Solutions de recherche d’images par le contenu
1.4 Quelques travaux intégrant la saillance visuelle
en recherche d’images par le contenu
Dans la littérature, la saillance visuelle est massivement utilisée pour filtrer les
caractéristiques locales [Gao 08, Liu 08]. Par exemple, Gao et al. [Gao 08] proposent
de définir des régions saillantes en croisant la carte de saillance visuelle d’une image
et ses caractéristiques locales. Ils ont intégré un schéma de pondération des régions
saillantes à partir de leur taille et de leur position dans l’image. Dans leur approche,
seules les trois plus grandes régions (taille supérieure à 5% de la taille de l’image)
sont prises en compte. Une approche similaire a été proposée par Liu et al. [Liu 08].
À partir de cartes de saillance normalisées, des régions saillantes sont détectées. Les
auteurs proposent d’utiliser deux informations relatives à la saillance visuelle de ces
régions pour la recherche d’images par le contenu. La première est un histogramme
qui calcule la proportion de points dans chaque région ayant une certaine valeur de
saillance par rapport à toute l’image. La seconde encode l’information spatiale du
focus d’attention visuelle. Elle permet de calculer la proportion de saillance visuelle
dans la région saillante. D’autres utilisations de la saillance sont exploitées pour des
thématiques de recherche d’images par le contenu avec de la sémantique [Wang 10].
Conclusions
Dans ce chapitre, nous avons présenté quelques solutions de la littérature pour
la mise en œuvre d’une tâche de recherche d’images par le contenu. Nous avons
abordé les deux grandes étapes de cette tâche à savoir la caractérisation des images
par un ensemble de descripteurs et ensuite la comparaison des différentes signatures
visuelles. Nous nous sommes focalisés sur les descripteurs de caractéristiques locales
et quelques solutions de la littérature pour la création de signature visuelle. Mais
on peut également considérer le vecteur de caractéristiques locales comme étant une
signature et l’utiliser tel quel pour la recherche des plus proches voisins avec une
méthode d’appariement.
Nous avons également abordé l’utilisation d’informations du SVH telle que la saillance
visuelle. Nous avons alors présenté le fonctionnement du SVH dans les grandes lignes
depuis la réception du signal lumineux par la rétine jusqu’à son traitement par le
cortex visuel primaire. Ceci nous a permis d’introduire les différents modèles de
saillance et notamment un modèle cognitif : celui de Itti et Koch.
Cette revue de littérature nous permet d’introduire nos contributions pour la recherche
d’images par le contenu. Dans le chapitre suivant, nous aborderons une mé-
thode de recherche d’images par le contenu qui inclut des informations de saillance
en se basant sur le modèle de Itti présenté dans cette partie. L’idée est de tirer
profit de l’attention visuelle. Pour ce faire, nous avons d’abord évalué l’impact de la
pondération des vecteurs de descripteurs de caractéristiques locales par la saillance
au cours d’une tâche d’indexation. Nous avons ensuite étudié la saillance visuelle des
différents détecteurs de caractéristiques présentés dans cette partie. Pour finir, nous
avons ajouté des caractéristiques locales à partir d’un modèle d’attention visuel.
38Chapitre 2
Notre approche pour l’indexation
Sommaire
2.1 Bases d’images utilisées . . . . . . . . . . . . . . . . . . . . 40
2.2 Nos choix de descripteurs . . . . . . . . . . . . . . . . . . 42
2.3 Nouvelle méthode de construction du dictionnaire visuel
: Iterative Random visual words Selection (IteRaSel) 42
2.4 Évaluations de IteRaSel . . . . . . . . . . . . . . . . . . . 45
2.4.1 Sélection aléatoire des mots . . . . . . . . . . . . . . . . . 45
2.4.2 Sélection aléatoire des mots visuels couplée à un processus
itératif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.4.3 Stabilisation du processus aléatoire . . . . . . . . . . . . . 48
2.4.4 Évaluation de IteRaSel avec la combinaison des dictionnaires 49
2.4.5 Comparaison avec l’état de l’art . . . . . . . . . . . . . . 50
2.4.6 Discussions autour des résultats . . . . . . . . . . . . . . . 52
2.5 Pondération des vecteurs de descripteurs par la saillance 53
2.6 Évaluation de la saillance de certains détecteurs de
points clés . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
2.6.1 Saillance visuelle des caractéristiques locales . . . . . . . . 55
2.6.2 Discussions autour de ces premiers résultats . . . . . . . . 61
2.7 Étude de l’importance des points clés saillants . . . . . . 62
2.7.1 Impact de la suppression des points clés en fonction de
leur saillance . . . . . . . . . . . . . . . . . . . . . . . . . 62
2.7.2 Ajouts de points saillants . . . . . . . . . . . . . . . . . . 64
2.7.3 Discussions autour des travaux sur la saillance . . . . . . 65
Introduction
Dans ce chapitre consacré à nos premières contributions, nous présenterons nos
travaux sur la recherche d’images par le contenu. Nous avons pris le parti de ne
pas proposer le système d’indexation le plus performant possible mais d’apporter
de nouvelles façons d’indexer les images. Nous proposons, dans un premier temps,
39Chapitre 2. Notre approche pour l’indexation
une nouvelle construction de dictionnaire visuel. Grâce à ce nouvel algorithme, nous
arrivons à des résultats quasi-similaires à ceux de la littérature avec une taille de
dictionnaire très petite (294 pour le descripteur ayant les meilleurs résultats contre
une moyenne de 20 000 dans la littérature). Nous avons essentiellement opté pour
une représentation des images à partir d’un "Sac de mots visuels".
Nous avons, d’abord, comparé les résultats de cette nouvelle méthode de construction
du vocabulaire visuel aux résultats d’un K-means. Ensuite nous avons choisi
d’intégrer la saillance visuelle à nos travaux. Ceci s’est fait de deux façons :
– Pondération du vecteur de descripteurs par la saillance visuelle de la caracté-
ristique locale qu’il décrit, avant l’étape de BoVW ;
– Étudier la saillance des points clés détectés et l’importance de ces points en
fonction de leur saillance pour la tâche de reconnaissance d’images.
2.1 Bases d’images utilisées
Dans la littérature il existe plusieurs bases d’images pour évaluer un système
de reconnaissance d’images par le contenu. Elles sont de plus en plus grandes et
diversifiées [Nistér 06, Everingham 07, Huiskes 08, Huiskes 10, Everingham 12].
Nous avons opté pour la base University of Kentucky Benchmark proposée
par Nistér et Stewénius [Nistér 06] pour effectuer nos tests. Cette base sera notée
"UKB" dans la suite pour simplifier la lecture. Malgré sa petite taille, 10 200 images
comparées au million d’images de MIRFlickr 1M [Huiskes 10] par exemple, c’est une
base qui présente trois principaux avantages :
– Les images sont regroupées par 4 présentant le même objet avec des changements
différents (opérations géométriques, modification du point de vue, des
conditions d’éclairage, . . . ). Un exemple est donné par les images de la Figure
2.1 ;
– C’est une base facile d’accès et beaucoup de résultats existent pour pouvoir
faire une comparaison efficace. Dans notre cas, nous prendrons comme réfé-
rence les résultats obtenus par Jégou et al. [Jégou 10b, Jégou 12] ;
– Le calcul de score sur UKB est simple ; il suffit de compter le nombre d’images
ressemblantes (incluant la requête) retrouvées parmi les 4 premières. Le score
moyen sur UKB est donc donné sur 4. Par exemple, un score de 3.5 indique
que 3.5 images en moyenne sont retrouvées sur les 4 identiques existantes.
Nous avons également utilisé la base Pascal VOC 2012 [Everingham 12] essentiellement
pour la construction du dictionnaire visuel afin d’avoir une variabilité
importante des mots. En effet, c’est une base qui contient 17 125 images de scènes
réelles appartenant à l’une des 20 classes d’objets (personne, oiseau, avion, voiture,
chaise entre autres). Les images de la Figure 2.2 illustrent bien la variabilité de cette
base. Chaque classe inclut des éléments très différents. La classe "Oiseau" contient
différents animaux, des oiseaux en plein vol ou posés. C’est une base qui est traditionnellement
utilisée en classification du fait de sa complexité. En effet, deux classes
peuvent cohabiter sur une même image comme c’est le cas des images 2.2(e), 2.2(h),
2.2(i). Sur l’image 2.2(e) non seulement la voiture est tronquée mais en plus on y
40Chapitre 2. Notre approche pour l’indexation
Figure 2.1: Exemple de 4 images similaires de la base UKB.
(a) (b) (c)
(d) (e) (f)
(g) (h) (i)
Figure 2.2: Quelques images de la base Pascal VOC2012. Les images (a)-(c) illustrent la
classe "Oiseau", (d)-(f) la classe "Voiture" et (g)-(i) la classe "Personne".
voit un vélo. Sur l’image 2.2(h) on aperçoit un pilote dans l’avion et sur l’image
2.2(i) la classe "Personne" cohabite avec la classe "Sofa".
41Chapitre 2. Notre approche pour l’indexation
2.2 Nos choix de descripteurs
Nous avons choisi de juger l’efficacité et la précision de cinq descripteurs de
caractéristiques locales dans notre solution de recherche d’images par le contenu. Il
s’agit de :
– CM (Colour Moments) : 24 dimensions ;
– CMI (Colour Moment Invariants) : 30 dimensions ;
– SIFT (Scale-Invariant Feature Transform) : 128 dimensions ;
– SURF (Speeded Up Robust Feature) : 64 dimensions ;
– Opponent-SIFT que nous noterons OpSIFT pour la présentation des résultats :
384 dimensions.
Exceptés les descripteurs SURF, tous les autres ont été calculés avec le logiciel ColorDescriptor
proposé par van de Sande et al. [van de Sande 10].
Nous avons choisi comme détecteur, celui de Harris-Laplace qui offre de très bonnes
performances notamment dans les travaux de Zhang et al. [Zhang 07] dans le cadre
d’une tâche de classification. Pour tous les descripteurs sauf pour SURF, la configuration
de notre détecteur est la suivante :
– k=0.06 ;
– le seuil de la fonction de Harris est égal à 10−9
;
– le seuil pour le laplacien est égal 0.03.
Les descripteurs SURF ont été calculés avec Opencv avec un seuil du Hessian fixé à
300 puisqu’ils intègrent leur propre schéma de détection des caractéristiques locales.
Tous les détecteurs sont appliqués sur les images en niveaux de gris. Les descripteurs
SIFT et SURF n’exploitent que l’information en niveaux de gris ce qui n’est pas le
cas pour CM, CMI et OpponentSIFT.
2.3 Nouvelle méthode de construction du dictionnaire
visuel : Iterative Random visual words
Selection (IteRaSel)
Comme nous l’avons mentionné dans le chapitre précédent, la technique "Sac de
mots visuels" est l’une des méthodes les plus utilisées pour la création de la signature
d’une image. En effet, c’est une solution facile à mettre en œuvre et qui offre
des résultats satisfaisants. Son inconvénient majeur est de nécessiter d’un dictionnaire
de grande taille. La méthode traditionnelle de construction de ce dictionnaire
est l’algorithme K-means. L’utilisation de cet algorithme doit prendre en compte
la dimensionnalité des descripteurs. En effet, son efficacité tend à baisser avec une
dimensionnalité élévée, produisant même des résultats proches de l’aléatoire comme
l’indiquent Parsons et al. [Parsons 04]. Nous proposons alors une construction du
dictionnaire qui n’est pas sensible à ces problèmes de dimensionnalité. Elle est basée
sur une sélection aléatoire des mots. Nous l’avons nommé Iterative Random visual
words Selection (IteRaSel).
Deux solutions s’offrent à nous pour construire notre vocabulaire visuel à partir
d’une sélection aléatoire des mots :
42Chapitre 2. Notre approche pour l’indexation
– Choisir de façon aléatoire un certain nombre de descripteurs et les considérer
comme les mots visuels ;
– Créer un vocabulaire visuel synthétique en prenant en compte la dimension
des descripteurs.
Nous avons choisi la première solution pour la sélection des mots visuels de
façon aléatoire. Une fois les mots choisis, seuls ceux ayant un gain d’information
intéressant appartiendront au dictionnaire visuel final. Dans notre cas, nous avons
choisi un critère d’information en analogie avec le schéma de pondération tf-idf. Le
gain d’information du mot w, noté IGw, est donné par :
IGw =
nwD
nD
log N
nw | {z }
tf−idf
+
P
SalwD
nwD | {z }
Saillance visuelle
, (2.1)
avec nwD le nombre d’occurrences du mot w dans l’ensemble des descripteurs de
points clés de toute la base d’images ; cet ensemble de descripteurs de points clés
est noté D, nD le nombre total de points clés de la base, nw le nombre d’images
contenant le mot w dans la base, N le nombre d’images dans la base et SalwD le
score de saillance de tous les points clés de la base assignés au mot w.
On reconnait dans l’expression de IGw, le facteur de pondération tf-idf (équation
(1.14)) dans la première partie de la somme. Pour l’estimation de la saillance visuelle,
nous avons choisi d’utiliser le modèle d’attention visuelle de Itti. Nos cartes
de saillance ont été calculées avec le logiciel GBVS (Graph-Based Visual Saliency)
[Harel ]. Les valeurs de saillance sont comprises entre 0 et 1 ; 0 pour une caractéristique
locale non saillante et 1 pour le maximum de saillance. Cela correspond à un
pixel en blanc sur la carte de saillance illustrée sur la Figure 2.3.
(a) Image originale (b) Carte de saillance
Figure 2.3: Illustration d’une carte de saillance.
L’algorithme 2 décrit notre méthode de construction de vocabulaire visuel.
L’étape de tri mentionnée dans notre algorithme permet de supprimer les mots visuels
ayant très peu de gain d’information. Nous avons défini un seuil α permettant
de faire cette suppression. Il a été fixé à 10% après de nombreux tests. Si certains
mots visuels ont un gain d’information nul (ce qui est fort probable puisque les
mots sont choisis dans une base différente de celle de tests ; dans notre cas Pascal
VOC2012 pour les mots et UKB pour les test), alors à la première itération ils sont
supprimés sans prendre en compte α. Nous avons également supprimé les mots visuels
ayant un gain d’information trop important à la première itération. Un seuil
a été fixé par rapport à la taille de la base. Ceci permet d’éliminer les informations
43Chapitre 2. Notre approche pour l’indexation
Algorithme 2 : Construction du vocabulaire visuel avec IteRaSel
Entrées : D, K la taille souhaitée du dictionnaire visuel
Sorties : W le vocabulaire visuel final
Initialisation de W en choisissant de façon aléatoire un ensemble de mots
visuels;
répéter
Affecter chaque point clé de l’ensemble D au mot visuel dont il est le plus
proche par rapport à la distance euclidienne;
Calculer le gain d’information IGw de chaque mot w à l’aide de l’équation
(2.1);
Trier et supprimer des mots en fonction de leur valeur de gain
d’information;
jusqu’à Taille de W 3 donne des résultats similaires mais
avec un temps de construction du dictionnaire plus important. Les résultats des différentes
évaluations sont également donnés dans la Section suivante.
Une fois le dictionnaire visuel obtenu, nous l’avons utilisé pour créer les signatures
visuelles des images à l’aide d’un "Sac de mots visuels". Si la distance entre les
vecteurs de descripteurs et les mots visuels a été évaluée à l’aide d’une distance
euclidienne, nous avons estimé la similarité des signatures visuelles avec une distance
χ
2
.
44Chapitre 2. Notre approche pour l’indexation
2.4 Évaluations de IteRaSel
Tous les résultats que nous présenterons ici concernent la base UKB. Les mots ont
été construits à partir de Pascal VOC2012. Pour faciliter la lecture nous proposons
les facilités de notation suivantes :
– BoVW correspond à une signature visuelle de type "Sac de mots visuels" obtenue
avec un dictionnaire issu d’un K-means;
– IteRaSel correspond à une signature visuelle de type "Sac de mots visuels"
obtenue avec notre algorithme de construction du vocabulaire visuel.
2.4.1 Sélection aléatoire des mots
Dans un premier temps, nous avons comparé les résultats d’un dictionnaire obtenu
simplement avec une sélection aléatoire des mots à ceux obtenus avec un algorithme
K-Means. Les signatures visuelles utilisées sont des "Sacs de mots visuels".
Les résultats sont illustrés sur la Figure 2.4. Seul le comportement de trois descripteurs
est illustré, les deux autres ont le même comportement.
Figure 2.4: Sélection aléatoire des mots visuels vs K-means. Sur ce graphique CMI correspond
aux résultats obtenus avec un dictionnaire obtenu avec K-Means et randCMI à ceux
obtenus avec une sélection aléatoire des mots dans l’ensemble des descripteurs des images
de la base de construction des mots. Il en est de même pour les autres descripteurs.
On remarque globalement, que BoVW obtient de meilleurs résultats pour les dictionnaires
de petites tailles. Pour des tailles de dictionnaires plus importantes, une
simple sélection aléatoire des mots permet d’avoir des scores équivalents. Il s’agit
45Chapitre 2. Notre approche pour l’indexation
là d’un résultat très intéressant puisque la création d’un dictionnaire à partir d’un
processus aléatoire prend beaucoup moins de temps.
2.4.2 Sélection aléatoire des mots visuels couplée à un processus
itératif
Si on se réfère à la Figure 2.4, le descripteur CMI est celui qui atteint les meilleurs
résultats, tant avec un dictionnaire issu de K-Means qu’avec une sélection aléatoire
des mots visuels. Nous nous focaliserons donc sur les résultats avec ce descripteur
pour présenter l’impact du processus itératif sur la tâche de reconnaissance d’images
sur UKB.
Comme nous l’avons conclu précédemment de la Figure 2.4, la sélection aléatoire
des mots obtient des résultats similaires à K-Means pour des dictionnaires de grande
taille. Nous avons alors étudié le comportement du vocabulaire de mots visuels aléatoire
en intégrant le processus itératif de construction du dictionnaire à l’aide de
l’Algorithme 2.
Figure 2.5: Construction du dictionnaire final de façon itérative en partant de plusieurs
dictionnaires visuels de 2048 mots choisis de façon aléatoire. Entre 150 et 250 mots visuels
les résultats sont constamment compris entre 3.05 et 3.15.
La Figure 2.5 présente les résultats de plusieurs dictionnaires visuels construits de
façon itérative à partir de 2048 mots visuels. Il faut noter que la taille des dictionnaires
finaux n’est pas toujours identique en utilisant à chaque fois 2048 mots. Elle
dépend du nombre de mots qui auront été supprimés pendant le processus. On peut
mettre en évidence deux constatations :
1. Les résultats sont très stables. En effet, à partir d’un vocabulaire aléatoire,
pour un nombre final donné de mots, le score moyen se situe dans une fenêtre
46Chapitre 2. Notre approche pour l’indexation
très étroite. Par exemple, entre 150 et 250 mots, la valeur du score varie de
3.05 et 3.15 environ en sachant que le score maximal est de 4 ;
2. On atteint un score moyen élevé quelle que soit la taille des différents dictionnaires.
Dans les précédents résultats précédents (Figure 2.4), ni BoVW ni la
sélection aléatoire de vocabulaire n’a donné un score supérieur à 3. Le fait de
procéder à une construction itérative permet donc d’améliorer l’indexation.
Nous avons également étudié l’impact de la taille de l’ensemble aléatoire de mots
visuels de départ. Pour cela nous avons choisi de tester des dictionnaires initiaux de
taille appartenant à l’ensemble {1024, 2048, 4096, 8192, 16 384, 32 768, 65 536}.
Les résultats sont illustrés par la Figure 2.6.
Figure 2.6: Étude de l’impact de la taille du dictionnaire visuel aléatoire initial.
Pour obtenir ces résultats, nous avons créé 10 dictionnaires visuels aléatoires pour
chaque taille. Pour chaque taille, nous avons lancé l’Algorithme 2 10 fois, le score
présenté est donc la moyenne des 10 scores moyens (un score sur 4 étant obtenu pour
chacune des 10 200 images) pour chaque taille de dictionnaire visuel initial. Pour
chacun de ces dictionnaires, nous avons généré des vocabulaires finaux de tailles
comprises entre 50 et 500, par pas de 50. Les scores de chacun de ces dictionnaires
visuels finaux sont donc des moyennes. On note un réel impact du nombre de mots
initial sur l’ensemble des résultats. D’un côté, commencer la construction du dictionnaire
avec 1024 mots n’est pas suffisant. D’autre part, utiliser un dictionnaire initial
de plus de 4096 mots n’a aucune conséquence effective. Nous avons alors choisi ce
seuil comme étant la taille maximale de notre dictionnaire initial.
Comme nous l’avons évoqué dans la Section 2.3, nous avons opté pour une combinaison
des vocabulaires visuels pour pallier l’instabilité de notre algorithme que
pourrait induire le tirage aléatoire.
47Chapitre 2. Notre approche pour l’indexation
2.4.3 Stabilisation du processus aléatoire
Puisque l’algorithme de construction de notre vocabulaire de mots visuels se base
sur un processus aléatoire, il faut plusieurs tirages pour assurer une certaine stabilité
du dictionnaire final.
En plus du fait de générer plusieurs dictionnaires visuels initiaux, nous avons décidé
de combiner les dictionnaires résultant de chaque tirage. Ce nouveau dictionnaire
sert d’entrée à l’algorithme pour construire un nouveau dictionnaire qui sera utilisé
pour calculer les signatures visuelles des images. Nous avons testé l’impact du
nombre de dictionnaires combinés que nous avons nommé β dans la Section 2.3 en le
faisant varier de 2 à 10. Comme précédemment, les résultats présentés ici ne concerne
que le descripteur CMI.
Figure 2.7: Score moyen obtenu après la combinaison des dictionnaires dans plusieurs
configurations : β = {2, . . . , 9, 10}. Les dictionnaires ont été générés à partir de 1024, 2048
et 4196 mots visuels choisis de façon aléatoire.
La Figure 2.7 illustre l’intérêt de grouper les dictionnaires pour en déduire un unique.
On y voit que quelle que soit la taille du vocabulaire de mots visuels initial, les scores
augmentent avec β, notamment de β = 2 à β = 3. Au delà de 3, les résultats évoluent
très peu ce qui nous permet de conclure que β = 3 est un très bon compromis pour
UKB. De plus, ce compromis permet de gagner sensiblement en temps de construction
du dictionnaire par rapport à β = 8 par exemple.
Nous avons testé d’autres techniques de combinaison des dictionnaires notamment :
combiner les vocabulaires donnant les meilleurs scores moyens ou encore combiner
plusieurs vocabulaires déjà issus d’un processus de combinaison. Aucune de ces
méthodes n’a donné des résultats très concluants. Nous avons donc retenu cette
technique de combinaison pour la stabilisation de l’algorithme d’autant plus qu’elle
48Chapitre 2. Notre approche pour l’indexation
est facilement reproductible.
Une fois l’algorithme définitif établi, nous avons étudié plus précisément le comportement
de chacun des descripteurs que nous avons choisis.
2.4.4 Évaluation de IteRaSel avec la combinaison des dictionnaires
Les dictionnaires visuels utilisés pour tous les résultats présentés ici ont été obtenus
de la façon suivante :
1. Sélection d’un ensemble de 4096 mots de façon aléatoire dans l’ensemble D des
descripteurs des images de la base Pascal VOC2012 ;
2. Construction d’un vocabulaire visuel à partir de l’Algorithme 2 ;
3. Les étapes 1 et 2 sont répétées 2 fois conduisant ainsi à 3 vocabulaires visuels ;
4. Les trois vocabulaires visuels sont utilisés pour créer un dictionnaire final ;
Une fois le vocabulaire visuel final obtenu, les "Sacs de mots visuels" des images de
UKB sont construits. Ces signatures visuelles sont comparées avec une distance χ
2
.
Les résultats obtenus avec les descripteurs que nous avons choisis sont donnés dans
le Tableau 2.1.
Tableau 2.1: Scores moyens sur UKB. K-Means et IteRaSel correspondent à l’algorithme
utilisé pour construire le dictionnaire visuel.
Descripteurs K-Means IteRaSel %(IteRaSel/K-Means)
CMI 2.95 (K=2048) 3.22 (K=294) +7.4%
CM 2.62 (K=2048) 2.81 (K=265) +7%
SURF 2.69 (K=2048) 2.75 (K=253) +2.75%
OpSIFT 2.30 (K=2048) 2.46 (K=159) +6.9%
SIFT 2.19 (K=2048) 2.30 (K=187) +6.5%
Quel que soit le descripteur, les résultats obtenus avec notre dictionnaire sont meilleurs
comparés à ceux obtenus avec K-Means bien que K soit plus petit dans le cas de
IteRaSel. Pour tous les descripteurs sauf SURF, nous obtenons une amélioration
des résultats d’environ 7%. Pour les descripteurs SURF, l’amélioration est de près
de 3%. Ceci démontre que notre méthode de sélection itérative des mots visuels
est meilleure. Sans aucune connaissance a priori des descripteurs (dimensionnalité
notamment), on améliore les résultats de K-means. Ces résultats sont d’autant plus
intéressants que les descripteurs qui obtiennent les meilleurs scores moyens sont de
petite dimensionnalité : 24 pour CMI (3.22) et 30 pour CM 1
(2.81).
Nous avons focalisé la suite de nos travaux sur le descripteur CMI qui a l’avantage
d’offrir des bons résultats pour une très petite taille comparé à SIFT ou ses
extensions couleur. La Figure 2.8 présente les résultats de l’étude de l’impact de la
1. Les 3 moments d’ordre 0 sont inclus.
49Chapitre 2. Notre approche pour l’indexation
Figure 2.8: Score moyen obtenu avec des dictionnaires finaux de plusieurs tailles générés à
partir d’un dictionnaire de taille 4096. La courbe en rouge correspond à une tendance de
l’ensemble des nuages de points.
taille du dictionnaire final comprise entre 50 et 500 en utilisant un vocabulaire visuel
initial composée de 4096 mots. La première conclusion en l’analysant est qu’on
atteint de très bons résultats avec très peu de mots visuels : entre 250 et 300. On remarque
également qu’on obtient un score moyen de 3 pour des dictionnaires de très
petites tailles : entre 50 et 100. Ce résultat est très encourageant et très intéressant
puisqu’il est bien supérieur à ceux qu’on obtient avec un dictionnaire de taille 2048
construit à partir d’un K-means (cf. Figure 2.4).
Nous avons ensuite comparé nos résultats à certains obtenus dans la littérature.
Nos comparaisons se feront essentiellement avec les signatures visuelles VLAD et
FV que nous avons présentées dans le chapitre précédent.
2.4.5 Comparaison avec l’état de l’art
Comme nous l’avons annoncé précédemment, nous ne présenterons que les résultats
obtenus avec le descripteur CMI qui est celui qui obtient les meilleurs résultats
dans nos expérimentations. On pourrait nous reprocher de ne pas nous attarder
sur le descripteur SIFT largement utilisés dans la littérature, mais ils le sont à
partir d’un vocabulaire de taille beaucoup plus importante que celle que nous visons
[Jégou 10b, Jégou 12] dans une approche BoVW. Les meilleurs résultats obtenus
avec les SIFT proviennent de signatures visuelles différentes : vocabulary trees
[Nistér 06], VLAD et FV [Jégou 10b, Jégou 12]. En effet, ces techniques de construction
de signatures visuelles conservent beaucoup plus d’informations qu’un simple
comptage des occurrences d’un pattern visuel.
Les résultats que nous allons présenter en ce qui concerne IteRaSel n’incluent au-
50Chapitre 2. Notre approche pour l’indexation
cune normalisation des histogrammes de fréquence des mots visuels. En effet, lors
de la normalisation L2 de nos histogrammes, nous avons constaté une baisse de nos
résultats de 3.22 à 3.07 malgré le fait qu’elle soit souvent utilisée dans la littérature
[Jégou 10b, Jégou 12]. Nous aborderons dans la dernière partie, nos différents tests
de normalisation et leurs résultats.
Nos résultats sans aucune normalisation
Les scores présentés dans le Tableau 2.2 sont les meilleurs obtenus dans chacun
des articles cités pour la méthode de création de signature visuelle. Le descripteur
utilisé dans ces articles de la littérature est SIFT.
Tableau 2.2: Comparaison de notre meilleur score moyen avec quelques uns de la littérature.
FV correspond à la signature visuel "Vecteur de Fisher".
Signature visuelle Meilleur score
FV[Jégou 12] (SIFT K=256) 3.47
IteRaSel (CMI K=294) 3.22
VLAD [Jégou 10b] (SIFT K=64) 3.17
BoVW (CMI K=2048) 2.95
BoVW [Jégou 12] (SIFT K=20 000) 2.87
Les dictionnaires obtenus avec IteRaSel sont de tailles différentes pour tous les descripteurs.
En effet, le nombre souhaité était de 256 mais avec le processus itératif
et la suppression des mots, ce nombre optimum n’est pas toujours atteint. Si à une
itération i on a une taille K
′
i > 256 et qu’à i + 1, K
′
i+1 < 256 alors on conservera le
dictionnaire obtenu à l’itération i.
En analysant le Tableau 2.2, on remarque que toutes les autres signatures visuelles
obtiennent de meilleurs résultats comparées à BoVW malgré la taille de leur dictionnaire.
La première conclusion est que les résultats d’une méthode utilisant la
technique "Sac de mots visuels" (compter l’occurrence des mots visuels) dépendent
énormément du vocabulaire visuel donc de sa construction. Certes, les VLAD ont
été construits avec un dictionnaire visuel de très petite taille (64 mots) comparé
au nôtre (294 mots) mais nos premiers résultats sont très encourageants. En effet,
VLAD intègre plus d’informations que la signature "Sac de mots visuels".
Évaluation de l’impact de la normalisation sur nos résultats
Soit nbKP le nombre de points clés dans une image, nous avons testé des normalisations
définies de la façon suivante :
norm = (nbKP )
p
, p ∈ {0, 0.1, 0.2, . . . , 0.9, 1}. (2.2)
Notons que si p=1, il s’agit d’une normalisation L1 et si p=0, aucune normalisation
n’est effectuée.
Le facteur de normalisation a un grand impact sur les résultats comme le démontre
51Chapitre 2. Notre approche pour l’indexation
Figure 2.9: Impact de la normalisation sur le score moyen.
la Figure 2.9. On y voit que la valeur de p influence le score moyen final. Pour p=0, le
cas dans lequel nous nous sommes placés précédemment pour comparer nos travaux
à la littérature, on a l’un des plus bas scores. Pour toutes les distances évaluées,
entre p=0 et 1, le score évolue atteignant son maximum dans l’intervalle [0.5, 1].
L’impact de la normalisation peut paraître infirme mais l’échelle étant de 4 sur
UKB, le gain en reconnaissance est intéressant. Dans le cas de la distance χ
2 que
nous avons utilisée pour la comparaison de nos signatures visuelles, entre le meilleur
score moyen (p=0.6) et le cas p=0, on note une amélioration des résultats de 3.5%.
À partir de cette étude, nous avons donc choisi notre score moyen de référence à
p=0.5 : 3.35. Comme on peut également le voir sur cette Figure 2.9, le choix de la
distance a un réel impact. Entre la distance L2 et la distance χ
2
, le gain est d’environ
17.6% quel que soit le facteur de normalisation.
2.4.6 Discussions autour des résultats
Les résultats présentés dans toute la Section 2.4 montrent que l’approche de
construction de dictionnaire que nous proposons permet d’améliorer les résultats
obtenus avec un BoVW et ceci quel que soit le descripteur.
Notre construction de vocabulaire visuel est très simple et pourtant les résultats
obtenus sont proches des meilleurs de la littérature : 3.35 si on normalise nos histogrammes
avec 294 mots et 3.47 avec FV pour un dictionnaire de 256 mots visuels. Ce
taux de classification moyen est d’autant plus intéressant que la signature visuelle
BoVW prend en compte très peu d’informations. Si le vocabulaire visuel est de taille
K, la représentation BoVW contiendra K valeurs alors qu’un FV contient K*D (D
étant la dimension du descripteurs) valeurs. La stabilité des résultats malgré le tirage
aléatoire du début prouve leur répétabilité. Les autres intérêts de la méthode
proposée concernent son indépendance de la dimensionnalité du descripteur ainsi
que sa prise en compte de la variabilité de la base de tests. On peut déduire de nos
différentes expérimentations que la sélection aléatoire des mots visuels d’une base
d’images hétérogène peut donner d’aussi bons, voire de meilleurs résultats, qu’un
K-Means.
52Chapitre 2. Notre approche pour l’indexation
Nous ne l’avons pas abordé, mais nous avons testé le choix des mots à partir de la
base UKB. Les différents scores moyens sont un peu plus bas (3.03) pour CMI ce
qui indique que les mots doivent décrire une variabilité intéressante. L’hétérogénéité
de la base d’images de sélection des mots est donc très importante.
Une dernière conclusion à nos travaux concerne le descripteur CMI. C’est un descripteur
qui n’est pas très plébiscité dans la littérature par rapport à SIFT qui cependant
sur UKB, dans nos expérimentations, se révèle comme ayant les plus hauts
scores de reconnaissance. Ceci pourrait être lié aux contenus des images de UKB.
Les couleurs et leurs invariances suffiraient peut-être à représenter les différents objets/scènes.
Notons quand même que dans la littérature, lorsque le descripteur SIFT
est utilisé sur UKB, les meilleurs résultats sont obtenus avec VLAD ou FV. Cela
voudrait peut-être dire que les 128 dimensions de SIFT encodent des informations
de manière beaucoup plus fine et qu’il n’y a donc aucun intérêt à les représenter
par un histogramme. Les différentes réductions de dimensionnalité qui sont faites
pour passer de 128 à 64 [Jégou 10b, Jégou 12] et qui permettent d’avoir de meilleurs
résultats sont aussi une piste de réflexion sur la nécessité des descripteurs de dimensions
de plus en plus grandes.
Dans la suite de ces travaux sur l’indexation, nous intègrerons l’apport du SVH en
étudiant l’impact de la saillance visuelle dans nos expérimentations. Nous avons travaillé
uniquement avec le descripteur CMI. Puisque la saillance visuelle n’est pas une
information qui modifie la nature du descripteur de caractéristique locale, a priori,
si les résultats s’améliorent, ils devraient avoir le même comportement avec un autre
descripteur.
La première façon d’utiliser la saillance visuelle, que nous avons testée, est la pondération
des vecteurs de descripteurs par la valeur de la saillance visuelle de chaque
caractéristique locale. Nous avons utilisé le modèle de saillance visuel proposé par Itti
et al. [Itti 98] qui est le même que celui utilisé pour la construction du vocabulaire
visuel dans l’algorithme IteRaSel.
2.5 Pondération des vecteurs de descripteurs par
la saillance
Nous avons pondéré chaque vecteur de descripteurs par la saillance de la caractéristique
locale qu’il décrit avant de construire les sacs de mots.
D’un point de vue score moyen, nous n’avons observé aucun changement des résultats
obtenus sur UKB. On obtient le même score moyen avec ou sans la pondération
par la saillance. La première conclusion de ce résultat est que la pondération des
vecteurs de descripteurs par la saillance des caractéristiques qu’ils décrivent n’est
pas une façon efficace d’utiliser cette information du système visuel humain. Cette
conclusion n’est valable que sur la base UKB et pour le descripteur CMI. Nous pensons
néanmoins que cela devrait être similaire quel que soit le descripteur puisque
le facteur de pondération est le même.
Nous avons alors essayé d’étudier l’apport de la saillance malgré le score moyen inchangé.
Nous avons remarqué que les scores moyens ne sont pas les mêmes pour
chaque image. Il y a donc bien un impact en utilisant ce système de pondération.
53Chapitre 2. Notre approche pour l’indexation
Pour en savoir plus, nous avons regardé de plus près le rang des 4 images ressemblantes
après la recherche des plus proches voisins. En effet, utilisant l’algorithme
des K (K=4 pour UKB) plus proches voisins, toutes les 10 200 images de la base
sont ordonnées en fonction de leur distance à la requête. Chacune d’elle se voit donc
affecter un rang allant de 0 à 10 199.
Figure 2.10: Étude du rang des images ressemblantes en pondérant les vecteurs de descripteurs
par la saillance du point décrit. La notation AS signifie "Avec ondération par la
saillance" et SS "Sans pondération".
La Figure 2.10 illustre l’étude de la somme des 4 rangs. Nous avons fait cette étude
pour trois valeurs différentes de p : 0, 0.5 et 1 définissant le facteur de normalisation
des histogrammes donné par l’équation (2.2). En analysant ce graphique, on
confirme la conclusion précédente. La pondération des vecteurs de caractéristiques
par la saillance des points clés n’affecte pas énormément le résultat. En effet, pour
les 3 normalisations étudiées, dans au moins 72% des cas les images retrouvées sont
les mêmes. En effet :
– Quand la somme des rangs est la même (le cas AS=SS), les 4 premières images
retrouvées sont les bonnes ;
– Quand la somme des rangs dans une configuration (AS ou SS) est inférieure à
celle de l’autre configuration, alors au moins une image n’est pas parmi les 4
premières.
La pondération par la saillance entraîne certes de moins bons résultats mais ceci
dans de très faibles proportions (4%) maximum. Ces derniers sont compensés par
les cas dans lesquels la pondération par la saillance améliore les rangs des 4 images
ressemblantes.
54Chapitre 2. Notre approche pour l’indexation
On peut conclure de cette étude des rangs des images que la pondération des vecteurs
de caractéristiques par la saillance ne change en rien les résultats d’un point
de vue score moyen des 4 images similaires. Elle permet néanmoins d’améliorer leurs
rangs parmi les 10 200 images de la base.
Puisque la pondération par la saillance des vecteurs de caractéristiques n’a aucun
effet sur le score moyen, nous avons décidé d’étudier de plus près la saillance des
détecteurs des points clés. En effet, les résultats précédents sous-entendent une hypothèse
: les points clés trouvés avec le détecteur de Harris-Laplace ont une saillance
équivalente, ce qui reviendrait à appliquer quasiment le même facteur de normalisation
à tous les vecteurs de descripteurs. Pour vérifier cette hypothèse, nous avons
évalué la saillance des points clés détectés par quatre détecteurs.
2.6 Évaluation de la saillance de certains détecteurs
de points clés
Nous avons effectué cette étude sur quatre bases d’images dont les deux bases
que nous avons présentées dans la Section 2.1. Les deux autres bases sont des bases
conçues pour l’étude de la saillance visuelle :
– La base d’images de Le Meur et Baccino [Le Meur 06] qui contient 27 images ;
notée LeMeur ;
– La base d’images de Kootstra et al. [Kootstra 11] qui contient 101 images ;
notée Kootstra.
Les détecteurs évalués sont les suivants :
– Harris ;
– Harris-Laplace ;
– DoG ;
– FAST ;
Les paramètres utilisés sont les mêmes que ceux utilisés pour la Figure 1.4 dans le
chapitre précédent (1.1.2).
2.6.1 Saillance visuelle des caractéristiques locales
Pour évaluer la saillance des points, nous avons défini un seuil à partir duquel
on peut dire qu’un point est saillant ou non. Nos valeurs de saillance visuelles étant
comprises entre 0 et 1, un seuil intuitif pourrait donc être 0.5. Nous avons préféré dé-
terminé un seuil expérimental qui permet de définir une région saillante intéressante
(reconnaissance de l’objet, de la scène). Nous avons testé plusieurs valeurs comprises
entre 0.3 et 0.6. Certains sont illustrés sur la Figure 2.11. Nous avons choisi de le
fixer à 0.4. En effet, cette valeur permet de pouvoir deviner plus facilement sur une
grande partie des images l’objet (la scène) comparé à 0.5 par exemple. À l’inverse
0.3 est un peu trop bas. Un pixel sera donc considéré comme saillant si son intensité
dans la carte de saillance est supérieure ou égale à 0.4.
Le fait d’inclure des bases d’images traditionnellement utilisées pour l’étude de la
saillance visuelle nous permet de vérifier l’indépendance de nos résultats à la nature
de la base.
55Chapitre 2. Notre approche pour l’indexation
(a) Image originale
(b) t=0.3 (c) t=0.4 (d) t=0.5
Figure 2.11: Illustration du test de quelques seuils de saillance sur l’image.
Nous avons choisi d’utiliser des graphiques de type "Boîtes à moustaches" pour illustrer
cette étude. Sur ces graphiques, la ligne horizontale correspond à la valeur
médiane de l’ensemble. Les valeurs représentées en rouge sont les "outliers". Leurs
valeurs ne sont pas comprises dans l’intervalle :
[(q1 − w(q3 − q1)),(q3 + w(q3 − q1))] , (2.3)
avec q1 et q3 représentant respectivement les premier et troisième quartiles.
Nous avons choisi w égal à 1.5, cette valeur correspondant à peu près à ±2.7σ et
prendrait en compte 99.3% des données si elles suivent une loi normale. 2
Avant d’étudier la répartition de la saillance des points clés détectés, nous avons
évalué la quantité de pixels saillants au vu du seuil que nous avons défini dans les 4
bases d’images. Sur la Figure 2.12, nous avons quantifié en 10 valeurs de façon uniforme
la saillance. Cette opération nous permet d’étudier la distribution des pixels
en fonction de la saillance. Le pourcentage d’"outliers" correspondant à la quantité
d’informations a été calculé par rapport aux données initiales. Par exemple pour la
base LeMeur composée de 27 images, on dispose de 270 (27x10 intervalles) valeurs.
1.48% indique que 4 valeurs sur les 270 ne rentrent pas dans l’intervalle défini par
l’équation (2.3). Même si pour les bases UKB et Pascal VOC2012 il semble qu’il
y ait un nombre important de points aberrants ("outliers"), en regardant leur taux
(1.48% pour LeMeur, 1.58% pour Kootstra, 2.28% pour UKB et 1.99% pour Pascal
VOC2012), on se rend compte qu’on reste dans les mêmes proportions. En effet sur
UKB et Pascal VOC2012 il y a beaucoup plus d’images (10 200 pour UKB contre 27
pour LeMeur). Les "outliers" présents sur cette figure sont dus au fait que certaines
images comportent plus d’informations saillantes que d’autres au sein d’une même
base. Ce graphique est une première analyse globale des bases d’images. Pour les
4 bases d’images, le premier intervalle [0, 0.1] est celui qui a la médiane m la plus
élevée : m > 30% pour LeMeur, m > 20% pour Kootstra, m > 40% pour UKB et
2. C’est la valeur qui est souvent utilisée par défaut.
56Chapitre 2. Notre approche pour l’indexation [0−0.1[ [0.1−0.2[ [0.2−0.3[ [0.3−0.4[ [0.4−0.5[ [0.5−0.6[ [0.6−0.7[ [0.7−0.8[ [0.8−0.9[ [0.9−1] 010203040506070
80
90
Quantification de la valeur de la saillance
Pourcentage de pixels par intervalle (%)
(a) LeMeur : 1.48% d’outliers
[0−0.1[ [0.1−0.2[ [0.2−0.3[ [0.3−0.4[ [0.4−0.5[ [0.5−0.6[ [0.6−0.7[ [0.7−0.8[ [0.8−0.9[ [0.9−1]
0
10
20
30
40
50
60
70
80
90
Quantification de la valeur de la saillance
Pourcentage de pixels par intervalle (%)
(b) Kootstra : 1.58% d’outliers
[0−0.1[ [0.1−0.2[ [0.2−0.3[ [0.3−0.4[ [0.4−0.5[ [0.5−0.6[ [0.6−0.7[ [0.7−0.8[ [0.8−0.9[ [0.9−1]
0
10
20
30
40
50
60
70
80
90
Quantification de la valeur de la saillance
Pourcentage de pixels par intervalle (%)
(c) UKB : 2.28% d’outliers
[0−0.1[ [0.1−0.2[ [0.2−0.3[ [0.3−0.4[ [0.4−0.5[ [0.5−0.6[ [0.6−0.7[ [0.7−0.8[ [0.8−0.9[ [0.9−1]
0
10
20
30
40
50
60
70
80
90
Quantification de la valeur de la saillance
Pourcentage de pixels par intervalle (%)
(d) Pascal VOC2012 : 1.99% d’outliers
Figure 2.12: Répartition des valeurs de saillance visuelle des images des 4 bases choisies.
57Chapitre 2. Notre approche pour l’indexation
LeMeur Kootstra UKB Pascal VOC2012
0
10
20
30
40
50
60
70
80
90
100
Différentes bases
Pourcentage de caractéristiques locales (%)
Figure 2.13: Pourcentage des pixels ayant une saillance visuelle ≥ 0.4.
m ∼ 30% pour Pascal VOC2012. Ces premiers résultats sont cohérents dans la mesure
où, un modèle de saillance est sensé imiter notre système d’attention visuelle en
sélectionnant très peu d’informations mais les plus pertinentes. Nous pourrions donc
déjà conclure, que globalement, UKB et Pascal VOC2012 ne comportent pas énormément
d’informations saillantes comparées aux bases LeMeur et Kootstra. Cette
première conclusion se base sur les proportions de pixels présents dans le premier
intervalle mais également dans les autres.
Si nous nous intéressons aux taux de pixels saillants (≥ 0.4), les conclusions de la
Figure 2.13 confirment les précédentes. En effet, les bases LeMeur et Kootstra ont
les valeurs médianes les plus élevées. Ceci se comprend aisément puisque ce sont des
bases d’images conçues pour les travaux sur la saillance visuelle. Les bases UKB et
Pascal VOC2012 peuvent contenir plusieurs informations visuellement attractives
de tailles différentes liées à la complexité de la scène ou aux différents objets. Notons
également que la taille des objets ou des régions visuellement saillantes joue
un rôle important dans ces résultats. Même si le pourcentage de pixels saillants
est plus important sur LeMeur et Kootstra, globalement sur les 4 bases d’images
la conclusion est la même : très peu de pixels ont une valeur de saillance visuelle
supérieure ou égale à 0.4. Le fait que ces bases d’images contiennent globalement
peu d’informations saillantes permet d’émettre la même hypothèse par rapport aux
comportements des détecteurs : très peu de points détectés seront saillants.
Dans la suite, nous nous sommes intéressés au comportement des détecteurs.
Cette étude nous permettra de déterminer celui qui permet d’extraire le plus de
points saillants dans les configurations que nous avons utilisées. Le but ici n’est pas
de trouver la meilleure configuration des différents paramètres entrant en jeu dans
le calcul des caractéristiques locales pour avoir de meilleurs résultats. Nous avons
pris les valeurs par défaut proposées par les différents auteurs en supposant qu’elles
correspondent à une certaine optimisation moyenne. Nous rappelons ici que le fait
qu’un détecteur produise plus ou moins de points saillants n’est pas forcément lié à
sa performance en matière de reconnaissance d’image par le contenu. Ce paramètre
58Chapitre 2. Notre approche pour l’indexation
n’est d’ailleurs aucunement pris en compte dans l’évaluation des détecteurs à travers
les différentes métriques de la littérature.
(a) 393 216 pixels (b) 2716 points détectés (c) Carte de saillance
27.58% Pix et 51.36% KP
(d) 196 608 pixels (e) 1519 points détectés (f) Carte de saillance
36.04% Pix et 74.52% KP
(g) 307 200 pixels (h) 7 points détectés (i) Carte de saillance
9.57% Pix et 100% KP
(j) 166 500 pixels (k) 9 points détectés (l) Carte de saillance
1.37% Pix et 100% KP
Figure 2.14: Exemple d’une image par base pour illustrer la non corrélation entre le nombre
de pixels ayant une saillance ≥ 0.4 dans l’image et celui de caractéristiques locales. Pour
cette illustration, les caractéristiques locales sont extraites avec le détecteur de HarrisLaplace.
Sur la première ligne, il s’agit d’une image de la base LeMeur, sur la deuxième
d’une de la base Kootstra, sur la troisième de UKB et sur la dernière une de Pascal
VOC2012. % Pix correspond au pourcentage de pixels dans l’image ayant une saillance ≥
0.4 et %KP à celui des caractéristiques locales détectées remplissant les mêmes conditions.
Nous tenons à préciser que nous avons étudié la corrélation entre le nombre de pixels
ayant une valeur de saillance supérieure ou égale à 0.4 et celui de points clés respectant
la même condition, et aucun lien n’a été trouvé. Le nombre de caractéristiques
59Chapitre 2. Notre approche pour l’indexation LeMeur Kootstra UKB Pascal VOC2012 0102030405060708090
100
Différentes bases
Pourcentage de pixels (%)
(a) Harris
LeMeur Kootstra UKB Pascal VOC2012
0
10
20
30
40
50
60
70
80
90
100
Différentes bases
Pourcentage de pixels (%)
(b) Harris-Laplace
LeMeur Kootstra UKB Pascal VOC2012
0
10
20
30
40
50
60
70
80
90
100
Différentes bases
Pourcentage de pixels (%)
(c) DOG
LeMeur Kootstra UKB Pascal VOC2012
0
10
20
30
40
50
60
70
80
90
100
Différentes bases
Pourcentage de pixels (%)
(d) FAST
Figure 2.15: Illustration de la répartition des points clés saillants des 4 bases choisies.
60Chapitre 2. Notre approche pour l’indexation
est avant tout lié au contenu de l’image. La Figure 2.14 l’illustre bien. Les images
que nous avons choisies sur cette figure ont un pourcentage relativement faible de
pixels saillants et pourtant une grande partie (≥ 50%) des points clés détectés est
saillante. Les images 2.14(g) et 2.14(j) illustrent bien la nécessité d’une certaine
variation géométrique pour la détection des caractéristiques locales. L’autre conclusion,
en observant les images de la Figure 2.14, est que si l’image recherchée est
constituée d’un objet placé sur un fond homogène, malgré le peu de caractéristiques
locales détectées, elles seront potentiellement saillantes.
Les résultats de l’étude de la saillance visuelle des différentes caractéristiques locales
sont présentés sur les graphiques de la Figure 2.15. Si on fait la moyenne
des différentes médianes m, on obtient : m ∼ 50% pour Harris, m ∼ 32% pour
Harris-Laplace, m ∼ 35% pour DoG et m ∼ 37% pour FAST. La première remarque
concerne le détecteur de Harris. Ce dernier apparaît comme celui qui extrait le plus
de points clés saillants malgré la nature des images de ces bases. On pourrait l’expliquer
par le fait que ce détecteur mesure des différences d’intensités dans l’espace
de l’image qui représenteraient une mesure de contraste intéressante pour capter la
saillance visuelle. La différence entre les trois autres détecteurs est minime. Les ré-
sultats de Harris-Laplace et DoG pourraient s’expliquer par le changement d’échelle
qu’ils intègrent.
Le détecteur Harris-Laplace bien qu’il soit présenté comme meilleur dans la littérature
à celui de Harris par sa robustesse au changement d’échelle est globalement celui
qui produit le moins de points clés saillants. Ces conclusions ne font que confirmer
que les notions de saillance et de pertinence/importance peuvent être liées mais pas
forcément interdépendantes.
2.6.2 Discussions autour de ces premiers résultats
L’étude de la saillance visuelle des points clés que nous avons proposée n’avait
jamais été faite et permet de mieux appréhender les détecteurs que nous avons
utilisés. En conclusion générale à cette étude, on peut dire que, majoritairement,
les détecteurs que nous avons choisis n’extraient que peu d’informations visuellement
saillantes. Celles-ci peuvent être utiles si la tâche et la base le permettent.
Si, dans la base d’images utilisée, les points saillants sont pertinents pour la reconnaissance
d’images alors nous pensons que la saillance visuelle peut être utile
pour du filtrage de points clés. D’ailleurs, Zdziarski et al. [Zdziarski 12] ont utilisé
la saillance visuelle pour sélectionner les caractéristiques locales. En utilisant le
descripteur SURF, la réduction du nombre de caractéristiques ne diminuait pas significativement
les performances du classifieur. Ces premiers travaux présagent alors
que la saillance visuelle peut très bien être incluse dans les solutions actuelles sans affecter
leurs performances. Cette notion de filtrage est d’autant plus intéressante que,
dans la littérature, l’échantillonnage dense est de plus en plus utilisé pour améliorer
les performances des différents modèles [Gordoa 12, Delhumeau 13]. Si la saillance
visuelle permet à l’humain de pouvoir catégoriser en un laps de temps très court des
images, elle pourrait alléger les vecteurs de caractéristiques. Il s’agit évidemment
d’un raccourci puisque dans la réalité, la reconnaissance et la catégorisation font
appel à d’autres processus cognitifs.
61Chapitre 2. Notre approche pour l’indexation
Nous pensons également que la saillance visuelle peut être utile pour ajouter des
informations intéressantes dans certains cas. Ainsi, certains détecteurs de la litté-
rature ont des limites notamment sur des images présentant très peu d’information
géométrique : le cas de l’image 2.14(j) par exemple. L’une des solutions est de mettre
en place une détection dense ou tout au moins de rajouter des points. Nous proposons
alors d’ajouter des points en prenant en compte les spécificités des différents
détecteurs. Le détecteur Harris-Laplace a priori est un bon compromis, ne serait-ce
que sur UKB et Pascal VOC2012, pour ajouter des points saillants puisqu’il est celui
qui en détecte le moins. Nous étudierons l’impact de cette opération dans la section
suivante.
Dans la suite la notion de saillance n’est plus définie par rapport au précédent seuil
choisi de 0.4. Nous avons ordonné les pixels en fonction de leur saillance visuelle.
2.7 Étude de l’importance des points clés saillants
Nous avons évalué l’importance des points clés en fonction de la valeur de leur
saillance visuelle. Pour ce faire, nous avons procédé de deux façons :
– Supprimer des points clés en fonction de leur saillance ;
– Ajouter des caractéristiques locales visuellement saillantes.
Cette étude s’est faite dans deux configurations. Dans un premier temps, nous
avons travaillé avec les caractéristiques locales détectées avec Harris-Laplace et pour
finir nous avons comparé les résultats à une détection dense. Pour cette quantification
dense, nous avons utilisé une fenêtre de taille 15*15 tous les 6 pixels
[van de Sande 10]. Sur les images de UKB de taille 640*480, nous obtenons 8190
caractéristiques locales.
2.7.1 Impact de la suppression des points clés en fonction
de leur saillance
Dans cette étude, nous avons supprimé les points clés en fonction de leur saillance.
Nous avons étudié deux configurations après avoir rangé les points clés en fonction
de leur saillance visuelle :
– Suppression des points les moins saillants et des points les plus saillants ;
– Remplacement des points les moins saillants par le même nombre de points les
plus saillants issus de la quantification dense.
Sur la Figure 2.16, on remarque que la suppression des points les moins saillants 3
n’affecte pas énormément le score moyen. Par exemple, si on considère la configuration
"Sans normalisation", lorsqu’on supprime 20% des points les plus saillants,
on obtient un score moyen de 2.92 alors qu’il faut supprimer 64% des points les
moins saillants pour descendre à ce score. Cette différence de pourcentage rejoint les
conclusions de l’étude des points clés saillants détectés. En effet, comme il y a très
peu de points ayant une saillance élevés, si on considère les courbes "Saillants" et
3. Ici les points sont supprimés en fonction de leurs valeurs de saillance triées. La notion de
saillance ici n’a rien à voir avec celle définie lors de l’étude de la saillance des détecteurs : le seuil
0.4.
62Chapitre 2. Notre approche pour l’indexation
Figure 2.16: Impact de la suppression des points clés en fonction de leur saillance. Sailants
et Saillants_Norma correspondent aux résultats de la suppression des points en triant la
saillance par ordre décroissant (les points les plus saillants sont supprimés en premier)
alors que NonSaillants et NonSaillants_Norma correspondent aux résultats de l’inverse
(les points les moins saillants sont supprimés en premier). Norma indique que nous avons
normalisé nos histogrammes de mots visuels avec p=0.5.
"Saillants_Norma", dès les premières suppressions, on les élimine. Cela montre que
les points les plus saillants détectés par Harris-Laplace sont importants sur UKB.
Le comportement est le même avec la normalisation. Mais celle-ci permet cependant
de gagner en précision : 3.21 à 20% ce qui correspond à peu près au score obtenu
quand on n’applique aucune normalisation et qu’on conserve tous les points (3.22).
Nous avons effectué les mêmes études en partant d’un ensemble de caractéristiques
locales obtenues à partir d’une quantification dense. Cette nouvelle configuration
dont les résultats sont présentés sur la Figure 2.17, nous permet d’étudier la
dépendance des résultats précédents de la méthode de détection des caractéristiques
locales. En se mettant dans une configuration d’échantillonnage dense, lorsqu’on ne
supprime aucun point, le score moyen est de 3.27 avec le même dictionnaire visuel. Si
on le compare au score moyen de 3.35 obtenu en appliquant une normalisation avec
p=0.5 et un détecteur de Harris-Laplace en ne supprimant également aucun point,
on se rend compte qu’on perd 2.39%. Sur UKB, l’échantillonnage dense que nous
avons utilisé n’améliore pas les résultats et n’a donc aucun intérêt a priori puisqu’il
est plus long. Ceci peut être dû au fait que plusieurs informations "parasites" (qui
sont identiques dans plusieurs images) ont dues être décrites. En effet, étant potentiellement
communes à plusieurs images, ces caractéristiques locales introduisent
potentiellement des biais dans les "Sacs de mots visuels". D’ailleurs, la présence de
ces informations "parasites" s’illustre par l’amélioration du taux de reconnaissance
dans les premiers pourcentages supprimés : ∼ +2.75% à 65% de points non saillants
63Chapitre 2. Notre approche pour l’indexation
Figure 2.17: Étude de la dépendance des résultats de l’importance des caractéristiques
locales saillantes de la méthode de détection des caractéristiques : détection dense.
supprimés 4
. Les résultats de la suppression des points les moins saillants dans une
configuration dense reposent la question de l’utilité d’un nombre important de points.
Même si le score moyen obtenu avec une détection dense est plus bas que notre score
de référence, les résultats obtenus en étudiant l’impact de la suppression des points
clés saillants sont identiques à ceux présentés sur la Figure 2.16. Les caractéristiques
locales les plus saillantes sont plus importantes si on veut effectuer un filtrage sans
affecter considérablement le score moyen. Elles sont d’autant plus importantes quand
on fait une sélection dense puisqu’on peut facilement éliminer les motifs sporadiques.
On peut conclure de cette première étude que les points clés les plus saillants
sont très importants. En effet, ils permettent comme l’illustrent les courbes de la
Figure 2.16 de garder une très bonne précision. Cette étude est d’autant plus intéressante
qu’elle montre que les caractéristiques locales les moins saillantes, notamment
sur UKB, peuvent être filtrées en définissant un certain pourcentage sans affecter
énormément les résultats. Ces résultats rejoignent ceux obtenus par Zdziarski et al.
[Zdziarski 12] en filtrant les descripteurs SURF par leur saillance.
2.7.2 Ajouts de points saillants
Les signatures visuelles considérées pour cette étude n’ont pas été normalisées.
Nous avons conclu des études précédentes que les points détectés les moins saillants
n’étaient pas indispensables pour avoir un score de classification intéressant (supé-
rieur ou égal à 3 par exemple). Quand on utilise le détecteur Harris-Laplace, sur
4. On a désormais 2867 caractéristiques par images.
64Chapitre 2. Notre approche pour l’indexation
UKB, sans normalisation des signatures visuelles, il faut avoir supprimé 58% des
points les moins saillants pour descendre en dessous de 3. Nous avons alors décidé
de remplacer ces points par les points les plus saillants de la détection dense. Pour
illustrer notre propos, supposons que nous désirons supprimer 4% des points les
moins saillants détectés, nous remplaçons ces points par le même nombre de points
les plus saillants issus de la détection dense. Les résultats de cette étude sont illustrés
sur la Figure 2.18.
Figure 2.18: Remplacement des points détectés les moins saillants par les points les plus
saillants issus de la détection dense.
Nous avons arrêté l’étude à la suppression de 90% des points les moins saillants
parce qu’au delà, cela reviendrait tout simplement à ne considérer que les points
détectés en dense. D’ailleurs, la première conclusion concerne la précision gardée
après le remplacement de 90% des points. Ceci illustre d’autant plus l’importance
des points saillants pour la reconnaissance des images de UKB. Si on ne remplaçait
pas ces points, le taux de reconnaissance descendrait à 1.94. Le même constat est fait
en supprimant 60% des points les moins saillants détectés avec Harris-Laplace. On
note une amélioration de la reconnaissance de +3.75%. Le résultat le plus important
se situe à 20%. La reconnaissance est meilleure que si on considérait simplement
tous les points détectés avec Harris-Laplace, 3.27 au lieu de 3.22 soit une amélioration
de +1%. Certes, cette amélioration est peu importante mais elle démontre
que remplacer des points de saillance visuelle faible par d’autres de saillance visuelle
forte ne dégrade pas du tout les résultats et a plutôt tendance à les améliorer. Ceci
confirme alors que, sur cette base d’images, la saillance visuelle est très importante.
Elle permet de garder une très bonne précision.
2.7.3 Discussions autour des travaux sur la saillance
Nous avons proposé une étude de la saillance des points clés ainsi que leur importance.
Dans un premier temps, nous avons analysé la saillance des caractéristiques
65Chapitre 2. Notre approche pour l’indexation
locales détectées. Nous en avons conclu que, globalement, les bases d’images considé-
rées ne contiennent pas énormément d’informations saillantes. Bien évidemment, ces
résultats ne sont valables que dans le cas du modèle que nous avons utilisé. Même
si ce modèle de saillance visuelle n’est pas celui qui donne les meilleurs résultats
[Borji 13b], il nous a permis de faire un travail préliminaire. Pour toutes les bases
que nous avons étudiées, la majorité des pixels a une valeur de saillance visuelle
comprise entre 0 et 0.3. Nous avons aussi conclu de l’étude de la corrélation entre le
pourcentage de pixels saillants dans une image et celui des caractéristiques locales
saillantes détectées qu’il n’y avait aucun lien entre les deux. Il s’agit là d’un résultat
prévisible puisque les deux informations sont liées au contenu de la scène mais
sont issues de deux processus différents. Les résultats obtenus dans cette première
partie confirment une fois encore qu’on peut avoir des informations importantes
pour un système de recherche d’images par le contenu sans qu’elles soient les plus
saillantes du point de vue de notre système de vision. Ceci se justifie par le taux de
pourcentage de caractéristiques locales saillantes détectées. Même si le détecteur de
Harris apparaît comme celui détectant le plus de points saillants, ceci ne le classerait
en rien comme étant le plus efficace. Dans une seconde partie de ce chapitre,
nous nous sommes focalisés sur l’importance des caractéristiques locales saillantes
dans la tâche d’indexation de notre système. Nous avons remarqué que les points
clés saillants étant très importants pour avoir des résultats intéressants : au moins
un score de 3 sur 4. Il suffit de supprimer 20% des descripteurs des points clés les
plus saillants pour que le score moyen descende à 2.92. Ces premiers résultats ont
été confirmés lorsque nous avons remplacés les points clés les moins saillants par
les points les plus saillants (dans la même proportion issus de la détection dense).
D’ailleurs à 20%, on note une amélioration de +1% du taux de reconnaissance. Ces
résultats permettent de conclure que sur la base UKB les points clés saillants sont
importants d’autant plus que les résultats dans le cas d’une configuration dense
sont identiques. Ces résultats ne dépendent alors aucunement de la méthodologie de
détection des caractéristiques locales.
Conclusion
Dans ce chapitre consacré à nos premières contributions, nous avons travaillé
avec deux bases :
– la base UKB composée de 10 200 images, identiques 4 par 4 qui a constitué
notre base de tests ;
– la base Pascal VOC2012 composée de 17 125 images que nous avons utilisée
essentiellement pour la construction du dictionnaire visuel.
Nous avons proposé, dans un premier temps, une nouvelle façon de construire un
dictionnaire visuel. Cette technique se base sur les précédents résultats liés à l’utilisation
de l’algorithme K-Means sur des vecteurs de grande dimension. En effet, les
clusters obtenus tendent vers une distribution aléatoire pour de grandes dimensions.
Les descripteurs de caractéristiques locales traditionnellement utilisés en reconnaissance
d’images tels que SIFT et leurs dérivés sont souvent de dimension 128.
Notre algorithme se base sur une étape préliminaire de sélection aléatoire d’un en-
66Chapitre 2. Notre approche pour l’indexation
semble de descripteurs de caractéristiques locales. Ensuite nous appliquons une suppression
récursive en prenant en compte un gain d’information que nous avons défini.
Les signatures visuelles ont ensuite été construites en utilisant la technique "Sac de
mots visuels". Les résultats obtenus sont très satisfaisants sur la base UKB comparés
à ceux de la littérature. En moyenne, notre algorithme permet un gain de
5% par rapport à l’algorithme BoVW [Sivic 03] avec un dictionnaire de taille 294.
La taille du dictionnaire influence énormément les résultats des signatures de type
"Sac de mots visuels". Traditionnellement les meilleurs résultats sont obtenus avec
des vocabulaires visuels de tailles supérieures ou égales à 10 000. Le descripteur
SIFT est très plébiscité alors que nous obtenons des très bons scores moyens avec le
descripteur CMI sur UKB en comparaison aux signatures visuelles habituellement
plus performantes telles que VLAD [Jégou 10b] et FV [Perronnin 07]. Ce sont là des
résultats intéressants puisque ce descripteur est de taille 5 fois plus petite que SIFT.
Ceci peut évidemment être dû à la nature des images de UKB et reste à vérifier sur
d’autres bases.
La seconde partie de nos travaux a été consacrée à l’utilisation de la saillance visuelle
pour la reconnaissance d’images par le contenu. Nous avons d’abord testé la
pondération par la saillance visuelle des caractéristiques visuelles. Ces premières expérimentations
n’ont pas été concluantes en termes de score moyen sur UKB. Le seul
impact que nous avons noté concerne le rang des 4 images les plus ressemblantes.
Parmi les 10 200 images de la base, la pondération par la saillance améliore globalement
leur rang. Ces résultats nous ont amené à étudier la saillance visuelle des
détecteurs de caractéristiques locales. Pour ce faire, nous avons rajouté deux bases
d’images conçues pour l’étude de la saillance visuelle : LeMeur et Kootstra. Des
quatre détecteurs choisis (DoG, FAST, Harris et Harris-Laplace), celui de Harris est
celui qui produit le plus de caractéristiques locales dans les régions saillantes. Le dé-
tecteur Harris-Laplace qui est l’un des meilleurs de la littérature est celui qui détecte
le moins de caractéristiques locales saillantes. Nous avons néanmoins étudié l’impact
du filtrage de points clés par la saillance visuelle à partir de ce dernier puisqu’il est
le plus utilisé. Les premiers résultats montrent que les points clés saillants sont très
importants. Les mêmes résultats ont été obtenus dans une quantification dense des
pixels des images montrant qu’ils ne sont pas dépendants de la nature de la sélection
des caractéristiques locales mais probablement de la base.
67Chapitre 2. Notre approche pour l’indexation
68Conclusion Partie 1
Dans cette première partie dédiée à la reconnaissance d’images par le contenu,
nous avons, dans un premier chapitre, fait une revue de la littérature axée sur les
différentes techniques que nous avons ensuite utilisées dans nos contributions dé-
taillées dans le second chapitre.
Le Chapitre 1 nous a permis de rappeler et d’expliquer quelques notions fondamentales
en indexation depuis la description des images jusqu’à la création de la
signature visuelle. Deux solutions existent pour la description : une approche globale
sur laquelle nous n’avons pas insisté et une approche locale. C’est cette dernière
que nous avons choisie dans nos travaux présentés dans le Chapitre 2. Nous avons
fait le choix de ne pas nous intéresser aux tâches de catégorisation et de classification
dans cette première partie. Ce qui nous importe dans ces premières contributions
c’est la précision des descripteurs et la robustesse de la méthode. Il est évident que
nos résultats sont perfectibles, nous l’avons prouvé en montrant que la normalisation
pouvait améliorer le score moyen sur UKB. La distance entre les signatures visuelles
peut aussi également changer les résultats. Nous avons opté pour la distance χ
2
,
en partie parce que la distance L2 impactait négativement nos résultats. Il s’agit
là de différents leviers sur lesquels on peut pousser la réflexion. Celle-ci pourrait
être menée depuis la création du dictionnaire jusqu’à la comparaison des signatures
visuelles.
Malgré la simplicité de l’algorithme de construction de dictionnaire visuel que nous
avons proposé, les résultats obtenus sont très encourageants. Cet algorithme permet
non seulement de gagner du temps lors de la création du dictionnaire, mais également
de travailler avec un dictionnaire de petite taille sur UKB, rivalisant ainsi avec des
méthodes telles que VLAD ou FV. Après ces premiers travaux, nous avons évalué
la saillance des détecteurs de caractéristiques locales. Nous en avons conclu qu’aucune
corrélation n’existait entre le nombre de pixels saillants et celui de points clés
saillants détectés sur les quatre bases que nous avons testées. Le détecteur de Harris
qui n’est pas forcément le plus performant de la littérature est celui qui détecte
le plus de points dans les régions saillantes. Celui de Harris-Laplace détecte certes
moins de points mais tous les points détectés dans les régions saillantes sont très
importants pour la précision de l’indexation. Ces premiers résultats, très encourageants,
nous ont permis d’apporter une seconde contribution pour la reconnaissance
des émotions que nous exposerons dans la partie suivante. En effet, nous avons émis
l’hypothèse que la précision des différents descripteurs de caractéristiques locales en
reconnaissance d’images pourrait être utile pour cette tâche de haut niveau. Si dans
69Conclusion Partie 1
la première partie de nos travaux, nous n’avons pas utilisé de système d’apprentissage,
pour la reconnaissance des émotions nous avons intégré un classifieur à notre
approche.
Dans la seconde partie de ce manuscrit, nous présenterons d’abord quelques solutions
pour la reconnaissance des émotions. Ensuite nous exposerons notre approche
basée sur les méthodes traditionnelles de reconnaissance d’images par le contenu.
Pour constituer une vérité-terrain, nous avons construit une base qui a été évaluée
en intégrant la saillance visuelle. Nous avons d’ailleurs défini un ensemble de critères
pour décrire et comparer les différentes bases d’images pour la reconnaissance des
émotions que nous présenterons dans le Chapitre 4.
70Deuxième partie
Reconnaissance de l’impact
émotionnel des imagesIntroduction Partie 2
Les outils actuels de reconnaissance d’images par le contenu sont de plus en plus
performants. Néanmoins il y a encore une branche qui résiste aux progrès : celle de
la reconnaissance des émotions induites par la visualisation d’une image. Si la reconnaissance
des émotions à partir des visages commence à être bien maîtrisée, à travers
les différents modèles de mouvements faciaux existants, l’impact émotionnel global
d’une image quelconque est encore à l’état de test. Et pourtant c’est un domaine
qui pourrait offrir de belles perspectives vu le développement des outils numériques
et du tout connecté/intelligent.
Les travaux sur les émotions et les images peuvent être classés en deux grands
groupes. Le premier qui s’intéresse aux phénomènes biologiques régissant les émotions
et le second qui essaie de proposer des solutions tentant d’approcher les vérités
terrain. Nous ne nous intéresserons pas aux travaux focalisés sur la compréhension
du phénomène émotionnel mais sur les solutions. Ainsi nous présenterons dans le
premier chapitre quelques solutions de la littérature sur les émotions et les images ;
des travaux sur les émotions et les couleurs aux solutions utilisant des descripteurs
sémantiques et/ou bas niveaux. Nous évoquerons également quelques bases de la littérature
dont nous discuterons dans le second chapitre. Ce dernier sera entièrement
consacré à notre approche pour la reconnaissance des émotions. Nous avons choisi
d’évaluer une architecture de recherche d’images par le contenu. Les descripteurs que
nous avons retenus offrent de bons résultats pour cette tâche. Les contraintes des
bases de la littérature nous ont obligés à construire une base d’images que nous avons
évaluée au cours d’expérimentations subjectives. Nous avons choisi de segmenter les
images par la saillance visuelle et d’étudier l’impact de cette segmentation aussi bien
lors des évaluations que de la classification par notre approche computationnelle.
73Introduction Partie 2
74Chapitre 3
Reconnaissance des émotions dans
la littérature
Sommaire
3.1 Définition et théories de l’émotion . . . . . . . . . . . . . 76
3.2 Modélisations des émotions . . . . . . . . . . . . . . . . . 77
3.3 Émotions et couleurs . . . . . . . . . . . . . . . . . . . . . 79
3.4 Reconnaissance de l’impact émotionnel traitée comme
une tâche de reconnaissance d’image dans la littérature 83
3.4.1 Bases d’images de la littérature . . . . . . . . . . . . . . . 83
3.4.2 Systèmes de reconnaissance d’images basée émotion . . . 86
Introduction
Dans ce chapitre, nous reviendrons sur quelques travaux de la littérature sur la
reconnaissance de l’impact émotionnel des images. Dans un premier temps, nous
aborderons la question de la définition de l’émotion qui n’a trouvé un consensus que
très récemment. Les théories contemporaines des émotions telles que proposent Coppin
et Sander [Coppin 10] seront également abordées permettant ainsi de comprendre
les deux modélisations des émotions retrouvées le plus souvent dans la littérature.
Même si l’étude de l’impact émotionnel des images n’a pas encore un formalisme
aussi bien défini que la reconnaissance d’images par le contenu, il existe un certain
nombre de travaux dont une grande partie a été consacrée aux émotions et
aux couleurs, aux harmonies couleur et aux préférences couleur. Les solutions de
reconnaissance d’images par l’émotion utilisent le plus souvent les caractéristiques
de l’image, bas-niveau ou haut-niveau extraites des couleurs. Dans le dernier cas
de figure, une sémantique est extraite des différentes couleurs et ensuite affectée à
l’image. Nous présenterons quelques solutions de la littérature avant de finir sur les
propositions qui considèrent la reconnaissance des émotions comme une tâche d’indexation.
Pour ce faire, certaines bases de la littérature seront présentées : les deux
bases d’images proposées par Machajdik et Hanbury [Machajdik 10] et la base IAPS
75Chapitre 3. Reconnaissance des émotions dans la littérature
(International Affective Picture System) [Lang 08]. Cette dernière est l’une des premières
bases dédiée à l’étude des émotions largement évaluée et souvent utilisée dans
la littérature pour tester et comparer les différents travaux.
3.1 Définition et théories de l’émotion
Le concept d’émotion est utilisé de différentes manières selon qu’il est envisagé en
référence à l’aspect stimulus, à l’expérience subjective, à une phase d’un processus,
à une variable intermédiaire ou à une réponse. Après des années de débat, selon
David Sander [Sander 13], les scientifiques sont arrivés à un consensus pour définir
l’émotion. Il s’agirait d’un processus rapide, focalisé sur un événement et constitué
de deux étapes :
– Un mécanisme de déclenchement fondé sur la pertinence de l’événement (par
exemple, l’événement est-il pertinent pour mes buts ?) ;
– Une réponse émotionnelle à plusieurs composantes (les tendances à l’action,
les réactions du système nerveux autonome contrôlant par exemple le rythme
cardiaque, les expressions et les sentiments).
Une émotion est brève et toujours déclenchée par un événement spécifique. Mais,
d’après cette définition "consensuelle", c’est aussi un phénomène dynamique qui pré-
sente de multiples composantes. C’est une réaction à un stimulus affectif, environnemental
ou psychologique. L’émotion ressentie par rapport à une situation est propre
à chaque individu, à son passé et son histoire de vie, ses capacités intellectuelles, son
état psychologique. Les émotions fortes impliquent des répercussions physiques du
ressentiment psychologique initial : la tristesse peut provoquer les larmes, la peur
peut déclencher un cri, une perte urinaire parfois ou la joie peut générer un grand
sourire, voire même des larmes. Une même situation implique des émotions diffé-
rentes suivant l’individu concerné, le contexte et l’implication. On retrouve beaucoup
d’autres définitions de l’émotion induisant alors un nombre élevé de théories
de l’émotion.
Coppin et Sander [Coppin 10] proposent un récapitulatif des théories et concepts
contemporains des émotions. Ils en distinguent quatre :
– l’approche scientifique des émotions : deux théories contradictoires se
sont longtemps opposées à savoir les conceptions phériphéraliste et centraliste.
D’une part James [James 90] et Lange [Lange 22], soutiennent que ce qui était
considéré auparavant comme la conséquence de l’émotion en est en fait la cause.
Le déclenchement d’une émotion spécifique serait déterminé par la perception
d’un motif d’activation périphérique spécifique. Plus concrètement, nous aurions
peur parce que nous constaterions que nous tremblons. D’un autre côté,
selon Cannon [Cannon 27] et Bard [Bard 28], le déclenchement d’une émotion
spécifique est déterminé par le traitement d’un stimulus au niveau du système
nerveux central, le motif d’activation périphérique n’étant ni spécifique ni causal.
Cette théorie met donc en avant l’importance du système nerveux central.
Ainsi, les changements physiologiques ne sont pas conçus comme cause mais
comme conséquence de l’émotion.
Ces deux théories, certes opposées, sont fondées sur une approche physiolo-
76Chapitre 3. Reconnaissance des émotions dans la littérature
gique des émotions. Toujours selon Coppin et Sander [Coppin 10], le débat
James-Lange/Cannon-Bard a été important pour la prise de conscience du
rôle de la cognition dans l’émotion. Ceci est très bien illustré par les travaux
menés par Schachter [Schachter 62], qui figurent parmi l’une des contributions
pionnières les plus influentes dans le champ des sciences affectives. En effet,
Schachter considère qu’une émotion est déterminée par une interaction entre
deux composantes : une activation physiologique (arousal) et une cognition
concernant la situation déclenchante de cette activation physiologique.
– les théories de l’évaluation cognitive de l’émotion : l’émotion est le
fruit des évaluations cognitives que l’individu fait au sujet de l’événement, qu’il
soit externe ou interne, ou de la situation, qui initie l’émotion. Ces théories
sont également appelées "théories de l’appraisal". Selon Coppin et Sander, ces
modèles postulent que les organismes explorent constamment leur environnement,
réagissant aux stimuli pertinents. Ils soulignent que la contribution majeure
de ces théories est de spécifier un ensemble standard de critères qui sont
supposés sous-tendre le processus d’évaluation cognitive de l’émotion. Lors du
déroulement d’un événement, l’individu concerné évaluerait l’importance de
cet événement sur un certain nombre de critères.
– les théories des émotions de base : une perspective évolutionniste, faisant
l’hypothèse que l’évolution a joué un rôle central dans le façonnement
des caractéristiques. Les pères de cette approche sont sont entre autres Darwin,
Ekman, Izard, Plutchik [Rigoulot 08, Tayari 09]. Certains chercheurs ont
avancé l’existence d’un nombre limité d’émotions fondamentales universelles,
qui auraient ainsi chacune une fonction évolutionnaire. Ces dernières sont dites
"basiques" ou "primaires" ou encore "fondamentales". Il faut noter que seulement
cinq émotions de base sont communes aux différentes propositions (la
tristesse, la colère, la joie, le dégoût et la peur). Les émotions plus complexes
proviendraient quant à elles d’un mélange de ces émotions de base.
– les théories dimensionnelles : l’affect peut être décrit en recourant à des
dimensions élémentaires indépendantes, qu’il est possible de combiner, qui seraient
des propriétés phénoménologiques basiques de l’expérience affective.
Les deux dernières théories induisent les deux principales catégorisations des émotions
qu’on retrouve, le plus souvent, dans les systèmes informatiques de reconnaissance
des émotions issues des images et des vidéos.
3.2 Modélisations des émotions
Ici nous revenons plus en détail sur les deux classifications habituelles des émotions
sont :
– l’approche catégorielle ;
– l’approche dimensionnelle.
77Chapitre 3. Reconnaissance des émotions dans la littérature
Dans l’approche catégorielle (discrète), les processus émotionnels peuvent être expliqués
par un ensemble d’émotions basiques ou fondamentales. Cette approche intègre
le modèle de Ekman [Ekman 92] et aussi celui de Plutchik [Plutchik 97] qui sont les
plus connus. Ekman définit six émotions primaires qui sont la colère, le dégoût, la
peur, la joie, la tristesse et la surprise. Plutchik quant à lui compare les émotions à
une palette de couleurs comme on peut le voir sur la Figure 3.1. Il propose un modèle
de huit émotions qui correspondent à des couleurs dites "primaires" et peuvent
s’opposer par deux.
Figure 3.1: Circumplex de Plutchik.
Dans la littérature, beaucoup de travaux se basent sur une modélisation discrète
des émotions, par exemple, ceux de Wei et al. [Wei 08], Paleari et Huet [Paleari 08],
Kaya et Epps [Kaya 04] ou encore Machajdik et Hanbury [Machajdik 10], même si
le nombre d’émotions n’est pas toujours le même.
Les modèles de l’approche dimensionnelle se différencient des modèles de l’approche
catégorielle par le fait que les émotions résultent d’un nombre fixé de concepts
représentés dans un espace multidimensionnel. Les dimensions peuvent être un axe
de plaisir, d’éveil ou de puissance. Ces dimensions varient en fonction des besoins du
modèle. Le modèle le plus utilisé est celui de Russell (Figure 3.2) avec les dimensions
valence et activation (Valence-Arousal) dans lequel :
– La valence représente la manière dont se sent une personne quand elle regarde
par exemple une image. Cette dimension varie du positif au négatif et permet
de distinguer les émotions négatives et agréables.
– L’activation correspond au niveau d’excitation corporel.
Ces modèles permettent de représenter un très grand nombre d’émotions dans un
espace bidimensionnel dont les dimensions varient d’une information trop présente
78Chapitre 3. Reconnaissance des émotions dans la littérature
à pas assez. Cependant certaines émotions peuvent être confondues (la peur et la
colère par exemple) ou non représentées du tout (entre autre la surprise) dans un
modèle bidimensionnel de type valence/éveil.
Figure 3.2: Circumplex de Russell. L’axe Déplaisant-Plaisant correspond à la valence et
l’autre à l’activation.
Dans les travaux sur les émotions, une grande partie de la littérature a été longtemps
consacrée aux liens entre les émotions et les couleurs. Les auteurs sont d’accord sur
le fait que chaque couleur transmet des émotions particulières. Comme le disent
Ou et al. [Ou 04a], les couleurs jouent un rôle important dans la prise de décisions,
évoquant différents sentiments émotionnels. Par contre aucune conclusion n’est unanime.
Ces sentiments évoqués par une couleur ou des combinaisons de couleurs sont
appelés "émotions de couleur" (colour emotions).
3.3 Émotions et couleurs
Plusieurs travaux ont été menés sur l’étude des émotions liées aux couleurs notamment
à travers l’influence de la culture, de l’âge, du genre, du niveau social. Nous
ne ferons pas une revue de littérature détaillée mais tenterons d’évoquer quelques
travaux intéressants et pionniers. Les études que nous présenterons ici ont été menées
sur des patchs d’une couleur ou des paires de couleurs. Les premières études
sur les couleurs et les émotions portent le plus souvent sur le rouge, le vert, le bleu
et le jaune.
En 1990, Daniel Beresniak [Beresniak 90] publiait que le rouge est une couleur vivante
et excitante. En revanche, la combinaison "rouge+gris" provoquerait un sentiment
tragique. Le jaune serait la couleur la plus gaie, la plus claire, rayonnante
et jeune. Ce serait également une couleur tonique et éclatante. La couleur la plus
dynamique serait l’orange. Cette couleur combinerait la gaité du jaune et l’action
du rouge. Pour finir le bleu serait une couleur profonde et mystique qui appellerait
au calme.
Plus récemment en 2004, Kaya et al. [Kaya 04] ont fait évaluer par 98 étudiants
79Chapitre 3. Reconnaissance des émotions dans la littérature
volontaires (44 hommes et 54 femmes) 13 couleurs. Le détail des couleurs est donné
dans l’Annexe B. Les participants avaient pour consigne d’indiquer leur réponse
émotionnelle à la couleur observée ainsi que la raison de ce choix. Chaque patch de
couleur, de taille 10cm*12cm était affiché au milieu de l’écran. L’ordre des couleurs
était aléatoire et les étudiants ne pouvaient associer qu’une émotion à un patch. Le
vert a atteint le nombre le plus élevé d’émotions positives (sensations de relaxation,
joie, confort, paix et espoir) dans 95.9% des cas. Cette couleur est souvent associée
à la nature produisant ainsi un sentiment d’apaisement et de confort d’après
leurs évaluations. Le jaune est perçu comme énergétique avec des émotions positives
(93.9%). Les émotions souvent associées à cette couleur sont la joie et l’excitation
parce qu’elle est associée au soleil. La couleur bleu est la troisième couleur avec
le plus grand nombre de réponses positives. Elle est associée à l’océan et au ciel
induisant ainsi un effet de calme et de relaxation. La couleur rouge est associée à
l’amour et à la romance mais également au sang et au diable. Le blanc est associé à
l’innocence, à la paix et à l’espoir parce qu’il ferait penser à une mariée, à la neige,
à une colombe et au coton. Le blanc est aussi associé à la solitude et l’ennui. Le noir
est associé à la dépression, la peur, la colère parce qu’il est associé à des événements
tragiques. Il est également associé à la force, la santé et la richesse. Le gris est associé
à des émotions négatives. Il fait référence au mauvais temps, à des sentiments de
dépression, de tristesse et à l’ennui.
La recherche en émotions liées à une couleur ou une combinaison de deux couleurs
est désormais un domaine de recherche bien établi. En effet, en plus des travaux
décrits ci-dessus, dans une série de publications, Ou et al. [Ou 04a, Ou 04b, Ou 04c]
ont étudié les relations entre les émotions, les préférences et les couleurs. Ils ont
d’ailleurs établi un modèle des émotions liées aux couleurs à partir d’expériences psychophysiques.
Dans un premier temps, les observateurs (des étudiants britanniques
et chinois) ont évalué différents patchs d’une couleur selon dix échelles d’émotions
liées aux couleurs à savoir : Chaud-Froid, Lourd-Léger, Moderne-Classique, PropreSale,
Actif-Passif, Dur-Doux, Tendu-Détendu, Frais-Pas Frais, Masculin-Féminin et
Plaisant-Déplaisant. Une onzième a été ajoutée dans le cadre de la combinaison de
deux couleurs [Ou 04b] : l’échelle Harmonieux-Disharmonieux. Le détail des couleurs
est donné dans l’Annexe B. Leurs travaux ont prouvé qu’on pouvait réduire
le nombre d’échelles d’émotions liées aux couleurs à trois catégories ou à trois facteurs
d’émotions liées aux couleurs : l’activité, le poids et la chaleur d’une couleur.
Ces trois facteurs d’émotions sont définis dans l’espace CIELAB et donnés par les
équations (3.1)-(3.3).
colour activity = −2.1 + 0.6
(L
∗ − 50)2 + (a
∗ − 3)2 +
b
∗ − 17
1.4
!2
1
2
, (3.1)
colour weight = −1.8 + 0.04 (100 − L
∗
) + 0.45 cos (H
∗
ab − 100˚), (3.2)
colour heat = −0.5 + 0.02 (C
∗
ab)
1.07 cos (H
∗
ab − 50˚), (3.3)
avec
H
∗
ab = arctan
b
∗
a
∗
!
et C∗
ab =
q
a
∗2 + b
∗2
. (3.4)
80Chapitre 3. Reconnaissance des émotions dans la littérature
Dans ces équations L
∗
, a
∗
et b
∗
sont les coordonnées de la couleur testée dans l’espace
CIELAB. Les auteurs ont conclu que ces trois facteurs étaient en accord avec les
travaux précédents entre autres ceux de Kobayashi [Kobayashi 81].
Influence de la culture, du genre et de l’âge Les résultats obtenus dans les
travaux sur les couleurs et les émotions peuvent changer énormément en fonction de
la culture des observateurs. En 1996, par exemple Saito [Saito 96] a trouvé que pour
les Japonais le noir pouvait être lié à des sensations positives. Ou et al. [Ou 04a]
ont également noté des différences entre les observateurs britanniques et chinois au
cours de leurs évaluations sur des échelles d’émotions particulières : Tendu-Détendu
et Plaisant-Déplaisant.
Le genre peut également influencer les émotions liées aux couleurs. En 1993, Boyatzis
et Varghese [Boyatziz 93] ont montré dans l’une de leurs études, que les filles sont
particulièrement plus positives à l’égard des couleurs plus vives et négatives à l’égard
des couleurs sombres. Quant aux garçons, ils étaient beaucoup plus susceptibles
d’avoir une réaction émotionnelle positive pour les couleurs foncées. Globalement,
tous les groupes (les garçons et les filles) ont une plus forte réaction positive pour
les couleurs vives et plus de sentiments négatifs pour des couleurs plus sombres. Ils
notent également que des réactions physiologiques sont liées à la couleur (tension
musculaire, tonus ou réflex en réponse à certaines couleurs). Le rouge augmente
la tension musculaire de la normale 23 unités à 42, le jaune à 30, et le bleu à
24. D’une façon généralisée, les couleurs chaudes (rouge, orange) sont stimulantes
tandis que les couleurs froides (bleu, vert) sont associées à la détente. Cela pourrait
être lié à l’humeur associée à ces couleurs. Plus récemment en 2001, Bradley et
al. [Bradley 01] concluent de leurs expérimentations que les femmes ont tendance
à évaluer "Faiblement positives" des images que les hommes classent neutres. Elles
réagiraient également plus fortement face aux images négatives.
Beke et al. [Beke 08] quant à eux ont étudié les préférences en fonction de l’âge.
Les résultats indiquent d’importantes différences dépendant des changements neurophysiologiques,
de la culture. De leur côté, Suk and Irtel [Suk 10] ne notent aucune
différence majeure entre les réponses émotionnelles des participants pour une couleur
en fonction de l’écran d’affichage.
Émotions liées à des patchs texturés Certains auteurs dans la littérature ont
analysé l’émotion liée à la couleur en ajoutant d’autres informations au patch couleur
analysé. Lucassen et al. [Lucassen 10] ont par exemple, étudié l’émotion liée à des
patchs de textures colorées. Ils ont choisi quatre des échelles d’émotions précédemment
utilisées par Ou et al. [Ou 04a] : Chaud-Froid, Masculin-Féminin, Dur-doux et
Lourd-Léger. Ils ont adopté une stratégie particulière de test : celle de ne pas montrer
les échantillons les uns après les autres mais de les montrer par bloc. Ceci permettrait
de réduire les erreurs de classification par les observateurs. L’expérimentation
se déroule en deux phases de tests à une semaine d’intervalle. D’une façon générale,
les observateurs reproduisent mieux leurs réponses sur les échantillons non texturés
que sur des échantillons texturés du premier au second test. Ces derniers sont également
plutôt du même avis en ce qui concerne les échantillons de textures en niveaux
de gris. Les couleurs sombres et saturées entraînent par contre un désaccord entre les
81Chapitre 3. Reconnaissance des émotions dans la littérature
sujets. Ceci s’est surtout constaté au niveau des échelles Chaud-Froid et Dur-Doux.
Les auteurs ont conclu de leurs travaux que lorsque des échantillons texturés étaient
utilisés dans l’étude de l’émotion liée à une couleur, la texture joue un rôle très
important. Ils ont par exemple montré que l’échelle Dur-Doux était complètement
dominée par la composante texture. Les autres échelles seraient dominées par les
paramètres de couleur, mais la texture diminue le poids de la balance, notamment
sur les échelles Masculin-Féminin, Lourd-Léger et Chaud-Froid.
Harmonie de couleurs Un autre concept lié au problème de l’émotion d’une
couleur est celui de l’harmonie de couleurs. En effet, les combinaisons de couleurs
harmonieuses sont celles qui génèrent un effet plaisant lorsqu’elles sont vues dans
un voisinage donné.
Ou et Luo [Ou 06] ont étudié l’harmonie dans les combinaisons de deux couleurs
afin de développer un modèle quantitatif pour la prédiction. Durant des expérimentations
psychophysiques, les observateurs ont annoté des paires de couleurs. À partir
de ces résultats, les auteurs ont développé un modèle composé de trois facteurs indépendants
d’harmonie : l’effet chromatique HC, l’effet de la clarté HL et l’effet de
la teinte HH. Ces trois facteurs sont combinés pour former un modèle d’harmonie de
deux couleurs noté CH définissant l’harmonie de l’ensemble. L’écriture de ce modèle
est donnée par l’équation (3.5) :
CH = HC + HL + HH. (3.5)
Soient deux couleurs C1 et C2 représentées dans l’espace CIELAB par (L
∗
1
, a∗
1
, b∗
1
) et
(L
∗
2
, a∗
2
, b∗
2
) ; HC, HL et HH sont définis par les équations(3.6)-(3.8).
HC = 0.04 + 0.53 tanh (0.8 − 0.045∆C) (3.6)
∆C =
"
(∆H
∗
ab)
2 +
(∆C
∗
ab)
1.46
2
# 1
2
∆H
∗
ab = |H
∗
ab1 − H
∗
ab2
|
∆C
∗
ab = |C
∗
ab1 − C
∗
ab2
|
HL = HLsum + H∆L (3.7)
HLsum = 0.28 + 0.54 tanh (−3.88 + 0.029Lsum)
Lsum = L
∗
1 + L
∗
2
H∆L = 0.14 + 0.15 tanh (−2 + 0.2∆L)
∆L = |L
∗
1 − L
∗
2
|
HH = HSY 1 + HSY 2
(3.8)
HSY = EC(HS + EY )
EC = 0.5 + 0.5 tanh (−2 + 0.5C
∗
ab)
HS = −0.08 − 0.14 sin(hab + 50˚) − 0.07 sin(2hab + 90˚)
EY =
0.22L
∗ − 12.8
10
exp (
90˚− hab
10
− exp (
90˚− hab
10 ))
Selon les auteurs, le modèle proposé montre un rendement satisfaisant pour la pré-
diction de l’harmonie des combinaisons de deux couleurs.
82Chapitre 3. Reconnaissance des émotions dans la littérature
Dans une extension de ces travaux à la combinaison de trois couleurs, en 2011 Ou
et al. [Ou 11] vérifient l’hypothèse selon laquelle chaque paire de couleurs contribuerait
de façon additive dans l’harmonie totale d’un ensemble de trois couleurs. Les
résultats obtenus confirment que l’approche de l’additivité peut être utilisée comme
un outil simple mais robuste pour prédire le score de l’harmonie d’une combinaison
de trois couleurs. Ils en ont conclu que la même approche pouvait être utilisée
pour une combinaison de plus de trois couleurs. Solli et al. [Solli 09] arrivent aux
mêmes conclusions dans leurs travaux sur l’harmonie d’une image multi-colorée.
Selon les auteurs, l’harmonie d’une image couleur peut être estimée à partir de l’ensemble
des harmonies de toutes les paires de couleurs possibles qui la composent.
Les combinaisons de couleurs non harmonieuses prennent cependant le pas sur celles
harmonieuses. Cela signifie alors que si une image contient à la fois des combinaisons
de deux couleurs harmonieuses et non harmonieuses, le score de combinaisons non
harmonieuses est très important dans l’harmonie globale perçue.
Outre l’évaluation des émotions en fonction de la couleur ou de l’harmonie, dans
la littérature, la reconnaissance des émotions est également traitée comme une tâche
de reconnaissance d’images. L’idée sous-jacente est d’utiliser les techniques traditionnelles
de reconnaissance d’image pour aborder la reconnaissance de l’émotion. On
va alors extraire des caractéristiques de l’image et les utiliser pour trouver l’impact
émotionnel.
3.4 Reconnaissance de l’impact émotionnel traitée
comme une tâche de reconnaissance d’image
dans la littérature
Pour considérer la reconnaissance des émotions comme une tâche de reconnaissance
d’image, il faut dans un premier disposer de bases annotées. Ces dernières
permettent d’évaluer les différentes propositions de la littérature. Le taux de réussite
du système est alors donné par rapport à la vérité terrain.
3.4.1 Bases d’images de la littérature
Différentes bases d’images ont été utilisées dans la littérature pour l’étude des
émotions [Yanulevskaya 08, Machajdik 10, Solli 10]. Ces dernières sont généralement
différentes par leur contenu qui varie des images abstraites aux photographies voire
à des montages de scènes particuliers. Nous ne nous focaliserons que sur trois bases
qui sont disponibles en téléchargement :
– Les deux bases proposées par Machajdik et Hanbury [Machajdik 10] ;
– La base IAPS (International Affective Picture System) [Lang 08].
83Chapitre 3. Reconnaissance des émotions dans la littérature
Les deux bases proposées par Machajdik et Hanbury
Machajdik et Hanbury [Machajdik 10] ont publié deux bases d’images 1
: une
base d’images abstraites et une base de photographies. Ils ont choisi une modélisation
discrète des émotions en optant pour la catégorisation proposée par Mikels
et al. [Mikels 05]. Ce modèle comporte l’amusement, l’excitation, la satisfaction et
l’émerveillement comme émotions positives et la colère, le dégoût, la peur et la tristesse
pour représenter les émotions négatives.
(a) (b) (c)
(d) (e) (f)
Figure 3.3: Illustration des bases d’images de Machajdik et Hanbury. Les images 3.3(a)-
3.3(c) sont issues de la base d’images abstraites et les autres de celles des photographies.
La base d’images abstraites proposée par les auteurs contient 280 images issues de la
combinaison de couleurs et de textures, sans aucun objet reconnaissable. Les images
3.3(a)-3.3(c) illustrent cette première base d’images. Pour obtenir une vérité terrain,
les images ont été annotées dans un sondage en ligne où les participants pouvaient
choisir la meilleure catégorie émotionnelle pour chacune des 20 images composant
une session. 230 participants ont évalué cet ensemble d’images et chaque image a été
annotée en moyenne 14 fois. Pour chaque image, l’émotion retenue est celle ayant
obtenue un maximum de votes. Les images pour lesquelles les votes des participants
sont peu concluants ont été supprimées induisant alors 228 images correctement annotées.
L’ensemble des photos artistiques, illustré par les images 3.3(d)-3.3(f), provient d’un
site de partage de photographies artistiques 2
. Ces images ont été prises par des personnes
désireuses d’évoquer une certaine émotion par une manipulation consciente
1. Elles sont téléchargeables sur le site http://www.imageemotion.org.
2. www.deviantart.com
84Chapitre 3. Reconnaissance des émotions dans la littérature
du contenu de l’image, de la luminosité, des couleurs, . . . Cette base de données
leur permet de déterminer si l’utilisation consciente de couleurs et de textures par
les artistes améliore la classification. Pour ces images, l’émotion est déterminée par
l’artiste qui met sa photographie en ligne.
IAPS (International Affective Picture System)
C’est une base d’images composée de photographies pour la recherche sur les
émotions. Elle a été conçue depuis la fin des années 1980 par le CSEA (Center
for the Study of Emotion & Attention) de l’Université de Floride. Les images de
cette base ont été évaluées selon des échelles affectives : le plaisir, l’excitation et la
domination. Ceci correspond à une représentation tridimensionnelle des émotions.
La base contient plus de 1000 images 3
et chacune d’elles a été évaluée par environ
100 personnes. Les valeurs affectives de ces images ont été obtenues suite à 18 études
séparées d’environ 60 images chacune. Pendant les évaluations, l’image était affichée
pendant 6 secondes. Les participants adultes disposaient ensuite de 15 secondes (20
secondes pour les enfants) pour donner des scores à chacune des trois dimensions
émotionnelles. La notation s’est fait à l’aide d’un système graphique : SAM (Self
Assessment Mannequin) illustré par la Figure 3.4. Ce dernier classe :
– De "souriant/heureux" à "fronçant les sourcils/malheureux" pour la dimension
de la valence ;
– De "excité/les yeux grand ouverts" à "détendu/endormi" pour la dimension de
l’éveil ;
– D’une grande figurine (tout en contrôle) à une petite figurine (dominé) pour
la dimension de la dominance.
Figure 3.4: SAM utilisé durant les évaluations de IAPS. La première ligne de figurines
correspond à la valence, la ligne du milieu à l’éveil et la dernière la dominance.
Les participants avaient le choix d’utiliser les états des 5 figurines ou de sélectionner
un état entre deux figurines. Chaque dimension est ainsi décrite par une échelle de
3. Celle que nous avons reçue comporte 1182 images exactement.
85Chapitre 3. Reconnaissance des émotions dans la littérature
9 valeurs.
Outre les évaluations sur la base d’une modélisation dimensionnelle ; la base IAPS a
été annotée selon un modèle discret dans la littérature [Davis 95, Mikels 05]. Nous
n’aborderons que les évaluations de Mikels at al. [Mikels 05] puisque le nombre
d’images annotées est le plus important ; 490 images dont 203 négatives et 187. Le
caractère négatif ou positif d’une image a été déterminé en fonction des valeurs des
dimensions de valence et d’éveil. Les dimensions ayant un score de 1 à 9, sur l’axe du
plaisir par exemple, 1 correspond à une émotion négative et 9 positive. Le modèle
discret utilisé est le même que celui repris par Machajdik et Hanbury [Machajdik 10]
que nous avons évoqué précédemment. Deux études ont été conduites séparément ;
une pour les images positives et une autre pour les images négatives. Durant chaque
étude, 60 étudiants (30 hommes et 30 femmes) ont participé aux évaluations en
échange de crédits de cours. Ils pouvaient indiquer plusieurs labels émotionnels pour
une même image. Il faut noter que les participants à chacune des deux études sont
différents 4
. Dans chacune des deux études, l’ensemble des images a été divisé en
deux sous-groupes aléatoires. Les observateurs ont été répartis en groupe de 4 à 15
et l’ordre des sous-groupes d’images a été contrebalancé pour les différents groupes
de participants.
Les trois bases d’images que nous avons présentées ont été évaluées par des solutions
de reconnaissance d’images par l’émotion. IAPS est beaucoup plus souvent
utilisée puisqu’elle sert en quelque sorte de consensus d’évaluation des solutions computationnelles.
Elle tire cet avantage de ses différentes évaluations (dimensionnelle,
discrète).
3.4.2 Systèmes de reconnaissance d’images basée émotion
Tous les systèmes que nous évoquerons dans cette partie ont en commun leur
utilisation d’au moins une technique de reconnaissance d’images. La plupart d’entre
eux utilisent les caractéristiques bas-niveau de l’image soit pour construire une information
haut-niveau relative aux émotions soit pour les utiliser avec un système
de classification.
Reconnaissance d’émotions basée sur la détection de visages
La première famille des solutions que nous aborderons est assez particulière et restrictive.
Il s’agit des solutions utilisant la détection de visages. Une émotion est alors
associée à des traits du visage (sourcils, lèvres entre autres). De nombreux travaux
portent ainsi sur le décodage de l’expression faciale émotionnelle ; ceux de Tomkims
[Tomkims 62] en 1962, Scherer et Ekman [Scherer 84] en 1984 ou encore plus récemment
ceux de Ekman en 1992 [Ekman 92]. Ce dernier est d’ailleurs le "mentor" de
la célèbre série américaine "Lie to me".
Les solutions de la littérature basées sur la détection de visages utilisent, pour la plupart,
une modélisation discrète [De Silva 97, Busso 04]. Un système apparaît comme
étant le standard pour la description des expressions faciales : il s’agit de la méthode
4. Aucun participant à l’étude 2 n’avait participé à l’étude 1.
86Chapitre 3. Reconnaissance des émotions dans la littérature
de description des mouvements du visage FACS (Facial Action Coding System), dé-
veloppée par les psychologues Paul Ekman et Wallace Friesen en 1978 [Ekman 78].
Les mouvements du visage sont décomposés en unités d’action AU (Action Unit).
FACS repose sur la description de 46 AUs identifiées par un numéro. Par exemple,
l’AU1 correspond au mouvement de lever les sourcils au niveau du nez. À partir
de combinaisons des différentes unités d’action, on définit les émotions. La joie, par
exemple, correspond à la combinaison des AUs 6 et 12.
Reconnaissance d’émotions basée sur les caractéristiques de l’image
L’autre famille de solutions dans la littérature est celle qui se base sur des caractéristiques
de l’image qu’elles soient bas-niveau ou haut-niveau construites à partir
d’une information bas-niveau, le plus souvent la couleur.
Le premier groupe de travaux que nous évoquerons ici est celui des systèmes de
reconnaissance d’images basée sur les émotions à partir de la description sémantique
des couleurs. À partir de cette information, ils associent à une image une
sémantique émotionnelle. Wang et Yu [Wang 05], à partir d’un algorithme de clustering
flou, transforment les régions couleurs en termes sémantiques. Pour ce faire,
dans un premier temps, les images sont segmentées dans l’espace couleur CIELAB.
Ensuite, les régions segmentées sont exprimées dans l’espace CIELCH (la version
cylindrique de l’espace CIELUV) [Sève 09]. L’utilisateur peut donc interroger leur
système en construisant une requête composée de différentes notions émotionnelles
sémantiques ou à partir de phrases. Toujours sur le même principe, Hong et Choi
[Hong 06] présentent un système appelé FMV (Fuzzy Membership Value) qui extrait
automatiquement une sorte d’interprétation sémantique des images couleur. Il
permet à l’utilisateur de retrouver les images à partir de concepts sémantiques hautniveau
tels que "naturel", "actif", . . . Les "concepts émotion" sont déduits de l’espace
couleur HSI. Wang et al. [Wang 06] ont, quant à eux, utilisé un espace émotionnel tridimensionnel
pour annoter les images et créer des requêtes sémantiques. Cet espace
est basé sur des expérimentations psychologiques conduites avec 12 paires de mots
émotionnels. Les trois dimensions de cet espace sont similaires à celles proposées par
Ou et al. [Ou 04a] dont les relations sont données par les équations (3.1)-(3.3). Les
caractéristiques d’images utilisées sont des histogrammes qui, combinés à un SVM
prédisent les facteurs émotionnels.
D’un autre côté, se développent des systèmes se basant essentiellement sur les
caractéristiques bas-niveau. Celles qu’on retrouve le plus souvent sont liées à la couleur,
à la texture, aux formes.
Solli et Lenz [Solli 10] ont utilisé deux vecteurs de caractéristiques psychophysiques
basées sur l’impact émotionnel de combinaisons de couleurs (histogramme d’émotions
et le sac d’émotion). Ces descripteurs sont construits à partir des facteurs
d’émotions définis par Ou et al. [Ou 04a] dont les relations sont données par les
équations (3.1)-(3.3). Les auteurs ont comparé leurs performances à un algorithme
exploitant l’histogramme RGB et deux descripteurs de caractéristiques locales qui
sont SIFT [Lowe 99] et une de ses extensions couleur proposée par van De Weijer
et Schmid [Van De Weijer 06]. Ils ont utilisé un SVM pour la classification. Ils ont
évalué les quatre descripteurs sur 2 bases d’images :
87Chapitre 3. Reconnaissance des émotions dans la littérature
– une première base construite à partir de 1.2 million d’images (de dimension
maximale 128) de Picsearch 5 qui est une société suédoise qui développe et
propose des services de recherche d’images pour les sites web ;
– une seconde base de 750 000 images commerciales gérée par la société suédoise
Matton Images 6
. Les images de cette base ont été redimensionnées comme
celle de la première base.
Leurs résultats montrent que l’histogramme d’émotions et le sac d’émotions accomplissent
mieux la tâche de classification que les caractéristiques locales.
Yanulevskaya et al. [Yanulevskaya 08] ont utilisé les statistiques locales de l’image
pour classer une partie des images de IAPS. Ils ont utilisé le sous-ensemble de IAPS
annoté de façon discrète par Mikels [Mikels 05]. Ils ont choisi les descripteurs Wiccest
[Geusebroek 06] et des filtres de Gabor [Bovik 90]. Les premiers utilisent les
statistiques de l’image pour modéliser efficacement des informations de texture. La
texture est décrite par la distribution des bords. Ainsi, un histogramme d’un filtre
gaussien dérivé est utilisé pour représenter les statistiques de bord. Les filtres de Gabor
répondent, en effet, aux motifs réguliers dans une orientation donnée et sur une
échelle de fréquence donnée. À partir de ces caractéristiques, les auteurs ont utilisé
un SVM pour la reconnaissance des émotions. Ils concluent de leurs travaux que les
émotions sont liées à des catégories spécifiques de la scène, comme des paysages ou
des insectes. L’émerveillement et le dégoût pourraient être identifiés par la distribution
des couleurs de l’image. La tristesse et les émotions positives indifférenciées
seraient liés à des textures de la scène.
Machajdik et Hanbury [Machajdik 10] ont également testé leur système sur le sousensemble
de IAPS évalué par Mikels [Mikels 05]. Ils ont utilisé des attributs de
couleur, de textures, de composition et de contenu (dont les visages humains). Ils
ont conclu, dans un premier temps, que l’occurrence et la taille des visages humains
étaient les caractéristiques déterminantes de l’amusement sur la base IAPS. Les émotions
des images de cette base seraient fortement liées à leur contenu alors que les
couleurs apparaissent plus importantes pour les images de la base de photographies.
Pour finir, nous citerons les travaux de Liu et al. [Liu 11a] dont le système combine
des caractéristiques bas-niveau et sémantiques à l’aide de la Théorie de l’Évidence
[Smets 90] sur IAPS. La classification a été faite avec un SVM. Les différentes émotions
des images de la base ont été regroupées en 4 groupes comme l’illustre la
Figure 3.5. Leurs tests montrent que les descripteurs de textures LBP (Local Binary
Pattern) [Ojala 02] et Tamura [Wu 05] sont ceux qui obtiennent les meilleures classifications.
Au moment de la combinaison des différents résultats de classification,
la fusion avec la Théorie de l’évidence donne de meilleurs résultats comparée à une
simple moyenne des classifications, la classification minimale/maximale ou encore la
fusion avec un algorithme de vote majoritaire.
5. http://www.picsearch.com/
6. http://www.matton.com
88Chapitre 3. Reconnaissance des émotions dans la littérature
Figure 3.5: Différentes classes reconstituées par Liu et al. pour l’évaluation de leur approche
sur IAPS.
Conclusions : Synthèse et critiques de l’état de l’art
La première conclusion qui peut être tirée des différentes évaluations des émotions
concerne l’aspect personnel et subjectif des émotions. Il s’agit d’un ressenti très
dépendant du vécu de l’observateur. Le challenge de mise en place d’un système de
reconnaissance des émotions est d’autant plus important que l’émotion ne dépend
pas d’une seule caractéristique de l’image. Une émotion peut être liée à la texture
comme l’ont montré Lucassen et al. [Lucassen 10]. Dans les travaux de Machajdik et
Hanbury [Machajdik 10], les couleurs sont très déterminantes pour la reconnaissance
des émotions des images abstraites. Ce résultat est tout à fait logique puisque ce
sont les informations prépondérantes de ces images. Un système de reconnaissance
d’émotions ne peut pas être universel. Les émotions sont certes liées aux couleurs
mais dépendent aussi des cultures, du genre. Ceci induit la nécessité d’une vérité
terrain la plus hétérogène possible.
Le plus gros problème rencontré dans l’extraction de l’impact émotionnel d’une
image est celui du manque d’harmonisation du choix du modèle émotionnel. La
question récurrente est celle de la définition du modèle idéal. La modélisation discrète
est largement utilisée. Cette dernière a pour principal inconvénient d’être basée sur
des expressions faciales rendant parfois l’évaluation des images fastidieuse. D’un
autre côté, elle est plus accessible à un grand nombre de personnes. Chaque auteur
travaille donc sur le modèle qui lui convient le mieux en fonction de ses aspirations.
Outre la modélisation de l’émotion, il faut citer l’absence de base de tests universelle
même si IAPS fait désormais figure de compromis.
Face à cette littérature hétéroclite sur les bases d’images et leur évaluation, nous
proposons dans la Section 4.1 du chapitre suivant, un ensemble de critères pour
décrire les bases d’images. Cet ensemble de critères permet également de comparer
les bases et d’en faciliter le choix. Nous avons comparé les trois bases présentées dans
ce chapitre et, à partir de leurs insuffisances dans le cadre de nos travaux, nous avons
construit une nouvelle base. IAPS aurait pu répondre à nos attentes en matière de
qualité d’évaluation si elle n’était pas aussi restrictive. En effet, nous avons décidé
dans nos travaux d’inclure la saillance visuelle dans les évaluations, afin d’en étudier
89Chapitre 3. Reconnaissance des émotions dans la littérature
l’impact. Ceci n’aurait pas été possible avec les images de IAPS qui ne sont pas
publiables à grande échelle. En effet, nous avons pris le pari d’évaluer nos images en
ligne puisque Internet apparaît comme étant un média facile et gratuit pour toucher
un grand nombre de personnes. Les différentes conditions d’affichage ne posent a
priori pas de problèmes, puisque, d’après les études de Suk and Irtel [Suk 10], aucune
différence majeure n’a été notée entre les réponses émotionnelles des participants
pour une couleur en fonction de l’écran d’affichage. Nous donnerons ensuite dans les
Section 4.2 et 4.3 les détails sur notre base d’images et ses différentes évaluations.
Pour la reconnaissance de l’impact émotionnel des images, nous avons opté pour une
solution de type reconnaissance d’images par le contenu. Nous avons, comme pour
nos solutions en indexation, évalué d’abord certains descripteurs présentés dans le
Chapitre 2 pour cette tâche et ensuite inclus la saillance dans notre système pour
en étudier l’impact.
90Chapitre 4
Notre approche pour la
reconnaissance des émotions
Sommaire
4.1 Proposition d’une nouvelle taxonomie de description
des bases d’images pour l’étude des émotions . . . . . . 93
4.1.1 Critères d’évaluation des informations intrinsèques à la base 93
4.1.2 Critères d’évaluation des informations extrinsèques à la base 93
4.1.3 Critères d’évaluation de disponibilité de tests physiologiques
effectués sur la base . . . . . . . . . . . . . . . . . 94
4.1.4 Comparaison des bases de données évoquées dans le chapitre
précédent avec nos critères . . . . . . . . . . . . . . 95
4.2 Nouvelle base pour l’étude de l’impact émotionnel :
SENSE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.3 Évaluations subjectives de notre base d’images . . . . . 98
4.3.1 Évaluations SENSE1 . . . . . . . . . . . . . . . . . . . . . 100
4.3.2 Évaluations SENSE2 . . . . . . . . . . . . . . . . . . . . . 102
4.3.3 Récapitulatif de la base SENSE à partir des critères proposés105
4.4 Évaluation de descripteurs bas-niveau pour la reconnaissance
de l’impact émotionnel d’une image . . . . . . 107
4.4.1 Descripteurs globaux . . . . . . . . . . . . . . . . . . . . . 107
4.4.2 Descripteurs locaux . . . . . . . . . . . . . . . . . . . . . 109
4.4.3 Protocole expérimental . . . . . . . . . . . . . . . . . . . 110
4.4.4 Étude de l’impact du dictionnaire visuel . . . . . . . . . . 111
4.4.5 Évaluation de l’impact de la signature visuelle . . . . . . 114
4.4.6 Récapitulatif des premiers résultats . . . . . . . . . . . . . 116
4.4.7 Présentation de nos résultats . . . . . . . . . . . . . . . . 117
4.4.8 Comparaison de nos résultats avec la littérature . . . . . 120
4.5 Prise en compte de la saillance visuelle . . . . . . . . . . 121
4.5.1 Sélection dense des caractéristiques locales . . . . . . . . . 122
4.5.2 Classification des images de SENSE2 . . . . . . . . . . . . 123
4.6 Récapitulatif des différents résultats de l’évaluation des
descripteurs de recherche d’images par le contenu . . . . 125
91Chapitre 4. Notre approche pour la reconnaissance des émotions
Introduction
Dans ce chapitre, nous présenterons dans un premier temps une nouvelle taxonomie
de description des bases d’images pour l’étude des émotions. Cette nouvelle
taxonomie permet de résumer rapidement et efficacement une base. En effet, ces
bases représentent l’axe principal des recherches actuelles. Les résultats obtenus dans
l’analyse des émotions issues des images dépendent essentiellement de leur contenu
et de la qualité de leur évaluation. La proposition de critères de description a été
faite en fonction des différentes insuffisances dont souffre la littérature. Nous partageons
les mêmes constats que Machajdik et Hanbury [Machajdik 10] à propos des
bases de la littérature qui ont, entre autres, relevé les insuffisances suivantes :
– La plupart des bases d’images utilisées est inconnue (non publiée).
– Dans la majorité des cas, aucune information n’est donnée sur la manière dont
les images ont été sélectionnées. Par exemple, existerait-il un filtrage manuel
qui pourrait potentiellement entrainer un biais ?
– La description des bases est parfois incomplète ([Cho 04]).
– Les mesures d’évaluations sont souvent très peu décrites ([Yanulevskaya 08]).
– Une catégorisation arbitraire des émotions qui rend les comparaisons entre les
différents travaux laborieuses.
Outre les bases de données, les papiers concernant la mise en place d’une solution
"computationnelle" de reconnaissance des émotions souffrent aussi de plusieurs biais.
Dans la plupart des cas, les différentes stratégies de travail des auteurs rendent la
comparaison des résultats difficile voire impossible. Une solution semble émerger
comme consensus : évaluer les résultats de son système sur IAPS. Malgré cela, on
ne peut pas parler de comparaison efficace. En effet, les images utilisées pour les
ensembles d’apprentissage et de te test ne sont pas connus car exprimés en termes
de pourcentages. Certes, les résultats sont évalués sur une même base mais les différents
taux de classification ne peuvent justement être utilisés pour comparer la
performance des différentes approches. On ne pourra donc pas juger un système
plus performant qu’un autre, même sur IAPS si les images utilisées ne sont pas les
mêmes. Il n’existe pas une base d’apprentissage et une de test comme c’est le cas
dans certains challenges en indexation, sur Pascal VOC par exemple.
Si IAPS fait figure de référence dans la littérature, elle présente entre autres inconvé-
nients des termes restreints de son utilisation. Ceci nous a, en partie, conduit à créer
notre propre base d’images que nous présenterons dans une seconde partie de ce chapitre.
Il ne s’agit pas seulement d’une base d’images supplémentaire car nous l’avons
évaluée sous un angle innovant en considérant un modèle d’attention visuel. Pour
finir, nous présenterons notre solution de reconnaissance des émotions. Nous avons
considéré la tâche de reconnaissance de l’impact émotionnel des images comme une
surcouche à un système d’indexation. Cette hypothèse nous a donc conduit à n’utiliser
que des descripteurs bas-niveau robustes et efficaces en reconnaissance d’image
par le contenu. La prise en compte de la complexité de l’information "émotionnelle"
s’est faite en utilisant un classifieur. Notre objectif n’est pas de proposer le système
le plus performant possible mais surtout d’évaluer des outils de reconnaissance
d’images par le contenu pour la tâche "haut-niveau" que nous nous sommes fixée.
92Chapitre 4. Notre approche pour la reconnaissance des émotions
4.1 Proposition d’une nouvelle taxonomie de description
des bases d’images pour l’étude des
émotions
Comme nous l’avons évoqué dans le chapitre précédent, il existe de nombreuses
bases d’images pour l’étude des émotions. Ces différentes bases sont très différentes
de par leur contenu et leurs évaluations. Face à cette diversité nous proposons dans
un premier temps un ensemble de critères permettant de les décrire/comparer facilement
et rapidement. Cette nouvelle taxonomie a deux objectifs :
– Comparer efficacement les différentes bases de la littérature ;
– Résumer les différentes bases, facilitant ainsi un choix.
Les critères que nous proposons peuvent être regroupés en trois groupes informationnels
:
– Les informations intrinsèques ;
– Les informations extrinsèques ;
– Les évaluations physiologiques disponibles.
La dernière famille de critères peut paraître surprenante, mais du fait de leur complexité,
les émotions sont étudiées sous plusieurs angles dont l’axe physiologique.
Dans ce cadre plusieurs mesures physiologiques (EEG, rythme cardiaque, . . . ) sont
explorées afin d’essayer de comprendre au mieux l’impact émotionnel des images.
4.1.1 Critères d’évaluation des informations intrinsèques à
la base
Nous avons proposé trois critères intrinsèques qui nous paraissent très informatifs
et déterminants dans le choix d’une base de travail. Il s’agit :
– Du nombre d’images dans la base ;
– De l’évaluation moyenne de chaque image de la base qui informe sur le
nombre moyen d’observateurs ayant évalué une image ;
– De l’aspect "libre de droits d’utilisation" des images de la base qui permet
de savoir si la base peut être annotée à nouveau différemment et si oui quelles
en sont les conditions 1
. Ce dernier aspect est très important puisque certaines
bases d’images (IAPS par exemple) peuvent être sensibles.
Les informations intrinsèques pourraient être suffisantes dans certains cas mais
sont incomplètes pour une description détaillée.
4.1.2 Critères d’évaluation des informations extrinsèques à
la base
Les informations extrinsèques suivantes peuvent compléter la description et faciliter
la comparaison :
1. Toutes les modifications potentielles devront être faites ou évaluées dans le cadre de l’utilisation
des bases pour des travaux de recherche sans aucun but lucratif.
93Chapitre 4. Notre approche pour la reconnaissance des émotions
– La disponibilité de la base qui indique la rapidité de disponibilité de la
base d’images pour la communauté. Par exemple les deux bases de données
proposées par Machajdik et Hanburry [Machajdik 10] peuvent être directement
téléchargées alors que la mise à disponibilité de IAPS [Lang 08] nécessite une
demande ;
– La modélisation des émotions considérée lors des tests : ce critère est très
important puisque le choix d’une modélisation discrète ou dimensionnelle est
intimement lié aux objectifs des travaux ;
– L’hétérogénéité des évaluations en fonction du genre, de l’âge des participants
: ce critère est très important pour garantir une évaluation cohérente ;
– La nature de l’impact émotionnel des images : ce critère permet de savoir
si la base d’images concernée est une base suscitant de fortes émotions. C’est un
critère très important dans le cas où l’on souhaiterait organiser des nouveaux
tests sur la base d’images 2
. Si on est en présence d’une base dont les images
sont à fort impact émotionnel, il faudra veiller, pendant l’organisation des
tests, à ne pas introduire des biais d’évaluation entre les images successives 3
;
– La complexité de la tâche d’évaluation qui décrit une évaluation accessible
ou non au grand public. Par exemple, la modélisation dimensionnelle
utilisée pour IAPS par le biais du SAM semble moins facile qu’un modèle
discret, la dominance et l’éveil pouvant être difficiles à appréhender.
Les deux familles d’informations proposées ci-dessus suffiraient amplement à dé-
crire et comparer des bases d’images pour l’étude des émotions. Mais avec l’engouement
actuel pour la compréhension de nos réactions face à des contenus numériques,
on note un intérêt dans la littérature pour les tests physiologiques.
4.1.3 Critères d’évaluation de disponibilité de tests physiologiques
effectués sur la base
Les évaluations physiologiques à la présentation d’un stimuli émotionnel permettent
d’associer potentiellement une émotion (repérée par des variations physiologiques)
à une image ou à une série d’images.
Parmi les mesures physiologiques potentiellement exploitables (rythme cardiaque,
EEG, . . . ), nous nous focaliserons sur la réponse SSVEP (Steady-State Visually Evoked
Potential). Dans la littérature [Kemp 02, Keil 03], cette dernière a prouvé qu’elle
n’était pas seulement une réaction mécanique du cerveau à un stimulus de clignotement.
Selon les auteurs de ces travaux, elle serait modulée par l’attention de l’utilisateur
et l’état affectif. SSVEP est en fait un cas particulier de VEP (Visually Evoked
Potential) qui dans le contexte d’une EEG (Électro-encéphalographie) est un potentiel
électrique provoqué par la présentation d’un stimulus visuel. Ce potentiel peut
être enregistré par le cerveau et la réponse SSVEP permet de récupérer les différentes
valeurs enregistrées. Quand on désire étudier la réponse SSVEP le stimulus doit être
2. Bien évidemment en disposant des droits.
3. Il faudra dans ce cas, veiller à ce que l’impact émotionnel d’une image n’influe sur celui d’une
autre.
94Chapitre 4. Notre approche pour la reconnaissance des émotions
présenté plusieurs fois à une fréquence au moins supérieure à 3.5Hz. Le plus souvent,
on considère des valeurs supérieures à 6Hz [Kemp 02, Friman 07]. Une réponse
périodique peut être alors observée dans le signal EEG enregistré via des électrodes
placées sur le cuir chevelu, en particulier dans la région occipitale du cerveau, où ré-
side le cortex visuel. Les hypothèses de captation d’état affectif grâce aux réponses
SSVEP ont été étudiées dans la littérature [Kemp 02, Keil 03, Wang 13]. Durant
leurs évaluations, quelques images de IAPS ont été montrées à des groupes d’observateurs
pendant que leur signal EEG était enregistré. Leurs résultats montrent via
l’amplitude, la latence et de la topographie de la réponse SSVEP que cette dernière
pourrait être corrélée à l’excitation et à la valence des images montrées.
Avec ces nouveaux critères, il est désormais très facile de comparer les bases
d’images et d’avoir un aperçu intéressant à leur sujet.
4.1.4 Comparaison des bases de données évoquées dans le
chapitre précédent avec nos critères
Le Tableau 4.1 présente les résultats de comparaison des deux bases d’images de
Machajdik et al. [Machajdik 10] et IAPS [Lang 08] selon nos différents critères.
Les premières conclusions de ce tableau concernent la qualité d’évaluation des images
des bases Machajdik1 et Machajdik2. En effet, comparées à IAPS, elles souffrent
d’une évaluation insuffisante et aucune information n’est disponible sur l’hétérogé-
néité des participants. Ces deux bases restent néanmoins très intéressantes puisqu’elles
sont facilement accessibles. Elles sont téléchargeables et aucune autorisation
n’est nécessaire tant que l’on reste dans un cadre de recherche académique. Ce
qui n’est pas le cas pour IAPS qui requiert une autorisation préalable en précisant
les contours des travaux de recherche 4
. Le principal inconvénient de cet ensemble
d’images est son aspect fortement sémantique. En effet, certaines images de la base
sont manipulées, changeant complètement la sémantique de la scène. Par exemple,
si on remplace un sèche-cheveux par un pistolet dans une scène où quelqu’un se
sèche les cheveux, l’image devient dramatique. Étant donné les images aux contenus
très porteurs de sémantique et la forte puissance de l’impact émotionnel de certaines
d’entre elles, on pourrait se poser la question de l’organisation des tests. Certaines
images n’auraient-elles pas biaisées l’évaluation ? Un filtrage particulier a t-il été
fait ? Comment a été défini l’ordre des images dans les différentes séries ? Toutes
sortes d’images ont-elles été évaluées par les enfants ? Autant de questions sur les
conditions d’évaluation même si le nombre de participants permet de considérer
cette base comme étant fiable. Aucun détail n’est donné dans la description de la
base pour répondre à ces questions.
Les trois bases comparées dans le Tableau 4.1 ont un inconvénient majeur : tout
projet de modification de l’une d’entre elles doit être adressé aux auteurs. Dans les
clauses de IAPS par exemple, aucune diffusion sur Internet n’est autorisée pour que
la base ne soit pas largement connue du grand public introduisant ainsi des biais
dans les évaluations. Ce dernier point réduit énormément nos possibilités de travail
4. Dans notre cas, nous avons reçu la base environ 1 mois après notre demande.
95Chapitre 4. Notre approche pour la reconnaissance des émotions Tableau 4.1: Comparaison des bases d’images de Machajdik et al.[Machajdik 10] et IAPS [Lang 08]. Machajdik1 correspond à l’ensemble des images de peintures abstraites et Machajdik2 aux photographies. Base d’images Machajdik1 Machajdik2 IAPS Informations intrinsèques Nombre d’images 228 807
> 1000
Évaluations par image (Moyenne) 14 1
∼ 100
60
∗
Images libres de droits Oui∗∗ Oui∗∗ Oui∗∗
Informations
extrinsèques
Disponibilité de la base +++ +++ ++
Modélisation des émotions Discrète Discrète Discrète
∗
Dimensionnelle
Hétérogénéité des évaluations Non renseignée Non Oui
Nature de l’impact émotionnel
+ ++ +++
Complexité de l’évaluation ++ ++ +++
Évaluations physiologiques disponibles Aucune Aucune EEG (SSVEP)
∗ Si on considère l’évaluation faite par Mikels et al. [Mikels 05] seulement 490 images ont été évaluées (203
images négatives et 187 images positives).
∗∗ Uniquement dans le cadre de travaux de recherche académique. Il existe des clauses spécifiques à l’évaluation
des images de IAPS. Par exemple, ne pas les diffuser sur Internet pour que leur évaluation ne soit pas biaisée
par la suite. Les deux autres bases d’images sont uniquement disponibles d’après les auteurs pour un usage
scientifique.
96Chapitre 4. Notre approche pour la reconnaissance des émotions
et nous a contraint à créer notre propre base d’images. En effet, nous avons pour
objectif de tester d’autres stratégies d’évaluations des images dans le cadre de l’étude
de l’impact émotionnel. Nous souhaitons notamment introduire la saillance visuelle
dans l’évaluation des images.
4.2 Nouvelle base pour l’étude de l’impact émotionnel
: SENSE
Nous avons choisi de travailler sur des images "faiblement sémantiques". Toutes
les images ayant une sémantique, la terminologie "faiblement sémantique" semble
excessive. Il s’agit ici d’images qui ne provoquent pas d’émotions très fortes 5
. Ce
sont essentiellement des images d’environnements de la vie quotidienne qui nous
permettent de limiter l’interaction entre les émotions de chaque image lors des évaluations
subjectives. C’est un aspect très important dans la mesure où il minimise
les biais d’évaluation. Nous voulions que l’évaluation d’une image soit liée à son
contenu et non pas à celui de celle qui la précède.
Nous avons alors créé la base SENSE (Studies of Emotions on Natural image DatabaSE)
composée de 350 images libres de droit et gratuites dans sa grande majorité.
Elle comprend des paysages, des animaux, des personnages, des aliments, des bâtiments,
comme l’illustre la figure 4.1.
(a) (b) (c)
(d) (e) (f)
Figure 4.1: Quelques images de SENSE.
Aucune manipulation d’images de type remplacement d’une partie de la scène par
une autre n’a été effectuée. Les seules transformations "non naturelles" qui ont été
5. En comparaison à certaines images de IAPS.
97Chapitre 4. Notre approche pour la reconnaissance des émotions
effectuées sont des rotations et des modifications de la balance des couleurs sur
quelques images (2,29%). D’ailleurs l’image 4.1(e) est un exemple de modification
de la balance des couleurs de l’image 4.1(d). Par ailleurs, notre base de données
contient également très peu d’images avec des visages humains (4,86%). Ce dernier
point s’explique par notre volonté de limiter l’interprétation des expressions des différents
visages donnant l’impact émotionnel des images 6
.
La base SENSE a ensuite été évaluée au cours de différentes expérimentations subjectives.
4.3 Évaluations subjectives de notre base d’images
Les informations que nous avons recueillies pour quantifier l’impact émotionnel
des images étaient :
– La nature de l’émotion ;
– La puissance de l’émotion.
Figure 4.2: Application de test.
Comme on peut le voir sur la Figure 4.2 qui correspond à l’application des expérimentations
subjectives, la puissance de l’émotion variait de "Faible" à "Fort".
La nature de l’émotion quant à elle était renseignée grâce à un choix entre "Négative",
"Neutre" et "Positive". Ce choix de modélisation émotionnelle s’apparente à
un modèle dimensionnel. Il se justifie par notre souhait de décorréler l’évaluation
de l’impact émotionnel des mots traduisant les émotions basées essentiellement sur
l’expression du visage (par exemple la surprise, la joie, la colère, la tristesse). Aussi
cette modélisation nous permet d’avoir un protocole de tests facile et accessible à
6. Un image qui contient un visage triste n’a pas forcément un impact émotionnel négatif. Le
contexte pourrait être plus important que l’expression faciale.
98Chapitre 4. Notre approche pour la reconnaissance des émotions
tous les observateurs au vu des images "faiblement sémantiques" de notre base.
Nous avons organisé deux types d’évaluations de notre base d’images. Les premières
évaluation sont appelées SENSE1 et les secondes SENSE2 pour faciliter la
lecture. Ces deux évaluations ont été organisées à plusieurs mois d’intervalle. Durant
les évaluations SENSE1 qui sont illustrées par la Figure 4.2, les participants ont
jugé des images entières. Les évaluations SENSE2 justifient pleinement la création
de notre base en plus des insuffisances des trois bases évoquées dans la Section 4.1.
Nous avons intégré à nos expérimentations un modèle d’attention visuelle. Au lieu
d’évaluer les images entières, les sujets devaient annoter des "imagettes" qui correspondaient
aux parties les plus saillantes (visuellement attractives). Des exemples de
ces dernières sont donnés sur la Figure 4.3.
(a) 61% (b) 27% (c) 6%
Figure 4.3: "Imagettes" correspondant aux images 4.1(a)-4.1(c) évaluées pendant SENSE2.
La taille des images est exprimée en ratio par rapport à la taille de l’image originale.
SENSE2 a pour objectif principal d’étudier l’impact de la réduction des régions
observées par un modèle de saillance sur l’évaluation de l’impact émotionnel. Les
deux évaluations étaient disponibles sur Internet, nous permettant ainsi, d’avoir une
bonne hétérogénéité d’observateurs et surtout une évaluation moyenne par image
intéressante dans un délai relativement court 7
.
Notons quand même qu’avant de lancer les évaluations SENSE1 et SENSE2 nous
avons fait des tests préalables au laboratoire dans une salle de tests normalisée dans
les même conditions d’affichage et d’éclairage contrôlées. Vingt cinq observateurs
(28% de femmes et 72% d’hommes ; la moitié âgée de 18 à 24 ans, les autres âgés de
25 ans à plus de 50 ans) ont participé volontairement à ces expérimentations. Seulement
48 images ont été évaluées et ceci au cours de deux sessions séparées d’une
semaine. Durant chacune des sessions les participants ont jugé 24 images. Certaines
images étaient identiques mais présentées avec un traitement différent (changement
de la dynamique des couleurs ou rotation) d’une série à l’autre, voire au sein de la
même série. Les volontaires disposaient de 8 secondes pour noter chacune d’elles.
Si le temps paraît aussi court c’est tout simplement pour augmenter les chances de
7. Un taux de participation globalement satisfaisant (≥ 50 personnes par image) était atteint
au bout d’un mois.
99Chapitre 4. Notre approche pour la reconnaissance des émotions
recueillir des émotions primaires et non des émotions qui découlent d’une éventuelle
interprétation trop poussée de la sémantique du contenu de ces images. Ce temps est
également comparable à celui utilisé lors des évaluations de IAPS. L’image à évaluer
était affichée pendant 6 secondes et les participants disposaient de 15 secondes pour
les adultes, 20 pour les enfants, pour indiquer leurs émotions selon le système de
notation SAM (Self Assessment Mannequin). Ces premiers tests nous ont permis de
jauger la capacité des participants à évaluer nos images selon le protocole défini.
Certes, les premières évaluations de vérification de notre protocole de test se sont
déroulées dans des conditions d’affichage et d’éclairage contrôlées, mais ces conditions
ne sont pas indispensables pour la tâche visée. En effet, l’idée de nos travaux
est d’avoir l’impact émotionnel dans des conditions d’affichage de tous les jours 8
.
Durant SENSE1 et SENSE2 les volontaires ont évalué 24 images 9
, choisies de fa-
çon pseudo-aléatoire dans la base de 350 images/imagettes, sans temps imposé. La
consigne d’effectuer la tâche le plus rapidement possible leur a été donnée dès le
début du test ; dans le but de recueillir leurs premières émotions. Cette consigne a
bien été respectée. Par exemple, le temps d’observation moyen durant SENSE1 est
de 6.6 secondes.
Tous les résultats des tests n’ont pas été gardés. Nous avons éliminé, dans un premier
temps, les réponses que nous jugions trop rapides (<3 secondes) et trop lentes
(>8 secondes). Ces réponses ont été éliminées pour respecter les objectifs de nos
expérimentations. Nous avons ensuite fait un filtrage d’adresses IP pour éviter que
certaines personnes, tentées de repasser le test plusieurs fois, n’introduisent des biais.
Normalement la probabilité d’avoir deux séries identiques de suite est faible du fait
de la sélection pseudo-aléatoire. Pour éviter de supprimer des résultats intéressants
venant d’adresses IP identiques (cas de l’Université de Poitiers par exemple), nous
avons vérifié entre temps les adresses qui étaient retrouvées plusieurs fois.
4.3.1 Évaluations SENSE1
1741 participants dont 893 femmes soit 51.29% des sujets, ont effectué cette
expérimentation à travers le monde (28 pays différents) comme le montre la Figure
4.4(a). Notons quand même que malgré cette diversité la grande majorité habite en
France. Les aspects les plus intéressants sont la répartition quasi-similaire des sujets
en fonction de leur genre (51.29% de femmes et 48.71% d’hommes) et l’hétérogénéité
en fonction de la tranche d’âge. Comme on peut le voir sur la Figure 4.4(b), la base
a été évaluée par des personnes de tous les âges allant de moins de 15 ans à plus
de 50 ans. Nous avons quand même constaté qu’une grande partie des participants
était âgée de 15 à 30 ans (81.1%).
Notons que dans un souci de cohérence des résultats nous avons comparé ces résultats
à ceux obtenus au cours des tests dans les conditions d’affichage contrôlées. Les
résultats sont très proches confirmant ainsi que notre procédure de tests sur Internet
8. On ne pourra pas obliger un utilisateur à regarder une image ou une vidéo dans un pièce
avec un éclairage standardisé, sur un écran d’une taille définie, . . . Ce sont là des contraintes qui
ne correspondent en rien aux conditions d’utilisation des applications proposées aujourd’hui.
9. S’ils ont fait le test complet ; le test peut être arrêté à tout moment pour que les expérimentations
restent plaisantes.
100Chapitre 4. Notre approche pour la reconnaissance des émotions
est valide pour notre tâche.
Chaque image a été évaluée par 104.81 personnes en moyenne. Seulement 6% de
toute la base a été annoté par moins de 100 participants. L’image la moins annotée
a été évaluée par 86 personnes différentes.
(a) Répartition par pays de résidence (b) Répartition par âge
Figure 4.4: Illustration de l’hétérogénéité des expérimentations SENSE1.
0
10
20
30
40
50
60
70
80
90
Neg Neut Pos
Taux de classification moyen
dans chaque classe d’émotion
Figure 4.5: Résultats des évaluations SENSE1 selon les 3 classes d’émotions. Les moyennes
présentées sur ce graphiques sont accompagnées des écart-type pour chaque classe. Sur
cette figure Neg désigne les images négatives, Neut les neutres et Pos les positives.
En dépit du fait que nous avons pris le parti de travailler sur des images "faiblement
sémantiques", les participants à nos tests sont assez cohérents dans leurs évaluations.
Sur la Figure 4.5 nous avons représenté le pourcentage moyen d’observateurs qui
contribue à l’attribution de la classe d’émotion. Nous considérons qu’une image est
classée dans une des trois classes d’émotions (Négative, Neutre ou Positive) si la
différence entre les deux classes majoritaires est d’au moins 10% 10. Les participants
aux expérimentations SENSE1 sont plus unanimes à propos des images positives et
négatives que celles classées "Neutre". Ceci peut s’expliquer par la relative ambigüité
du terme neutre. On peut associer le neutre à une image parce qu’on ne ressent rien
ou parce qu’on ne sait pas comment définir ce qu’on ressent. Nous n’avons pas tous
la même définition pour ce type d’émotions, ni les mêmes ressentis d’ailleurs. Nous
10. Si une image a classé de la façon suivante : 49%, 40%, 11% respectivement Négative, Neutre,
Positive, elle sera considérée comme "Non catégorisée" puisque ((49 − 40) < 10). Les différents
pourcentages correspondent au pourcentage de personnes ayant voté pour la classe.
101Chapitre 4. Notre approche pour la reconnaissance des émotions
avons également évalué les différences entre genres sur notre base et les résultats
sont présentés dans l’Annexe C.
Malgré le nombre de participants, 61 images (17.43%) sont "non catégorisées". Nous
avons émis l’hypothèse que ceci est dû à l’interprétation sémantique de leur contenu.
Même en réduisant le temps d’observation, l’humain a toujours tendance à aller vers
une interprétation sémantique des images. Nous avons alors opté pour une autre
façon de réduire la possibilité d’interprétation sémantique : réduire la taille de l’image
observée. Nous avons mis en place cette technique en utilisant un modèle d’attention
visuelle bottom-up afin de concentrer l’évaluation sur les informations saillantes.
4.3.2 Évaluations SENSE2
Modèle d’attention visuelle utilisé pour générer les "imagettes"
Notre hypothèse lors de la mise en œuvre de ces évaluations est que d’une part la
réduction de la taille des régions observées pourrait améliorer les évaluations. D’autre
part les émotions sont basées sur les caractéristiques bas niveau (certes réinterprétées
par un processus haut niveau) qui peuvent être extraites avec un modèle de saillance.
Pour ce faire, nous avons utilisé le modèle hybride proposé par Perreira Da Silva et
al. [Perreira Da Silva 10b]. Ce dernier permet de modéliser l’évolution temporelle
du focus visuel de l’attention. C’est un modèle d’attention visuelle bottom-up qui
se base sur le modèle de Itti et al. [Itti 98] comme on peut le voir sur la Figure 4.6.
La différence entre ce modèle et celui de Itti et al. [Itti 98] se situe au niveau de la
seconde partie de l’architecture. La combinaison des différentes cartes se fait avec
une approche compétitive : le système proies/prédateurs. Les auteurs ont démontré
que c’est une manière optimale d’extraire de l’information. Selon eux, les équations
proies/prédateurs sont particulièrement adaptées à ce genre de tâche :
– Les systèmes proies/prédateurs étant dynamiques, ils incluent intrinsèquement
une évolution temporelle de leurs activités. Ainsi le focus de l’attention visuel
vu comme un prédateur peut évoluer dynamiquement ;
– Le choix d’une méthode de fusion des différentes cartes est assez difficile
sans aucun objectif. Une solution consisterait à développer une compétition
entre les différentes cartes et attendre que l’équilibre se fasse avec le système
proies/prédateurs. Cela reflètera alors la compétition entre l’émergence et l’inhibition
des éléments qui attirent ou non notre attention ;
– Les systèmes discrets peuvent certes avoir des comportements chaotiques mais
ceci peut être intéressant dans certains cas. Ils permettraient l’émergence de
chemins d’exploration de la scène visuelle d’origine, même dans les zones non
saillantes, reflétant peut être quelque chose de l’ordre de la curiosité. Les auteurs
ont d’ailleurs montré que malgré le comportement non déterministe des
équations proies/prédateurs, le système présente des propriétés intéressantes
de stabilité, de reproductibilité et de réactivité tout en permettant une exploration
rapide et efficace de la scène.
Nous avons utilisé les paramètres optimaux proposés par les auteurs pour créer les
"imagettes", obtenues à partir du rectangle englobant des régions saillantes. Leur
taille varie de 3% à 100% de la taille de l’image originale.
102Chapitre 4. Notre approche pour la reconnaissance des émotions
Figure 4.6: Architecture du modèle d’attention visuelle de Perreira Da Silva et al.
[Perreira Da Silva 10b].
Résultats des expérimentations SENSE2
1166 participants dont 624 femmes (53.49%) ont évaluée les 350 "imagettes".
Durant SENSE2 chaque "imagette" a été évaluée par 65.39 personnes en moyenne.
Seulement deux "imagettes" ont été évaluées par moins de 50 personnes. L’image la
moins évaluée était jugée par 47 personnes. Durant ces évaluations, nous avons une
nouvelle fois atteint un nombre intéressant d’observations par image. Les proportions
de participations suivant l’âge sont équivalentes à celles de SENSE1.
La première conclusion à l’analyse des résultats de SENSE2 est qu’une image de
taille trop petite n’a aucun intérêt. En effet, toutes les "imagettes" de taille infé-
rieure ou égale à 7% 11 ont été annotées "Neutre" ou sont "non catégorisées".
Si on s’intéresse dans un second temps à l’impact de la réduction de la taille des
images sur l’évaluation de l’impact émotionnel, on remarque d’après la Figure 4.7
que, pour les trois classes d’émotions 77% des images sont bien catégorisées avec
des imagettes de taille supérieure ou égale à 50%. Ce résultat implique que l’utilisation
d’un modèle de saillance bottom-up ne détruit pas l’information intéressante
pour l’évaluation sauf dans le cas d’"imagettes" trop petites. Il s’agit d’une conclusion
exploitable aussi bien pour les évaluations qui se voient améliorées que pour
les systèmes de reconnaissance des émotions à partir des caractéristiques de l’image.
11. Cette taille correspondant au ratio entre la taille de l’"imagette" et celle de l’image originale.
103Chapitre 4. Notre approche pour la reconnaissance des émotions
Figure 4.7: Taux de bonne classification au cours de SENSE2 en fonction de la taille des
régions. Les taux de bonne classification sont donnés ici en référence aux résultats de
SENSE1.
L’extraction de caractéristiques pourrait être faite plus précisément dans ces régions
saillantes.
Si on s’intéresse enfin à l’impact de la réduction de la taille de la zone observée sur
l’évaluation de l’impact émotionnel, on déduit d’après la Figure 4.8 que l’utilisation
d’un modèle d’attention visuelle est une très bonne alternative.
0
10
20
30
40
50
60
70
80
90
100
P1 P2 P3
Taux de classification
Taille des images évaluées durant SENSE2
Même classe que durant SENSE1
Catégorisée durant SENSE2
P1 : ]7%, 50%[
P2 : [50%, 70%[
P3 : [70%, 100%]
Figure 4.8: Taux de classification moyen des images durant SENSE2. "Même classe que
durant SENSE1" correspond aux images qui sont classées dans la même classe durant
SENSE1 et SENSE2. "Catégorisée durant SENSE2" correspond aux images non catégorisées
durant SENSE1 et désormais classée durant SENSE2.
En effet, en moyenne près de 80% des images sont classées de la même façon. Le
résultat le plus intéressant concerne les images "non catégorisées" durant SENSE1.
79% sont désormais classées le plus souvent dans l’une des deux classes majoritaires
104Chapitre 4. Notre approche pour la reconnaissance des émotions
de SENSE1. On peut alors conclure que cette réduction de la taille de la zone
observée réduit le temps d’analyse et permet de prendre des décisions plus probantes
dans des délais courts.
4.3.3 Récapitulatif de la base SENSE à partir des critères
proposés
Dans le Tableau 4.2 nous présentons la description de SENSE à partir des critères
que nous avons proposés.
Tableau 4.2: Description de SENSE avec les critères proposés dans la Section 4.1.
Informations
intrinsèques
Nombre d’images 350
Évaluations par image (Moyenne) ∼ 100 pour SENSE1
∼ 65 pour SENSE2
Images libres de droits Oui∗
Informations
extrinsèques
Disponibilité de la base +++
Modélisation des émotions ∼ Dimensionnelle∗∗
Hétérogénéité des évaluations Oui
Nature de l’impact émotionnel ++
Complexité de l’évaluation +
Évaluations physiologiques disponibles Aucune
∗ Uniquement pour les recherches académiques.
∗∗ Notre modélisation des émotions est équivalente à un modèle dimensionnel.
Même si le nombre d’images de notre base est 3 fois inférieur à celui de IAPS, elle
reste une base convenablement évaluée (∼ 100 évaluations par images pour SENSE1
et ∼ 65 pour SENSE2) avec une hétérogénéité des observateurs intéressante. Dans le
Tableau 4.2, nous avons indiqué qu’aucune évaluation physiologique n’est disponible.
Cependant, nous avons évalué les réponses EEG sur 12 images de notre base. Du
fait de ce nombre très faible, nous préférons ne pas les mettre à disposition. Les
évaluations se sont déroulées en trois sessions et les images ont été présentées dans
un ordre pseudo-aléatoire. Durant une session chaque image était affichée pendant
8 secondes avec un "scintillement" (flickering) à 10Hz. Ensuite une image noire était
affichée pendant 5 secondes. L’évaluation reprenait jusqu’à ce que les 12 images aient
été vues. Seulement 4 participants ont effectué volontairement nos évaluations. Le
nombre peu élevé de participants s’explique par les contraintes de ces évaluations.
Ils devaient porter un casque comme celui de la Figure 4.9. En plus du casque, on
leur appliquait sur le cuir chevelu, au niveau de l’électrode concernée, un gel pour
augmenter la conductivité au niveau du cuir chevelu.
Le signal EEG a été enregistré à l’aide de 4 électrodes positionnées sur la région
occipitale en Pz, POz, PO3 et PO4 suivant le système 10-20, proposé par Sharbrough
105Chapitre 4. Notre approche pour la reconnaissance des émotions
Figure 4.9: Exemple de casque utilisé pour récupérer le signal EEG [Cas ].
Figure 4.10: Positionnement des électrodes dans le système international 10-20 [Ele ]. Les
4 potentiels que nous avons utilisées sont entourés en rouge.
et al. [Sharbrough 91] et illustré par la Figure 4.10.
Le but de ces évaluations était d’étudier une possible relation entre les réponses
SSVEP sur une base d’images "faiblement sémantiques". En effet, la plupart des
études de la littérature sont faites sur des images plus sémantiques telles que celle
de IAPS qui provoquent des réponses émotionnelles très fortes. Nous avons conclu de
nos analyses que la réponse SSVEP obtenue au cours de nos expérimentations était
bel et bien liée au contenu de nos images. Pour plus d’informations, les résultats de
cette étude de corrélation sont présentés dans l’Annexe D.
106Chapitre 4. Notre approche pour la reconnaissance des émotions
Nous disposons désormais d’une base d’images convenablement évaluée qui nous
servira, entre autres, pour l’apprentissage du système de reconnaissance de l’impact
émotionnel des images que nous proposons. En effet, la reconnaissance de l’impact
émotionnel des images étant une tâche de haut niveau, elle nécessite l’utilisation d’un
classifieur. Les résultats de notre solution seront évalués par rapport à la littérature
par le biais de tests sur IAPS. Malgré ces évaluations, on ne peut pas effectuer des
comparaisons efficaces puisqu’aucune information n’est donnée dans la littérature
sur :
– Le détail des images de IAPS retenues ;
– Le nombre d’images utilisé pour l’apprentissage/le test.
4.4 Évaluation de descripteurs bas-niveau pour la
reconnaissance de l’impact émotionnel d’une
image
Nous avons utilisé des descripteurs locaux et globaux afin de capter un maximum
d’informations bas niveau. On peut toujours en choisir d’autres ou chercher pourquoi
l’un serait plus intéressant qu’un autre. Mais du fait de l’utilisation d’un classifieur,
on ne pourrait véritablement conclure sur la pertinence d’un descripteur par rapport
à un autre. Dans ce cas de figure, aussi bien le descripteur que le classifieur combinent
leurs apports. Bien évidemment si le descripteur n’est pas approprié, le classifieur ne
comblera pas le déficit. Notre stratégie a été, dans un premier temps, de considérer
quelques descripteurs qu’on peut qualifier d’intuitifs (couleurs par exemple). Nous
avons ensuite étudier le comportement de descripteurs très précis en indexation
classique (SIFT, GIST, . . . ).
Afin de normaliser le processus de calcul des descripteurs, nous avons opté pour
un redimensionnement des images de manière à ce que la plus grande dimension
soit égale à 256. Pour des descripteurs de textures nécessitant des images carrées,
nous avons utilisé la technique de "zero padding" afin d’obtenir des images de taille
256*256.
4.4.1 Descripteurs globaux
Les trois descripteurs globaux que nous avons retenus sont les couleurs, les textures
et le descripteur GIST.
Couleurs
Comme nous l’avons évoqué dans le chapitre précédent, les couleurs sont les premières
caractéristiques discriminantes des émotions.
Pour identifier les différentes couleurs, nous avons utilisé une segmentation couleur
par croissance de régions [Fernandez-Maloigne 04]. L’initialisation des germes s’est
faite en procédant à une analyse d’histogramme en niveaux de gris. La conversion
en niveaux de gris a été réalisée conformément au standard NTSC dont la relation
107Chapitre 4. Notre approche pour la reconnaissance des émotions
est :
NdG = 0.299R + 0.587G + 0.114B. (4.1)
L’analyse d’histogramme a été faite sur l’image en niveaux de gris afin de gagner en
temps de calcul dans la recherche des zones homogènes. Les germes considérés sont
les maxima de cet histogramme. La croissance quant à elle s’est faite dans l’espace
couleur CIELAB, par le biais de la distance ∆E, pour minimiser les problèmes
d’apparition de fausses couleurs au moment de la comparaison entre la couleur du
pixel à agglomérer et la couleur moyenne de la région croissante.
La distance ∆E entre ces deux couleurs est donnée par l’équation :
∆E =
r
(L1 − L2)
2 + (a
∗
1 − a
∗
2
)
2 + (b
∗
1 − b
∗
2
)
2
, (4.2)
avec (L1, a∗
1
, b∗
1
) et (L2, a∗
2
, b∗
2
) deux couleurs dans l’espace CIELAB à comparer.
Nous n’avons conservé que la couleur moyenne des différentes régions. Il existe plusieurs
solutions pour fixer la valeur de ∆E. Dans les standards de cet espace, une
distance de ∆E ≤ 3 indique que deux couleurs sont visuellement identiques. Nous
avons considéré un voisinage en 8-connexités et les seuils suivants :
– Différence entre un pixel à ajouter et la région déjà existante : ∆E ≤ 5 ;
– Différence inter-région pour décider de la fusion de deux couleurs : ∆E ≤ 6.
Puisque nous n’avons gardé que les couleurs moyennes des régions, à cette étape
aucune considération de la localisation de la région n’est faite.
Les différents seuils ont été déduits expérimentalement et nous permettent d’avoir
un nombre acceptable de régions et de respecter les couleurs présentes dans l’image
comme l’illustrent les images de la Figure 4.11.
(a) (b)
Figure 4.11: Illustration de la segmentation en région couleurs.
Textures
Les textures ont aussi une place importante dans le ressenti émotionnel. Une
grille par exemple, quelle que soit sa couleur, a une sémantique d’enfermement ; le
métal ne fait pas le même effet, que ce soit au toucher ou à la vue, qu’un brin
d’herbe.
108Chapitre 4. Notre approche pour la reconnaissance des émotions
La caractérisation des textures a été faite à l’aide des coefficients Wave Atoms calculés
sur les images en niveaux de gris, obtenues avec l’équation (4.1). Ils sont basés
sur la décomposition introduite par Demanet et Ying [Demanet 09].
Les Wave Atoms sont, en première approximation, une variante de paquets d’ondelettes
2D avec une longueur d’onde d’échelle parabolique. Sur la Figure 4.12, nous
avons illustré la partition spectrale des coefficients des transformées en ondelettes
et en Wave Atoms. On remarque que la transformée en ondelettes permet une dé-
composition en trois orientations : horizontale, verticale et diagonale. Le nombre
d’orientations dans le cas d’une transformée en Wave Atoms est bien plus important
et est fonction de l’échelle considérée. Ce paramètre est implicite et varie de
manière plus fine. L’intérêt des Wave Atoms réside dans leur parcimonie pour les
textures localement oscillantes. Ils ont montré leur fort pouvoir descriptif pour ce
type de textures que ce soit pour la compression [Demanet 09] ou la segmentation
[Lecellier 09].
(a) (b)
Figure 4.12: Partition spectrale des images de coefficients des transformées en ondelettes
(a) et en Wave Atoms (b) [Lecellier 09].
Nous avons considéré 5 niveaux de décomposition illustrés par la Figure 4.13. Nous
n’avons conservé que les échelles 4 et 5 qui nous offrent un compromis entre le niveau
de description et la parcimonie. L’échelle 4 est composée de 91 orientations ; chaque
orientation ayant 24 ∗ 2
4
soit 256 coefficients. L’échelle 5 quant à elle comporte 32
orientations de 1024 coefficients chacune.
4.4.2 Descripteurs locaux
Tous les descripteurs locaux que nous avons évalués ont déjà été présentés dans
la Sous-Section 1.1.2 du Chapitre 1. Nous avons choisi d’étudier le comportement
des descripteurs suivants pour une tâche de reconnaissance de l’impact émotionnel
des images :
– SIFT ;
– CSIFT ;
– OpSIFT ;
109Chapitre 4. Notre approche pour la reconnaissance des émotions
(a) Image originale (b) Décomposition sur 5 niveaux
Figure 4.13: Illustration de la décomposition en Wave Atoms sur une image synthétique.
– CM ;
– CMI.
Sur les images de SENSE1 nous avons utilisé le détecteur de Harris-Laplace. Puisque
les images de SENSE2 sont de taille variable et qu’il n’y a pas toujours de caractéristiques
locales détectées avec Harris-Laplace, nous avons procédé à la même
quantification dense que celle utilisée dans le Chapitre 2 (2.7.1).
4.4.3 Protocole expérimental
Nous avons utilisé les BoVW et les VLAD comme méthodes de représentation de
nos descripteurs à l’exception des GIST. Les VLAD ont été calculés essentiellement
sur les descripteurs locaux. Plusieurs vocabulaires visuels ont été testés. Pour les descripteurs
GIST nous avons effectué une ACP. En effet, Oliva et Torralba [Oliva 01]
préconisent d’utiliser cette solution pour réduire les dimensions des descripteurs calculés
sur des images de même taille (ce qui est notre cas). Nous avons sélectionné
ensuite un nombre K de vecteurs propres pour la projection qui nous permet de
conserver 98% de nos données
Pour la classification des émotions, nous avons choisi trois classes qui correspondent
aux différentes natures d’émotions que nous avons utilisées au cours de nos évaluations
subjectives. En ce qui concerne les images de IAPS, nous avons essayé de
reconstituer ces différentes classes d’émotions à partir des informations que nous
avons reçues avec la base d’images.
Nous avons choisi le classifieur SVM avec un noyau linéaire dans son extension multiclasses
basée sur la stratégie "Un contre Un". Le but de nos travaux n’est pas d’avoir
le système d’apprentissage le plus performant. Le choix du SVM se justifie surtout
parce qu’il se présente dans de nombreux travaux comme étant le meilleur classifieur
pour les émotions, par exemple ceux de [Liu 11a].
La liste des images avec les configurations d’ensemble d’apprentissage et de test est
donnée dans l’Annexe E.
110Chapitre 4. Notre approche pour la reconnaissance des émotions
Nous avons choisi d’évaluer l’impact de différents paramètres constituant un système
de recherche d’images par le contenu. Ainsi, nous avons étudié l’impact du choix du
dictionnaire visuel, de la signature visuelle avant de présenter nos résultats en fonction
des conclusions de ces analyses.
Dans la suite de ce document, SENSE1 désigne l’ensemble des images évaluées durant
les expérimentations SENSE1 et idem pour SENSE2.
4.4.4 Étude de l’impact du dictionnaire visuel
Au début de nos travaux, nous avons émis l’hypothèse, comme c’est souvent le
cas en recherche d’images par le contenu, qu’un dictionnaire visuel très hétérogène
nous permettrait de pouvoir représenter les différentes motifs intéressants dans le
cadre de notre tâche. Nous avons donc décider d’étudier l’impact de ce dernier sur les
résultats de classification en utilisant dans un premier temps une signature visuelle
de type "Sac de mots" (BoVW). Nous avons utilisé pour ce faire deux constructions
différentes de dictionnaire visuel :
1. La première version utilise l’algorithme K-Means (1) (une ACP dans le cas du
descripteur GIST). Nous avons défini une taille du dictionnaire visuel fonction
du nombre de descripteurs calculé sur la base d’apprentissage 12. Soit K la taille
du dictionnaire visuel ; elle est obtenue à l’aide de l’équation (4.3) :
K =
√4 N ∗ d, (4.3)
avec N le nombre total de descripteurs et d la dimensionnalité du descripteur.
Nous avons construit deux vocabulaires visuels à partir de SENSE1 et IAPS.
Les résultats seront présentés en utilisant l’écriture Base_Dictionnaire. Ainsi
SENSE1_S correspond aux images de SENSE1 dont les signatures visuelles
ont été construites à partir du dictionnaire visuel issu de SENSE1. Dans le
cas de GIST, ceci revient à définir les axes principaux à partir d’une des deux
bases.
2. La seconde configuration utilise l’algorithme IteRaSel présenté dans le Chapitre
2 (Section 2). Nous avons utilisé les vocabulaires visuels générés pour la
comparaison avec l’état de l’art sur UKB. Le dictionnaire visuel utilisé dans ce
cas est complètement indépendant des deux bases d’images SENSE et IAPS.
Mais cette dernière configuration n’a été mise en œuvre que pour les descripteurs
de caractéristiques locales CM, CMI, SIFT et OpSIFT.
Nous avons donc trois vocabulaires visuels pour les caractéristiques locales et deux
pour les descripteurs globaux. Nous étudierons leur impact dans le cadre d’une tâche
de reconnaissance des émotions. Cette étude sera faite à partir de deux critères :
– Le taux de classification moyen pour chaque descripteur ;
– La matrice de confusion pour les trois classes d’émotions.
Nous présenterons dans un premier temps les résultats de classification dans les trois
classes d’émotions : Négative, Neutre et Positive.
En analysant la Figure 4.14, on remarque de suite que tous les différents descripteurs
12. Dans ce cas, la base d’apprentissage désigne l’ensemble des images à partir desquelles le
vocabulaire visuel a été construit.
111Chapitre 4. Notre approche pour la reconnaissance des émotions
Figure 4.14: Taux de classification moyens pour SENSE1 et IAPS.
n’ont pas le même comportement en fonction des bases d’images et des dictionnaires
visuels. Certains descripteurs ont tendance à avoir un comportement stable d’une
base à l’autre et d’un dictionnaire visuel à l’autre. C’est notamment le cas de CSIFT
avec une légère amélioration du taux de classification ∼ +2% avec l’utilisation du
dictionnaire visuel obtenu à partir de IAPS. Contrairement à ce dernier, les résultats
de CM ont l’air de dépendre du dictionnaire mais aussi de la base d’images. Que
ce soit sur IAPS ou sur SENSE1, on observe des écarts de taux de classification
notamment avec le dictionnaire construit à partir de la base Pascal VOC2012 (IteRaSel).
Ces différences de taux de classification sont d’autant plus importants sur
IAPS avec un dictionnaire issu de l’algorithme IteRaSel : ∼ −30% au minimum.
La couleur affecte différemment chacune des bases. Les couleurs obtenus à partir de
SENSE1 obtiennent de meilleurs résultats que ce soit sur SENSE1 ou sur IAPS. Le
dictionnaire visuel des couleurs issu de IAPS induit une perte de ∼ −15% s’agissant
du taux de classification correcte sur SENSE1 comparé à celui construit à partir
de SENSE1. Ce résultat pourrait s’expliquer par la grande variabilité en couleurs
de notre base comparée à IAPS. Cette dernière comporte beaucoup d’images négatives
avec des couleurs sombres alors que SENSE1 c’est le contraire. Pour finir, en
ce qui concerne le descripteur Wave Atoms, les deux échelles donnent des résultats
satisfaisants (> 33% qui est le taux de classification aléatoire) notamment avec un
dictionnaire issu de IAPS sur les deux bases.
Nous avons, dans un second temps, étudié ce qui se passe au sein de chaque classe
à travers les matrices de confusion. Afin de simplifier les illustrations, seules les
diagonales, correspondant au taux de bonne classification dans chaque classe seront
représentées sur la Figure 4.15. Cette dernière permet de mieux analyser ce
112Chapitre 4. Notre approche pour la reconnaissance des émotions
(a) IAPS : les résultats de la classe "Neutre" sont mis en évidence. Les images
de cette classe sont très difficiles à reconnaître.
(b) SENSE1 : IteRaSel permet de mieux reconnaître les images neutres.
Figure 4.15: Taux de bonne classification dans chacune des classes d’émotions pour chaque
descripteur. C’est tout à fait normal qu’il n’y ait aucun taux de bonne classification indiqué
pour IteRaSel pour les descripteurs globaux : Couleurs, GIST, WA4 et WA5. Gist (98)
indique que nous avons gardé 98% des informations lors de l’ACP.
qui se passe pour chaque classe d’émotions. Les images neutres apparaissent comme
étant les plus difficiles à classer surtout sur IAPS. Aucun descripteur ne fait mieux
qu’une classification aléatoire. SIFT qui obtient les meilleurs résultats donne 30%
113Chapitre 4. Notre approche pour la reconnaissance des émotions
pour SENSE1, 25% pour IAPS et 20% pour IteRaSel.
Sur IAPS, un descripteur en particulier s’illustre comme étant le meilleur pour les
images neutres avec le dictionnaire IteRaSel : CM (95% des images neutres bien
classées sur IAPS et 57.32% sur SENSE). Ce résultat vient tout simplement du fait
que, dans cette configuration, CM classifie la majorité des images dans la classe
"Neutre" aussi bien pour SENSE1 que pour IAPS. C’est d’ailleurs ce qui explique
que ce descripteur obtienne le taux de classification le plus bas (cf. Figure 4.14) avec
le dictionnaire IteRaSel.
Que ce soit avec le dictionnaire visuel issue de SENSE1 ou IAPS, la plupart des
descripteurs ont un comportement quasi-identique pour les classes d’émotions "Né-
gative" et "Positive". Les couleurs quant à elles permettent d’identifier les émotions
positives et négatives.
Nous nous sommes intéressé de plus près à la couleur du fait de tous les travaux
dans la littérature qui lui sont consacrés. Ce descripteur qui offre un bon taux
de classification moyen (cf. Figure 4.14), ne permet pas de correctement classer les
images neutres. D’ailleurs sur IAPS, quel que soit le dictionnaire visuel, aucune
image neutre n’est classée neutre. Elles sont toutes classées négatives ou positives
comme on peut le voir dans les Tableaux 4.3 et 4.4. Ces tableaux correspondent aux
matrices de confusion des couleurs pour IAPS.
Tableau 4.3: Matrice de confusion
des couleurs IAPS_I
Neg Neut Pos
Neg 81.97% 0 18.03%
Neut 65% 0 35%
Pos 74.14% 0 25.86%
Tableau 4.4: Matrice de confusion
des couleurs IAPS_S
Neg Neut Pos
Neg 85.25% 0 14.75%
Neut 70% 0 30%
Pos 75.86% 0 24.14%
On conclut donc que ce descripteur permet surtout de classer les images négatives.
En effet, pour les deux autres classes une simple classification aléatoire (33%) serait
meilleure.
Puisque nous avons décidé d’évaluer les outils de recherche d’images par le
contenu pour la reconnaissance des émotions, l’autre facteur très déterminant dans
les résultats est la signature visuelle. Nous avons donc étudié son impact.
4.4.5 Évaluation de l’impact de la signature visuelle
Outre la représentation "Sac de mots", nous avons utilisé la signature visuelle
VLAD. Pour ce faire, nous avons choisi K=64. En effet, comme nous l’avons déjà
indiqué dans le Chapitre 1 (1.2.2), quand on utilise les VLAD on n’a besoin de très
peu de mots.
Comme lors de l’étude de l’impact du dictionnaire visuel, nous avons étudié le taux
de classification moyen mais également les matrices de confusion. Pour ces travaux
114Chapitre 4. Notre approche pour la reconnaissance des émotions
nous n’intégrons pas le dictionnaire IteRasel (qui n’a pas été utilisé pour les descripteurs
globaux du fait de l’utilisation de la saillance visuelle), ni le descripteur GIST
(qui ne peut être utilisé ni avec la signature visuelle BoVW ni avec VLAD).
Figure 4.16: Taux de classification moyens pour les bases SENSE1 et IAPS. Nous avons
mis en évidence le comportement des descripteurs globaux.
Sur la Figure 4.16, nous avons représenté les taux de classification moyen pour les
bases SENSE1 et IAPS. La première remarque concerne les descripteurs globaux : la
signature visuelle VLAD ne leur conviendrait pas tous (les couleurs faisant l’exception)
et ceci quel que soit le dictionnaire ou la base. Nous avons vérifié cette première
conclusion en étudiant les classifications au sein de chaque classe d’émotions.
Sur la Figure 4.17, nous avons mis en évidence le comportement des descripteurs
globaux pour chaque signature visuelle pour les émotions négatives et positives. On
ne note aucune différence importante. Les résultats dépendent aussi bien du descripteur,
du dictionnaire visuel que de la base d’image.
Si on considère le dictionnaire visuel construit à partir de SENSE1, la classe "Positive"
est la plus affectée par le changement de signature visuelle pour la base SENSE1.
C’est tout le contraire en ce qui concerne IAPS ; c’est plutôt la classe "Négative" qui
est affectée.
Le changement de signature visuelle affecte différemment SENSE1 et IAPS. En effet,
sur la première les descripteurs globaux modifient leur comportement avec VLAD
pour les images négatives sur IAPS et positives sur SENSE1. Ce sont des résultats
peu surprenants dans la mesure où VLAD a été proposé pour les descripteurs de
caractéristiques locales. Le fait que les bases soient affectées différemment est tout à
fait logique du fait de leur contenu. IAPS contient énormément d’images négatives
alors que pour SENSE1 c’est le contraire. Ceci implique que le taux de classification
moyen sur ces deux bases dépend énormément du taux de reconnaissance au sein de
la classe majoritaire.
115Chapitre 4. Notre approche pour la reconnaissance des émotions
(a) Signature visuelle BOW
(b) Signature visuelle VLAD
Figure 4.17: Taux de bonne classification dans chaque classe d’émotion. Nous avons mis
en évidence le comportement des descripteurs globaux pour les classes "Positive" et "Né-
gative".
4.4.6 Récapitulatif des premiers résultats
Dans un premier temps, nous avons étudié l’impact du dictionnaire visuel sur les
résultats de classification. Cette étude nous a permis de vérifier notre hypothèse de
116Chapitre 4. Notre approche pour la reconnaissance des émotions
départ concernant l’importance de l’hétérogénéité du vocabulaire dans le cadre de
notre tâche. Si on ne considère que les taux de classification moyens sur les 3 classes
d’émotions, à part quelques exceptions, les différents descripteurs ont un comportement
équivalent en fonction des dictionnaires. Les différences principales se décèlent
quand on s’intéresse à ce qui se passe au sein de chaque classe. On découvre alors que
certains dictionnaires sont plus adaptés à certaines émotions. C’est le cas du dictionnaire
IteRaSel qui est plus adapté pour les émotions neutres, ceci indépendamment
de la base d’images ou du descripteur. L’autre conclusion générale à ces premiers
travaux concerne la difficulté à identifier les émotions neutres. Il s’agit d’émotions
complexes à modéliser. On comprend alors mieux pourquoi, dans la littérature, elles
ne sont pas souvent traitées. C’est pour cette raison que, dans la suite, nous ne les
considérons plus. Seules les images positives et négatives seront traitées.
L’étude de l’impact de la signature visuelle n’a montré aucune différence importante.
Néanmoins nous avons remarqué que la signature visuelle VLAD ne convenait pas
aux descripteurs globaux (les couleurs faisant l’exception). Concrètement les descripteurs
WA4 donne dans la majorité des cas des résultats moins bons qu’un tirage
aléatoire (< 33%) avec la signature visuelle VLAD. D’une façon plus générale, les
deux bases d’images sont affectées par la modification des signatures visuelles dans
leur classe la plus représentative. Nous avons donc décidé dans la suite d’utiliser la
signature visuelle "Sac de mots visuels" pour les descripteurs globaux et VLAD pour
les descripteurs de caractéristiques locales.
4.4.7 Présentation de nos résultats
Ayant supprimé la classe "Neutre", nous avons recommencé un apprentissage sur
les classes "Positive" et "Négative". Nous présenterons d’abord les résultats de chaque
descripteur et ensuite les résultats d’une combinaison avec une stratégie "Majority
Voting". Comme nous l’avons annoncé précédemment, les descripteurs de caractéristiques
locales seront représentés avec VLAD, les couleurs et les textures avec BoVW
et GIST avec une projection après une ACP. Seuls les deux vocabulaires visuels
construits à partir de K-means sur SENSE1 et de IAPS seront utilisés ici du fait de
l’utilisation de VLAD. Nous préférons utilisés cet algorithme puisque cette signature
visuelle a été définie à partir de ce type de dictionnaire visuel. Toutes les signatures
visuelles sont normalisées L2.
Le Tableau 4.5 présente les résultats de classification pour chaque descripteur.
Comme nous l’avons déjà remarqué dans les évaluations précédentes, les différents
descripteurs n’ont pas les mêmes comportements en fonction des bases et des dictionnaires
visuels associés. Les mêmes conclusions faites sur 3 classes sont valables
pour 2 classes d’émotions. Par exemple ; SIFT donne quasiment les mêmes résultats
quelle que soit la configuration base d’images/dictionnaire visuel aussi bien pour la
reconnaissance des images positives que négatives. Les descripteurs CMI et WA4
quant à eux paraissent beaucoup plus appropriés pour la reconnaissance des images
négatives (3 configurations sur 4 ; la configuration IAPS_I est l’exception). Ces deux
descripteurs peuvent d’ailleurs être considérés comme polyvalents pour la reconnaissance
de l’impact émotionnel des images puisque dans chaque classe d’émotions ils
permettent de reconnaître au moins 50% des images, garantissant un score meilleur
117Chapitre 4. Notre approche pour la reconnaissance des émotions
Tableau 4.5: Taux moyens des classifications pour chaque descripteur. La signature visuelle
BoVW a été utilisée pour les descripteurs globaux et VLAD pour les locaux. Les résultats
en rouge correspondent à ceux qui sont moins bons qu’une classification aléatoire (< 50%).
Configuration base de test_Dictionnaire visuel
Descripteurs Classes
d’émotions SENSE1_S SENSE1_I IAPS_S IAPS_I
Moyenne
Descripteurs globaux
Couleurs
Négative 40% 70% 85.25% 78.69% 68.49%
Positive 80.21% 43.75% 27.59% 29.31% 45.22%
WA4
Négative 50% 50% 77.05% 68.85% 61.48%
Positive 30.21% 52.08% 20.69% 32.76% 33.94%
WA5
Négative 30% 60% 57.38% 44.26% 47.91%
Positive 50% 65.62% 41.38% 58.62% 53.91%
GIST
Négative 90% 40% 42.62% 62.3% 58.73%
Positive 27.08% 61.46% 56.90% 37.93% 45.84%
Descripteurs locaux
CM
Négative 10% 80% 40.98% 60.66% 47.91%
Positive 88.54% 54.17% 68.97% 51.72% 65.85%
CMI
Négative 70% 60% 60.66% 86.89% 69.39%
Positive 57.29% 58.33% 55.17% 27.59% 49.60%
Négative 70% 70% 52.46% 60.66% 63.28%
SIFT
Positive 56.25% 52.08% 51.72% 53.45% 53.38%
CSIFT
Négative 80% 90% 73.77% 67.21% 77.75%
Positive 50% 54.17% 53.45% 50% 51.91%
OpSIFT
Négative 60% 60% 65.57% 60.66% 61.56%
Positive 47.92% 52.08% 48.28% 63.79% 53.02%
Négative 55.55% 64.44% 61.75% 65.58% 61.83% Moyenne
Positive 54.16% 54.86% 47.13% 45.02% 50.29%
qu’une classification aléatoire.
Le changement de dictionnaire visuel a peu d’impact globalement sur le comportement
des descripteurs pour une classification en 2 classes. Néanmoins quelques-uns,
comme CM, sont affectés sur la base SENSE1. Le taux d’images négatives reconnues
est nettement supérieur avec le dictionnaire visuel construit à partir de IAPS
(+70% sur SENSE1 et +20% sur IAPS). En ce qui concerne les images positives on
observe l’effet inverse : -34% sur SENSE1 et -17% sur IAPS. Ceci illustre très bien
l’impact de la variabilité de la base. En effet, IAPS contient énormément d’images
négatives : le dictionnaire construit avec ses images permet de mieux reconnaître ces
dernières. Construire le dictionnaire visuel avec SENSE1 améliore la reconnaissances
des images positives puisque cette base en contient énormément.
Globalement les caractéristiques basées sur les SIFT offrent de bons taux de pré-
118Chapitre 4. Notre approche pour la reconnaissance des émotions
Tableau 4.6: Comparaison des taux de classification avant et après une fusion MV.
Avant fusion Après fusion
SENSE1_S
Négative 55.56% 60%
Positive 54.17% 57.29%
Moyenne 54.86% 57.55%
SENSE1_I
Négative 64.44% 90%
Positive 54.86% 64.58%
Moyenne 59.65% 66.98%
IAPS_S
Négative 61.75% 75.41%
Positive 47.13% 41.38%
Moyenne 54.44% 58.82%
IAPS_I
Négative 65.58% 77.05%
Positive 45.02% 46.55%
Moyenne 55.30% 62.18%
diction en utilisant un dictionnaire de seulement 64 mots et une signature visuelle
VLAD. La meilleure reconnaissance d’images négatives est faite grâce à CSIFT avec
90% des images de SENSE1 reconnue avec le dictionnaire de IAPS. Les descripteurs
globaux s’en sortent également très bien montrant ainsi une complémentarité entre
les caractérisations des images que nous avons choisies. Ceci s’illustre très bien par
les résultats de WA4 et WA5. Le premier est plus adapté pour les images négatives
alors que le second sera préféré pour les positives. On pourrait également conclure
que les images négatives sont beaucoup plus faciles à reconnaître sur les deux bases
que nous avons choisies.
La tâche de reconnaissance de l’impact émotionnel des images étant complexe, on
ne peut choisir un seul descripteur. Le contenu des bases d’images joue un rôle important
et les techniques de recherche d’images par le contenu s’adaptent très bien.
Dans le Tableau 4.6, nous avons résumé le résultat de la comparaison des taux
de classification moyens avant et après la fusion avec la méthode "Majority Voting"
que nous notons MV. La classe finale de l’image correspond à celle donnée par un
maximum de classifieurs.
On constate une nette amélioration après la fusion MV. Par exemple la reconnaissance
des images négatives est impacté positivement de 15% en moyenne. D’ailleurs
les meilleurs taux de classification après la fusion sont obtenus avec le dictionnaire
construit à partir de IAPS. Cette conclusion est également valable pour les images
positives de notre base. Avant la fusion, 54.86% des images positives étaient reconnues
contre 64.58% après. Notons que la fusion ne change pas les résultats de
reconnaissance des images positives de IAPS qui sont en moyenne moins bons qu’une
classification aléatoire.
Si on considère plus généralement ces résultats après fusion, on remarque qu’ils sont
119Chapitre 4. Notre approche pour la reconnaissance des émotions
améliorés surtout en ce qui concerne notre base d’images et ceci indépendamment
des dictionnaires visuels et des émotions :
– ∼ +15% pour les images négatives et ∼ +6% sur les positives ;
– ∼ +17% avec le dictionnaire visuel de IAPS et ∼ +3.7% avec le dictionnaire
visuel de SENSE1.
Les premières analyses de nos travaux sur la reconnaissance de l’impact émotionnel
des images à partir des techniques "traditionnelles" de recherche d’images par le
contenu montre que :
– Les différents descripteurs que nous avons choisis remplissent bien leur rôle.
Certes les taux de classification ne sont pas comparables à ceux obtenus en
CBIR mais nous avons remarqué un comportement relativement stable d’une
configuration de dictionnaire visuelle à une autre, ; à l’exception du descripteur
CM pour les émotions négatives. L’étude de l’impact de la signature visuelle
a montré que les descripteurs locaux représentés avec VLAD donnaient de
meilleurs résultats comparés à BoVW ;
– Les descripteurs locaux et globaux sont complémentaires et nous ne pourrions
conclure facilement à un descripteur idéal pour la tâche de reconnaissance
des émotions. SIFT et ses extensions couleur offrent ici encore des résultats
intéressants et pourraient à la rigueur si on devrait faire un choix, être ceux que
nous retiendront. Comme nous l’avons remarqué dans nos travaux en recherche
d’images par le contenu sur UKB dans la partie précédente, le descripteur CMI
est encore un compromis intéressant. Une fois encore il se classe vraiment bien
malgré sa dimensionnalité derrière SIFT et ses extensions en couleur ;
– La fusion que nous proposons même basique permet d’améliorer considérablement
les résultats notamment sur notre base et les images négatives. Nos
travaux sur IAPS et SENSE1 montrent que ces dernières sont les images les
mieux reconnues avec les descripteurs que nous avons choisis.
4.4.8 Comparaison de nos résultats avec la littérature
Cette comparaison se fera essentiellement sur IAPS puisqu’elle sert souvent d’évaluation
aux différents systèmes de la littérature. Nous avons évoqué dans la Section
4.1 que la comparaison des travaux de la littérature n’est pas toujours représentative.
En effet, les modélisations des émotions diffèrent le plus souvent rendant alors
la comparaison délicate. Nous avons choisi trois travaux de la littérature :
– Ceux de Wei et al. [Wei 08] qui utilisent une description sémantiques des
images pour la classification émotionnelle des images. Ils ont choisi une modélisation
discrète des émotions en 8 classes : "Colère", "Désespoir", "Intérêt",
"Irritation", "Joie", "Plaisir", "Fierté" et "Tristesse". Les taux de classification
qu’ils obtiennent sont compris entre 33.25% pour la classe "Plaisir" et 50.25%
pour "Joie". On ne dispose par contre d’aucune information sur la base d’images
qu’ils ont utilisée ;
– Ceux de Liu et al. [Liu 11a] qui utilisent des descripteurs de couleur, texture,
forme et un ensemble de descripteurs sémantiques basés sur les couleurs. Les
résultats qu’ils obtiennent sur IAPS sont en moyenne de 54.70% après une
fusion avec la Théorie de l’ Évidence et 52.05% avec une fusion MV. Pour leur
120Chapitre 4. Notre approche pour la reconnaissance des émotions
classification, ils ont retenu 4 classes en subdivisant le modèle dimensionnel
Valence/Éveil subdivisant en 4 quadrants ; ceux définis par l’intersection des
axes (Cf. Figure 3.5) ;
– Ceux de Machajdik et al. [Machajdik 10] dans lesquels des attributs de couleur,
textures, composition et contenu sont utilisés. Ils utilisent une catégorisation
discrète en 8 classes qui sont : l’amusement, l’excitation, la satisfaction et
l’émerveillement comme émotions positives et la colère, le dégoût, la peur et
la tristesse pour représenter les émotions négatives. Les taux de classification
moyens sont compris entre 55% et 65%. Le taux le plus bas est obtenu pour
la classe "Satisfaction" et le plus élevé pour la classe "Émerveillement". Tout
comme dans notre cas la répartition des images au sein des différentes classes
d’émotions n’est pas équitable. La plus petite classe contient 8 images et la
plus grande 63. Dans ces résultats, ils présentent les taux de classification de
leur meilleur descripteur dans chaque catégorie.
Si on compare, nos résultats à ceux obtenus dans les trois travaux ci-dessus, nous
nous situons plutôt dans la moyenne haute sur IAPS avec des résultats de 54.44%
et 55.30% avant fusion et 58.82% et 62.18% après. La méthodologie que nous avons
adoptée nous permet d’égaler les méthodologies de la littérature voire de faire mieux
s’agissant des taux de bonne classification. Notons qu’il ne s’agit là que d’un indice
et non pas d’un jugement sur les méthodes du fait de l’éclectisme des travaux dans
le domaine. Cette comparaison nous permet de valider notre approche qui si elle offrait
des résultats très en dessous de la littérature pourrait être jugée d’inappropriée.
Une fois cette validation de notre approche faite, nous avons intégré la saillance
visuelle qui s’est avérée utile dans nos évaluations subjectives. En effet, les évaluations
SENSE2 ont prouvé qu’elle pouvait permettre d’améliorer l’évaluation subjective
des images par la réduction de la taille de la zone observée. Nous avons alors
étudié l’apport de cette information dans notre approche.
4.5 Prise en compte de la saillance visuelle
Nous n’avons effectué ce travail que sur les descripteurs de caractéristiques locales.
Dans un premier temps, nous avons pondéré les différents vecteurs de descripteurs
par la saillance visuelle des points clés. Les résultats obtenus d’un point de vue taux
de classification correcte sont similaires à ceux obtenus dans le Chapitre 2. Aucune
amélioration signifiante n’a été trouvée. Nous avons alors opté pour la classification
des images de SENSE2. Pour rappel, ces images sont des vignettes représentant le
rectangle englobant les régions saillantes que nous avons évaluées. Ces dernières sont
de tailles différentes allant de 3% à 100% de la taille des images de SENSE1. Nous
avons alors opté pour une stratégie de sélection des caractéristiques locales diffé-
rentes. En effet, sur les plus petites images, le détecteur de Harris-Laplace que nous
avons utilisé précédemment ne détecte pas toujours des caractéristiques locales dans
la configuration que nous avons retenue. Nous avons alors opté pour une description
dense des images de SENSE2 en utilisant une fenêtre de taille 15*15 tous les 6
121Chapitre 4. Notre approche pour la reconnaissance des émotions
pixels. Cette étude a été faite avec le dictionnaire IteRaSel avec la signature visuelle
BoVW ; elle correspond mieux à ce dictionnaire visuel.
Pour que la comparaison des résultats de SENSE2 soit complète, nous présenterons
d’abord les résultats de l’utilisation de la quantification dense sur SENSE1 et IAPS.
4.5.1 Sélection dense des caractéristiques locales
Cette étude nous permet d’avoir un aperçu de l’impact de la sélection des caractéristiques
locales. Les résultats de cette étude sont présentés sur la Figure 4.18.
(a) Taux de classification moyens sur les 2 classes "Positive" et "Négative".
(b) Taux de classification moyens pour chacune des classes "Positive" et "Négative".
Figure 4.18: Résultats de l’étude de l’impact de la sélection des caractéristiques locales.
Si on analyse les résultats en considérant les taux de classification moyen sur les 2
classes d’émotions, on remarque que la sélection des caractéristiques locales de façon
dense n’améliore pas significativement les résultats. Les plus grandes différences se
notent pour le descripteur CM et sur la base SENSE1. Si on regarde de plus près ce
122Chapitre 4. Notre approche pour la reconnaissance des émotions
qui se passe dans chaque classe, on note que la classe d’émotions la plus affectée par
la modification de la sélection des caractéristiques locales est la classe dominante
de chaque base d’images. Les différences notées au niveau de la classification pour
le descripteur CM se confirme dans ces classes dominantes. D’ailleurs, nous avons
quelque part une explication du comportement de ce descripteur. Il s’agit d’un attribut
qui représente les moments couleur d’une région autour d’une caractéristique
locale. En effet, en faisant une quantification dense, on tombe sur des régions homogènes
qui peuvent se répéter très souvent sans rien apporter à la description de
l’image.
Globalement, la sélection dense des caractéristiques locales n’améliore pas vraiment
les résultats de classification. Le gain en taux de classification moyen est de +0.71%
sur SENSE1 et +1.68% sur IAPS.
4.5.2 Classification des images de SENSE2
La classification des images de SENSE2 revient à faire un filtrage des caractéristiques
locales par la saillance visuelle.
Nous présenterons également les résultats pour une classification en 3 classes pour
que l’analyse des résultats soit complète.
Figure 4.19: Taux de classification moyens obtenus sur SENSE2 et SENSE1.
Que ce soit dans le cadre d’une classification en 3 ou en 2 classes, SENSE2 donne des
résultats équivalents voire meilleurs à ceux de SENSE1 excepté pour le descripteur
CM comme on peut le voir sur la Figure 4.19. Les résultats obtenus avec ce descripteur
sont cohérents du fait des conclusions précédentes. Les résultats s’améliorent
de façon intéressante pour les descripteurs SIFT et OpSIFT ∼ +6% et +10% respectivement
pour 3 et 2 classes. Si on analyse le comportement des descripteurs en
fonction des classes d’émotions (Figure 4.20), on remarque que cette amélioration
des résultats concerne essentiellement la classe "Négative" pour SIFT et la classe
"Positive" pour OpSIFT.
L’utilisation des images de SENSE2 améliore non seulement l’évaluation de notre
bases au cours des tests subjectifs, mais en plus les émotions positives et négatives
123Chapitre 4. Notre approche pour la reconnaissance des émotions
(a) Classification suivant 3 classes.
(b) Classification suivant 2 classes.
Figure 4.20: Taux de classification moyens pour les descripteurs locaux obtenus sur
SENSE2 et SENSE1.
sont mieux reconnues avec notre système. SIFT et OpSIFT sont les meilleurs suivis
par CMI. Les images neutres restent toujours aussi complexes à reconnaître.
Tout comme pendant l’évaluation, nous pouvons alors conclure que l’utilisation de
la saillance visuelle, telle que nous l’avons présentée ici permet d’améliorer les résultats
en augmentant le nombre d’images négatives et positives reconnues.
Ces résultats sont d’autant plus intéressants qu’ils donnent des résultats satisfaisants
et augurent de perspectives intéressantes. Notre hypothèse de départ de travailler
sur une partie de l’image en espérant avoir des résultats intéressants se vérifie. Le
filtrage par la saillance visuelle est donc une très bonne alternative de sélection dans
notre approche de la reconnaissance de l’impact émotionnel des images.
124Chapitre 4. Notre approche pour la reconnaissance des émotions
4.6 Récapitulatif des différents résultats de l’évaluation
des descripteurs de recherche d’images
par le contenu
Les travaux dont nous avons présenté les résultats s’articulent autour des deux
bases d’images SENSE1 et SENSE2. Nous avons utilisé l’architecture d’un système
de recherche d’images par le contenu que nous avons évaluée pour la reconnaissance
de l’impact émotionnel des images illustré par la Figure 4.21.
Figure 4.21: Résumé de l’approche que nous avons utilisée pour la reconnaissance de l’impact
émotionnel des images.
Comme pour une recherche d’images par le contenu, plusieurs étapes du processus
peuvent modifier les résultats. Il s’agit notamment de la construction du dictionnaire
visuel et du choix de la signature visuelle. Nous avons étudié l’impact de ces deux
paramètres en utilisant 3 dictionnaires visuels différents et deux signatures visuelles.
Le changement de dictionnaire visuel n’a pas montré d’impact considérable sur les
résultats de classification. Les trois dictionnaires que nous avons utilisés sont issus
des bases SENSE, IAPS et Pascal VOC2012. En ce qui concerne ce dernier, nous
l’avons construit avec la méthode IteRaSel présentée dans le Chapitre 2. Cette étude
nous a permis de vérifier notre hypothèse de départ concernant l’importance de l’hé-
térogénéité du vocabulaire dans le cadre de notre tâche. Si on ne considère que les
taux de classification moyens sur les 3 classes d’émotions, à part quelques exceptions,
les descripteurs que nous avons choisis ont un comportement équivalent. Les diffé-
rences principales se situent au sein de chaque classe. Nous avons alors découvert
que certains dictionnaires sont plus adaptés pour certaines émotions. C’est le cas du
dictionnaire IteRaSel qui est plus adapté pour les émotions neutres quelle que soit
la base d’images et le descripteur.
La modification de la signature visuelle, quant à elle, nous a permis de pouvoir choisir
un type de signature visuelle en fonction de la nature du descripteur. Nous avons
en effet conclu de nos analyses que la signature visuelle VLAD ne convenait pas aux
125Chapitre 4. Notre approche pour la reconnaissance des émotions
descripteurs globaux et ceci quel que soit le dictionnaire ou la base. Cette constatation
nous a permis de justifier nos choix de signatures visuelles pour la comparaison
de nos résultats aux travaux de la littérature. Nous avons également exclu par la
suite la classe "Neutre" du fait de sa complexité de reconnaissance.
Nos résultats sont très encourageants et dans certaines configurations meilleurs que
ceux de la littérature en matière de taux de reconnaissance. Ils montrent que les descripteurs
locaux et globaux sont complémentaires pour la reconnaissance de l’impact
émotionnel. Néanmoins le choix du descripteur le plus efficace ou le mieux indiqué
reste délicat. SIFT et ses extensions couleur offrent des résultats intéressants et pourraient
être préconisés. Le descripteur CMI est encore un compromis intéressant. Une
fois encore, il se classe vraiment bien, malgré sa dimensionnalité, derrière SIFT et
ses extensions couleur comme ce fût déjà le cas pour la recherche d’images par le
contenu dans le Chapitre 2. Nous avons proposé d’utiliser une combinaison des ré-
sultats des différentes descripteurs à l’aide de la méthode "Majority Voting". Cette
fusion permet d’améliorer considérablement les résultats notamment sur notre base.
Les images négatives sont également mieux reconnues sur les deux bases d’images.
La comparaison avec les résultats de la littérature que nous avons faite n’est aucunement
qualitative puisque les approches sont différentes. Elle permet d’avoir une
idée des taux de classification de la littérature pour valider notre approche. La mé-
thodologie que nous avons adoptée égale les résultats de la littérature s’agissant des
taux de bonne classification. Nous nous situons plutôt dans la moyenne haute sur
IAPS avec des résultats de 54.44% et 55.30% avant fusion et 58.82% et 62.18% après
respectivement pour les images négatives et positives.
Pour finir, nous avons étudié l’hypothèse que la réduction des images par la saillance
visuelle pourrait également être intéressante pour la classification. Nous avons en
effet noté une amélioration des résultats pour les classes "Négative" et "Positive".
Cette amélioration est conséquente pour les descripteurs SIFT et OpSIFT ; ∼ +6%
et ∼ +10% respectivement pour 3 et 2 classes. Ces résultats combinés aux pré-
cédents, nous permettent de pouvoir préconiser l’utilisation de SIFT et OpSIFT
comme descripteurs de caractéristiques locales pour la reconnaissance de l’impact
émotionnel des images. Il s’agit là des deux meilleurs descripteurs si on considère
toutes nos expérimentations.
Conclusions
Dans nos travaux, nous avons pris le parti de considérer la tâche de reconnaissance
de l’impact émotionnel des images comme une tâche de recherche d’images par
le contenu. Ici le contenu est une information haut niveau, fortement sémantique et
influencée par le vécu de chacun. Cette dernière ne pourra pas être uniquement
quantifiée avec des descripteurs bas niveau ou résumée par un ensemble fini et précis
d’informations bas niveau. C’est ces deux derniers points qui rendent la tâche encore
plus difficile surtout que la plupart des études faites dans le domaine sont très
hétérogènes, dépendant de plusieurs critères dont les deux plus importants sont la
base d’images et les descripteurs. Le premier point a été le plus handicapant dès le
début de nos travaux. En effet, il n’existe aucun répertoire des différentes bases et on
126Chapitre 4. Notre approche pour la reconnaissance des émotions
découvre le plus souvent au fil de la littérature les différentes évaluations disponibles.
Nous avons alors proposé une nouvelle taxonomie afin de faciliter la comparaison et
par la même occasion une description résumée de ces dernières.
Chacune des bases de la littérature a ses contraintes qui peuvent être plus ou moins
un frein. Nous nous sommes intéressés à trois bases en particulier de la littérature :
les deux bases de Machajdik et al. [Machajdik 10] et IAPS [Lang 08]. Les deux premières
parce que leurs auteurs furent les premiers à répertorier quelques insuffisances
de la littérature et la dernière qui fait office de consensus pour évaluer ses résultats.
Chacune souffre de différentes lacunes ; des défauts d’évaluation aux restrictions de
distribution en passant par le contenu. Au vu de nos motivations d’évaluation, il
nous paraissait indispensable de créer une nouvelle base et surtout de l’évaluer de
façon convenable. La base SENSE que nous avons construite comporte 350 images
évaluées de deux façons différentes : une évaluation classique et une évaluation en ré-
duisant la taille des régions observées à partir de la saillance visuelle. Pour ces deux
expérimentations subjectives, plus de 60 évaluations par images en moyenne avec
une hétérogénéité des participants nous permettent de proposer une base d’images
bien annotée à la communauté. L’utilisation de la saillance visuelle lors des évaluations
dans nos tests a permis de réduire le nombre d’images non catégorisées.
L’ambiguïté à été levée pour 79% des images concernées au cours des tests SENSE1.
Ces évaluations nous ont servi de vérité terrain en plus de IAPS pour tester notre
approche pour la reconnaissance de l’impact émotionnel des images.
Nous avons choisi d’utiliser un schéma de recherche d’images par le contenu couplé
à un système d’apprentissage pour la reconnaissance des émotions. Les descripteurs
que nous avons retenus sont traditionnellement utilisés en CBIR et font preuve d’une
précision intéressante. Nous avons alors émis et vérifié l’hypothèse que ces descripteurs
bas niveau encoderaient également des informations intéressantes pour la tâche
de haut niveau qui nous intéresse. Les deux signatures visuelles que nous avons retenues
sont : BoVW et VLAD. Toutes les deux nécessitent la construction d’un
dictionnaire traditionnellement issu d’un clustering K-means. Nous avons justement
testé l’influence de ce dictionnaire en modifiant à la fois la base d’images mais également
la technique de construction du dictionnaire. Nous avons utilisé la signature
visuelle BoVW pour cette première étude et aucune modification conséquente n’a été
notée. Néanmoins, nous avons remarqué que le dictionnaire IteRaSel se distinguait
pour les images neutres, celles là même qui sont les plus complexes à reconnaître.
Le choix de la signature visuelle affecte quant à lui différemment les descripteurs
locaux et globaux. Ainsi nous avons remarqué que VLAD correspondait mieux aux
descripteurs locaux et BoVW aux globaux. C’est donc cette configuration que nous
avons retenue au moment de comparer nos travaux à ceux de la littérature.
Les résultats de cette comparaison montrent que l’approche que nous avons retenue,
illustrée par la Figure 4.21, semble convenir pour la tâche de reconnaissance de l’impact
émotionnel. Nos taux de classification se situent dans la moyenne haute de la
littérature. Les descripteurs de recherche d’images par le contenu peuvent donc être
utilisés pour la reconnaissance de l’impact émotionnel. Au cours de nos différentes
expérimentations, les résultats montrent une certaine complémentarité en fonction
des classes d’émotions. La méthode basique "Majority Voting" que nous avons utilisée
montre une performance intéressante sur les bases IAPS et SENSE1 notamment
127Chapitre 4. Notre approche pour la reconnaissance des émotions
pour la reconnaissance des images négatives (∼ +15%).
Dans la dernière partie de ce chapitre nous avons utilisé les images de SENSE2, mimant
ainsi une segmentation de régions d’intérêt basée sur la saillance visuelle. Nous
avons choisi des descripteurs locaux pour résumer ces régions en optant pour une sé-
lection dense des caractéristiques locales. Ce choix est principalement motivé par la
taille variable de ces régions segmentées : de 3% à 100% de la taille des images originales.
Les taux de classification moyens sont globalement étonnamment plus élevés.
Cette segmentation en régions d’intérêt grâce à la saillance visuelle semble résumer
au mieux les images simulant la réduction d’ambiguïté constatée au cours des expé-
rimentations subjectives. Le gain en taux de classification est remarquable au sein
de la classe "Négative" avec les descripteurs SIFT et OpSIFT ∼ +6% et +10%
respectivement pour 3 et 2 classes. Ces résultats augurent de bonnes perspectives
que nous aborderons dans la conclusion générale de ce document.
128Conclusion Partie 2
Dans cette dernière partie consacrée à la reconnaissance des émotions, nous nous
sommes, dans un premier temps, intéressés à l’état de l’art. L’émotion est un phénomène
très personnel qui dépend du vécu de l’observateur. La tâche de mise en place
d’un système de reconnaissance des émotions est alors d’autant plus complexe que
l’émotion ne dépend pas d’une seule caractéristique de l’image. Elle peut être liée à la
texture comme l’ont montré Lucassen et al. [Lucassen 10] ou à la nature de l’image.
Dans les travaux de Machajdik et Hanbury [Machajdik 10], les couleurs sont très dé-
terminantes pour la reconnaissance des émotions des images abstraites. De plus, on
rencontre plusieurs problèmes dans la littérature du domaine. Le premier concerne le
manque d’harmonisation du choix du modèle émotionnel. La modélisation discrète,
largement utilisée est relative aux expressions faciales rendant parfois l’évaluation
des images fastidieuse. D’un autre côté, elle est plus accessible à un grand nombre de
personnes. Chaque auteur travaille donc sur le modèle qui lui convient en fonction de
ses aspirations. Le second problème est l’absence de base de tests universelle même si
IAPS fait figure de compromis pour évaluer les performances de son système. Nous
avons donc proposé dans un premier temps, un ensemble de critères pour décrire
les bases d’images qui permet également de comparer ces dernières et de faciliter le
choix.
Certaines bases de la littérature (IAPS entre autres) malgré leur évaluation consé-
quente, présentent des contraintes d’utilisation très fortes (clauses de confidentialité
rendant impossible l’organisation de nouvelles évaluations subjectives). Nous avons
alors construit une nouvelle base d’images SENSE qui a été largement évaluée : plus
de 60 annotations par images. Cette base ainsi que IAPS nous ont servi de vérité
terrain pour évaluer notre approche.
Nous avons voulu analyser l’apport de la saillance visuelle pour la reconnaissance de
l’impact émotionnel. Ainsi nous avons fait évaluer des régions d’intérêt segmentées à
partir de la saillance visuelle. Cette étude sur notre base nous a permis de conclure
que cette segmentation améliore les évaluations à condition que les régions ne soient
pas trop petites. Que ce soit avec les images ou avec les régions d’intérêt segmentées
à partir de la saillance visuelle, nos résultats de classification à partir d’outils de
recherche d’images par le contenu (BoVW, VLAD) sont très prometteurs. Comparés
la littérature, sur IAPS nous nous situons plutôt dans la moyenne haute. Ceci
témoigne alors que la méthode utilisée n’est pas inappropriée. L’architecture d’un
système de recherche d’images par le contenu peut donc très bien être utilisée pour
la reconnaissance des émotions. Les descripteurs locaux et globaux se complètent
129Conclusion Partie 2
parfaitement. La signature visuelle BoVW est suffisante mais VLAD semble plus
adaptée pour les descripteurs locaux.
130Conclusion générale et
perspectives
Conclusion
Dans cette conclusion, nous reviendrons sur les différents apports de nos travaux.
Les résultats que nous avons présentés se basent sur des outils traditionnellement
utilisés en recherche d’images par le contenu qui ont été aussi évalués tout au long
de ce manuscrit :
– Descripteurs de caractéristiques locales et globales ;
– Dictionnaire visuel ;
– Signatures visuelles BoVW et VLAD.
Nous avons proposé un algorithme de construction de dictionnaire visuel à partir
d’une sélection aléatoire de mots visuels couplée à un processus itératif. Cette solution
se montre tout aussi efficace couplée à la signature visuelle BoVW pour des
tailles de vocabulaire très petites (≤ 256) par rapport à celles de la littérature avec
K-Means (souvent ≥ 10000). Dans nos travaux le descripteur CMI qui n’est pas très
plébiscité dans la littérature égale les résultats de SIFT sur UKB.
Tout au long de ce manuscrit, l’apport de la saillance a été évalué à différentes
étapes du processus depuis la détection des caractéristiques locales jusqu’à l’évaluation
des images pour la reconnaissance des émotions.
Concernant la détection des caractéristiques locales, nous avons remarqué que très
peu de détecteurs, parmi les quatre les plus utilisés dans la littérature que nous avons
évalués, produisaient des points saillants. Ces premiers résultats nous indiquent que
l’intégration de la saillance visuelle n’est pas implicite aux détecteurs de caracté-
ristiques locales mais doit être additionnelle à cette étape. Le détecteur de Harris
est celui qui produit le plus de points clés saillants sur les quatre bases d’images
étudiées 13. Ces résultats ne remettent pas du tout en cause ceux sur la performance
du détecteur Harris-Laplace [Zhang 07]. D’ailleurs, malgré les résultats du
détecteur Harris-Laplace, les points clés les plus saillants sont très importants pour
la recherche des images. En supprimant 20% des caractéristiques locales les plus
saillantes, on perd 25% en taux de bonnes réponses sur la base UKB alors que les
résultats sont quasiment identiques quand on supprime 20% des caractéristiques les
13. Pour rappel, 2 de ces bases sont utilisées en recherche d’images par le contenu et les 2 autres
en évaluation de la saillance visuelle
131Conclusion générale et perspectives
moins saillantes. Ces premiers résultats sur la saillance et le filtrage des points clés
en recherche d’image par le contenu montrent tout l’intérêt d’utiliser cette information.
Ils rejoignent également les résultats de Zdziarski et al. [Zdziarski 12] qui ont
filtré les SURF en fonction de la saillance visuelle.
La saillance visuelle a aussi montré un intérêt dans les travaux sur la reconnaissance
des émotions. Pour cette tâche "haut niveau", nous avons proposé une nouvelle base
d’images SENSE, largement annotée de façon très hétérogène. La saillance visuelle
nous a permis d’améliorer l’évaluation de notre base d’images en réduisant l’interprétation
sémantique. Nos résultats montrent qu’elle est utile à condition que la
taille de la région observée ne soit pas trop petite. Ceci implique que l’objet/la scène
doit être reconnaissable. Les résultats de classification des régions d’intérêt déduites
de la saillance visuelle des images sont équivalents, voire meilleurs en fonction des
descripteurs et des classes d’émotions, aux résultats obtenus en utilisant des images
non segmentées. Cela justifie alors de la pertinence de cette information pour la
reconnaissance de l’impact émotionnel notamment pour les images négatives avec
les descripteurs SIFT et OpponentSIFT. Le gain en taux de classification d’environ
6% en témoigne. Plus généralement, les descripteurs que nous avons choisis (CM,
CMI, Couleurs, CSIFT, GIST, SIFT, OpSIFT, WA4 et WA5) se sont montrés complémentaires
pour la reconnaissance de l’impact des émotions aussi bien sur la base
SENSE que sur IAPS. Si on devait en désigner comme étant le plus adapté ou le
plus polyvalent, nous choisirons SIFT et/ou une de ses extensions couleur.
Perspectives
Nous avons étudié la saillance des détecteurs de caractéristiques locales et en
avons déduit qu’ils n’incluent pas implicitement une notion de saillance visuelle pertinente.
Ce résultat est d’autant plus logique qu’il est lié à leur construction. Nous
avons prouvé, pour le descripteur de Harris-Laplace, que les caractéristiques locales
non saillantes avaient très peu d’importance dans le résultat final. Une façon inté-
ressante d’exploiter l’attention visuelle serait donc de remplacer les caractéristiques
les moins saillantes par des pixels beaucoup plus saillants choisis de façon adéquate.
Cette perspective a été entamée et de bons résultats ont été obtenus en remplaçant
une partie des points clés les moins saillants par les caractéristiques les plus saillantes
issues de la sélection "dense". Une idée serait de pousser la réflexion en les rempla-
çant par les pixels les plus saillants de l’image, tout simplement. L’étude devrait
être menée sur tous les détecteurs et les descripteurs afin de généraliser l’impact de
la saillance sur UKB.
Nous avons montré que Harris-Laplace ne détectait pas beaucoup de caractéristiques
locales. On pourrait alors ajouter des points clés saillants en définissant un certain
pourcentage de caractéristiques à considérer par image.
Nous avons montré que la saillance visuelle peut être très utile aussi bien pour la
recherche d’images par le contenu que pour la reconnaissance de l’impact émotionnel
des images. Dans nos travaux nous avons fait le choix de modèles de saillance
"Bottom-Up". La première raison est le nombre réduit de modèles "Top-Down" disponibles.
Néanmoins une suite logique à nos travaux, notamment dans le cadre de
la reconnaissance des émotions, serait d’étudier l’impact de l’utilisation d’un modèle
132Conclusion générale et perspectives
"Top-Down".
La segmentation en régions d’intérêt saillantes que nous avons utilisée se contente
du rectangle englobant l’ensemble des zones à forte attention visuelle. Nous proposons
en perspective à ces travaux de considérer les différentes régions saillantes
indépendamment et de leur associer une émotion. L’émotion finale de l’image serait
donc le résultat d’une combinaison de celle de chacune des régions. On reprendrait
ainsi l’idée de Solli et al. [Solli 09] pour l’harmonie d’une image multi-colorée qui
dépend de la combinaison entre les combinaisons de couleurs non harmonieuses et
harmonieuses. La méthode de fusion pourrait être trouvée à partir d’évaluations subjectives
pour trouver la pondération correcte entre les "patchs" négatifs et positifs.
Pour finir on pourrait également étudier l’apport de chaque descripteur au moment
de la fusion. Peut être qu’en fonction de la base et de la classe d’émotions il faudrait
pondérer différemment les descripteurs ou n’en choisir qu’un certain nombre.
133Conclusion générale et perspectives
134AnnexesAnnexe A
Calcul des CMI
Le descripteur CMI se calcule à partir des moments couleur généralisés M d’ordre
p+q et de degré a+b+c, notés Mabc
pq .
S02 =
M2
00M0
00
(M1
00)
2
D02 =
M11
00 M00
00
M10
00 M01
00
S12 =
M2
10M0
01M1
01+M1
10M2
01M0
00+M0
10M1
01M2
00−M2
10M1
01M0
00−M1
10M0
01M2
00−M0
10M2
01M1
00
M2
00M1
00M0
00
D11 =
M10
10 M01
01 M00
00 +M01
10 M00
01 M10
00 +M00
10M10
01 M01
00 −M10
10 M00
01 M01
00 −M01
10M10
01 M00
00 −M00
10 M01
01 M10
00
M10
00 M01
00M00
00
D1
12 =
M11
10 M00
01 M10
00 +M10
10 M11
01 M00
00 +M00
10M10
01 M11
00 −M11
10 M10
01 M00
00 −M10
10M00
01 M11
00 −M00
10 M11
01 M10
00
M11
00 M10
00M00
00
D2
12 =
M11
10 M00
01 M01
00 +M01
10 M11
01 M00
00 +M00
10M01
01 M11
00 −M11
10 M01
01 M00
00 −M01
10M00
01 M11
00 −M00
10 M11
01M0100
M11
00 M01
00M00
00
D3
12 =
M02
10 M00
01 M10
00 +M10
10 M02
01 M00
00 +M00
10M10
01 M02
00 −M02
10 M10
01 M00
00 −M10
10M00
01 M02
00 −M00
10 M02
01 M10
00
M02
00 M10
00M00
00
D4
12 =
M20
10 M01
01 M00
00 +M01
10 M00
01 M20
00 +M00
10M20
01 M01
00 −M20
10 M00
01 M01
00 −M01
10M20
01 M00
00 −M00
10 M01
01 M20
00
M20
00 M01
00M00
00
Dans ces différentes équations :
– Mi
pq vaut successivement Mi00
pq , M0i0
pq , M00i
pq ;
– Mij
pq vaut successivement Mij0
pq , Mi0j
pq , M0ij
pq .
137Annexe A. Calcul des CMI
138Annexe B
Couleurs utilisées pour l’étude des
émotions de couleurs
Dans le Tableau B.1, nous avons répertorié les différentes couleurs évaluées au
cours des évaluations de Kaya et al. [Kaya 04] et dans le Tableau B.2 celles évaluées
au cours des expérimentations de Ou et al. [Ou 04a]
Tableau B.1: Différentes couleurs évaluées au cours des expérimentations de Kaya et al.
[Kaya 04].
Couleurs Codage Munsell
Rouge 5R 5/14
Jaune 7.5Y 9/10
Vert 2.5G 5/10
Bleu 10B 6/10
Violet 5P 5/10
Orange 5YR 7/12
Vert-Jaune 2.5GY 8/10
Bleu-Vert 5BG 7/8
Violet-Bleu 7.5PB 5/12
Rouge-Violet 10RP 4/12
Blanc N/9
Noir N/1
Gris N/5
Ces couleurs proviennent du système de Munsell [Munsell 05]. Dans ce système colorimétrique,
les couleurs sont décrites dans un espace tridimensionnel (Teinte, Valeur,
Chromaticité) comme l’illustre la Figure B.1.
Dans ce système de couleur :
– La teinte représente une nuance de couleur. Le système est basé sur les 5 teintes
suivantes : R pour le Rouge, Y pour le Jaune, G pour le Vert, B pour le Bleu et
P pour le Violet. À ces 5 teintes de base se rajoutent des teintes intermédiaires,
139Annexe B. Couleurs utilisées pour l’étude des émotions de couleurs
Figure B.1: Système colorimétrique de Munsell.
par exemple, YR (Jaune-Rouge) pour la couleur orange. Chacune des couleurs
est donnée en 10 nuances. Une teinte est définie par un chiffre s’étalant de 0 à
360˚.
– La valeur représente la luminosité/clarté perçue. Elle s’échelonne de 0 pour le
noir à 10 pour le blanc.
– La chromaticité représente la pureté d’une couleur basée sur la perception
visuelle. Elle commence à 0 pour le gris et n’a pas de limite supérieure.
140Annexe B. Couleurs utilisées pour l’étude des émotions de couleurs
Tableau B.2: Différentes couleurs évaluées au cours des expérimentations de Ou et al.
[Ou 04a].
Notation NCS
des couleurs
L
∗
a
∗ b
∗ C
∗ h
∗
R-1080 45.9 61.7 29.1 68.2 2
Y-61070 84.8 6.3 82.0 82.3 86
G-2060 61.4 -49.7 17.8 52.8 160
R90B-3050 49.6 -8.9 -33.2 34.4 255
R70B-3060 38.0 13.8 -42.0 44.2 288
Y60R-5040 42.2 25.9 26.5 37.0 46
G80Y-4040 58.3 -3.2 40.3 40.4 94
B50G-5040 39.3 -28.2 -5.8 28.8 192
R70B-5030 41.4 5.0 -24.3 24.8 282
R-1020 84.7 17.1 5.6 18.0 18
Y-1030 89.0 1.6 39.4 39.4 88
B30G-1040 78.4 -26.7 -10.9 28.8 202
R60B-1040 74.0 11.3 -23.7 26.3 296
G50Y-4020 64.2 -8.2 19.0 20.7 113
B50G-5030 47.1 -22.0 -5.7 22.7 195
R50B-5020 49.8 10.8 -11.9 16.1 312
N-9000 15.7 0.3 -1.5 1.6 282
N-7000 43.2 0.3 0.2 0.4 37
N-3500 72.1 0.4 0.6 0.7 58
B-0502 97.8 -2.1 0.4 2.1 168
C
∗
et h∗
sont obtenus à partir des relations de l’Equation (3.4).
141Annexe B. Couleurs utilisées pour l’étude des émotions de couleurs
142Annexe C
Influence du genre sur l’évaluation
de l’impact émotionnel des images
de la base SENSE
Introduction
L’étude des différences cognitives et comportementales entre genre est un domaine
très actif. L’objectif commun aux différents travaux est de trouver pourquoi
les hommes et les femmes ne réagissent pas de la même façon dans certaines conditions
et de modéliser ces différences.
La majorité des travaux de recherche sur les différences induites par le genre peuvent
être résumée en deux théories :
– Les théories sociales : les différences entre hommes et femmes sont socialement
construites et influencées par des facteurs tels que les rôles stéréotypes sexistes
([Fischer 04]).
– Les théories biologiques : Les différences entre genre seraient dues aux diffé-
rences biologiques ([Hofer 06]).
On peut également retrouver dans la littérature des approches qui soutiennent la
combinaison de ce ces deux théories ([Halpern 11]).
Dans ces travaux, nous ne nous sommes pas intéressés à la raison de ces différences.
Nous avons essayé de trouver les situations dans lesquelles les hommes et les femmes
n’étaient pas d’accord lors de nos évaluations. Ces travaux s’inscrivent notamment
dans l’esprit de vérifier les conclusions faites par Bradley et al [Bradley 01] lors de
l’évaluation d’images. Au cours de leurs expériences, les femmes étaient plus réactives
aux matériaux désagréables. Aussi, comparativement aux hommes, elles ont évalué
"légèrement agréables" des images notés "neutres" par ces derniers. Nous tenons à
signaler que les images utilisées par Bradley et al. sont beaucoup plus sémantiques
que celles de notre base : elles proviennent de IAPS.
143Annexe C. Influence du genre sur l’évaluation de l’impact émotionnel
des images de la base SENSE
Résultats de l’analyse des différences entre genre
au cours de nos expérimentations subjectives
Les résultats que nous présentons ici sont issus de l’analyse des expérimentations
SENSE1. Pour rappel, les observateurs devaient indiquer la nature des émotions :
"Négative", "Neutre" ou "Positive" et la puissance qui variait de "Faible" à "Fort" pour
chaque image. 1741 participants dont 893 femmes soit 51.29% des sujets, ont effectué
cette expérimentation à travers le monde (28 pays différents) avec une grande
majorité vivant en France. Le point le plus intéressant pour cette analyse concerne
la répartition quasi-similaire des sujets en fonction de leur genre (51.29% de femmes
et 48,71% d’hommes).
Tableau C.1: Nombre d’images dans chaque classe d’émotions en fonction du genre.
Nature de l’émotion Femmes Hommes
Négative 20% 14.57%
Neutre 34.43% 43.43%
Positive 43.43% 39.71%
Non catégorisées 1.14% 2.29%
Le Tableau C.1 résume la classification de notre base d’images en fonction du genre.
La première conclusion à cette classification est que globalement, les femmes trouvent
notre base d’images positive alors que les hommes la trouvent neutre. Elles ont évalué
"Négative" beaucoup d’images que les hommes ont indiqué "Neutre". On pourrait
alors conclure que les femmes attribueraient plus de "scores émotifs" ("Positive" et
"Négative") que les hommes. Ces premières conclusions sont cohérentes avec celles
de la littérature, par example ceux de [Barrett 98, Fischer 04]. Nous avons ensuite
analysé les différences de jugements entre les hommes et les femmes. Ces résultats
sont représentés sur la Figure C.1.
Sur cette Figure, les conclusions précédentes sont confirmées. La grande partie des
désaccords d’évaluation concerne les images classées "Négative" et "Positive" par les
femmes qui sont classées "Neutre" par les hommes. Ceci peut s’expliquer par la complexité
comme nous l’avons déjà évoqué des émotions neutres. Nous n’avons noté
dans nos études aucune contradiction "PositiveFemmes_NegativeHommes" même si
quelques cas de la configuration inverse existent. On pourrait alors déduire que les
images classées "Positive" sur notre base par les femmes sont évaluées "Positive" ou
"Neutre" par les hommes. Pour conclure cette étude, nous avons étudié les couleurs
moyennes des images source des désaccords. Ces dernières sont résumées dans le
Tableau C.2.
On constate que les cas NegF_PosH et NegF_NeutH montrent la sensibilité des
hommes aux couleurs froides et sombres. Ce premier résultat rejoint les conclusions
de Odom et al. [Odom 00]. Ils ont également conclu que les hommes étaient beaucoup
plus susceptibles d’avoir des réactions positives face aux couleurs sombres que
144Annexe C. Influence du genre sur l’évaluation de l’impact émotionnel
des images de la base SENSE
Figure C.1: Répartition des désaccords entre hommes et femmes lors de l’évaluation
de l’impact émotionnel sur notre base. Les annotations sont de la forme "jugementFemmes_jugementHommes".
Ainsi PosF_NeutH correspond aux images jugées "Positive"
par les femmes et "Neutre" par les hommes.
Tableau C.2: Différentes couleurs moyennes au sein des désaccords entre genre relevés sur
notre base.
Type de
désaccord
Patchs représentant les
couleurs moyennes
NegF_PosH
NeutF_NegH
NeutF_PosH
NegF_NeutH
PosF_NeutH
les femmes. Le cas NegF_NeutH est assez particulier. En effet, les femmes ont potentiellement
interprété la sémantique des images contenant des couleurs sombres
et froides. Dans le cas de nos études, ces images contiennent des grilles métalliques,
des reptiles ou encore le mauvais temps.
Conclusions
L’évaluation de l’impact émotionnel des images peut être délicate si on n’adopte
pas la bonne stratégie. Dans notre cas, au regard du contenu faiblement sémantique
de notre base d’images, nous avons choisi une façon simple d’annoter les images.
Cette dernière comprend deux paramètres : la nature de l’émotion et la puissance
de l’émotion. L’étude des différences d’évaluation en fonction du genre s’est essentiellement
faite sur la nature.
Les résultats que nous obtenons sont cohérents avec ceux de la littérature. Les prin-
145Annexe C. Influence du genre sur l’évaluation de l’impact émotionnel
des images de la base SENSE
cipaux désaccords concernent les images positives et négatives. Les femmes semblent
plus sensibles aux couleurs claires et les hommes jugent de façon "moins négative"
les images contenant des couleurs foncées.
146Annexe D
Résultats des évaluations EEG sur
quelques images de SENSE
Les travaux que nous présentons ici ont été réalisés en 2013 en collaboration avec
le département d’Informatique de l’Université de Milan (Dipartimento di Informatica,
Università degli stidi di Milano) avec Enrico Calore alors doctorant et Daniele
Marini, Professeur.
Introduction
Nous avons évalué les réponses EEG sur 12 images de notre base. Le but de ces
évaluations étaient dans un premier temps d’étudier une possible relation entre les
réponses SSVEP et ensuite la corrélation entre ces réponses et un descripteur basniveau
des images. Dans cette étude préliminaire nous avons choisi la "luminance".
Les évaluations se sont déroulées en trois sessions et ont été présentées dans un ordre
pseudo-aléatoire. Durant une session chaque image était affichée pendant 8 secondes
avec un "scintillement" à 10Hz. Ensuite une image toute noire est affichée pendant
5 secondes. L’évaluation reprend jusqu’à ce que les 12 images aient été vues.
Seulement 4 participants ont effectué volontairement nos évaluations. Le signal EEG
a été enregistré à l’aide de 4 électrodes positionnées sur la région occipitale en Pz,
POz, PO3 et PO4 (cf. Figure 4.10) suivant le système 10-20, proposé par Sharbrough
et al. [Sharbrough 91].
Étude de différentes corrélations
Nous avons étudié la corrélation entre l’intensité de la réponse SSVEP des 4 participants
à nos évaluations. Cette réponse SSVEP a été calculée avec une technique
relativement nouvelle de l’état de l’art [Friman 07, Garcia-Molina 11].
Nous avons utilisé la corrélation de Pearson pour l’étude de la corrélation potentielle
entre les différentes réponses. 1
1. Nous avons utilisé le logiciel PSPPIRE https://www.gnu.org/software/pspp/tour.html
pour ce faire.
147Annexe D. Résultats des évaluations EEG sur quelques images de
SENSE
Dans un premier temps, nous avons évalué la corrélation entre les réponses SSVEP
calculées pour les images des différents sessions de tests et les observateurs pour
être sûre qu’il y existe une modulation significative de la réponse par le contenu des
images. Nous avons considéré deux configurations :
1. Nous avons calculée la réponse SSVEP pour la durée totale d’affichage d’une
image en utilisant l’algorithme de l’"Énergie Minimale" [Friman 07].
2. Nous avons calculé avec le même algorithme la réponse SSVEP pour chaque
seconde d’affichage et en avons fait une moyenne pour la durée totale de l’af-
fichage.
Tableau D.1: Corrélation entre les différentes sessions de tests dans la première configuration.
Sessions S1_Moy_8s S2_Moy_8s S3_Moy_8s
S1_Moy_8s
Coef. Pearson 1 0.56 0.49
Importance - 0 0
Population 48 48 48
S2_Moy_8s
Coef. Pearson 0.56 1 0.40
Importance 0 - 0
Population 48 48 48
S3_Moy_8s
Coef. Pearson 0.49 0.40 1
Importance 0 0 -
Population 48 48 48
Tableau D.2: Corrélation entre les différentes sessions de tests dans la seconde configuration.
Sessions S1_Moy_1s S2_Moy_1s S3_Moy_1s
S1_Moy_1s
Coef. Pearson 1 0.62 0.61
Importance - 0 0
Population 48 48 48
S2_Moy_1s
Coef. Pearson 0.62 1 0.68
Importance 0 - 0
Population 48 48 48
S3_Moy_1s
Coef. Pearson 0.61 0.68 1
Importance 0 0 -
Population 48 48 48
Dans le Tableau D.1, nous avons représenté la corrélation entre les différentes sessions
dans la configuration 1 et dans le Tableau D.2 celle de la configuration 2. Dans
ces deux tableaux, la population (qui correspond au nombre de réponses SSVEP
considéré) est égale à 48 puisque nous avons étudié les réponses SSVEP pour les 4
148Annexe D. Résultats des évaluations EEG sur quelques images de
SENSE
participants (12 images/participant ⇒ 12 réponses/participant). Au regard des différents
résultats de ces deux tableaux, l’hypothèse nulle de corrélation dans les deux
configurations peut être rejetée. Une corrélation forte est à noter dans le seconde
configuration entre les différentes sessions. Ceci confirme que les réponses SSVEP
calculées sont bien corrélées au contenu des images.
Tableau D.3: Corrélation entre la réponse SSVEP et la luminance.
Sessions Luminance
S1_Moy_1s
Coef. Pearson 0.14
Importance 0.33
Population 48
S2_Moy_1s
Coef. Pearson 0.12
Importance 0.43
Population 48
S3_Moy_1s
Coef. Pearson 0.04
Importance 0.80
Population 48
Moyenne_1s
Coef. Pearson 0.12
Importance 0.43
Population 48
S1_Moy_8s
Coef. Pearson -0.24
Importance 0.10
Population 48
S2_Moy_8s
Coef. Pearson -0.33
Importance 0.02
Population 48
S3_Moy_8s
Coef. Pearson -0.07
Importance 0.63
Population 48
Moyenne_8s
Coef. Pearson -0.27
Importance 0.06
Population 48
Dans le Tableau D.3, nous avons résumé les résultats de l’étude de corrélation entre
les réponses SSVEP et la teinte des images. Cette dernière information bas-niveau
peut être importante dans l’impact émotionnel d’une image. Nous avons ensuite
gardé la valeur moyenne pour chaque image. En analysant les différents coefficients
de Pearson, nous ne pouvons pas rejeter l’hypothèse nulle dans les deux configurations.
Une exception néanmoins est faite pour la seconde série de test et ceci pour
une réponse SSVEP calculée sur la durée totale d’observation. Ces résultats sont
probablement dûs à la nature de nos images. En effet, comparées à celles d’IAPS,
149Annexe D. Résultats des évaluations EEG sur quelques images de
SENSE
nos images ne provoquent pas d’émotions fortes.
Conclusions
L’étude des réponses SSVEP associées aux différentes images nous permet de
confirmer qu’il existe une corrélation forte entre les images de la base SENSE évaluées
et les réponses SSVEP des différents observateurs. Par contre nous ne pouvons pas
identifier à ce stade de l’étude préliminaire que nous avons conduite, quel descripteur
bas-niveau module la réponse SSVEP. Une étude statistique signifiante doit être
menée conjointement à d’autres évaluations subjectives plus importantes.
150Annexe E
Configuration des ensembles
d’apprentissage et de test des
bases SENSE et IAPS
Dans cette annexe nous donnons la constitution complète de nos ensembles d’apprentissage
et de test pour les bases SENSE et IAPS. Le Tableau E.1 donne le nombre
d’images que nous avons utilisé pour chacune des deux bases.
Tableau E.1: Nombre d’images dans les ensembles d’apprentissage et de test
Négative Neutre Positive Total
Ensemble d’apprentissage
IAPS 248 84 228 560
SENSE 53 53 53 159
Ensemble de test
IAPS 61 20 58 139
SENSE 10 82 96 188
Le détail des images (numéro des images utilisées) est donné ci-dessous.
Configuration des images de la base IAPS
Ensemble d’apprentissage
Images négatives 1019, 1050, 1051, 1052, 1080, 1090, 1110, 1111, 1114, 1120,
1201, 1202, 1271, 1274, 1275, 1280, 1303, 1304, 1525, 1930, 2095, 2120, 2141, 2205,
2278, 2301, 2455, 2456, 2490, 2520, 2590, 2683, 2691, 2692, 2700, 2703, 2715, 2717,
2722, 2730, 2751, 2753, 2799, 2800, 2900, 2981, 3000, 3001, 3015, 3016, 3017, 3019,
3051, 3053, 3059, 3060, 3062, 3063, 3064, 3068, 3071, 3080, 3100, 3101, 3103, 3110,
3120, 3130, 3140, 3150, 3160, 3168, 3180, 3181, 3185, 3191, 3212, 3213, 3215, 3216,
3225, 3230, 3261, 3266, 3301, 3350, 3400, 3500, 3550, 4621, 5970, 5971, 6021, 6022,
6190, 6200, 6211, 6212, 6213, 6220, 6231, 6241, 6242, 6243, 6250, 6260, 6263, 6300,
6312, 6313, 6315, 6350, 6370, 6410, 6415, 6510, 6530, 6540, 6550, 6555, 6561, 6562,
6563, 6570, 6821, 6825, 6830, 6831, 6836, 6838, 7135, 7136, 7361, 7380, 8230, 8485,
151Annexe E. Configuration des ensembles d’apprentissage et de test des
bases SENSE et IAPS
9001, 9002, 9006, 9007, 9010, 9031, 9040, 9041, 9043, 9046, 9050, 9075, 9102, 9120,
9140, 9145, 9163, 9180, 9181, 9183, 9185, 9186, 9187, 9220, 9252, 9253, 9254, 9265,
9290, 9291, 9295, 9300, 9302, 9320, 9321, 9322, 9326, 9330, 9331, 9332, 9341, 9342,
9373, 9395, 9405, 9409, 9410, 9412, 9414, 9415, 9417, 9419, 9421, 9423, 9424, 9425,
9427, 9428, 9429, 9430, 9433, 9435, 9440, 9452, 9471, 9480, 9490, 9491, 9500, 9520,
9530, 9560, 9570, 9571, 9584, 9590, 9599, 9600, 9610, 9611, 9621, 9622, 9623, 9630,
9810, 9830, 9831, 9832, 9901, 9902, 9903, 9904, 9908, 9909, 9910, 9911, 9920, 9921,
9922, 9925, 9930, 9940, 9941, 2055.1 , 2352.2 , 2375.1 , 2900.1 , 3005.1 , 4664.2 ,
6250.1 , 6570.1 , 9635.1
Images neutres 1810, 2038, 2190, 2191, 2206, 2210, 2214, 2215, 2221, 2230, 2270,
2271, 2372, 2381, 2383, 2393, 2410, 2411, 2440, 2480, 2495, 2514, 2516, 2518, 2580,
2595, 2749, 2752, 2830, 2850, 2870, 3210, 5120, 5395, 5455, 5500, 5740, 6000, 6150,
7000, 7003, 7004, 7009, 7010, 7030, 7034, 7036, 7040, 7050, 7056, 7080, 7090, 7110,
7130, 7140, 7150, 7161, 7170, 7175, 7179, 7187, 7190, 7205, 7207, 7224, 7233, 7234,
7235, 7255, 7490, 7495, 7496, 7510, 7550, 7560, 7590, 7640, 7700, 7705, 7950, 8232,
9070, 9210, 9700
Images positives 1340, 1410, 1440, 1441, 1463, 1500, 1510, 1540, 1600, 1601,
1603, 1604, 1620, 1630, 1670, 1710, 1721, 1722, 1731, 1740, 1811, 1812, 1850, 1910,
1999, 2030, 2035, 2040, 2050, 2057, 2058, 2060, 2071, 2075, 2080, 2091, 2151, 2152,
2153, 2154, 2156, 2158, 2160, 2165, 2208, 2209, 2216, 2222, 2250, 2260, 2274, 2299,
2303, 2304, 2306, 2310, 2314, 2331, 2332, 2339, 2341, 2344, 2345, 2346, 2352, 2360,
2362, 2370, 2387, 2388, 2391, 2395, 2501, 2510, 2530, 2540, 2560, 2598, 2650, 2655,
2791, 4002, 4003, 4180, 4220, 4250, 4290, 4310, 4490, 4500, 4520, 4550, 4599, 4601,
4603, 4607, 4609, 4610, 4611, 4612, 4616, 4617, 4622, 4623, 4626, 4628, 4640, 4641,
4645, 4650, 4651, 4652, 4656, 4658, 4659, 4660, 4666, 4670, 4676, 4677, 4681, 4687,
4689, 4690, 4700, 5000, 5001, 5010, 5199, 5200, 5201, 5202, 5215, 5220, 5260, 5270,
5450, 5460, 5470, 5480, 5594, 5600, 5611, 5621, 5626, 5629, 5631, 5660, 5725, 5760,
5764, 5779, 5781, 5811, 5814, 5820, 5829, 5830, 5831, 5833, 5870, 5890, 5891, 5910,
5994, 7200, 7220, 7230, 7270, 7280, 7282, 7284, 7289, 7325, 7330, 7350, 7390, 7400,
7405, 7410, 7460, 7470, 7480, 7481, 7501, 7502, 7508, 7530, 7570, 7580, 8021, 8030,
8034, 8041, 8080, 8090, 8120, 8161, 8162, 8163, 8180, 8185, 8186, 8190, 8200, 8208,
8210, 8260, 8300, 8320, 8330, 8340, 8370, 8371, 8380, 8400, 8461, 8465, 8470, 8490,
8496, 8497, 8499, 8500, 8502, 8503, 8510, 8531
Ensemble de test
Images négatives 1070, 1113, 1220, 1300, 2053, 2276, 2457, 2688, 2710, 2750,
2811, 3010, 3030, 3061, 3069, 3102, 3131, 3170, 3195, 3220, 3300, 3530, 6020, 6210,
6230, 6244, 6311, 6360, 6520, 6560, 6571, 6834, 7359, 9000, 9008, 9042, 9090, 9160,
9184, 9250, 9280, 9301, 9325, 9340, 9400, 9413, 9420, 9426, 9432, 9470, 9495, 9561,
9592, 9620, 9800, 9900, 9905, 9912, 9927, 2345.1 , 3550.1 ,
Images neutres 2200, 2220, 2280, 2394, 2484, 2570, 2810, 4561, 5731, 7002, 7020,
7041, 7100, 7160, 7180, 7211, 7247, 7500, 7595, 8160
152Annexe E. Configuration des ensembles d’apprentissage et de test des
bases SENSE et IAPS
Images positives 1460, 1590, 1610, 1720, 1750, 1920, 2045, 2070, 2150, 2155,
2170, 2224, 2300, 2311, 2340, 2347, 2373, 2398, 2550, 2660, 4210, 4470, 4597, 4608,
4614, 4624, 4643, 4653, 4664, 4680, 4695, 5030, 5210, 5300, 5551, 5623, 5700, 5780,
5825, 5836, 5982, 7260, 7286, 7352, 7430, 7492, 7545, 8031, 8116, 8170, 8193, 8280,
8350, 8420, 8492, 8501, 8540, 2352.1
Configuration des images de la base SENSE
Ensemble d’apprentissage
Images négatives 320, 305, 338, 341, 319, 92, 171, 340, 313, 87, 211, 335, 93, 332,
330, 314, 307, 225, 334, 210, 141, 155, 327, 322, 333, 226, 216, 24, 172, 151, 90, 318,
154, 149, 107, 339, 323, 204, 170, 329, 303, 18, 100, 150, 308, 182, 189, 302, 106, 301,
57, 300, 348
Images neutres 242, 1, 227, 9, 5, 290, 19, 67, 239, 183, 175, 13, 291, 39, 312, 316,
224, 194, 21, 219, 77, 326, 304, 234, 120, 6, 310, 236, 17, 38, 243, 135, 315, 309, 233,
223, 231, 222, 167, 75, 64, 40, 252, 221, 198, 180, 11, 108, 317, 185, 176, 168, 144
Images positives 260, 343, 266, 76, 47, 164, 45, 2, 267, 196, 82, 337, 286, 264,
117, 29, 41, 342, 283, 113, 80, 125, 298, 78, 278, 272, 115, 10, 34, 345, 205, 131, 56,
279, 265, 159, 79, 287, 240, 165, 122, 346, 288, 281, 273, 53, 277, 129, 95, 81, 187,
297, 193
Ensemble de test
Images négatives 35, 52, 68, 96, 103, 116, 137, 220, 311, 328
Images neutres 3, 7, 8, 12, 14, 16, 22, 27, 30, 33, 36, 42, 49, 59, 62, 63, 66, 84,
88, 89, 91, 98, 99, 104, 105, 109, 111, 112, 114, 118, 119, 121, 130, 140, 143, 145,
147, 148, 152, 153, 157, 158, 161, 169, 174, 177, 178, 184, 191, 192, 195, 200, 201,
202, 203, 209, 212, 214, 215, 217, 218, 228, 229, 232, 235, 237, 247, 250, 257, 259,
263, 268, 269, 275, 294, 306, 321, 324, 325, 331, 336, 347
Images positives 4, 15, 20, 23, 25, 26, 28, 31, 32, 37, 43, 44, 46, 48, 50, 54, 55,
58, 60, 61, 65, 69, 70, 72, 73, 74, 83, 85, 86, 94, 97, 101, 102, 110, 123, 124, 126, 127,
128, 132, 133, 134, 136, 138, 139, 142, 146, 156, 160, 162, 163, 166, 179, 181, 186,
188, 190, 197, 199, 206, 207, 208, 213, 230, 238, 241, 244, 245, 246, 248, 249, 251,
253, 254, 255, 256, 258, 261, 262, 270, 271, 274, 276, 280, 282, 284, 285, 289, 292,
293, 295, 296, 299, 344, 349, 350
153Annexe E. Configuration des ensembles d’apprentissage et de test des
bases SENSE et IAPS
154Références bibliographiquesRéférences bibliographiques
[Abdel-Hakim 06] A. E. Abdel-Hakim & A. A. Farag. CSIFT : A SIFT Descriptor
with Color Invariant Characteristics. In Proceedings
of the IEEE Computer Society Conference on Computer Vision
and Pattern Recognition), 2006. Pages 17 et 18
[Achanta 09] R. Achanta, S. Hemami, F. Estrada & S. Susstrunk.
Frequency-tuned salient region detection. In Proceedings of
the IEEE Conference on Computer Vision and Pattern Recognition,
pages 1597–1604, June 2009. Page 35
[Air ] http://svtdaybyday.blogspot.fr/2014_04_01_archive.
html. Page 31
[Alahi 12] A. Alahi, R. Ortiz & P. Vandergheynst. FREAK : Fast
Retina Keypoint. In Proceedings of the IEEE Conference on
Computer Vision and Pattern Recognition, pages 510–517,
June 2012. Page 20
[Arya 98] S. Arya, D. M. Mount, N. S. Netanyahu, R. Silverman &
A. Y. Wu. An Optimal Algorithm for Approximate Nearest
Neighbor Searching Fixed Dimensions. Journal of ACM,
vol. 45, no. 6, pages 891–923, 1998. Page 28
[Ballard 91] D. H. Ballard. Animate Vision. Artif. Intell., vol. 48, no. 1,
pages 57–86, 1991. Page 32
[Bard 28] P. Bard. A diencephalic mechanism for the expression of
rage with special reference to the sympathetic nervous system.
American Journal of Physiology – Legacy Content,
vol. 84, no. 3, pages 490–515, 1928. Page 76
[Barrett 98] L. F. Barrett, L. Robin, P. R. Pietromonaco & Kristen M.
Eyssell. Are Women the "More Emotional" Sex ? Evidence
From Emotional Experiences in Social Context. Cognition
& Emotion, vol. 12, no. 4, pages 555–578, 1998. Page 144
[Bay 06] H. Bay, T. Tuytelaars & L. Van Gool. SURF : Speeded Up
Robust Features. vol. 3951 of Lecture Notes in Computer
Science, pages 404–417. Springer Berlin Heidelberg, 2006.
Page 19
157Références bibliographiques
[Beke 08] L. Beke, G. Kutas, Y. Kwak, G. Y. Sung, D. Park & P. Bodrogi.
Color preference of aged observers compared to young
observers. Color Research & Application, vol. 33, no. 5,
pages 381–394, 2008. Page 81
[Beresniak 90] D. Beresniak. Abc des couleurs leurs incidences dans votre
vie quotidienne. 1990. Pages 1 et 79
[Bian 09] P. Bian & L. Zhang. Biological Plausibility of Spectral Domain
Approach for Spatiotemporal Visual Saliency. In Proceedings
of the 15th International Conference on Advances
in Neuro-information Processing, vol. 1 of ICONIP’08, pages
251–258. Springer-Verlag, 2009. Page 35
[Borji 11] A. Borji, D. Sihite & L. Itti. Computational Modeling of
Top-down Visual Attention in Interactive Environments. In
Proceedings of the British Machine Vision Conference, pages
1–12. BMVA Press, 2011. Page 34
[Borji 13a] A. Borji & L. Itti. State-of-the-Art in Visual Attention Modeling.
IEEE Trans. Pattern Anal. Mach. Intell., vol. 35,
no. 1, pages 185–207, 2013. Page 34
[Borji 13b] A. Borji, D. Sihite & L. Itti. Quantitative Analysis of
Human-Model Agreement in Visual Saliency Modeling : A
Comparative Study. IEEE Transactions on Image Processing,
vol. 22, no. 1, pages 55–69, 2013. Pages 34, 37 et 66
[Boujut 12] H. Boujut. Mesure Sans Référence de la Qualité des Vidéos
Haute Définition Diffusées avec des Pertes de Transmission.
Thèse, Université Bordeaux I : École doctorale de Mathématiques
et d’Informatique, Sept. 2012. Pages 29, 31, 33, 34, 35
et 37
[Bovik 90] A. C. Bovik, M. Clark & W. S. Geisler. Multichannel Texture
Analysis Using Localized Spatial Filters. IEEE Trans.
Pattern Anal. Mach. Intell., vol. 12, no. 1, pages 55–73, 1990.
Page 88
[Boyatziz 93] C.J. Boyatziz & R. Varghese. Children’s Emotional Associations
With Colors. The Journal of Genetic Psychology,
vol. 155, pages 77–85, 1993. Pages 1 et 81
[Bradley 01] M. M. Bradley, M. Codispoti, D. Sabatinelli & P. J. Lang.
Emotion and Motivation II : Sex Differences in Picture Processing.
Emotion, vol. 1, no. 3, pages 300–319, 2001. Pages
81 et 143
[Burghouts 09] G. J. Burghouts & J. M. Geusebroek. Performance Evaluation
of Local Colour Invariants. Computer Vision and
Image Understanding, vol. 113, pages 48–62, 2009. Pages 17
et 18
[Busso 04] C. Busso, Z. Deng, S. Yildirim, M. Bulut, C. M. Lee, A. Kazemzadeh,
S. Lee, U. Neumann & S. Narayanan. Analysis of
158Références bibliographiques
Emotion Recognition Using Facial Expressions, Speech and
Multimodal Information. In Proceedings of the 6th International
Conference on Multimodal Interfaces, pages 205–211.
ACM, 2004. Pages 2 et 86
[Calonder 10] M. Calonder, V. Lepetit, C. Strecha & P. Fua. BRIEF : Binary
Robust Independent Elementary Features. vol. 6314 of
Lecture Notes in Computer Science, pages 778–792. Springer
Berlin Heidelberg, 2010. Page 20
[Cannon 27] W. B. Cannon. The James-Lange Theory of Emotions :
A Critical Examination and an Alternative Theory. The
American Journal of Psychology, vol. 39, no. 1/4, pages 106–
124, 1927. Page 76
[Cas ] http://www.biosemi.com/headcap.htm. Page 106
[Chi ] http://www.kartable.fr/premiere-s/svt/1034/cours/
le-cerveau,1S07065. Page 31
[Chikkerur 10] S. Chikkerur, T. Serre, C. Tan & T. Poggio. What and
where : A Bayesian inference theory of attention. Vision
Research, vol. 50, no. 22, pages 2233–2247, 2010. Page 34
[Cho 04] S. Cho. Emotional image and musical information retrieval
with interactive genetic algorithm. Proceedings of the IEEE,
vol. 92, no. 4, pages 702–711, 2004. Page 92
[Coppin 10] D. Coppin G.and Sander. Théories et concepts contemporains
en psychologie de l’émotion, pages 25–56. Hermès
Science publications-Lavoisier, 2010. Pages 75, 76 et 77
[Cor ] http://commons.wikimedia.org/wiki/File:Ventraldorsal_streams.svg.
Page 32
[Davis 95] W. J. Davis, M. A. Rahman, Libby J. Smith, Ayesha Burns,
L. Senecal, D. McArthur, J. A. Halpern, A. Perlmutter,
W. Sickels & W. Wagner. Properties of human affect induced
by static color slides (IAPS) : dimensional, categorical and
electromyographic analysis. Biological Psychology, vol. 41,
no. 3, pages 229–253, 1995. Page 86
[De Silva 97] L. C. De Silva, T. Miyasato & R. Nakatsu. Facial emotion
recognition using multi-modal information. In Proceedings
of International Conference on Information, Communications
and Signal Processing, vol. 1, pages 397–401, Sept.
1997. Pages 2 et 86
[Delhumeau 13] J. Delhumeau, P. Gosselin, H. Jégou & P. Pérez. Revisiting
the VLAD Image Representation. In Proceedings of the 21st
ACM International Conference on Multimedia, pages 653–
656. ACM, 2013. Page 61
[Demanet 09] L. Demanet L.and Ying. Wave atoms and time upscaling
of wave equations. Numerische Mathematik, vol. 113, pages
1–71, 2009. Page 109
159Références bibliographiques
[Dieny 08] B. Dieny & U. Ebels. Stockage de l’information : les acquis
et les promesses du nanomagnétisme et de la spintronique.
Clefs CEA, no. 56, pages 62–66, 2007-2008. Page 7
[Douze 09] M. Douze, H. Jégou, H. Sandhawalia & C. Amsaleg
L.and Schmid. Evaluation of GIST Descriptors for Webscale
Image Search. In Proceedings of the ACM International
Conference on Image and Video Retrieval, pages 1–19.
ACM, 2009. Pages 2 et 11
[Ekman 78] P. Ekman & W. V. Friesen. Facial action coding system :
Manual, vol. 1-2. Consulting Psychologists Press, 1978. Page
87
[Ekman 92] P. Ekman. Facial expressions of emotions. Psychological
science, vol. 3, no. 1, pages 34–38, 1992. Pages 2, 78 et 86
[Ele ] http://www.hindawi.com/journals/tswj/2013/618649/
fig2/. Page 106
[Everingham 07] M. Everingham, L. Van Gool, C. K. I. Williams, J. Winn
& A. Zisserman. The PASCAL Visual Object Classes Challenge
2007 (VOC2007) Results, 2007. Pages 2 et 40
[Everingham 12] M. Everingham, L. Van Gool, C. K. I. Williams, J. Winn
& A. Zisserman. The PASCAL Visual Object Classes Challenge
2012 (VOC2012)Results, 2012. Pages 2, 3, 18 et 40
[Fernandez-Maloigne 04] C. Fernandez-Maloigne, A. Trémeau & P. Bonton. Image
numérique couleur : De l’acquisition au traitement. 2004.
Page 107
[Fischer 04] A. H. Fischer, P. M. Rodriguez Mosquera, A.E. M. Van Vianen
& A. S. R. Manstead. Gender and culture differences
in emotion. Emotion, vol. 4, pages 87–94, 2004. Pages 143
et 144
[Friman 07] O. Friman, I. Volosyak & A. Graser. Multiple Channel Detection
of Steady-State Visual Evoked Potentials for BrainComputer
Interfaces. Biomedical Engineering, IEEE Transactions
on, vol. 54, no. 4, pages 742–750, 2007. Pages 95,
147 et 148
[Förstner 94] W. Förstner. A framework for low level feature extraction.
vol. 801 of Lecture Notes in Computer Science, pages 383–
394. Springer Berlin Heidelberg, 1994. Page 13
[Gao 08] K. Gao, S. Lin, Y. Zhang, S. Tang & H. Ren. Attention Model
Based SIFT Keypoints Filtration for Image Retrieval.
In Proceedings of the 7th IEEE/ACIS International Conference
on Computer and Information Science, pages 191–196,
May 2008. Page 38
[Garcia-Diaz 09] Antón Garcia-Diaz, Xosé. Fdez-Vidal, Xosé. Pardo & Raquel
Dosil. Decorrelation and Distinctiveness Provide with
160Références bibliographiques
Human-Like Saliency. In Advanced Concepts for Intelligent
Vision Systems, vol. 5807 of Lecture Notes in Computer
Science, pages 343–354. Springer Berlin Heidelberg,
2009. Page 35
[Garcia-Molina 11] G. Garcia-Molina & D. Zhu. Optimal spatial filtering for
the steady state visual evoked potential : BCI application. In
Proceedings of the 5th International IEEE/EMBS Conference
on Neural Engineering, pages 156–160, 2011. Page 147
[Geusebroek 01] J. Geusebroek, R. van den Boomgaard, A. W. M. Smeulders
& H. Geerts. Color Invariance. IEEE Transactions on
Pattern Analysis and Machine Intelligence, vol. 23, no. 12,
2001. Page 18
[Geusebroek 06] J. and Geusebroek. Compact Object Descriptors from Local
Colour Invariant Histograms. In Proceedings of the British
Machine Vision Conference, pages 1–10. BMVA Press, 2006.
Page 88
[Goferman 12] S. Goferman, L. Zelnik-Manor & A. Tal. Context-Aware Saliency
Detection. IEEE Trans. Pattern Anal. Mach. Intell.,
vol. 34, no. 10, pages 1915–1926, 2012. Page 35
[Gordoa 12] A. Gordoa, J. A. Rodriguez-Serrano, F. Perronnin & E. Valveny.
Leveraging category-level labels for instance-level
image retrieval. In Proceedings of the IEEE Conference
on Computer Vision and Pattern Recognition, pages 3045–
3052, June 2012. Pages 11 et 61
[Grauman 05] K. Grauman & T. Darrell. The pyramid match kernel :
discriminative classification with sets of image features. In
Proceedings of the 10th IEEE International Conference on
Computer Vision, vol. 2, pages 1458–1465, Oct. 2005. Page
26
[Gu 07] J. Gu E.and Wang & N. I. Badler. Generating Sequence
of Eye Fixations Using Decision-Theoretic Attention Model.
In Attention in Cognitive Systems. Theories and Systems
from an Interdisciplinary Viewpoint, vol. 4840 of Lecture
Notes in Computer Science, pages 277–292. Springer Berlin
Heidelberg, 2007. Page 34
[Halpern 11] D. F. Halpern. Sex differences in cognitive abilities. Psychology
Press, 4th edition, 2011. Page 143
[Harel ] J. Harel. A Saliency Implementation in MATLAB. Pages 37
et 43
[Harris 88] C. Harris & M. Stephens. A Combined Corner and Edge
Detector. In Proceedings of the 4th Alvey Vision Conference,
pages 147–151, 1988. Pages 2 et 13
161Références bibliographiques
[Hays 07] A. A. Hays J.and Efros. Scene Completion Using Millions
of Photographs. In ACM SIGGRAPH Papers, 2007. Pages 2
et 11
[His ] https://sites.google.com/site/
int3llig3nc3artifici3ll3/retrospective-de-lhistoire-de-l-ia.
Page 1
[Hofer 06] A. Hofer, C. M. Siedentopf, A. Ischebeck, M.A. Rettenbacher,
M Verius, S. Felber & W. W. Fleischhacker. Gender
differences in regional cerebral activity during the perception
of emotion : A functional MRI study. NeuroImage, vol. 32,
no. 2, pages 854–862, 2006. Page 143
[Hong 06] S. Hong & H. Choi. Color image semantic information retrieval
system using human sensation and emotion. In Issues
in Information Systems, vol. 7, pages 140–145, 2006. Pages
2 et 87
[Huiskes 08] M. J. Huiskes & M. S. Lew. The MIR Flickr Retrieval Evaluation.
In Proceedings of the ACM International Conference
on Multimedia Information Retrieval. ACM, 2008.
Page 40
[Huiskes 10] M. J. Huiskes, B. Thomee & M. S. Lew. New Trends and
Ideas in Visual Concept Detection : The MIR Flickr Retrieval
Evaluation Initiative. In Proceedings of the ACM International
Conference on Multimedia Information Retrieval,
pages 527–536. ACM, 2010. Page 40
[Indyk 98] P. Indyk & R. Motwani. Approximate Nearest Neighbors :
Towards Removing the Curse of Dimensionality. In Proceedings
of the Thirtieth Annual ACM Symposium on Theory
of Computing, pages 604–613. ACM, 1998. Page 28
[Itti 98] L. Itti, C. Koch & E. Niebur. A Model of Saliency-Based
Visual Attention for Rapid Scene Analysis. IEEE Trans.
Pattern Anal. Mach. Intell., vol. 20, no. 11, pages 1254–1259,
1998. Pages 34, 35, 37, 53 et 102
[James 90] W. James. The principles of psychology, vol. 1 of American
science series : Advanced course. H. Holt, 1890. Pages 28
et 76
[Jauzein 10] F. Jauzein. Le traitement cérébral de l’information visuelle,
2010. Page 30
[Jégou 10a] H. Jégou, M. Douze & C. Schmid. Improving bag-of-features
for large scale image search. International Journal of Computer
Vision, vol. 87, no. 3, pages 316–336, Feb. 2010. Page
7
[Jégou 10b] H. Jégou, M. Douze, C. Schmid & P. Pérez. Aggregating local
descriptors into a compact image representation. In Proceedings
of the 23rd IEEE Conference on Computer Vision &
162Références bibliographiques
Pattern Recognition, pages 3304–3311. IEEE Computer Society,
2010. Pages 2, 17, 21, 24, 26, 40, 50, 51, 53 et 67
[Jégou 11] H. Jégou, M. Douze & C. Schmid. Product Quantization
for Nearest Neighbor Search. Pattern Analysis and Machine
Intelligence, IEEE Transactions on, vol. 33, no. 1, pages 117–
128, Jan. 2011. Pages 2 et 17
[Jégou 12] H. Jégou, F. Perronnin, M. Douze, J. Sanchez, P. Perez
& C. Schmid. Aggregating Local Image Descriptors into
Compact Codes. Pattern Analysis and Machine Intelligence,
IEEE Transactions on, vol. 34, no. 9, pages 1704–1716, Sept.
2012. Pages 40, 50, 51 et 53
[Judd 09] T. Judd, K. Ehinger, F. Durand & A. Torralba. Learning to
Predict Where Humans Look. In Proceedings of the IEEE
International Conference on Computer Vision, 2009. Page
35
[Kaya 04] Naz Kaya & Helen H. Epps. Color-Emotion associations :
Past experience and personal preference. AIC Colors and
Paints, Interim Meeting of the International Color Association,
2004. Pages 1, 78, 79 et 139
[Ke 04] Y. Ke & R. Sukthankar. PCA-SIFT : a more distinctive
representation for local image descriptors. In Proceedings of
the IEEE Computer Society Conference on Computer Vision
and Pattern Recognition, vol. 2, pages 506–513, 2004. Pages
2, 17 et 19
[Keil 03] A. Keil, T. Gruber, M.. Müller, S. Moratti, M. Stolarova,
M. Bradley & P.J. Lang. Early modulation of visual perception
by emotional arousal : Evidence from steady-state visual
evoked brain potentials. Cognitive, Affective, & Behavioral
Neuroscience, vol. 3, no. 3, pages 195–206, 2003. Pages 94
et 95
[Kemp 02] A. H. Kemp, M. A. Gray, P. Eide, R. B. Silberstein & P. J.
Nathan. Steady-State Visually Evoked Potential Topography
during Processing of Emotional Valence in Healthy Subjects.
NeuroImage, vol. 17, no. 4, pages 1684–1692, 2002. Pages 94
et 95
[Kienzle 09] W. Kienzle, M. O. Franz, B. Schölkopf & F. A. Wichmann.
Center-surround patterns emerge as optimal predictors for
human saccade targets. Journal of Vision, vol. 9, no. 5 :7,
pages 1–15, 2009. Page 35
[Kobayashi 81] S. Kobayashi. The aim and method of the color image scale.
Color Research & Application, vol. 6, no. 2, pages 93–107,
1981. Page 81
[Koch 85] C. Koch & S. Ullman. Shifts in Selective Visual Attention :
Towards the Underlying Neural Circuitry. Human Neurobiology,
vol. 4, pages 219–227, 1985. Page 35
163Références bibliographiques
[Kootstra 08] G. Kootstra, A. Nederveen & B. Boer. Paying Attention
to Symmetry. In Proceedings of the British Machine Vision
Conference, pages 1–10. BMVA Press, 2008. Page 34
[Kootstra 11] G. Kootstra, B. de Boer & L. Schomaker. Predicting Eye
Fixations on Complex Visual Stimuli Using Local Symmetry.
Cognitive Computation, vol. 3, no. 1, pages 223–240, 2011.
Page 55
[Lang 08] P. J. Lang, M. M. Bradley & B. N. Cuthbert. International
affective picture system ( IAPS) : Affective ratings of pictures
and instruction manual. Technical Report A-8. Rapport
technique, University of Florida, 2008. Pages 3, 76, 83,
94, 95, 96 et 127
[Lange 22] C. G. Lange, W. James & I. A. Haupt. The emotions. Psychology
classics. Williams & Wilkins Company, 1922. Page
76
[Lazebnik 06] S. Lazebnik, C. Schmid & J. Ponce. Beyond Bags of Features
: Spatial Pyramid Matching for Recognizing Natural
Scene Categories. In Proceedings of the IEEE Computer
Society Conference on Computer Vision and Pattern Recognition,
vol. 2, pages 2169–2178, 2006. Pages 26 et 27
[Le Meur 05a] O. Le Meur. Attention sélective en visualisation d’images
fixes et animées affichées sur écran : Modèles et évaluation
de performances-Applications. Thèse, École polytechnique
de l’Université de Nantes : École doctorale STIM, Oct. 2005.
Pages 29, 30, 32, 33, 34, 35 et 37
[Le Meur 05b] O. Le Meur, D. Thoreau, P. Le Callet & D. Barba. A spatiotemporal
model of the selective human visual attention. In
Proceedings of the IEEE International Conference on Image
Processing, vol. 3, pages 1188–1191, Sept. 2005. Page 34
[Le Meur 06] O. Le Meur, P. Le Callet, D. Barba & D. Thoreau. A coherent
computational approach to model bottom-up visual attention.
Pattern Analysis and Machine Intelligence, IEEE
Transactions on, vol. 28, no. 5, pages 802–817, May 2006.
Pages 34 et 55
[Le Meur 13] O. Le Meur & T. Baccino. Methods for comparing scanpaths
and saliency maps : strengths and weaknesses. Behavior Research
Methods, vol. 45, no. 1, pages 251–266, 2013. Page
37
[Lecellier 09] F. Lecellier. Les contours actifs basés région avec a priori
de bruit, de texture et de forme : Application à l’échocardiographie.
Thèse, Université de Caen, 2009. Page 109
[Leutenegger 11] S. Leutenegger, M. Chli & R. Y. Siegwart. BRISK : Binary
Robust Invariant Scalable Keypoints. In Proceedings of the
164Références bibliographiques
International Conference on Computer Vision, pages 2548–
2555. IEEE Computer Society, 2011. Page 20
[Li 08] X. Li, C. Wu, C. Zach, S. Lazebnik & J. Frahm. Modeling
and Recognition of Landmark Image Collections Using
Iconic Scene Graphs. In Proceedings of the 10th European
Conference on Computer Vision : Part I, pages 427–440.
Springer-Verlag, 2008. Pages 2 et 11
[Li 10a] J. Li, Y. Tian, T. Huang & W. Gao. Probabilistic MultiTask
Learning for Visual Saliency Estimation in Video. International
Journal of Computer Vision, vol. 90, no. 2, pages
150–165, 2010. Page 34
[Li 10b] Y. Li, Y. Zhou, J. Yan, Z. Niu & J. Yang. Visual Saliency
Based on Conditional Entropy. In Computer Vision-ACCV,
vol. 5994 of Lecture Notes in Computer Science, pages 246–
257. Springer Berlin Heidelberg, 2010. Page 34
[Liu 08] W. Liu, W. Xu & L. Li. A tentative study of visual attentionbased
salient features for image retrieval. In Proceedings of
the 7th World Congresson Intelligent Control and Automation,
pages 7635–7639, June 2008. Page 38
[Liu 11a] E. Liu N.and Dellandréa & L. Chen. Evaluation of features
and combination approaches for the classification of emotional
semantics in images. In International Conference on
Computer Vision Theory and Applications, 2011. Pages 2,
88, 110 et 120
[Liu 11b] T. Liu, Z. Yuan, J. Sun, J. Wang, N. Zheng, X. Tang &
H. Shum. Learning to Detect a Salient Object. IEEE Trans.
Pattern Anal. Mach. Intell., vol. 33, no. 2, pages 353–367,
2011. Page 34
[Lowe 99] D. G. Lowe. Object Recognition from Local Scale-Invariant
Features. International Conference on Computer Vision,
vol. 2, pages 1150–1157, 1999. Pages 2, 14, 17 et 87
[Lowe 04] D. G. Lowe. Distinctive Image Features from Scale-Invariant
Keypoints. International Journal of Computer Vision,
vol. 60, pages 91–110, 2004. Pages 2 et 17
[Lucassen 10] M. P. Lucassen, T. Gevers & A. Gijsenij. Adding texture to
color : quantitative analysis of color emotions. In Proceedings
of CGIV, 2010. Pages 81, 89 et 129
[Machajdik 10] J. Machajdik & A. Hanbury. Affective image classification
using features inspired by psychology and art theory. In
Proceedings of the international conference on Multimedia,
pages 83–92, 2010. Pages 2, 3, 75, 78, 83, 84, 86, 88, 89, 92, 94,
95, 96, 121, 127 et 129
[Mahadevan 10] V. Mahadevan & N. Vasconcelos. Spatiotemporal Saliency
in Dynamic Scenes. IEEE Transactions on Pattern Analysis
165Références bibliographiques
and Machine Intelligence, vol. 32, no. 1, pages 171–177, 2010.
Page 34
[Marat 09] S. Marat, T. Ho Phuoc, L. Granjon, N. Guyader, D. Pellerin
& A. Guérin-Dugué. Modelling Spatio-Temporal Saliency
to Predict Gaze Direction for Short Videos. International
Journal of Computer Vision, vol. 82, no. 3, pages 231–243,
2009. Page 34
[Matas 02] J. Matas, O. Chum, M. Urban & T. Pajdla. Robust Wide
Baseline Stereo from Maximally Stable Extremal Regions. In
Proceedings of the British Machine Vision Conference, pages
1–10, 2002. Page 2
[Mikels 05] J. A. Mikels, B. L. Fredrickson, G. R. Larkin, C. M. Lindberg,
S. J. Maglio & P. A. Reuter-Lorenz. Emotional category
data on images from the international affective picture
system. Behavior Research Methods, vol. 37, no. 4, pages
626–630, 2005. Pages 84, 86, 88 et 96
[Mikolajczyk 01] K. Mikolajczyk & C. Schmid. Indexing based on scale invariant
interest points. In Proceedings of the 8th IEEE International
Conference on Computer Vision, vol. 1, pages
525–531, 2001. Pages 2, 13, 14 et 15
[Mikolajczyk 02] K. Mikolajczyk & C. Schmid. An Affine Invariant Interest
Point Detector. In Computer Vision-ECCV, vol. 2350 of
Lecture Notes in Computer Science, pages 128–142. Springer
Berlin Heidelberg, 2002. Page 14
[Mikolajczyk 05a] K. Mikolajczyk & C. Schmid. A performance evaluation of
local descriptors. IEEE Transactions on Pattern Analysis &
Machine Intelligence, vol. 27, no. 10, pages 1615–1630, 2005.
Page 19
[Mikolajczyk 05b] K. Mikolajczyk, T. Tuytelaars, C. Schmid, A. Zisserman,
J. Matas, F. Schaffalitzky, T. Kadir & L. Van Gool. A Comparison
of Affine Region Detectors. Int. J. Comput. Vision,
vol. 65, no. 1-2, pages 43–72, 2005. Page 12
[Mindru 04] F Mindru, T. Tuytelaars, L Van Gool & T. Moons. Moment
invariants for recognition under changing viewpoint
and illumination. Computer Vision and Image Understanding,
vol. 94, no. 1–3, pages 3–27, 2004. Pages 19 et 20
[Moravec 77] H. P. Moravec. Towards Automatic Visual Obstacle Avoidance.
In Proceedings of the 5th International Joint Conference
on Artificial Intelligence, vol. 2, pages 584–584. Morgan
Kaufmann Publishers Inc., 1977. Page 13
[Muja 09] M. Muja & D. G. Lowe. Fast approximate nearest neighbors
with automatic algorithm configuration. In Proceedings of
the International Conference on Computer Vision Theory
and Applications, pages 331–340, 2009. Page 28
166Références bibliographiques
[Munsell 05] A. H. Munsell. A color notation. G. H. Ellis Company, 1905.
Page 139
[Nistér 06] D. Nistér & H. Stewénius. Scalable Recognition with a Vocabulary
Tree. In Proceedings of the IEEE Conference on Computer
Vision and Pattern Recognition, vol. 2, pages 2161–
2168, 2006. Pages 2, 3, 10, 17, 40 et 50
[Odom 00] A. S. Odom & S. S. Sholtz. The reds, whites, and blues of
emotion : examining color hue effects on mood tones. 2000.
Page 144
[Oei ] http://www.ophtalmo-mougins.com/anatomie-oeilophtalmo-06-alpes-maritimes-83-var.html.
Page 29
[Ojala 02] T. Ojala, M. Pietikainen & T. Maenpaa. Multiresolution
gray-scale and rotation invariant texture classification with
local binary patterns. Pattern Analysis and Machine Intelligence,
IEEE Transactions on, vol. 24, no. 7, pages 971–987,
July 2002. Page 88
[Oliva 01] A. Oliva & A. Torralba. Modeling the Shape of the Scene :
A Holistic Representation of the Spatial Envelope. International
Journal of Computer Vision, vol. 42, pages 145–175,
2001. Pages 2, 11 et 110
[Ou 04a] L. C. Ou, M. R. Luo, A. Woodcock & A. Wright. A study
of colour emotion and colour preference. Part I : Colour
emotions for single colours. Color Research & Application,
vol. 29, no. 3, pages 232–240, 2004. Pages 1, 79, 80, 81, 87,
139 et 141
[Ou 04b] L. C. Ou, M. R. Luo, A. Woodcock & A. Wright. A study
of colour emotion and colour preference. Part II : Colour
emotions for two-colour combinations. Color Research &
Application, vol. 29, no. 4, pages 292–298, 2004. Pages 1
et 80
[Ou 04c] L. C. Ou, M. R. Luo, A. Woodcock & A. Wright. A study
of colour emotion and colour preference. Part III : Colour
preference modeling. Color Research & Application, vol. 29,
no. 5, pages 381–389, 2004. Pages 1 et 80
[Ou 06] L. C. Ou & M. R. Luo. A colour harmony model for twocolour
combinations. Color Research & Application, vol. 31,
no. 3, pages 191–204, 2006. Pages 1 et 82
[Ou 11] L. C. Ou, P. Chong, M. R. Luo & C. Minchew. Additivity
of colour harmony. Color Research & Application, vol. 36,
no. 5, pages 355–372, 2011. Pages 1 et 83
[Paleari 08] M. Paleari & B. Huet. Toward emotion indexing of multimedia
excerpts. Proceedings on Content-Based Multimedia
Indexing, International Workshop, pages 425–432, 2008.
Page 78
167Références bibliographiques
[Parsons 04] L. Parsons, E. Haque & H. Liu. Subspace clustering for
high dimensional data : a review. In Proceedings of the
ACM SIGKDD, vol. 6, pages 90–105. Explorations Newsletter,
2004. Pages 3 et 42
[Perreira Da Silva 10a] M. Perreira Da Silva. Modèle computationnel d’attention
pour la vision adaptative. Thèse, Université de La Rochelle,
2010. Pages 29, 31 et 37
[Perreira Da Silva 10b] M. Perreira Da Silva, V. Courboulay, A. Prigent & P. Estraillier.
Evaluation of preys/predators systems for visual
attention simulation. In Proceedings of the International
Conference on Computer Vision Theory and Applications,
pages 275–282. INSTICC, 2010. Pages 102 et 103
[Perreira Da Silva 12] M. Perreira Da Silva & V. Courboulay. Implementation and
evaluation of a computational model of attention for computer
vision. In Developing and Applying Biologically-Inspired
Vision Systems : Interdisciplinary Concepts, pages 273–306.
Hershey, Pennsylvania : IGI Global., 2012. Page 34
[Perronnin 06] F. Perronnin, C. Dance, G. Csurka & M Bressan. Adapted
vocabularies for generic visual categorization. In Proceedings
of the ECCV, pages 464–475, 2006. Page 23
[Perronnin 07] F. Perronnin & C. R. Dance. Fisher Kernels on Visual Vocabularies
for Image Categorization. In Proceedings of the
IEEE Computer Society Conference on Computer Vision
and Pattern Recognition. IEEE Computer Society, 2007.
Pages 2, 24, 25, 26, 27 et 67
[Perronnin 08] F. Perronnin. Universal and Adapted Vocabularies for Generic
Visual Categorization. Pattern Analysis and Machine Intelligence,
IEEE Transactions on, vol. 30, no. 7, pages 1243–
1256, July 2008. Pages 11 et 23
[Plutchik 97] R. Plutchik & H. R. Conte. Circumplex models of personality
and emotions. American Psychological Association,
1997. Page 78
[Ramström 02] O. Ramström & H. Christensen. Visual Attention Using
Game Theory. In Biologically Motivated Computer Vision,
vol. 2525 of Lecture Notes in Computer Science, pages 462–
471. Springer Berlin Heidelberg, 2002. Page 35
[Ret ] http://commons.wikimedia.org/wiki/File:Retina.svg.
Page 30
[Rigoulot 08] S. Rigoulot. Impact comportemental et électrophysiologique
de l’information émotionnelle en vision périphérique. PhD
thesis, Université de Lille II - École Doctorale de BiologieSanté,
Sept. 2008. Page 77
168Références bibliographiques
[Rosin 09] P. L. Rosin. A Simple Method for Detecting Salient Regions.
Pattern Recogn., vol. 42, no. 11, pages 2363–2371, 2009.
Page 35
[Rosten 05] E. Rosten & T. Drummond. Fusing points and lines for
high performance tracking. In Proceedings of the IEEE International
Conference on Computer Vision, vol. 2, pages
1508–1511, Oct. 2005. Pages 15 et 16
[Rosten 06] E. Rosten & T. Drummond. Machine learning for high-speed
corner detection. In Proceedings of the European Conference
on Computer Vision, vol. 1, pages 430–443, May 2006. Page
15
[Saito 96] M. Saito. Comparative studies on color preference in Japan
and other Asian regions, with special emphasis on the preference
for white. Color Research & Application, vol. 21,
no. 1, pages 35–49, 1996. Page 81
[Sánchez 13] J. Sánchez, F. Perronnin, T. Mensink & J. Verbeek. Image
Classification with the Fisher Vector : Theory and Practice.
International Journal of Computer Vision, vol. 105, no. 3,
pages 222–245, 2013. Pages 25 et 28
[Sander 13] D. Sander. Vers une définition de l’émotion. Cerveau&Psycho,
no. 56, 2013. Pages 1 et 76
[Schachter 62] S. Schachter & J. Singer. Cognitive, social, and physiological
determinants of emotional state. Psychological Review,
vol. 69, no. 5, pages 379–399, 1962. Page 77
[Scherer 84] K. R. Scherer & P. Ekman. Approaches to emotions. Lavoisier,
Jan. 1984. Pages 2 et 86
[Schmid 00] C. Schmid, R. Mohr & C. Bauckhage. Evaluation of Interest
Point Detectors. Int. J. Comput. Vision, vol. 37, no. 2, pages
151–172, 2000. Pages 12 et 14
[Sève 09] R. Sève. Science de la couleur : Aspects physiques et perceptifs.
Chalagam Edition, 2009. Page 87
[Sharbrough 91] F. Sharbrough, G. E. Chatrian, R. P. Lesser, H. Luders,
M. Nuwer & T. W. Picton. American Electroencephalographic
Society guidelines for standard electrode position nomenclature.
J. Clin. Neurophysiol., vol. 8, pages 200–202,
1991. Pages 106 et 147
[Sivic 03] J. Sivic & A. Zisserman. Video Google : A Text Retrieval
Approach to Object Matching in Videos. In Proceedings
of the International Conference on Computer Vision, pages
1470–1477, 2003. Pages 2, 3, 21, 24 et 67
[Smets 90] P. Smets. The Combination of Evidence in the Transferable
Belief Model. IEEE Trans. Pattern Anal. Mach. Intell.,
vol. 12, no. 5, pages 447–458, May 1990. Page 88
169Références bibliographiques
[Smith 97] S. M. Smith & J. M. Brady. SUSAN&Mdash ;A New Approach
to Low Level Image Processing. Int. J. Comput. Vision,
vol. 23, no. 1, pages 45–78, May 1997. Page 15
[Solli 09] M. Solli & R. Lenz. Color harmony for image indexing. In
Proceedings of the 12th International Conference on Computer
Vision Workshops, pages 1885–1892, Sept. 2009. Pages
1, 83 et 133
[Solli 10] M. Solli & R. Lenz. Emotion Related Structures in Large
Image Databases. In Proceedings of the ACM International
Conference on Image and Video Retrieval, pages 398–405.
ACM, 2010. Pages 2, 83 et 87
[Suk 10] H. Suk & H. Irtel. Emotional response to color across media.
Color Research & Application, vol. 35, no. 1, pages 64–77,
2010. Pages 81 et 90
[Swain 91] M. J. Swain & D. H. Ballard. Color indexing. International
Journal of Computer Vision, vol. 7, pages 11–32, 1991. Pages
2 et 11
[Tayari 09] I. Tayari, N. Le Thanh & C. Ben Amar. Modélisation des
états émotionnels par un espace vectoriel multidimensionnel.
Rapport technique, Laboratoire Informatique, Signaux
et Systèmes de Sophia Antipolis, Déc. 2009. Page 77
[Tomasi 91] C. Tomasi & T. Kanade. Detection and Tracking of Point
Features. Rapport technique, International Journal of Computer
Vision, 1991. Page 13
[Tomkims 62] S. S. Tomkims. Affect imagery consciousness : The positive
affects, vol. 1. Springer Publishing Company, 1962. Pages 2
et 86
[Treisman 80] A. Treisman & G. Gelade. A featureintegration theory of
attention. Cognitive Psychology, vol. 12, pages 97–136, 1980.
Page 35
[Turing 50] A. M. Turing. Computing Machinery and Intelligence, 1950.
Page 1
[Tuytelaars 08] T. Tuytelaars & K. Mikolajczyk. Local Invariant Feature
Detectors : A Survey. Foundations and Trends in Computer
Graphics and Vision, vol. 3, no. 3, pages 177–280, 2008.
Pages 12 et 13
[van de Sande 10] K. E. A. van de Sande, T. Gevers & C. G. M. Snoek. Evaluating
Color Descriptors for Object and Scene Recognition.
IEEE Transactions on Pattern Analysis and Machine Intelligence,
vol. 32, no. 9, pages 1582–1596, 2010. Pages 2, 16,
17, 18, 21, 26, 27, 42 et 62
[Van De Weijer 06] J. Van De Weijer & C. Schmid. Coloring local feature extraction.
In Proceedings of the European Conference on
170Références bibliographiques
Computer Vision, vol. 3952 of Lecture Notes in Computer
Science, pages 334–348. Springer, 2006. Page 87
[Wang 05] W. Wang & Y. Yu. Image Emotional Semantic Query Based
on Color Semantic Description. In Proceedings of the
The 4th International Conference on Machine Leraning and
Cybernectics, vol. 7, pages 4571–4576, 2005. Pages 2 et 87
[Wang 06] W. Wang, Y. Yu & S. Jiang. Image Retrieval by Emotional
Semantics : A Study of Emotional Space and Feature Extraction.
In Proceedings of the IEEE International Conference
on Systems, Man and Cybernetics, vol. 4, pages 3534–3539,
Oct. 2006. Page 87
[Wang 10] B. Wang, X. Zhang, M. Wang & P. Zhao. Saliency distinguishing
and applications to semantics extraction and retrieval
of natural image. In Proceedings of the International Conference
on Machine Learning and Cybernetics, vol. 2, pages
802–807, July 2010. Page 38
[Wang 11] C. Wang W.and Chen, Y. Wang, T. Jiang, F Fang & Y. Yao.
Simulating human saccadic scanpaths on natural images. In
Proceedings of the IEEE Conference on Computer Vision
and Pattern Recognition, pages 441–448, June 2011. Page
34
[Wang 13] S. Wang, G. Wu & Y. Zhu. Analysis of Affective Effects
on Steady-State Visual Evoked Potential Responses. In Intelligent
Autonomous Systems, vol. 194 of Advances in Intelligent
Systems and Computing, pages 757–766. Springer
Berlin Heidelberg, 2013. Page 95
[Wei 08] K. Wei, B. He, T. Zhang & W. He. Image emotional classification
based on color semantic description, vol. 5139 of
Lecture Notes in Computer Science, pages 485–491. Springer
Berlin / Heidelberg, 2008. Pages 78 et 120
[Wu 05] Q. Wu, C. Zhou & C. Wang. Content-Based Affective Image
Classification and Retrieval Using Support Vector Machines.
In Affective Computing and Intelligent Interaction, vol. 3784
of Lecture Notes in Computer Science, pages 239–247. Springer
Berlin Heidelberg, 2005. Page 88
[Yanulevskaya 08] V. Yanulevskaya, J. C. Van Gemert, K. Roth, A. K. Herbold,
N. Sebe & J. M. Geusebroek. Emotional valence categorization
using holistic image features. In Proceedings of the
15th IEEE International Conference on Image Processing,
pages 101–104, 2008. Pages 2, 83, 88 et 92
[Zdziarski 12] Z. Zdziarski & R. Dahyot. Feature selection using visual
saliency for content-based image retrieval. In Proceedings of
the IET Irish Signals and Systems Conference, pages 1–6,
2012. Pages 61, 64 et 132
171Références bibliographiques
[Zhang 07] J. Zhang, M. Marszalek, S. Lazebnik & C. Schmid. Local
features and kernels for classification of texture and object
categories : A comprehensive study. International Journal of
Computer Vision, vol. 73, no. 2, pages 213–238, 2007. Pages
42 et 131
[Zhang 09] L. Zhang, M. H. Tong & W. Garrison. SUNDAy : Saliency
Using Natural Statistics for Dynamic Analysis of Scenes. In
Proceedings of the Cognitive Science Society Conference,
2009. Page 34
172Liste des publicationsListe des publications
Revues nationales avec comité de lecture
– S. Gbèhounou, F. Lecellier, C. Fernandez-Maloigne, Extraction et analyse de
l’impact émotionnel des images, Traitement de Signal n˚3-4-5/2012, p. 409-
432.
Conférences internationales avec actes et comité de lecture
– T. Urruty, S. Gbèhounou, H. T. Le, J. Martinet, C. Fernandez-Maloigne, Iterative
Random Visual Word Selection 4th International Conference on Multimedia
Retrieval, 1-4 April 2014.
– S. Gbèhounou, F. Lecellier, C. Fernandez-Maloigne, V.Courboulay, Can salient
interest regions resume emotional impact of an image ?, 15th International
Conference on Computer Analysis of Images and Patterns, 27-29 August 2013,
LNCS 8047, p. 515.
– S. Gbèhounou, F. Lecellier, C. Fernandez-Maloigne, Gender influences on subjective
evaluations in image, 12th International AIC Colour Congress, 8-12
Juillet 2013.
– S. Gbèhounou, F. Lecellier, C. Fernandez-Maloigne, Extraction of emotional
impact in colour images, CGIV 2012, Vol. 6, Society for Imaging Science and
Technology, 2012, p. 314-319.
Conférences nationales avec actes et comité de lecture
– S. Gbèhounou, F. Lecellier, C. Fernandez-Maloigne, Extraction et analyse de
l’impact émotionnel des images, 18ème Congrès francophone sur la Reconnaissance
des Formes et l’Intelligence Artificielle, 24-27 Janvier 2012.
Exposés nationaux
– S. Gbèhounou, F. Lecellier, C. Fernandez-Maloigne, V.Courboulay, Les régions
saillantes améliorent-elles l’évaluation de l’impact émotionnel des images ?,
GDR ISIS, 26 Septembre 2013, Paris.
– S. Gbèhounou, F. Lecellier, C. Fernandez-Maloigne, V.Courboulay, Extraction
et analyse de l’impact émotionnel des images, Séminaire École Doctorale S2IM,
10-12 Avril 2013, Poitiers.
175Indexation de bases d’images : Évaluation de l’impact
émotionnel
Résumé : L’objectif de ce travail est de proposer une solution de reconnaissance
de l’impact émotionnel des images en se basant sur les techniques utilisées en recherche
d’images par le contenu. Nous partons des résultats intéressants de cette
architecture pour la tester sur une tâche plus complexe. La tâche consiste à classifier
les images en fonction de leurs émotions que nous avons définies "Négative", "Neutre"
et "Positive". Les émotions sont liées aussi bien au contenu des images, qu’à notre
vécu. On ne pourrait donc pas proposer un système de reconnaissance des émotions
performant universel. Nous ne sommes pas sensible aux mêmes choses toute notre
vie : certaines différences apparaissent avec l’âge et aussi en fonction du genre. Nous
essaierons de nous affranchir de ces inconstances en ayant une évaluation des bases
d’images la plus hétérogène possible. Notre première contribution va dans ce sens :
nous proposons une base de 350 images très largement évaluée. Durant nos travaux,
nous avons étudié l’apport de la saillance visuelle aussi bien pendant les expérimentations
subjectives que pendant la classification des images. Les descripteurs, que
nous avons choisis, ont été évalués dans leur majorité sur une base consacrée à la
recherche d’images par le contenu afin de ne sélectionner que les plus pertinents.
Notre approche qui tire les avantages d’une architecture bien codifiée, conduit à des
résultats très intéressants aussi bien sur la base que nous avons construite que sur la
base IAPS, qui sert de référence dans l’analyse de l’impact émotionnel des images.
Mots-clés : Recherche d’images par le contenu, Sac de mots visuels, impact émotionnel
des images, saillance visuelle, évaluations subjectives
Image databases indexing : Emotional impact assessing
Abstract : The goal of this work is to propose an efficient approach for emotional
impact recognition based on CBIR techniques (descriptors, image representation).
The main idea relies in classifying images according to their emotion which can be
"Negative", "Neutral" or "Positive". Emotion is related to the image content and also
to the personnal feelings. To achieve our goal we firstly need a correct assessed
image database. Our first contribution is about this aspect. We proposed a set
of 350 diversifed images rated by people around the world. Added to our choice
to use CBIR methods, we studied the impact of visual saliency for the subjective
evaluations and interest region segmentation for classification. The results are really
interesting and prove that the CBIR methods are usefull for emotion recognition.
The chosen desciptors are complementary and their performance are consistent on
the database we have built and on IAPS, reference database for the analysis of the
image emotional impact.
Keywords : Content Based Image Retrieval, Bag of Visual Words, image emotional
impact, visual saliency, subjective evaluations
Doctorat de l’Université de Poitiers, Spécialité : Traitement du Signal
et des images
Thèse préparée et soutenue au Département SIC du Laboratoire XLIM, UMR 7252
Université de Poitiers, Bât. SP2MI, Téléport 2, Bvd Marie et Pierre Curie
BP 30179, 86962 Futuroscope Chasseneuil Cedex France
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.
![[TXT]](http://www.audentia-gestion.fr/icons/text.gif){kind=icon}
