HAL Id: tel-01094327
https://hal.archives-ouvertes.fr/tel-01094327
Submitted on 15 Dec 2014
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of scientific
research documents, whether they are published
or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est
destin´ee au d´epˆot et `a la diffusion de documents
scientifiques de niveau recherche, publi´es ou non,
´emanant des ´etablissements d’enseignement et de
recherche fran¸cais ou ´etrangers, des laboratoires
publics ou priv´es.UNIVERSITÉ D’ORLÉANS
ÉCOLE DOCTORALE MIPTIS
MATHÉMATIQUES, INFORMATIQUE, PHYSIQUE THÉORIQUE
ET INGÉNIEURIE DES SYSTÈMES
Laboratoire d’Informatique Fondamentale d’Orléans
THÈSE
présentée par :
Hélène COULLON
soutenue le : 29 septembre 2014
pour obtenir le grade de : Docteur de l’université d’Orléans
Discipline/ Spécialité : Informatique
Modélisation et implémentation de parallélisme
implicite pour les simulations scientifiques basées sur
des maillages
THÈSE dirigée par :
Sébastien LIMET Professeur des Universités, Université d’Orléans
RAPPORTEURS :
David HILL Professeur des Universités, Université Blaise Pascal
Christian PEREZ Directeur de Recherche INRIA, ENS Lyon
JURY :
Rob BISSELING Professeur, Université de Utrecht, Pays-Bas
Jose-Maria FULLANA Professeur, Université Pierre et Marie Curie
Frédéric LOULERGUE Professeur, Université d’Orléans (Président)
Daniel PIERRE Directeur pôle scientifique et technique de
Antea France (Convention CIFRE)À mes parents
“Quand je serai grande, je voudrais inventer des choses”Remerciements
Trois ans, une durée qui parait si longue et qui est pourtant si courte ! Voici déjà le
moment de remercier toutes les personnes qui ont contribué directement ou indirectement
à ce travail de thèse, par des financements, des collaborations, ou tout simplement par
l’amitié, le soutien et plus encore.
La thèse représente beaucoup de travail, d’implication, voir même d’acharnement,
mais on oublie souvent de dire que la thèse c’est aussi une très grande part de chance,
comme souvent dans la vie, et certains en ont plus que d’autres. J’ai eu la grande chance
de rencontrer Sébastien Limet, mon directeur de thèse, et de travailler avec lui avant
et pendant (et j’espère après) la thèse. Sébastien a su me diriger et m’aiguiller dans les
bonnes directions, tout en me laissant toujours l’impression de diriger moi même mes
recherches ce qui est un travail très subtil et très difficile à réaliser. Bien évidemment, ma
thèse n’aurait pas été possible sans la société Géo-Hyd (Antea Groupe) qui l’a financée
en convention CIFRE, et sans l’Agence Nationale de la Recherche et de la Technologie
(ANRT) qui a subventionné Géo-Hyd pour cette thèse. J’ai eu, encore une fois, la chance
d’avoir de bonnes conditions de recherche. Je remercie plus particulièrement Daniel Pierre
pour avoir suivi ma thèse en entreprise et pour avoir su protéger mon temps de recherche.
Je remercie également l’ensemble des salariés de Géo-Hyd pour leur sympathie, leurs
encouragements ou leur amitié, et plus particulièrement mes amies Myriam et Leïla.
J’ai passé 5 superbes années au LIFO, d’abord comme ingénieur recherche, puis
comme doctorante. Je tiens donc à remercier le LIFO dans sa globalité et sans exception,
les anciens comme les nouveaux. Je tiens particulièrement à remercier les personnes qui
m’ont fait confiance pour donner des cours au département informatique de l’Université
d’Orléans : Ali, Alexandre, Sophie et Sylvain. Enfin, on les oublie souvent, mais un très
grand merci aux secrétaires Isabelle et Florence, pour leur bonne humeur et leur travail
irréprochable. Merci à mon ancien co-bureau Julien pour ses bons conseils, et aussi merci
à Mon SIM, Monsieur Patate, Iko, Matthieu Lopette, Nicducasquette, Peranth, Florent,
Le Foulque, Le Legaux, Davide, Shiruba, Le Trôme, El Cennalgo, Guigui etc. et tous les
doctorants, ATERs et post-docs passés au LIFO que je pourrais oublier de citer.
Toujours dans le contexte du travail, ma thèse a eu la chance d’être enrichie par un
grand nombre de collaborations. Un grand merci à Minh, Olivier, Stéphane, Christian,
Pierre-Yves, Jose-Maria et Xiaofei pour avoir travaillé avec moi sur des applications de
mon travail. Et un grand merci à Rob de m’avoir reçu à l’Université d’Utrecht et d’avoir
collaboré avec moi sur des problématiques que je ne connaissais pas. Merci aux personnes
qui m’ont aidé à rédiger et relire cette thèse, Sylvain, Pierre-Yves et surtout Caro ! Merci
và mes rapporteurs Christian et David, ainsi qu’aux membres de mon jury Frédéric, Rob,
Daniel pour leur temps et leur expertise.
Apprendre à se remettre en question, à jeter ce sur quoi on travaille depuis des mois
pour partir vers autre chose, apprendre à ne pas trouver de voie, à rester bloqué, autant
de difficultés qui rendent la thèse si difficile et une réelle formation à la recherche. Il
n’est pas rare de déprimer, de vouloir abandonner, de ne pas se sentir à la hauteur,
et alors une thèse parait impossible sans soutien, sans amitié. Merci à mes parents et
ma grande sœur qui m’ont soutenue, comme toujours, dans cette démarche. Merci à mes
amis Simon et Yannick pour les discussions, les pauses, les amusements et les sorties, mais
aussi pour leur aide dans les moments difficiles. Merci au Club de Floorball Orléanais,
aux Atlantics et aux filles de l’équipe de France, plus particulièrement à Caro, Auréa,
Guigui, Juju, Malabar, Élodie, Joss, Pauline etc. Merci au CLTO Hockey sur gazon, plus
particulièrement à Pablo, petit Pierre, Neness et Raymond.
Pour terminer ces remerciements, je remercie ma moitié, Jean-Hugues. Merci de
m’avoir épaulé et supporté pendant ces trois années stressantes et éprouvantes. Merci
de me donner la chance de continuer en recherche en faisant le sacrifice de quitter Orléans
pour Lyon.
viTable des matières
Table des matières vii
Liste des figures ix
1 Introduction 1
1.1 Contexte de la recherche . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.3 Organisation du manuscrit . . . . . . . . . . . . . . . . . . . . . . . . 5
2 Etat de l’art 7
2.1 Calcul parallèle : architectures et programmation . . . . . . . 8
2.1.1 Architectures parallèles . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.2 Paradigmes et modèles de parallélisation . . . . . . . . . . . . . . . . . 13
2.2 Problèmes numériques et Simulations scientifiques . . . . . . . . 19
2.2.1 Équations aux dérivées partielles . . . . . . . . . . . . . . . . . . . . . 19
2.2.2 Passage du continu au discret . . . . . . . . . . . . . . . . . . . . . . 20
2.2.3 Méthodes numériques basées sur les maillages . . . . . . . . . . . . . . 23
2.2.4 Exemples de méthodes numériques basées sur des maillages . . . . . . . 25
2.2.5 Programmation et parallélisation . . . . . . . . . . . . . . . . . . . . . 31
2.3 Distribution de données . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.3.1 Modèles de partitionnement . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.2 Cas particulier du partitionnement de matrices . . . . . . . . . . . . . 38
2.3.3 Cas particulier du partitionnement de maillages . . . . . . . . . . . . . 40
2.3.4 Partitionnements particuliers . . . . . . . . . . . . . . . . . . . . . . . 43
2.4 Le parallélisme implicite . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.4.1 Classification de problèmes et aide à la parallélisation . . . . . . . . . . 45
2.4.2 Solutions partiellement implicites . . . . . . . . . . . . . . . . . . . . 46
2.4.3 Solutions générales de parallélisme implicite . . . . . . . . . . . . . . . 47
2.4.4 Solutions à patrons . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.4.5 Solutions spécifiques à un domaine . . . . . . . . . . . . . . . . . . . . 53
2.5 Calculs de performances et difficulté de programmation . . . 56
2.5.1 Mesures de performances . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.5.2 Effort de programmation . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.6 Conclusion et positionnement du travail . . . . . . . . . . . . . . 61
vii3 SIPSim : Structured Implicit Parallelism for scientific Simulations
63
3.1 Structure de données distribuée . . . . . . . . . . . . . . . . . . . . 66
3.2 Application de données . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.3 Applicateurs et opérations . . . . . . . . . . . . . . . . . . . . . . . 68
3.4 Interfaces de programmation . . . . . . . . . . . . . . . . . . . . . . 68
3.5 Vue utilisateur et vue réelle . . . . . . . . . . . . . . . . . . . . . . 69
3.6 Type de programmation . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4 SkelGIS pour des maillages réguliers à deux dimensions 73
4.1 SIPSim pour les maillages réguliers à deux dimensions . . . . . 74
4.1.1 Structure de données distribuée . . . . . . . . . . . . . . . . . . . . . 74
4.1.2 Applicateurs et opérations . . . . . . . . . . . . . . . . . . . . . . . . 77
4.1.3 Interfaces de programmation . . . . . . . . . . . . . . . . . . . . . . . 78
4.1.4 Spécialisation partielle de template . . . . . . . . . . . . . . . . . . . 80
4.2 Résolution numérique de l’équation de la chaleur . . . . . . . . 82
4.2.1 Équation et résolution numérique . . . . . . . . . . . . . . . . . . . . 82
4.2.2 Parallélisation avec SkelGIS . . . . . . . . . . . . . . . . . . . . . . . 83
4.2.3 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.3 Résolution numérique des équations de Saint Venant . . . . . . 89
4.3.1 Équations de Saint Venant . . . . . . . . . . . . . . . . . . . . . . . . 89
4.3.2 Résolution numérique et programmation . . . . . . . . . . . . . . . . . 90
4.3.3 Parallélisation avec SkelGIS . . . . . . . . . . . . . . . . . . . . . . . 92
4.3.4 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
5 SkelGIS pour des simulations sur réseaux 101
5.1 Les réseaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
5.2 SIPSim pour les réseaux . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.2.1 Structure de données distribuée . . . . . . . . . . . . . . . . . . . . . 106
5.2.2 Application de données . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.2.3 Applicateurs et opérations . . . . . . . . . . . . . . . . . . . . . . . . 107
5.2.4 Interfaces de programmation . . . . . . . . . . . . . . . . . . . . . . . 108
5.2.5 Spécialisation partielle de template . . . . . . . . . . . . . . . . . . . 111
5.3 Structure de données distribuée pour les réseaux . . . . . . . . 112
5.3.1 Le format Compressed Sparse Row . . . . . . . . . . . . . . . . . . . . 113
5.3.2 Format pour les DAG distribués . . . . . . . . . . . . . . . . . . . . . 115
5.3.3 Implémentation de SkelGIS pour les réseaux . . . . . . . . . . . . . . . 122
5.4 Simulation 1D d’écoulement du sang dans les artères . . . . . . 123
5.4.1 Simulation 1D d’écoulement du sang dans le réseau artériel . . . . . . . 123
5.4.2 Parallélisation avec SkelGIS . . . . . . . . . . . . . . . . . . . . . . . 125
5.4.3 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
5.5 Partitionnement de réseaux . . . . . . . . . . . . . . . . . . . . . . . 137
viii5.5.1 Partitionnement par regroupement d’arêtes sœurs . . . . . . . . . . . . 137
5.5.2 Partitionnement avec Mondriaan . . . . . . . . . . . . . . . . . . . . . 141
5.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
6 Conclusion 153
6.1 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
6.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Bibliographie 159
Liste des figures
2.1 De la gauche vers la droite : maillage cartésien, curvilinéaire et non-structuré. 21
2.2 Maillages en théorie des graphes. . . . . . . . . . . . . . . . . . . . . . . . 23
2.3 Discrétisation régulière de Ω = {x : x ∈ [0, 1]}. . . . . . . . . . . . . . . . . 26
2.4 Discrétisation régulière de Ω = {(x, y) : (x, y) ∈ [0, 1]2}. . . . . . . . . . . . 27
2.5 Interprétation de la seconde forme intégrale de la loi de conservation. . . . 29
2.6 Discrétisation en cellules à volume fini suivant x et t. . . . . . . . . . . . . 29
2.7 Illustration de la méthode des éléments finis pour un cas simple à une
dimension. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.8 Fonctions de base Φj de type “tente”. . . . . . . . . . . . . . . . . . . . . . 31
2.9 Graphe donnant un exemple de partitionnement où la métrique edge-cut
ne représente pas le volume de communication. . . . . . . . . . . . . . . . 37
2.10 De gauche à droite : partitionnement en blocs, en blocs-lignes et bissection
récursive orthogonale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.11 De gauche à droite et de haut en bas : le maillage non structuré 2D, son
graphe nodal, son graphe dual et son graphe dual-diagonal. . . . . . . . . 42
2.12 Placement de notre travail par rapport à l’existant. . . . . . . . . . . . . . 62
3.1 Vue utilisateur (à gauche) et vue réelle (à droite) d’un programme SIPSim. 70
4.1 Deux types de connectivités pour les DMatrix de SkelGIS . . . . . . . . . 75
4.2 Décomposition d’un domaine à deux dimensions. . . . . . . . . . . . . . . 76
4.3 Exemple d’itérateur permettant de se déplacer dans trois éléments contigus
puis d’effectuer un saut de deux éléments avant la lecture contiguë suivante. 79
ix4.4 Spécialisation partielle de template pour l’objet DMatrix : T est le type
de donnée à stocker dans l’instance, Or est l’ordre de la simulation, et
box est le type de connectivité souhaitée. Ce paramètre a une valeur par
défaut à false (star est le choix par défaut). . . . . . . . . . . . . . . . . . 81
4.5 Fonction main du programme de résolution de l’équation de la chaleur
avec SkelGIS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4.6 Opération Laplacien pour la résolution de l’équation de la chaleur. . . . . 85
4.7 Logarithme des temps d’exécution de l’expérience 1 pour Heat_MPI et
Heat_SK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.8 Logarithme des temps d’exécution de l’expérience 2 pour Heat_MPI et
Heat_SK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.9 Logarithme des temps d’exécution de l’expérience 3 pour Heat_MPI et
Heat_SK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
4.10 Accélération de la simulation SkelGIS pour les trois expériences. . . . . . . 88
4.11 Déclaration des variables h, u et v . . . . . . . . . . . . . . . . . . . . . . 92
4.12 Logarithme des temps d’exécution de l’expérience 1 pour FS_MPI et
FS_SK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.13 Logarithme des temps d’exécution de l’expérience 2 pour FS_MPI et
FS_SK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.14 Logarithme des temps d’exécution de l’expérience 3 pour FS_MPI et
FS_SK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
4.15 Logarithme des temps d’exécution de l’expérience 4 pour FS_MPI et
FS_SK. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.1 Illustration d’un réseau à gauche et d’un exemple de simulation multiphysique
à droite avec deux types de discrétisation. Les nœuds subissent
une discrétisation cartésienne de l’espace et les arêtes subissent une discrétisation
non-structurée de l’espace. . . . . . . . . . . . . . . . . . . . . 103
5.2 Maillages et réseaux. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.3 Voisinage d’un nœud et d’une arête d’un réseau. . . . . . . . . . . . . . . . 110
5.4 Voisinage pour le cas particulier d’un maillage 1D dans les arêtes. . . . . . 110
5.5 Définition des objets DPMap_Edges et DPMap_Nodes. . . . . . . . . . . 111
5.6 Spécialisations partielles de template pour l’objet DPMap_Edges . . . . . 112
5.7 Graphe non orienté G et sa matrice d’adjacence Sp(G). . . . . . . . . . . 114
5.8 Graphe orienté acyclique correspondant au graphe 5.7. . . . . . . . . . . . 116
5.9 DAG global partitionné pour quatre processeurs. Le processeur 1 récupère
la partie bleue de ce partitionnement. . . . . . . . . . . . . . . . . . . . . . 117
5.10 Sous-graphe géré par le processeur 1 avant et après ré-indexation. . . . . . 118
5.11 Parallélisation de la structure et ré-indexation. . . . . . . . . . . . . . . . 119
5.12 Système de ré-indexation. . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
5.13 Déclaration des variables A et Q . . . . . . . . . . . . . . . . . . . . . . . 126
5.14 Déclaration d’une variable nd sur les nœuds du réseau . . . . . . . . . . . 127
x5.15 Accélération de la simulation bloodflow-SkelGIS sans et avec le recouvrement
des communications par les calculs. . . . . . . . . . . . . . . . . . . . 131
5.16 Comparaison des temps d’exécution entre bloodflow-OpenMP et
bloodflow-SkelGIS avec une échelle logarithmique. . . . . . . . . . . . . . . 132
5.17 Comparaison des accélérations entre bloodflow-OpenMP et bloodflowSkelGIS.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
5.18 Accélération de bloodflow-SkelGIS sur un DAG de 15k arêtes et nœuds
sur le TGCC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
5.19 Accélération de bloodflow-SkelGIS sur des DAGs de 50k et 100k arêtes et
nœuds sur Juqueen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
5.20 Accélération de bloodflow-SkelGIS sur un DAG de 500k arêtes et nœuds
sur Juqueen. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
5.21 Exemple de réseau G (à gauche) de type DAG, et du méta-graphe G0
associé (à droite). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
5.22 Moyenne (moy) et écart type (ect) du nombre d’arêtes obtenu pour chaque
processeurs suite au partitionnement. . . . . . . . . . . . . . . . . . . . . . 140
5.23 Moyenne (moy) et écart type (ect) du nombre d’octets à échanger pour
chaque processeur, pour chaque DPMap et pour une unique itération de
temps de la simulation, suite au partitionnement des arbres de la table 5.8. 140
5.24 Moyenne du nombre d’octets total à échanger pour chaque processeur,
dans le cadre de la simulation artérielle de la section 5.4, en utilisant les
arbres de la table 5.8. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
5.25 Transformation du graphe G d’un réseau en graphe G0
. . . . . . . . . . . . 143
5.26 Étapes de communication 1 et 3. . . . . . . . . . . . . . . . . . . . . . . . 143
5.27 Exemple de réseau G0 avec la matrice A et les hypergraphes Hr et Hc qui
y sont associés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
5.28 Problème de partitionnement pour les nœuds bleus de G0
. . . . . . . . . . 146
5.29 La matrice W et le graphe biparti complet auquel la matrice peut être
identifiée Gw. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
xi1
Introduction
Sommaire
2.1 Calcul parallèle : architectures et programmation . . . . . . . 8
2.1.1 Architectures parallèles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.1.2 Paradigmes et modèles de parallélisation . . . . . . . . . . . . . . . . . . 13
2.2 Problèmes numériques et Simulations scientifiques . . . . . . . . 19
2.2.1 Équations aux dérivées partielles . . . . . . . . . . . . . . . . . . . . . . 19
2.2.2 Passage du continu au discret . . . . . . . . . . . . . . . . . . . . . . . . 20
2.2.3 Méthodes numériques basées sur les maillages . . . . . . . . . . . . . . . 23
2.2.4 Exemples de méthodes numériques basées sur des maillages . . . . . . . 25
2.2.5 Programmation et parallélisation . . . . . . . . . . . . . . . . . . . . . . 31
2.3 Distribution de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.3.1 Modèles de partitionnement . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.2 Cas particulier du partitionnement de matrices . . . . . . . . . . . . . . 38
2.3.3 Cas particulier du partitionnement de maillages . . . . . . . . . . . . . . 40
2.3.4 Partitionnements particuliers . . . . . . . . . . . . . . . . . . . . . . . . 43
2.4 Le parallélisme implicite . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.4.1 Classification de problèmes et aide à la parallélisation . . . . . . . . . . 45
2.4.2 Solutions partiellement implicites . . . . . . . . . . . . . . . . . . . . . . 46
2.4.3 Solutions générales de parallélisme implicite . . . . . . . . . . . . . . . . 47
2.4.4 Solutions à patrons . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.4.5 Solutions spécifiques à un domaine . . . . . . . . . . . . . . . . . . . . . 53
2.5 Calculs de performances et difficulté de programmation . . . 56
2.5.1 Mesures de performances . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.5.2 Effort de programmation . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
2.6 Conclusion et positionnement du travail . . . . . . . . . . . . . . . 61
12 Chapitre 1. Introduction
1.1 Contexte de la recherche
Les calculs scientifiques, notamment dans le domaine de la simulation numérique,
ont toujours été consommateurs de ressources informatiques. Dans les années 60, à l’apparition
des premiers super-calculateurs, les calculs les plus demandeurs en ressources
étaient déjà les calculs scientifiques. Depuis, ce besoin de puissance de calcul n’a fait
qu’augmenter, donnant naissance à des architectures parallèles toujours plus complexes
à utiliser. La demande de puissance de calcul, ou de performance dans les architectures
parallèles, est a priori sans limites pour plusieurs raisons. Tout d’abord, les données utilisées
par les scientifiques sont de plus en plus précises et donc de plus en plus lourdes et
longues à traiter. Cette précision des données vient, par exemple, de la progression des
techniques d’acquisition, comme pour les données géo-référencées obtenues par des technologies
à laser (la télédétection LIDAR, par exemple). Cette précision peut également
être obtenue en complexifiant le maillage associé au domaine d’étude dans les simulations
numériques. En effet, dans les simulations, le domaine d’étude est généralement discrétisé
en un maillage afin de pouvoir être traité numériquement. Plus ce maillage est précis,
plus la simulation est précise et plus les calculs à effectuer sont nombreux, et il est en
pratique possible d’augmenter très largement la précision du maillage (sous réserve des
capacités de précision du matériel). De plus, il est évident qu’il est également possible
d’augmenter la taille du domaine d’étude de façon importante, ce qui est également à
l’origine des besoins croissants de puissance et de parallélisme. Enfin, si les maillages des
simulations numériques peuvent être complexifiés, les méthodes numériques et les calculs
peuvent l’être également. Un exemple très parlant de demande croissante de puissance
de calcul est le traitement des modèles météorologiques. Il est potentiellement toujours
possible d’ajouter des facteurs aux modèles, et de les complexifier, mais également d’augmenter
la taille du domaine étudié etc. Toutes ces modifications rendent les calculs plus
longs, demandant plus de puissance et plus de parallélisation, mais permettent d’obtenir
des prévisions plus précises.
Il résulte donc de cette demande croissante de puissance, la création d’architectures
parallèles, c’est-à-dire des architectures qui intègrent plusieurs processeurs, voire plusieurs
machines. De cette manière, il est possible d’obtenir plus de puissance de calcul
sans attendre les prochaines générations de processeurs. L’évolution de ces machines parallèles
nous a mené à des architectures matérielles de plus en plus compliquées et parfois
hétérogènes, mélangeant alors plusieurs machines (cluster ou cloud computing), plusieurs
cœurs et plusieurs processeurs mais aussi des calculateurs graphiques (GPU ). Les scienti-
fiques se retrouvent ainsi à devoir utiliser des architectures parallèles très complexes pour
pouvoir proposer des résultats pertinents et intéressants pour la communauté, sans en
maîtriser l’utilisation, comme d’ailleurs la plupart des informaticiens également. Le calcul
parallèle est donc devenu rapidement un domaine d’expertise que peu de personnes maî-
trise. Il n’est par conséquent pas envisageable que chaque scientifique non-informaticien
apprenne à programmer sur ces architectures et devienne un expert du parallélisme, par
manque de temps, d’argent, et de personnes pouvant les former. De plus, si une formation
de base est quant à elle envisageable, elle ne sera pas suffisante pour exploiter la pleine1.2. Contributions 3
puissance de ces machines. Même si cela se pratique dans certains cas, il paraît également
délicat d’imaginer des collaborations entre des scientifiques non-informaticiens et des experts
du parallélisme pour chaque code parallèle nécessaire. Pour ces raisons sont nés,
quasiment avec l’apparition des architectures parallèles, des outils et langages facilitant
leur programmation. Des modèles de programmation ont tout d’abord été proposés, puis
des langages et des bibliothèques parallèles, mais la complexité grandissante des architectures
a également fait évoluer ces solutions vers des solutions de parallélisme implicite qui
cachent partiellement ou totalement le parallélisme à l’utilisateur. Nous parlons alors de
parallélisme implicite partiel, lorsque les outils proposés cachent partiellement les technicités
du parallélisme, ou total, lorsque les outils cachent intégralement le code parallèle
à l’utilisateur. Nous classons les solutions de parallélisme implicite total suivant trois
grands types : les bibliothèques générales ; les solutions à patrons ; et les langages et bibliothèques
spécifiques. Dans le premier type une grande flexibilité est proposée et les
solutions permettent de s’adresser à tout type de traitements. Le second type propose,
quant à lui, un niveau d’abstraction très intéressant, et permet également de structurer
le code et de donner des repères simples à l’utilisateur. Enfin, le troisième type de parallélisme
implicite total est spécifique à un problème précis et propose des optimisations et
une efficacité pour ce problème. Le langage ou la bibliothèque est également plus simple
d’utilisation car proche du problème spécifique. Il s’agit des solutions les plus efficaces
mais également les moins flexibles.
1.2 Contributions
Cette thèse se place dans le cadre du parallélisme implicite pour les simulations numé-
riques. Nous proposons, tout d’abord, dans ce travail de thèse un modèle de programmation
parallèle implicite, nommé SIPSim pour Structured Implicit Parallelism for scientific
Simulations. Ce modèle présente une approche systématique pour proposer des solutions
de parallélisme implicite pour les simulations numériques basées sur des maillages. Le
modèle est basé sur quatre composants permettant de cacher intégralement le parallé-
lisme à l’utilisateur et d’obtenir un style de programmation proche du séquentiel. Le
modèle SIPSim se positionne à l’intersection des travaux existants en tentant de conserver
les avantages de chacun. Ainsi, le modèle a la particularité d’être à la fois efficace,
car spécifique au cas des simulations numériques à maillages, d’un niveau d’abstraction
permettant de conserver une programmation proche du séquentiel, ce qui garantit un
effort de programmation faible, tout en restant très flexible et adaptable à tout type de
simulations numériques.
Afin de valider le modèle SIPSim, une implémentation est proposée dans cette thèse,
sous le nom de SkelGIS. SkelGIS est une bibliothèque C++ constituée uniquement de
fichiers d’en-tête, ou autrement appelée header-only, implémentée en suivant le modèle
SIPSim pour deux cas de maillages différents : les maillages cartésiens à deux dimensions,
et les compositions de maillages issues des simulations sur des réseaux. Dans le premier
cas, de nombreuses solutions de parallélisme implicite existent, toutefois, en suivant le4 Chapitre 1. Introduction
modèle SIPSim, SkelGIS se place à l’intersection de plusieurs solutions et mêle à la fois
l’efficacité et la flexibilité de façon intéressante. Le deuxième cas, quant à lui, initie un
travail sur des simulations d’un genre plus complexe, où une composition de maillages est
effectuée. La flexibilité du modèle SIPSim est alors mise en avant, et ce type de travaux
n’a, à notre connaissance, jamais été proposé en parallélisme implicite. La bibliothèque
SkelGIS est évaluée en termes de performance et d’effort de programmation sur deux cas
réels d’application, développés et utilisés par des équipes de recherche en mathématiques
appliquées. Ces évaluations permettent donc, tout d’abord, de valider que SkelGIS (et le
modèle SIPSim) répond aux besoins de simulations complexes, et donc aux besoins des
scientifiques. Les performances obtenues sont comparées à des implémentations MPI et
OpenMP des mêmes simulations. Sur l’ensemble de ces évaluations, et pour un effort de
programmation beaucoup moins important, les performances obtenues sont très compé-
titives et proposent de meilleurs temps d’exécution. Nous montrons ainsi que SkelGIS
propose des solutions efficaces et flexibles, tout en cachant intégralement le parallélisme
à l’utilisateur et tout en conservant un style de programmation séquentiel.
La plupart des travaux présentés dans cette thèse ont fait l’objet de publications.
Publications dans des conférences internationales
1. Hélène Coullon, Sébastien Limet. Implementation and Performance Analysis of
SkelGIS for Network Mesh-based Simulations. Euro-Par 2014.
2. Hélène Coullon, Jose-Maria Fullana, Pierre-Yves Lagrée, Sébastien Limet, Xiaofei
Wang. Blood Flow Arterial Network Simulation with the Implicit Parallelism
Library SkelGIS. ICCS 2014.
3. Hélène Coullon, Sébastien Limet. Algorithmic skeleton library for scientific simulations
: Skelgis. In HPCS, pages 429-436. IEEE, 2013.
4. Hélène Coullon, Minh-Hoang Le, Sébastien Limet. Parallelization of shallow-water
equations with the algorithmic skeleton library skelgis. In ICCS, volume 18 of Procedia
Computer Science, pages 591–600. Elsevier, 2013.
Publications dans des journaux internationaux
1. Stéphane Cordier, Hélène Coullon, Olivier Delestre, Christian Laguerre, MinhHoang
Le, Daniel Pierre, and Georges Sadaka. Fullswof paral : Comparison of two
parallelization strategies (mpi and skelgis) on a software designed for hydrology applications.
ESAIM : Proceedings, 43 :59–79, 2013.
Publications en cours d’évaluation dans des journaux internationaux
1. Hélène Coullon, Minh-Hoang Le, Sébastien Limet. Implicit parallelism applied to
shallow-water equations using SkelGIS. In Concurrency and Computation : Practice
and Experience.1.3. Organisation du manuscrit 5
1.3 Organisation du manuscrit
Ce manuscrit est organisé en cinq chapitres supplémentaires dont voici le contenu :
— Nous étudions dans le chapitre 2 l’état de l’art nécessaire à la bonne compréhension
de ce manuscrit. Cet état de l’art est composé d’un historique et d’une présentation
des architectures parallèles, et des modèles et outils de parallélisation qui y sont
associés. Nous donnons ensuite une introduction sur les simulations numériques
basées sur des maillages, ce qui permet de rendre plus clairs les cas d’application
de cette thèse. Les bases nécessaires pour la compréhension des problèmes de dé-
compositions de domaines et de partitionnements de graphes, évoqués dans cette
thèse, sont ensuite abordés. Une description détaillée des solutions de parallélisme
implicites disponibles dans la littérature est ensuite proposée et permettra le positionnement
de notre travail dans ce contexte. Enfin, nous présentons les mesures
de performance et d’effort de programmation utilisées dans ce manuscrit.
— Le chapitre 3 présente le modèle de programmation implicite SIPSim. Il détaille
pour cela les quatre composants qui le constitue et le type de programmation
obtenu en adoptant ce modèle.
— Dans le chapitre 4 est ensuite détaillé la première implémentation du modèle
SIPSim, SkelGIS, pour le cas des maillages à deux dimensions cartésiens. Deux
cas d’application réels sont également détaillés et évalués dans ce chapitre.
— Le chapitre 5 continue la description de l’implémentation SkelGIS dans le cas
des simulations sur les réseaux, afin de valider davantage le modèle SIPSim. Une
section particulière précise l’implémentation et l’optimisation de la structure de
données distribuée, puis une section supplémentaire offre de nouveau un cas d’application
réel afin d’évaluer la solution. Pour terminer ce chapitre, le problème
de partitionnement des réseaux est évoqué et deux solutions plus récentes sont
présentées.
— Enfin, dans le chapitre 6 est présenté un bilan des travaux présentés dans cette
thèse, mais également un ensemble de perspectives de recherche.2
Etat de l’art
Sommaire
3.1 Structure de données distribuée . . . . . . . . . . . . . . . . . . . . . 66
3.2 Application de données . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.3 Applicateurs et opérations . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.4 Interfaces de programmation . . . . . . . . . . . . . . . . . . . . . . . . 68
3.5 Vue utilisateur et vue réelle . . . . . . . . . . . . . . . . . . . . . . . 69
3.6 Type de programmation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.7 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
78 Chapitre 2. Etat de l’art
Dans ce chapitre vont être introduites les notions nécessaires à la bonne compréhension
de ce manuscrit. Afin, tout d’abord, de comprendre les problématiques engendrées
par l’utilisation des machines parallèles, nous étudierons rapidement les évolutions des
architectures parallèles, et les modèles algorithmiques et de programmation qui en dé-
coulent. Par la suite, nous étudierons des notions sur le calcul et la simulation scientifique,
qui représentent les domaines d’application de cette thèse. Deux états de l’art précis seront
ensuite nécessaires, sur la décomposition de domaine, et le parallélisme implicite.
Ces notions représentent, en effet, les problématiques informatiques principales de cette
thèse. Enfin, cette thèse présentera un certain nombre de résultats expérimentaux, nous
terminerons donc ce chapitre par une discussion des choix effectués pour l’évaluation des
performances et de la difficulté de programmation des solutions.
2.1 Calcul parallèle : architectures et programmation
Dans cette première section de l’état de l’art, nous allons introduire les notions de base
du parallélisme, nécessaires à la compréhension de cette thèse. Nous commencerons par
un historique rapide des architectures parallèles, puis une description des architectures
actuelles. Nous décrirons ensuite les principaux modèles de parallélisation disponibles
pour programmer ces architectures.
2.1.1 Architectures parallèles
C’est en 1965 qu’a été exprimée dans “Electronics Magazine” la première loi de Moore,
qui n’était alors qu’un postulat fondé sur une simple observation. En effet, Gordon Moore
constata que la complexité des semiconducteurs doublait tous les ans, depuis leur apparition
en 1959. Le postulat consistait alors à supposer la poursuite de cette croissance.
C’est également dans les années 60 que sont apparus les premiers super-calculateurs,
dont le but initial était d’effectuer une exécution la plus rapide possible des instructions
d’un programme. Toutefois, bien que le monde informatique se basait alors sur la loi de
Moore, et donc sur la montée en puissance des semi-conducteurs (puis plus tard sur la
miniaturisation des transistors), l’idée de machine parallèle est apparue très rapidement.
En effet, de par la demande grandissante de performances, notamment pour les calculs
scientifiques, il est vite devenu difficile de devoir attendre la sortie d’une nouvelle gamme
de processeurs pour obtenir plus de puissance de calcul. Il n’était, de plus, pas envisageable
de racheter l’ensemble du matériel régulièrement. Ainsi, l’idée de faire collaborer
ensemble plusieurs ordinateurs pour obtenir un résultat plus rapidement se concrétisa
dans les années 60. On parla alors, pour la première fois, d’architectures multiprocesseurs,
un terme qui désignait alors une architecture SMP (Symetric Multi Processor ).
Encore utilisée à l’heure actuelle, sous une forme plus moderne, l’architecture SMP représente
un ensemble de processeurs identiques dans une même machine, qui partagent
une mémoire vive commune.
Dans les années 1970, l’architecture des super-calculateurs évolua, proposant l’utilisation
de processeurs vectoriels. Ces processeurs furent les plus puissants de leur génération2.1. Calcul parallèle : architectures et programmation 9
et connurent un grand succès. Leur puissance était due à leur capacité à appliquer une
même instruction à des parties différentes des données, de façon simultanée. Plusieurs
processeurs vectoriels ont ensuite été utilisés en parallèle pour obtenir toujours plus de
puissance.
Ce n’est qu’en 1975, et suite à l’apparition des transistors, que Gordon Moore ré-
évalua sa première loi sous la forme d’une deuxième loi qui supposait que le nombre de
transistors sur une puce pouvait doubler tous les deux ans. Une mauvaise interprétation
de cette loi fût longtemps énoncée. Un amalgame y était effectué entre le nombre de
transistors sur une puce et la fréquence d’horloge d’un processeur. Cette loi erronée s’est
pourtant avérée exacte jusqu’au début des années 2000, avant de poser des difficultés de
dissipation thermique pour des fréquences trop importantes. Dans les années 80, suite
à la miniaturisation des transistors, sont apparus les microprocesseurs. Leur puissance
était modeste, mais leur faible encombrement et leur faible consommation ont permis
l’apparition, puis la démocratisation, des ordinateurs personnels. Le perfectionnement
des techniques de miniaturisation a permis une croissance importante de la puissance des
microprocesseurs. Les microprocesseurs sont ainsi devenus très rapidement compétitifs,
en terme de performances, face aux processeurs vectoriels. Leur faible coût de fabrication
en ont fait les processeurs les plus utilisés dans les architectures parallèles. Nous allons
décrire avec plus de précision, dans la suite de cette section, les différentes architectures
parallèles issues de l’apparition des microprocesseurs.
2.1.1.1 Architectures à mémoire partagée
Architectures SMP. Comme nous l’avons décrit précédemment, cette architecture
parallèle (la plus ancienne), consiste à regrouper plusieurs processeurs au sein d’une
même machine et de leur faire partager une même mémoire vive. Cette architecture a
naturellement été étendue aux microprocesseurs, toutefois, il n’est pas possible d’utiliser
cette architecture parallèle en augmentant à l’infini le nombre de processeurs. En effet, les
processeurs d’une architecture SMP entrent tous en concurrence pour lire et écrire dans la
mémoire commune, ce qui implique que l’ajout de processeurs à cette architecture ne peut
être efficace que si la mémoire est capable d’alimenter les processeurs supplémentaires
en données à traiter. Les microprocesseurs ont très rapidement été plus rapides que les
mémoires, créant une limitation physique à cette architecture.
Architectures NUMA. Les architectures à mémoire non uniforme, NUMA (Non Uniform
Memory Access), définissent pour chaque processeur (ou petit groupe de processeurs)
l’attribution d’une sous-partie de mémoire en accès direct et très rapide. Chaque
processeur ne pourra accéder aux données des autres mémoires qu’à travers un bus d’interconnexion,
plus lent. Cette architecture vise à améliorer l’architecture SMP en réduisant
le goulot d’étranglement dû à la mémoire commune à l’ensemble des processeurs.
Architectures multi-cœurs et many-cœurs. Dans le but d’augmenter la puissance
des microprocesseurs, sans en augmenter la fréquence, le concept de cœurs multiples10 Chapitre 2. Etat de l’art
(multicore) est apparu en 2001. Cette architecture peut être vue comme une unique
puce regroupant plusieurs microprocesseurs. Dans cette architecture, la proximité des
cœurs de calcul permet une communication plus rapide entre les différentes mémoires
des différents cœurs. Certaines architectures proposent même un système de mémoire
cache partagée par les cœurs. Le principe de la mémoire cache, ou mémoire tampon, est
de fournir dans les architectures modernes une mémoire très proche des processeurs (ou
cœurs) et permettant un accès plus rapide aux données. Cette mémoire, comme son nom
l’indique sert de tampon entre la mémoire vive et les unités de calcul, elle réduit donc
les délais d’accès aux données. La mémoire cache est composée de plusieurs niveaux. Le
niveau L1, ou cache interne, est le plus rapide et le plus proche des unités de calcul.
La mémoire cache fonctionne par chargement de lignes de cache. Une ligne de cache est
de taille limitée et dépend du matériel présent dans le processeur. Lorsqu’un processeur
a besoin d’accéder à une donnée pour une opération arithmétique, cette donnée, et ses
données contiguës en mémoire, sont chargées dans une ligne de cache (suivant sa limite de
taille). Si une donnée non présente dans le cache est nécessaire (on parle alors de défaut
de cache), une ligne de cache est invalidée et une nouvelle ligne devra à son tour être
chargée etc. Ces nouveaux processeurs ont permis, tout comme l’architecture NUMA,
de réduire le goulot d’étranglement des architectures SMP. De plus ces architectures ont
permis de démocratiser les architectures parallèles dans les ordinateurs personnels. Plus
récemment sont apparus les architectures multiprocesseurs Intel MIC pour Intel Many
Integrated Core Architecture, dont, par exemple, le très médiatique accélérateur Xeon
Phi. Ces architectures regroupent plusieurs processeurs possédant chacun un très grand
nombre de cœurs. On parle alors d’architectures many-cœurs. Le nombre total de cœurs
est très important dans ces architectures et donne accès au calcul massivement parallèle
(tout comme les accélérateurs graphiques dont nous parlerons par la suite), sans pour
autant devoir apprendre de nouvelles interfaces de programmation (contrairement aux
accélérateurs graphiques).
2.1.1.2 Architectures à mémoire distribuée
Architecture en grappe. L’architecture en grappe, aussi appelée un cluster en anglais,
consiste à connecter entre elles, par un réseau d’interconnexion à très haut débit,
plusieurs machines (ou nœuds) indépendantes matériellement homogènes. Dans une architecture
en grappe, et contrairement à une architecture à mémoire partagée, chaque
nœud est indépendant et possède donc sa propre mémoire à laquelle les autres nœuds
n’ont pas accès. Les nœuds sont donc amenés, dans ce type d’architectures, à communiquer
au travers du réseau d’interconnexion. Un réseau à très haute performance étant
très coûteux, les machines d’une grappe sont géographiquement les plus proches possible,
dans une même pièce ou dans une même armoire de rangement. Il s’agit d’une
approche simple mais très favorable au calcul haute performance pour plusieurs raisons.
Tout d’abord, outre la rapidité du réseau, un travail sur la topologie des réseaux peut
rendre plus rapides les communications entre certains nœudss du cluster. Une topologie
proche de la topologie des données utilisées peut donc, par exemple, favoriser les performances
d’un parallélisme de données. De plus, une grappe est composée d’un grand2.1. Calcul parallèle : architectures et programmation 11
nombre de processeurs identiques ce qui permet de favoriser l’optimisation d’un type
de matériel donné. Avec la démocratisation des architectures multi-processeurs et multicœurs,
les grappes sont aujourd’hui composées d’un certain nombre de nœuds ou d’unités
de calcul indépendantes à mémoire partagée. En théorie, ces architectures peuvent donc
être considérées comme des architectures à mémoire distribuée, mais également comme
des architectures à mémoire hybride.
Architecture en grille. Le concept de grille est un concept proche du concept de
grappe. Toutefois, une grille consiste à relier entre elles des ressources de calcul hété-
rogènes (ordinateurs, grappes, serveurs etc.) et potentiellement distantes. En effet, le
but d’une grille est d’utiliser la puissance de calcul disponible à plusieurs endroits pour
proposer une unique architecture virtuelle possédant des ressources de calcul très importantes
et extensibles. L’utilisateur d’une grille ne fait que soumettre le lancement
de calculs et n’aura aucune information sur les machines utilisées pour son calcul. La
gestion de ce type d’architecture est donc très complexe et son utilisation est souvent
restreinte aux calculs massivement parallèles (embarrassingly parallel), qui consistent à
effectuer le même traitement un grand nombre de fois, ce qui ne provoque aucune communication
entre les ressources. Pour des calculs parallèles nécessitant des communications
entre les ressources de calcul, une unique ressource de la grille est généralement utilisée,
on retrouve alors la notion de serveur ou de cluster, par exemple. Les ressources d’une
grille pouvant être géographiquement éloignées, le réseau d’interconnexion reliant les ressources
n’est généralement pas un réseau à très haut débit, trop coûteux. Toutefois, la
plateforme expérimentale Grid’5000 relie, par exemple, une dizaine de grappes de plusieurs
villes françaises au travers du réseau à haut débit RENATER (Réseau national de
télécommunications pour la technologie, l’enseignement et la recherche).
Cloud computing. Le nuage, plus communément appelé le cloud, est un service mettant
à disposition des ressources de calcul ou de stockage distantes. Le cloud ressemble
donc aux concepts de grille et de cluster. Toutefois, il se distingue par plusieurs points.
Tout d’abord, le concept de cloud est un service grand public qui s’ouvre à tous et qui
est généralement payant. Les clusters, comme les grilles, sont souvent des outils réservés
à des utilisateurs précis sur une période de temps limitée. L’accès y est gratuit mais une
demande doit être mise en place pour utiliser ce type d’architectures. De plus, le cloud,
contrairement à la grille, n’a pas été pensé pour l’accès à des ressources délocalisées.
Très souvent les ressources d’un cloud appartiennent à une unique entité et sont regroupées
géographiquement dans un endroit (bien que des travaux regroupant plusieurs cloud
existent également). De même, le cloud se distingue de la grille par le fait qu’il n’est pas
été mis en place dans l’idée de relier des architectures hétérogènes. Le cloud est donc à
la frontière des clusters et des grilles, mais dans une optique de service commercial et
grand public.12 Chapitre 2. Etat de l’art
2.1.1.3 Architectures hétérogènes
Retour de la vectorisation. Toujours afin d’augmenter la puissance des microprocesseurs,
sans en augmenter la fréquence, les capacités de vectorisation ont été réintroduites
dans les microprocesseurs scalaires modernes. On peut notamment évoquer les instructions
SSE (Streaming SIMD Extension), qui sont associées à des registres de 128 bits sur
lesquels il est possible d’effectuer quatre opérations simultanées sur des nombres flottants
de 32 bits, ou deux opérations simultannées sur des nombres flottants de 64 bits etc. La
version la plus récente SSE4 donne accés à 47 types d’instructions. Les jeux d’instructions
AVX2 (Advanced Vector Extensions 2 ) et AVX-512, plus récents, proposent des
opérations simultanées sur des registres de 256 et 512 bits, ce qui augmente encore les
possibilités de calcul des microprocesseurs. Les registres vectoriels, ajoutés aux microprocesseurs
modernes, offrent une hétérogénéité d’architecture proposant des performances
très intéressantes.
Accélérateurs graphiques. Les processeurs graphiques, ou GPU, sont initialement
apparus pour effectuer des calculs performants et spécifiques à l’affichage graphique,
comme par exemple le rendu d’images en trois dimensions. Ils ont rapidement été massivement
parallélisés, de par la nature répétitive de leurs calculs. Initialement, ces processeurs
graphiques étaient cantonnés à un certain nombre de fonctionnalités, puis ils
sont devenus programmables, ce qui a initié une déviation de leur utilité première, pour
des calculs autres que graphiques. On ne parle alors plus de GPU mais de GPGPU. Un
GPGPU propose des unités de calcul alternatives aux CPU, et massivement parallèles.
Toutefois, il est important de noter qu’un GPU ne peut complètement s’abstraire d’un
CPU pour fonctionner, ce dernier permettant de charger des programmes et des données
en mémoire vive. Il s’agit donc d’une architecture parallèle hétérogène. Les GPU étant
peu coûteux et consommant peu d’énergie, leur utilisation dans les grands centres de calcul
internationaux devient fréquente. Dans ce cas, les GPGPU sont présents sur chaque
nœud du cluster et servent à effectuer les calculs. Les CPU, quant à eux servent à charger
en mémoire les programmes et les données et également à gérer les communications sur
le réseau d’interconnexion.
Architectures hybrides. Une architecture hétérogène, ou hybride apparaît comme
évidente après la description des architectures précédentes. Il s’agit de réutiliser l’approche
à mémoire partagée au sein de l’approche à mémoire distribuée. Cette architecture
permet d’augmenter le nombre total de processeurs utilisés et de répartir les faiblesses
sur plusieurs goulots d’étranglement au lieu d’un seul. Ce type d’architectures est devenu
une référence et est très utilisé parmi les grappes les plus puissantes du monde. Les
architectures hétérogènes peuvent être de type grappe/NUMA, grappe/multi-cœurs (ou
plus généralement grappe/CPU), mais également grappe/GPU etc.2.1. Calcul parallèle : architectures et programmation 13
2.1.2 Paradigmes et modèles de parallélisation
Avec l’apparition des architectures parallèles sont apparus les premiers problèmes de
programmation parallèle. En effet, un programme séquentiel en lui même, et sans l’aide
particulière du système d’exploitation ou de tout autre système externe de répartition de
charge sur les cœurs ou les processeurs, n’exploite pas directement les ressources d’une
machine parallèle. Or, la conception d’un programme parallèle peut s’avérer très complexe
et très dépendante des architectures utilisées. Avec l’apparition des machines parallèles
sont donc apparus également des paradigmes de programmation parallèle, offrant un ensemble
d’approches générales pour envisager un programme parallèle, puis des modèles de
programmation parallèle, permettant de concevoir de façon plus précise des programmes
sur ces machines. Les paradigmes de programmation parallèle représentent donc un niveau
d’abstraction plus bas et moins précis que les modèles de programmation parallèle.
Les modèles de programmation parallèle, même si certains sont naturellement induits
par le matériel, peuvent être implémentés pour différentes architectures parallèles. On
distingue donc les modèles de programmation des implémentations qui y sont associées
pour un modèle d’exécution donné. Par exemple un modèle de programmation parallèle
initialement pensé pour des architectures à mémoire distribuée pourrait être implémenté
sur une architecture DSM (Distributed Shared Memory) [79] qui permet de construire
un espace mémoire partagé pour tous les processeurs, bien que cet espace mémoire soit
physiquement distribué. Nous décrivons dans cette partie quelques uns des paradigmes
et des modèles de programmation parallèle les plus utilisés et les plus connus. Nous ne
décrirons en revanche pas leurs implémentations pour différents modèles d’exécution.
2.1.2.1 Paradigmes de programmation parallèle
Taxinomie de Flynn. En 1972, Michael J. Flynn définit une classification des architectures
des ordinateurs [54]. Quatre classes étaient alors répertoriées et sont représentées
dans la table 2.1. La première classe, nommée Single Instruction, Single Data (SISD) représente
les machines séquentielles n’exploitant aucun parallélisme. La deuxième classe,
Singe Instruction, Multiple Data (SIMD), représente les machines pouvant appliquer une
unique instruction à un ensemble de données. Cette classe concerne donc typiquement les
architectures vectorielles ou GPU. La troisième classe, Multiple Instruction, Single Data
(MISD), représente les machines permettant d’appliquer plusieurs instructions à la suite
sur un même donnée d’entrée. Cette classe concerne typiquement les programmes de type
pipeline ou les systèmes de tolérance aux pannes cherchant à comparer deux résultats
issus d’une même donnée. Enfin, la quatrième classe, Multiple Instruction, Multiple Data
(MIMD), représente les machines multiprocesseurs qui peuvent exécuter simultanément
des instructions différentes sur des données différentes.
Cette classification est toujours utilisée dans le parallélisme actuel, mais sous une
autre forme. En effet, les différentes classes ne sont plus représentatives d’architectures
matérielles particulières, la plupart des machines répondant à l’ensemble de ces classes. En
revanche, les classes de Flynn représentent désormais des paradigmes de programmation14 Chapitre 2. Etat de l’art
instruction unique instructions multiples
donnée unique SISD MISD
données multiples SIMD (SPMD) MIMD (MPMD)
Table 2.1 – Taxinomie de Flynn
parallèle, très souvent associés aux paradigmes de parallélisation de tâches et de données,
que nous allons décrire.
Parallélisme de tâches. Ce paradigme de programmation cherche à diviser un programme
en un ensemble de tâches qui peuvent être dépendantes, mais aussi indépendantes.
Dans ce cas c’est l’exécution du programme qui cherche à être parallélisée. Les
paradigmes de parallélisation MISD et MIMD peuvent être associés au parallélisme de
tâches. Dans le premier cas, des opérations successives sont appliquées sur un jeu de données
d’entrée, on appelle communément ce type de calcul un pipeline. L’instruction i + 1
ne peut alors être exécutée qu’une fois l’instruction i terminée. Toutefois, sur des données
d’entrées suffisamment nombreuses, le parallélisme peut apparaître en quinconce. En effet
étant donné une donnée d’entrée [x1, . . . , xn], une fois x1 calculé pour l’instruction i,
il est possible de calculer simultanément x2 pour l’instruction i et x1 pour l’instruction
i + 1. Le paradigme MIMD, quant à lui, est rencontré plus fréquemment et offre plus de
possibilités de parallélisation. Dans ce cas, on cherchera à identifier des tâches travaillant
sur des données différentes, ce qui rend les tâches indépendantes les unes des autres. Toutefois,
le développeur devra se charger de synchroniser les différentes tâches ensemble afin
de garantir la cohérence des résultats. Nous pouvons enfin noter la paradigme MPMD
(Multiple Program, Multiple Data), qui étend le concept MIMD à des programmes. Ainsi,
chaque processeur peut appliquer un ou plusieurs programmes qui lui sont propres à des
données éventuellement différentes des autres processeurs de façon indépendante. Les
synchronisations nécessaires au bon fonctionnement du programme parallèle sont alors à
la charge de l’utilisateur.
Parallélisme de données. Dans ce paradigme, le parallélisme se focalise sur la façon
dont les données sont distribuées sur les différents processeurs. L’ensemble des processeurs
effectuent alors le même jeu d’instructions sur des données d’entrée qui leurs sont propres.
Dans ce type de parallélisme les tâches effectuées par le programme sont peu modifiées.
Il faut toutefois réflechir et consevoir les communications, les échanges ou les synchronisations
nécessaires entre les processeurs pour que le programme parallèle soit correct
et donne le même résultat qu’en séquentiel. Les paradigmes SIMD et SPMD (Simple
Program, Multiple Data) sont associés au parallélisme de données. Ils représentent le
même type de parallélisation, toutefois SIMD est associé aux architectures vectorielles et
GPU, où la notion d’instruction est clairement définie et synchrone. L’approche SPMD
est plus vaste et moins tournée vers la solution matérielle. Elle peut s’appliquer à des
architectures à mémoire partagée comme distribuée. Ce paradigme considère une exécution
indépendante d’un programme sur chaque processeur, et sur des données différentes,2.1. Calcul parallèle : architectures et programmation 15
et met à la charge du programmeur les synchronisations nécessaires à la cohérence du
calcul général. Ce type de parallélisation est l’une des plus utilisée, notamment pour les
architectures à mémoire distribuée.
Paradigmes induits par le matériel. Nous abordons maintenant deux paradigmes
de programmation parallèle connus et induits par le matériel, qui sont utilisés par la plupart
des modèles présentés par la suite. Dans les architectures à mémoire partagée, les
processus peuvent interagir par l’écriture et la lecture dans des espaces mémoire partagés
et communs. Ces architectures permettent donc des interactions entre les processus par
la simple utilisation de la mémoire de la machine, mais font intervenir des problèmes
de concurrence d’accès aux données ainsi que de cohérence ou d’intégrité des données.
Le paradigme de programmation parallèle le plus utilisé pour gérer ces problématiques,
et que nous appelons paradigme à verrous, consiste à fournir des mécanismes permettant
d’assurer l’exclusion temporaire de l’accès aux données pour en garantir l’intégrité.
Le mécanisme le plus couramment utilisé se base sur des verrous d’exclusion mutuelle,
appelés mutex. Un verrou sur une variable n’est attribué qu’à un unique processus, ce
qui garantit qu’aucun autre processus ne pourra accéder ou écrire dans cette variable
jusqu’à l’obtention, à son tour, d’un verrou. Pour ce qui est des architectures à mémoire
distribuée, le paradigme le plus naturel, et parmi les plus utilisés, de passage de messages,
est venu du simple constat que, dans ces architectures, les processus ne partagent pas
d’espace d’adressage commun et qu’il est nécessaire d’échanger des messages pour que ces
processus puissent communiquer entre eux. Ce paradigme n’introduit donc pas de problèmes
de concurrence et d’intégrité des données, mais un problème de communication.
Le niveau d’abstraction le plus bas pour mettre en place ce paradigme consiste à utiliser
le réseau des machines et donc à faire, par exemple, appel à la programmation de sockets
Unix, qui permettent l’envoi d’octets à destinations d’une adresse réseau spécifique. De
nombreux modèles de programmation parallèle sont issus de ce paradigme.
2.1.2.2 Modèles de programmation parallèle
Mémoire partagée. Les modèles de programmation induits des architectures à mé-
moire partagée sont très souvent basés sur du parallélisme de tâches, mais peuvent également
se baser sur du parallélisme de données. Le standard des threads POSIX (ou
pthreads) [96] est l’un des modèles les plus répandus du parallélisme pour architectures
à mémoire partagée. Ce modèle est basé sur le paradigme de verrous évoqués dans la
partie précédente. Il permet de définir la création d’un nouveau processus léger (appelé
un thread), dont l’exécution sera gérée par le système, en suivant une politique d’ordonnancement.
A sa création, une tâche est assignée au thread et sera effectuée en parallèle
du programme principal, qui pourra continuer son exécution. Un certain nombre de routines
permettent ensuite des synchronisations entre les processus créés, et permettent de
poser des verrous pour la modification de données.
Le modèle de directives OpenMP [34], qui sera décrit avec précision dans la suite
de cette thèse, est le deuxième modèle très utilisé sur les architectures à mémoire partagée.
Il permet d’ajouter du multi-threading (le fait de créer plusieurs processus légers16 Chapitre 2. Etat de l’art
pour certaines tâches du programme) dans du code C, C++ ou Fortran, par l’ajout de
directives, sans modifications majeures du code, mais avec des résultats de performance
limités. Ce modèle est principalement basé sur la parallélisation de boucles, ou sur le
parallélisme de tâche dans lequel il est explicitement indiqué quels sont les différents
travaux disponibles pour les threads. Il est également demandé à l’utilisateur de déclarer
les variables locales et partagées du programme, afin de positionner automatiquement,
par la suite, des exclusions mutuelles pour l’accès aux données partagées.
Enfin, notons qu’il existe un modèle de programmation parallèle, nommé PGAS [6]
(Partitioined Global Adress Space), basé sur le concept d’espace d’adressage mémoire
global partitionné. Ce modèle propose une vision distribuée de la mémoire physiquement
partagée par les threads. Ce modèle suggère donc la création d’un espace d’adressage
virtuel partitionné global, auquel chaque thread a physiquement accès, mais dont les
traitements sont partitionnés pour chaque thread. Ce modèle permet donc d’éviter, en
grande partie, les problèmes de concurrence d’accès aux données, que l’on peut trouver
dans tous les modèles basés sur le paradigme à verrous. Ce modèle de programmation
est donc basé sur le paradigme de parallélisme de données, et s’implémente généralement
par la parallélisation d’un traitement sur un tableau ou un conteneur. Notons enfin que,
dans le modèle PGAS, le partitionnement proposé pour le traitement de données peut
changer aucours de l’exécution du programme parallèle.
Mémoire distribuée. Le modèle de programmation parallèle Message Passing Interface
(MPI) [61] est basé sur la paradigme de passage de messages et définit un protocole
de communication entre des processus indépendants et éventuellement distants. Ce modèle
a initialement été défini pour les architectures à mémoire distribuée, toutefois il
obtient également de très bonnes performances sur des architectures à mémoire partagée
et à mémoire hybride distribuée/partagée. Ce modèle est composé de communications
point-à-point, permettant de décrire l’envoi d’un message à un processeur précis, et de
communications collectives, permettant d’envoyer des informations à l’ensemble ou à une
sous-partie des autres processus. Notons que les communications point-à-point peuvent
être bloquantes ou non bloquantes pour permettre certaines optimisations dans les programmes
parallèles implémentés. Une communication non bloquante rendra la main avant
que la communication ne soit terminée, à l’inverse d’une communication bloquante. Il est
alors à la charge de l’utilisateur de s’assurer, aux endroits adéquats de son programme,
que la communication est terminée. MPI contient également des interfaces permettant
de créer des topologies entre les processus, de créer des types d’envois particuliers etc. Il
existe plusieurs implémentations génériques de cette norme, comme Open MPI [56] ou
MPICH2 [63], et il est de plus possible pour les constructeurs d’écrire leur propre implé-
mentation afin de l’optimiser à leur matériel. C’est notamment le cas de Intel MPI [22].
Ce modèle (et ses implémentations) a connu un grand succès depuis sa création dans les
années 90, et s’impose aujourd’hui comme l’un des outils de référence de la parallélisation,
tout particulièrement dans le domaine du calcul scientifique et de la haute performance.
Il est également important, pour la compréhension de cette thèse, de s’attarder sur
l’un des modèles de programmation les plus connus et les plus anciens, le modèle Bulk2.1. Calcul parallèle : architectures et programmation 17
Synchronous Parallel [92, 118], proposé par Valiant en 1990. Le modèle architectural de
BSP correspond naturellement à une machine à mémoire distribuée. En effet, dans ce
modèle la machine modélisée est une machine à mémoire distribuée composée d’un ensemble
de processeurs à mémoire indépendante. Toutefois, comme MPI, ce modèle peut
tout à fait s’appliquer à une architecture à mémoire partagée. Les caractéristiques d’une
machine BSP sont définies par quatre paramètres. Le premier, p, représente le nombre
de processeurs sur la machine. Le deuxième, r, représente la puissance d’un processeur
(mesurée en nombre d’opérations flottantes par seconde). L représente, quant à lui, le
temps nécessaire pour effectuer une synchronisation globale entre tous les processeurs. Et
pour finir, g représente le temps nécessaire pour l’envoi d’une donnée, du type souhaité,
sur le réseau. L’élément de base d’un algorithme ou d’un programme BSP est appelé une
super-étape (ou superstep). Un programme BSP est constitué d’une succession de super-
étapes qui peuvent être composées (1) de plusieurs phases de calculs indépendantes, (2)
de phases de communications, et (3) de phases de synchronisation entre les processeurs.
On distingue plus généralement des super-étapes de calculs, dans lesquelles chaque processeur
effectue une séquence d’opérations sur des données locales, et des super-étapes de
communications, où chaque processeur envoie et reçoit des messages. Quelle que soit la
représentation d’une super-étape, elle est toujours terminée par une synchronisation des
processeurs. Dans cette phase de synchronisation chaque processeur vérifie que l’ensemble
des tâches à accomplir sont terminées localement, et préviens les autres processeurs. Tous
les processeurs attendent les messages de terminaison des autres processeurs avant que la
super-étape ne se termine et qu’une autre puisse être commencée. Ce type de synchronisation
est appelé bulk synchronisation. L’une des forces du modèle BSP est de proposer une
fonction de coût calculée à partir des paramètres de la machine et de l’algorithme BSP
formulé en super-étapes. Étant donné une super-étape de calcul s, on note ω
(s)
le temps
d’exécution de la super-étape, qui est égal au temps maximum d’exécution, parmi tous les
processeurs. Nous avons alors ω
(s) = max
0≤i 0 représente le pourcentage de déséquilibre toléré, et en minimisant le nombre
d’arêtes coupées dans ce partitionnement. Cette dernière métrique, qui vise à couper le
moins d’arêtes possible lors du partitionnement, est aussi appelée la métrique edge-cut. Le
partitionnement standard de graphe est notamment implémenté dans les partitionneurs
Chaco [67], METIS [77] et Scotch [100].
La méthode standard de partitionnement de graphe a longtemps été la seule méthode
utilisée. Toutefois ses limites ont été très largement évoquées et résumées dans les travaux
de Hendrickson et Al [66]. La critique de cette approche repose sur deux faiblesses : la
métrique edge-cut et le modèle en lui-même. Nous n’allons pas évoquer ici l’ensemble des
faiblesses de la métrique et de la méthode de partitionnement, nous pouvons toutefois
noter deux points que nous considérons comme importants, et qui sont résolus par la
méthode de partitionnement d’hypergraphe décrite par la suite.
La première faiblesse que nous souhaitons évoquer concerne la métrique edge-cut.
Cette métrique dénombre les arêtes qui doivent être coupées suite au partitionnement
mis en place. La limite de cette métrique vient du fait qu’elle n’est pas proportionnelle au
volume de communication nécessaire dans un programme parallèle. En d’autres termes,
cette métrique ne modélise pas correctement les communications pour la plupart des
problèmes de partitionnement. Prenons un exemple afin d’illustrer cette caractéristique.
Étant donné le graphe représenté dans la figure 2.9, partitionné en trois parties, une pour
chaque processeur P0, P1 et P2. Étant donné que chaque arête e ∈ E représente un coût
de communication c(e) = 1 + 1 = 2 (afin de représenter une communication symétrique),
alors un partitionnement de graphe standard trouverait la métrique edge-cut comme
égale à c(e)×5 = 10. Dans cet exemple, pourtant, nous pouvons observer que le sommet
v2 est relié par deux arêtes à la partition du processeur P1, ce qui signifie qu’un unique2.3. Distribution de données 37
envoi de v2 est nécessaire dans l’implémentation. En procédant ainsi pour les sommets
v5 et v8 nous trouvons que le véritable volume de communication est égal à 7.
v1
v2 v3
v4
v8 v9 v6
v5
v7
P0
P1
P2
Figure 2.9 – Graphe donnant un exemple de partitionnement où la métrique edge-cut ne
représente pas le volume de communication.
La deuxième faiblesse que nous évoquerons ici est le fait que la méthode standard
de partitionnement de graphe ne permet d’exprimer que des dépendances symétriques.
Une arête représente, en effet, un envoi de données des deux sommets la constituant.
Ainsi la méthode de partitionnement manque d’expressivité pour certains problèmes
asymétriques.
2.3.1.2 Partitionnement d’hypergraphes
Un hypergraphe H = (V, N ) est composé d’un ensemble de sommets, ou nœuds,
noté V , et d’un ensemble N d’hyper-arêtes. Chaque hyper-arête est un sous-ensemble
de V . Une hyper-arête est donc une généralisation de la notion d’arête dans un graphe,
où plus de deux sommets de V peuvent être reliés entre eux. Dans le cas spécifique où
chaque hyper-arête contient exactement deux sommets, on revient alors à la définition
d’un graphe. Tout comme pour un graphe, tout sommet v ∈ V d’un hypergraphe peut
être pondéré par ω(v), et chaque hyper-arête n ∈ N peut, elle aussi, être associée à un
poids, ou un coût, que l’on note c(n). Ces poids sont généralement des réels positifs,
mais dans cette thèse nous considérerons ces poids comme des entiers naturels. Étant
donné un sous-ensemble S de V , ω(S) est défini comme la somme des poids de chacun
des sommets de S.
Le partitionnement p-way d’un hypergraphe H = (V, N ) est défini par p sousensembles
de V , V0, . . . , Vp−1 tels que pour tout i ∈ J0, pJ, Vi ⊂ V , Vi 6= ∅, et tels
que pour tout i, j ∈ J0, pJ, si i 6= j, alors Vi ∩ Vj = ∅. Le problème de partitionnement
d’un hypergraphe est alors de trouver un partitionnement p-way qui satisfasse la38 Chapitre 2. Etat de l’art
contrainte d’équilibrage (2.15), et qui minimise la métrique de coût suivante :
X
n∈N
c(n)(λ(n) − 1), (2.16)
où λ(n) est le nombre de parties connectées à une même hyper-arête n ∈ N ,
λ(n) = |{Vi
: 0 ≤ i < p et Vi ∩ n 6= ∅}|. (2.17)
Cette métrique, que l’on cherche à minimiser, est appelée la métrique-(λ − 1).
Le premier modèle de partitionnement d’hypergraphe est apparu dans les travaux
de Çatalyürek et Al [26] . Son efficacité pour modéliser certains problèmes de partitionnement
a été démontrée [28]. L’avantage principal de ce modèle est sa capacité à
représenter exactement le volume de communications, ce qui n’est pas le cas en utilisant
la métrique edge-cut du modèle de partitionnement de graphe. Reprenons, par exemple,
le graphe G = (V, E) de la figure 2.9, et construisons un hypergraphe H = (V, N ) où
|N | = |V |. L’ensemble des hyper-arêtes N est défini de façon à ce que chaque sommet
vi ∈ V corresponde à une hyper-arête hi ∈ N qui contient vi et l’ensemble de ses sommets
voisins dans G. Par exemple, l’hyper-arête du sommet v2 contient alors les sommets v2,
v8, v6 et v5. Cette hyper-arête contient donc des sommets des processeurs P2 et P1, son
coût est donc de 2. Lors du partitionnement, on retrouve alors la métrique de coût de
communication définie dans l’équation (2.16) qui est bien égale à 7 pour cet exemple.
Pour finir, la méthode de partitionnement d’hypergraphe permet la représentation de
problèmes asymétriques.
2.3.2 Cas particulier du partitionnement de matrices
Le modèle de partitionnement d’hypergraphes a été utilisé dans de nombreux travaux
afin de représenter les communications d’une multiplication de matrice creuse par un
vecteur [28]. Ce traitement est l’un des plus courants dans les calculs scientifiques et a
été très largement étudié. Un ensemble de méthodes de partitionnement, spécifiques à
ce problème, a été élaboré. Un parallèle pouvant être fait de plusieurs façons entre un
hypergraphe, ou un graphe, et une matrice creuse, les méthodes et les partitionneurs qui
ont été développés pour ce type de traitements permettent également de résoudre d’autres
problèmes de partitionnement. Dans cette thèse, le partitionneur Mondriaan [120], qui
implémente plusieurs de ces techniques, est utilisé. Nous allons donc décrire, dans cette
section, l’ensemble des modèles de partitionnement qui ont été mis en place pour le
problème de multiplication matrice creuse-vecteur. Nous ne décrirons pas, en revanche,
comment utiliser ces modèles sur la multiplication matrice creuse-vecteur en elle-même,
puisque cette thèse ne s’intéresse pas particulièrement à ce problème. Ces détails peuvent
être trouvés dans les travaux de Bisseling et Al [18].
2.3.2.1 Partitionnement à une dimension
Voyons une première façon de transformer une matrice vers un hypergraphe. Considé-
rons une matrice creuse A de taille m×n. Notons alors ai,j ses coefficients avec i ∈ J1, mJ2.3. Distribution de données 39
et j ∈ J1, nJ. On peut alors considérer que chaque colonne j de la matrice A est repré-
sentée par un sommet de l’hypergraphe avec un poids ω(j) égal au nombre de valeurs
non nulles dans la colonne j. Considérons ensuite que chaque ligne i de la matrice A est
représentée par une hyper-arête qui contient les sommets j pour lesquels ai,j 6= 0. Pour
finir, considérons que le coût d’une hyper-arête est égal à 1. Cette représentation d’une
matrice creuse A par un hypergraphe Hr est appelée le modèle row-net, qui signifie que
les hyper-arêtes (net) représentent les lignes de la matrice (row). Dans ce cas un partitionnement
p-way de l’hypergraphe Hr amène à un partitionnement à une dimension,
ou 1D, de la matrice A. Ce partitionnement distribue donc les colonnes de la matrice
A en p parties différentes. Chaque colonne étant pondérée par ω, le nombre de valeurs
non nulles dans la colonne, le partitionnement de Hr distribue de façon équilibrée les
valeurs non nulles de la matrice A en suivant la contrainte d’équilibrage définie dans
l’équation (2.15). Pour finir, le volume de communications causé par la séparation d’une
ligne de A dans plusieurs parties est minimisé par le fait qu’une ligne représente une
hyper-arête et minimise donc la métrique-(λ − 1) représentée dans l’équation (2.16).
Notons, pour terminer, qu’il est également possible de faire un partitionnement 1D de la
matrice A par le modèle column-net qui, à l’inverse, associe les lignes de A aux sommets
de l’hypergraphe Hc et les colonnes de A aux hyper-arêtes de Hc.
2.3.2.2 Partitionnements à deux dimensions
Un partitionnement à deux dimensions, ou 2D, de la matrice A est également possible
en procédant de plusieurs façons que nous allons décrire ici. Dans un partitionnement
de matrice 2D, les colonnes comme les lignes de la matrice peuvent être découpées en
plusieurs parties, ce qui implique des communications dans les deux directions. Le partitionnement
2D d’une matrice creuse a l’avantage de généraliser le problème, ce qui peut
conduire à une solution plus intéressante avec un meilleur équilibrage ou moins de communications.
Nous évoquerons ici quatre modèles principaux de partitionnement à deux
dimensions.
Méthode coarse-grain. Pour partitionner une matrice A, la méthode coarse-grain a
la particularité d’essayer de conserver les rapprochements naturels des valeurs non nulles
de la matrice par colonnes et par lignes, tout comme le fait un partitionnement 1D, mais
en prenant en compte les deux dimensions. Il existe plusieurs types de méthodes dites
coarse-grain. On peut, par exemple, noter le partitionnement cartésien, très utilisé pour le
partitionnement de maillages cartésiens (nous reviendrons plus en détails dessus). Nous
pouvons également évoquer l’approche Mondriaan [120] qui consiste à successivement
partitionner en deux (ou bipartitionner) la matrice jusqu’à atteindre p parties. A chaque
bipartitionnement, les méthodes row-net et column-net sont essayées, et celle proposant
le meilleur partitionnement est conservée. Les deux hypergraphes Hr et Hc sont donc
partitionnés à chaque itération. Ainsi, cette méthode effectue des partitionnements 1D
mais qui peuvent être effectués dans les deux directions ce qui permet d’obtenir un
partitionnement 2D et un plus grand nombre de solutions potentielles.40 Chapitre 2. Etat de l’art
Méthode fine-grain. À l’inverse de la méthode coarse-grain, qui se base sur l’unité des
lignes et des colonnes de la matrice, la méthode fine-grain [30] se propose de partitionner
chaque valeur non-nulle de façon indépendante dans p partitions. Pour cela un nouveau
type d’hypergraphe, noté Hf , est construit à partir de la matrice A. Chaque sommet
de cet hypergraphe représente non plus les lignes ou les colonnes de la matrice, mais
chaque élément non nul de la matrice. Deux types d’hyper-arêtes sont alors représentées.
Une hyper-arête ligne i contient l’ensemble des sommets correspondants aux valeurs non
nulles de la ligne i de A. Une hyper-arête colonne j, quant à elle, contient l’ensemble des
sommets correspondants aux valeurs non nulles de la colonne j de A. Le nombre total de
sommets dans l’hypergraphe Hf est égal au nombre de valeurs non nulles, et le nombre
d’hyper-arêtes est au plus égal à m + n. Une fois cet hypergraphe construit, il peut être
partitionné en p sous-ensembles de sommets en suivant la contrainte d’équilibrage (2.15)
et en minimisant la métrique de coût (2.16).
Méthode hybride. La méthode hybride [18] reprend le principe de l’approche Mondriaan
par bipartitionnements successifs, mais en ajoutant aux partitionnements des hypergraphes
Hr et Hc le partitionnement de l’hypergraphe Hf de la méthode fine-grain.
Méthode medium-grain. La méthode medium-grain a récemment été proposée dans
les travaux de Pelt et Al [101]. Cette méthode sépare tout d’abord la matrice A en deux
matrices Ac
et Ar
. La valeur ai,j est ainsi assignée à la matrice Ar
si le nombre de
valeurs non nulles dans la ligne i est plus grand que dans la colonne j, et à Ac dans le
cas contraire. La méthode crée alors une matrice :
B =
In (Ar
)
T
Ac
Im
, (2.18)
où Im est la matrice identité de taille m × m, et In la matrice identité de taille n × n. La
méthode de partitionnement 1D row-net est ensuite utilisée pour partitionner la matrice
B. La matrice Ar
étant transposée dans B, il s’agit là encore d’un partitionnement à
deux dimensions, où la dimension de partitionnement, pour chaque valeur, est choisie en
fonction de son attribution dans Ar ou Ac
.
2.3.3 Cas particulier du partitionnement de maillages
Cette thèse traite de solutions de parallélisme implicite pour le cas des simulations
scientifiques dont la résolution est basée sur des maillages. Nous allons, dans cette partie,
étudier le cas spécifique, et pratique, du partitionnement de maillages pour les applications
parallèles. Nous allons, tout d’abord étudier l’état de l’art pour le cas des maillages
réguliers à deux dimensions, puis nous traiterons le cas des maillages non-structurés.
2.3.3.1 Maillages à deux-dimensions réguliers
Comme nous l’avons vu, un maillage régulier à deux dimensions peut être de deux
types. Soit un maillage cartésien, soit un maillage curvilinéaire, mais qui peut alors être2.3. Distribution de données 41
ramené à un maillage cartésien. Un maillage cartésien est bien souvent représenté, dans
les esprits, comme une matrice. Par conséquent un partitionnement fine-grain pourrait,
par exemple, être envisagé pour partitionner les éléments non nuls de la matrice (tous
les éléments dans le cas d’une matrice dense). Un maillage cartésien étant dense, des mé-
thodes plus directes, et plus simples à mettre en œuvre, permettent d’obtenir rapidement
des partitionnements équilibrés et contenant peu de communications.
Notons par exemple le partitionnement rectiligne [97], qui est obtenu en partitionnant
tout d’abord les lignes du maillage en P parties, puis les colonnes en Q parties, tel que
p = P Q. On peut ensuite assigner chaque combinaison obtenue à chaque processeur. Une
variante de ce partitionnement est d’utiliser la même technique mais suivant une unique
dimension. On pourra aussi appeler le partitionnement rectiligne 2D, le partitionnement
par blocs, et le partitionnement rectiligne 1D, le partitionnement par blocs-lignes.
Dans certains cas, un maillage cartésien peut être non-uniforme. C’est le cas des
maillages dits adaptatifs. Ce type de maillage peut être intéressant pour résoudre des
EDP, puisqu’il permet d’adapter le maillage avec plus ou moins de précision (de points)
suivant les zones d’intérêt du domaine. Dans ce cas, il peut être à la fois plus compliqué
d’équilibrer le partitionnement, mais aussi de minimiser les communications. Les
travaux de Berger et Al [13] ont introduit en 1987 le partitionnement par bissection ré-
cursive orthogonale (ORB) pour ce type de maillages. La figure 2.10 représente les trois
partitionnements de maillages 2D introduits ici.
Figure 2.10 – De gauche à droite : partitionnement en blocs, en blocs-lignes et bissection
récursive orthogonale
2.3.3.2 Maillages non-structurés
Nous venons de voir que le partitionnement des maillages réguliers est un cas de
partitionnement relativement simple et pour lequel un grand nombre de possibilités de
résolution est disponible. Certains maillages sont eux beaucoup plus compliqués à partitionner
de par leur structure irrégulière. La méthode des éléments finis, que nous avons
décrite dans la partie 2.2.4.3, mène dans la plupart des cas à la création d’un maillage
non-structuré qui permet de représenter avec fidélité et avec plus ou moins de précision
la surface ou le volume d’un objet. La plupart du temps les cellules de ces maillages représentent
des triangles (2D) ou des tétraèdres (3D), ce qui permet, suivant la taille des
mailles, de pouvoir représenter très précisément les surfaces ou les volumes. Une maille42 Chapitre 2. Etat de l’art
peut avoir une taille quelconque et peut être un triangle de forme quelconque dans l’espace.
Le voisinage y est donc régulier, dans le sens où toutes les cellules ont par exemple
trois cellules voisines (dans le cas de triangles), mais les structures de données permettant
de représenter un maillage non structuré sont elles plus complexes et plus lourdes que
dans un maillage cartésien. Par conséquent, là où un maillage cartésien peut facilement
être identifié à une matrice, le maillage non-structuré est lui plus facilement représenté
par un graphe. Le problème de partitionnement d’un maillage non-structuré repose donc
sur le fait de trouver la bonne représentation du maillage en graphe pour ensuite pouvoir
le partitionner. Quatre représentations sont très souvent utilisées dans la littérature :
— La première, et la plus simple, est de considérer chaque point du maillage comme
un sommet d’un graphe, et chaque arête d’une face du maillage comme une arête
du graphe. Cette représentation est appelée le graphe nodal du maillage [122].
— La deuxième représentation, appelée le graphe dual du maillage [46, 106], associe
chaque cellule du maillage à un sommet du graphe. Deux sommets du graphe
sont reliés par une arête si deux cellules du maillage ont un côté, ou une face, en
commun.
— La troisième représentation combine le graphe nodal et le graphe dual afin d’obtenir
une représentation plus précise sur le maillage [122].
— Enfin, le graphe dual-diagonal représente chaque cellule du maillage par un sommet,
et deux sommets sont reliés par une arête si les cellules ont un point en
commun dans le maillage. Notons que cette représentation peut elle aussi être
combinée au graphe dual pour représenter avec plus de précision le maillage.
La figure 2.11 illustre le graphe nodal, le graphe dual et le graphe dual-diagonal d’un
maillage non structuré 2D. Une fois que la représentation du maillage par un graphe
Figure 2.11 – De gauche à droite et de haut en bas : le maillage non structuré 2D, son graphe
nodal, son graphe dual et son graphe dual-diagonal.2.3. Distribution de données 43
est choisie, les partitionneurs de graphes peuvent être utilisés, comme par exemple
Jostle [122], Metis [46, 106] et Scotch [100, 106].
Dans les travaux de Zhou et Al [131], le partitionnement d’hypergraphe est utilisé pour
partitionner un maillage non-structuré 3D contenant 1.07 milliard de cellules, 163840
processeurs. Le maillage y est représenté par un hypergraphe dans lequel chaque sommet
est associé à une cellule du maillage, et chaque hyper-arête correspond à une cellule et aux
cellules partageant une face avec celle-ci. Le partitionneur Zoltan [27] est ensuite utilisé.
Il est donc également possible d’utiliser le modèle de partitionnement d’hypergraphes
pour partitionner un maillage non-structuré et représenter plus fidèlement le volume de
communications.
2.3.4 Partitionnements particuliers
2.3.4.1 Méthodes à contraintes et objectifs multiples
Considérons un problème de partitionnement d’hypergraphe, ou de graphe, défini
comme dans les parties précédentes. On peut alors appeler la contrainte d’équilibrage
de l’équation (2.15) la contrainte du partitionnement, et la minimisation des métriques
(λ − 1) de l’équation (2.16), ou edge-cut, l’objectif du partitionnement. Un partitionnement
à contraintes multiples [9, 108] consiste alors à appliquer un tableau de poids à
chaque sommet de l’hypergraphe ou du graphe au lieu d’un simple poids. Ce tableau
représente les multiples contraintes d’équilibrage à respecter lors du partitionnement. De
même un partitionnement à objectifs multiples [58] appliquera un ensemble de coûts de
communications à une hyper-arête de l’hypergraphe, ou à une arête du graphe.
Pour effectuer un partitionnement à contraintes multiples, Aykanat et Al [108] ont
modifié l’algorithme multilevel dans ses trois phases. En effet, les phases de réduction,
de bi-partitionnement et de raffinement ont été modifiées pour tenir compte de plusieurs
contraintes de partitionnement. Dans les travaux de Schloegel et Al [58], l’algorithme
de partitionnement pour objectifs multiples s’effectue en trois phases. Tout d’abord un
algorithme de partitionnement k-way du partitionneur METIS [77] est appliqué pour
chacun des objectifs séparément. Un nouveau poids est ensuite attribué à chaque arête
du graphe initial. Ce poids est calculé comme une fonction des différents poids de l’arête
(objectifs multiples), du meilleur résultat de la métrique edge-cut obtenu dans la première
phase, et du vecteur de préférence des objectifs précisé par l’utilisateur. Enfin, un dernier
partitionnement k-way est opéré sur le graphe avec les nouvelles pondérations d’arêtes.
2.3.4.2 Méthode pour les calculs à phases
Certains calculs scientifiques ou simulations ont la particularité d’être organisés en
plusieurs phases. Cette organisation peut être de plusieurs types dans une simulation.
Tout d’abord, il est possible qu’il s’agisse de différentes phases de calcul, mais toutes
exécutées sur l’ensemble du maillage. Dans ce cas, les différentes phases peuvent avoir
un impact sur le type de communications et il est alors possible d’utiliser des partitionnements
à contraintes ou objectifs multiples. Il est également possible que les différentes44 Chapitre 2. Etat de l’art
phases du calcul soient exécutées sur des maillages différents, soit complètement distincts
les uns des autres, soit reliés entre eux par une composition de maillages (section 2.2.2.2).
Nous traitons plus en détails ce cas dans la section 5.5 de cette thèse. Enfin, il est également
possible que les différentes phases d’un calcul agissent sur différentes parties
d’un même maillage. Dans ce cas une contrainte d’ordonnancement apparaît à la fois
sur les calculs, mais aussi sur le maillage. Les travaux de Walshaw et Al [125] traitent
de ce type de calculs à phases. Dans ces travaux de partitionnement, les sommets du
graphe vont être classifiés afin de déterminer la phase qui les concerne. Le premier
sous-ensemble de sommets est alors partitionné, puis les sous-ensembles suivants seront
partitionnés à leur tour en tenant compte des partitionnements précédents, grâce à la
notion de point stationnaire introduite dans ces travaux. Notons que la méthode est
également capable de traiter des sommets qui appartiennent à plusieurs phases du calcul.
Le problème de partitionnement de graphes est un problème qui a largement été
étudié et dont quelques représentations ont étés présentées dans cette section. Nous utiliserons,
dans le chapitre 5 plus spécifiquement, certaines de ces notions afin de présenter
le problème de partitionnement de réseaux, et deux méthodes de résolution.
2.4 Le parallélisme implicite
Nous allons désormais aborder le cœur de cette thèse : le parallélisme implicite. Derrière
ce terme se cache le fait de vouloir apporter un accès facile, simplifié, voire transparent,
au calcul haute performance et au parallélisme à des utilisateurs non spécialistes, et
même non-informaticiens. En effet, si la plupart des scientifiques ont de plus en plus besoin
des machines parallèles pour obtenir des simulations intéressantes, ils ne savent pas
pour autant les utiliser à leur pleine capacité, soit par manque de temps et de ressources
humaines, soit par manque de connaissances sur les architectures matérielles utilisées. De
nombreux travaux sur le parallélisme implicite ont vu le jour presque simultanément avec
l’arrivée d’architectures parallèles, complexes à programmer. Ce domaine de recherche
est très actif et le sera probablement de plus en plus étant donné la complexité des architectures
parallèles actuelles et à venir (hiérarchie de mémoires complexes, systèmes
massivement multi-cœurs, systèmes hybrides etc.). Nous allons présenter, dans cet état de
l’art, un aperçu des solutions les plus utilisées et les plus reconnues du parallélisme implicite.
Pour cela, nous allons tout d’abord présenter des solutions permettant de classifier
les problèmes parallèles, nous évoquerons ensuite quelques-uns des nombreux langages
et des nombreuses bibliothèques de parallélisme partiellement implicites. Enfin nous entrerons
à proprement parlé dans les solutions de parallélisme implicite totale, que nous
essaierons de classer par niveau d’abstraction, le niveau d’abstraction le plus haut (qui ne
correspond pas nécessairement au meilleur niveau d’abstraction, et c’est l’une des discussions
de cette thèse) étant celui qui cache le plus de technicités et qui demande le moins
d’apprentissage à l’utilisateur. Ainsi nous évoquerons les bibliothèques de parallélisme
implicite générales, les solutions à patrons, puis pour terminer les solutions spécifiques
au domaine du calcul scientifique.2.4. Le parallélisme implicite 45
2.4.1 Classification de problèmes et aide à la parallélisation
Le niveau d’abstraction le plus bas du parallélisme est de considérer qu’il est préférable
de laisser les utilisateurs coder leurs propres programmes parallèles, mais de les aider dans
la conception de ces programmes. Les modèles de programmation tels que BSP [92, 119]
ou MPI [61], ainsi que le paradigme SPMD, décrits précédemment, sont des exemples de
solutions permettant de simplifier le parallélisme et proposent un niveau d’abstraction
plus haut que la programmation parallèle de base. En effet, pour certains types d’architectures
parallèles et pour certains types de problèmes, ces modèles de programmation
parallèle peuvent être utilisés relativement facilement. Il est d’ailleurs fréquent d’initier
les scientifiques à la programmation parallèle par ce type de modèles [17, 87].
Toutefois, lorsque les algorithmes deviennent plus compliqués à mettre en œuvre,
comme par exemple dans le cas de problèmes irréguliers, les modèles les plus simples
sont souvent limités, et une réflexion différente sur la conception du programme parallèle
est souvent nécessaire. Les travaux de Pingali et Al [103] proposent une classification
des algorithmes afin de mieux identifier la façon dont ils peuvent être parallélisés effi-
cacement. Il a ainsi été proposé The TAO of Parallelism in Algorithms, qui peut être
vu comme une abstraction des algorithmes. Cette abstraction permet, d’une part, d’extraire
les propriétés importantes pour la parallélisation du problème et, d’autre part, de
mettre de côté les propriétés n’entrant pas en compte dans les choix de parallélisation.
Dans l’analyse-TAO, la définition d’un algorithme est inspirée de l’aphorisme de Niklaus
Wirth [129] : Program = Algorithm + Data structure. L’abstraction proposée par
l’analyse-TAO est appelée operator formulation of algorithms. L’algorithme y est traduit
comme un graphe représentant les opérations effectuées sur des types de données abstraits,
noté graphe ADT. L’analyse-TAO se décompose en trois étapes. Tout d’abord la
définition de la topologie, qui représente la structure de données sur laquelle les calculs
sont effectués, puis les nœuds actifs, qui représentent les éléments à calculer dans une
opération donnée, et enfin les opérateurs, qui représentent les actions à effectuer sur les
nœuds actifs.
Une simulation scientifique pour laquelle des schémas numériques explicites sont appliqués
sur un maillage fixe (à l’inverse d’un maillage adaptatif) est définie comme suit,
dans l’analyse-TAO :
— Topologie : La topologie nécessaire dépend du type de maillage utilisé. Elle
peut être structurée, comme par exemple pour des maillages cartésiens, ou nonstructurée,
pour les maillages du même nom.
— Nœuds actifs : Dans l’analyse-TAO, l’algorithme d’une simulation scientifique est
appelé topology-driven. Cela signifie que l’ensemble des éléments du maillage sont
calculés à chaque itération de temps. De plus, si les schémas numériques à calculer
sont explicites, leurs calculs ne dépendent que de l’itération précédente et les
éléments du maillage peuvent donc être calculés de façon non-ordonnée.
— Opérateurs : Les opérations mises en place dans une simulation scientifique repré-
sentent les calculs des schémas numériques. Dans le cas d’un maillage non adaptatif,
ou fixé, la morphologie du maillage n’est pas modifiée au cours de l’algorithme.
L’analyse-TAO appelle ce type de simulation un calcul local (local computation).46 Chapitre 2. Etat de l’art
Notons que dans le cas d’une simulation utilisant des schémas numériques implicites,
l’algorithme est appelé data-driven, ce qui signifie que les calculs de certains éléments du
maillage peuvent rendre calculables d’autres éléments. Enfin, dans le cas d’un maillage
adaptatif, les opérateurs sont de type morph, ce qui signifie que le maillage peut être
modifié à chaque itération de temps de la simulation.
Ce premier niveau d’abstraction vise à simplifier la classification des algorithmes
parallèles et permet donc d’obtenir une première approche simplifiée du parallélisme
et du calcul haute performance. Toutefois, il ne résout pas le fait que l’utilisateur ne
connaît pas suffisamment les architectures et les détails techniques de la programmation
parallèle pour écrire des programmes parallèles. Ces modèles de programmation et ces
classifications sont, en revanche, très utilisés afin d’élaborer des solutions de parallélisme
implicite d’un niveau d’abstraction plus élevé.
2.4.2 Solutions partiellement implicites
Il existe un très grand nombre de bibliothèques et de langages permettant de simplifier
l’utilisation des machines parallèles, et donc d’écrire des programmes pour ces machines.
Toutefois, ces solutions proposent un parallélisme qui n’est que partiellement implicite,
laissant à l’utilisateur la charge de quelques notions parallèles, qui peuvent paraître, pour
certaines, simples sur de petits programmes, mais qui peuvent s’avérer très compliquées
pour des calculs eux-mêmes complexes. Les niveaux de parallélisme implicite proposés
sont très variés et nous allons évoquer ici quelques unes de ces solutions.
À un niveau d’abstraction relativement bas, on peut tout d’abord noter les langages
ou interfaces de programmations à base de directives. Citons deux de ces solutions, High
Performance Fortran [93] (HPF) et OpenMP [34]. Les langages de directives, et particulièrement
HPF ont été largement critiqués, et notamment accusés de rejeter certains
détails du parallélisme, potentiellement très techniques, sur l’utilisateur. En effet, HPF
demande, par exemple, à l’utilisateur de préciser les alignements des données entre elles,
ce qui garantit leur placement sur un même processeur. De même, HPF demande à l’utilisateur
de préciser des directives de distribution de données (en bloc, ou de façon cyclique
élément par élément, par exemple). OpenMP, de son côté, a réussi à devenir une réfé-
rence pour paralléliser facilement, mais pas nécessairement efficacement, des applications
sur architectures à mémoire partagée. Rappelons que si OpenMP est initialement un
modèle de programmation induit par et fait pour les architectures à mémoire partagée,
son implémentation peut être effectuée sur différents modèles d’exécution et notamment
pour des architectures à mémoire distribuée, en utilisant, par exemple, une architecture
DSM [79]. Bien que ses performances soient limitées, OpenMP est très utilisé dans les
calculs scientifiques. Les directives OpenMP sont, en effet, peu nombreuses et moins
techniques que celles proposées par HPF. Deux types de parallélisation sont possibles
en utilisant OpenMP. La plus simple, et la plus connue des scientifiques, est la méthode
dite fine-grain, ou à grain fin. Elle consiste en la parallélisation automatique de boucles
for. L’unique difficulté pour l’utilisateur est alors de détecter quelles variables sont locales
à la boucle et quelles variables doivent être partagées par les différents processus2.4. Le parallélisme implicite 47
créés automatiquement. Toutefois, il n’est pas rare que cette parallélisation de boucle,
très limitée, ne soit pas suffisante pour obtenir des performances intéressantes, et même
parfois acceptables, dans les calculs scientifiques. Le deuxième type de programmation
OpenMP est alors utilisé et s’appelle coarse-grain, ou à gros grain. Dans ce cas, on peut
noter deux types de solutions. Dans la première l’utilisateur a la charge de définir une
zone de code parallèle, en utilisant la directive #pragma omp parallel, où l’ensemble des
processus, créés automatiquement, exécuteront la même portion de code. L’utilisateur
devra également définir les variables locales et partagées, et on retrouve dans ce type de
parallélisation des problèmes de décomposition de domaine. Cette solution coarse-grain
peut donc s’apparenter au parallélisme de données. Le deuxième type de programmation
coarse-grain qui peut être envisagé est la définition par l’utilisateur de sections pouvant
directement être assignées à des processus différents. La directive est alors #pragma omp
parallel sections. Dans ce cas l’utilisateur doit identifier des tâches pouvant être effectuées
en parallèle par plusieurs processus, cette solution s’apparente donc au parallélisme de
tâches. L’utilisation des méthodes coarse-grain, permet souvent d’obtenir de meilleures
performances, toutefois le niveau d’abstraction proposé est plus bas, et le parallélisme
peu implicite, tout comme dans l’utilisation de HPF.
Les langages BSPLib [69] et Co-array Fortan [98] peuvent ensuite être évoqués. Là
encore, il ne s’agit pas d’un parallélisme implicite total, toutefois la programmation parallèle
y est simplifiée par un nombre de concepts limités et par l’utilisation d’un modèle
de programmation proche de BSP. Ces langages permettent notamment de simplifier
le paradigme à passage de messages, proposé par exemple par MPI [61]. BSPLib, par
exemple, ne demande à l’utilisateur que d’expliciter les envois de données et les synchronisations.
Le reste du travail est effectué directement par la bibliothèque grâce au modèle
de programmation BSP.
ZPL [32] est un langage parallèle basé sur la définition et l’utilisation de tableaux. Il
est, pour cette raison, notamment très adapté aux calculs matriciels. La distribution des
tableaux est effectuée automatiquement lors de l’exécution, et les programmes implémentés
suivent le paradigme SPMD. Si HPF, Co-array, BSPLib et ZPL, par exemple, sont des
langages proches du paradigme SPMD, ce qui signifie que chaque thread exécute le même
code sur des données différentes, les langages X10 [35] et Chapel [31] proposent, quant à
eux, un modèle plus général permettant de contrôler un ensemble d’opérations concurrentes.
Notons enfin que les langages Co-array et X10, parmi d’autres langages, utilisent
le modèle de programmation parallèle PGAS (Partitioned Global Adress Space) [6], déjà
évoqué dans la partie 2.1.2.2.
2.4.3 Solutions générales de parallélisme implicite
Le niveau d’abstraction suivant permet, lui, de cacher de façon beaucoup plus prononcée
le parallélisme aux utilisateurs. Nous évoquons ici les solutions de parallélisme
implicite, que l’on qualifie de générales, à l’inverse des solutions spécifiques que nous évoquerons
par la suite. Il s’agit à proprement parlé, de solutions de parallélisme implicite
totales. Afin de comprendre cette classe de solutions, nous allons prendre l’exemple de
la librairie standard template [95] du C++ (STL). Cette bibliothèque, très générale, per-48 Chapitre 2. Etat de l’art
met d’instancier et d’utiliser des conteneurs, comme par exemple des vecteurs, des listes,
des dictionnaires etc., et même de les imbriquer entre eux. Un ensemble d’algorithmes
peuvent ensuite être appliqués sur ces conteneurs, mais il est également possible d’écrire
ses propres programmes au moyen d’un outil principal : l’itérateur. L’itérateur permet,
en effet, de se déplacer dans un conteneur, mais aussi d’accéder aux valeurs qui y sont
associées. La STL permet d’écrire de façon simplifiée des programmes en C++. En un
sens donc, la STL est une solution de “conteneurs implicites”, qui permet de cacher la
complexité de gestion de conteneurs en C++ et de faciliter leur utilisation. Nous évoquons,
par le terme bibliothèques de parallélisme implicite générales, des bibliothèques
équivalentes à la STL mais qui permettent d’écrire des programmes parallèles. Il s’agit
donc de solutions permettant de mettre en place le paradigme de parallélisme de données,
ou SPMD, par la parallélisation des conteneurs et de leur manipulation. Dans ce
cas, les programmes écrits sont très généraux et touchent potentiellement un très grand
nombre de domaines scientifiques. Certaines de ces bibliothèques sont plus spécifiquement
décrites ici.
Bibliothèques sur conteneurs généraux. STAPL [25] signifie Standard Template
Adaptative Parallel Library et il s’agit d’une version parallèle de la STL, que nous venons
de décrire. Cette bibliothèque emprunte donc un certain nombre de concepts de
la STL, et son but est d’offrir autant, ou plus, de possibilités de codage que la STL,
tout en produisant des programmes parallèles. STAPL est composée de deux composants
principaux, le premier est le concept de pContainer qui représente une structure de données
distribuée représentant un conteneur distribué (tableau [113], liste [115], etc.). Le
deuxième concept, pAlgorithm, représente, quant à lui, un algorithme à appliquer sur un
pContainer. Il est possible dans STAPL, comme dans la STL, d’imbriquer des pContainers
et donc d’imbriquer également des appels à des pAlgorithms. Le niveau d’abstraction
proposé par STAPL est illustré par le concept de pView [24], qui représente une géné-
ralisation du concept d’itérateur. Le concept pView permet le parallélisme via un accès,
d’ordre inconnu, à l’ensemble des éléments d’un conteneur. Enfin, le STAPL parallel
container framework [114] permet d’écrire de nouveaux pContainers de façon simplifiée.
Notons également la bibliothèque PSTL [64], dont les buts sont proches de STAPL. PSTL
est une version parallèle de la STL, mais cette bibliothèque cherche à rester compatible
avec la STL là où STAPL propose de nouveaux conteneurs qui n’existent pas dans la
STL comme les matrices (pMatrix ) et les graphes (pGraph). La bibliothèque Threading
Building Blocks (TBB) [105] implémente, elle aussi, certains concepts équivalents à la
bibliothèque STAPL mais ne vise initialement que les architectures à mémoire partagée
(bien qu’une implémentation utilisant une architecture DSM puisse là encore être envisagée).
STAPL, de son côté, fonctionne de base à la fois pour les architectures à mémoire
partagée et distribuée. Enfin, Thrust [70] est une bibliothèque proposant elle aussi un
équivalent de la STL en parallèle pour des architectures GPU et hybrides CPU-GPU.
Bibliothèques sur graphes. Si les bibliothèques STAPL, PSTL et TBB se veulent
généralistes pour tout type de conteneurs, certaines bibliothèques, elles aussi basées sur2.4. Le parallélisme implicite 49
des conteneurs et des algorithmes, se concentrent sur les graphes, ce qui représente un
problème difficile à gérer en lui-même. Parallel Boost Graph Library (PBGL) [62] est une
bibliothèque parallèle générale sur les graphes. PBGL est une version parallélisée de BGL
(Boost Graph Library) [1], et reste entièrement compatible avec cette version séquentielle.
BGL et PBGL sont des bibliothèques implémentées dans l’ensemble de bibliothèques
Boost [3]. Elles en héritent donc les forts concepts de généricité et d’efficacité. BGL,
et donc PBGL, sont des bibliothèques C++ génériques visant à pouvoir exprimer un
maximum de problèmes, tout en proposant une implémentation efficace. Leur implé-
mentation est, pour cela, basée sur les concepts avancés de méta-programmation [3] et
de spécialisation de template [5]. Il en résulte, pour des scientifiques non-informaticiens,
une programmation techniquement difficile à comprendre, d’autant plus que certains
paramètres de spécialisation, permettant de rendre la solution plus efficace, sont loin
des préoccupations des scientifiques, comme par exemple des informations sur le type de
représentation du graphe souhaité, ou sur la distribution à effectuer pour le parallélisme.
En souhaitant être une bibliothèque générale à tous les problèmes de graphes, elle restreint
son utilisation à des utilisateurs avancés du C++ (bien qu’aucun code parallèle ne
soit demandé à l’utilisateur). La bibliothèque CGMGraph [33] implémente, tout comme
PBGL, un certain nombre d’algorithmes sur les graphes, comme par exemple les composantes
connexes, les arbres couvrants etc. Toutefois, le paradigme de programmation des
deux méthodes est différent. CGMGraph est une bibliothèque orientée objet alors que
PBGL est orientée programmation générique.
Il peut sembler que ce niveau d’abstraction est idéal. En effet, étant très général, il
touche l’intégralité du monde scientifique et permet d’écrire des programmes parallèles
en cachant potentiellement intégralement les détails du parallélisme. Cependant, de par
la généralité de ces solutions, il est difficile de proposer des optimisations spécifiques à un
domaine. Ces solutions peuvent être performantes mais ne peuvent être à la hauteur d’un
parallélisme manuel et optimisé pour un problème spécifique de simulation scientifique.
De plus, le souhait de généricité de ces solutions, et leurs paramétrages parfois complexes,
peut être à l’origine de nouvelles difficultés pour l’utilisateur. Une généricité trop faible,
à l’inverse, peut nuire aux performances de la solution.
2.4.4 Solutions à patrons
Les bibliothèques de parallélisme implicite générales, comme nous venons de le voir,
cherchent à cacher le parallélisme par le biais de conteneurs, d’algorithmes et d’itérateurs
(tableaux 1D, 2D, graphes etc.). Nous allons maintenant aborder des solutions proposant
un niveau d’absrtaction que nous considérons plus haut puisque davantage de détails
sont cachés à l’utilisateur. Ces solutions sont, elles aussi, basées sur des structures de
données implicitement distribuées, mais proposent, de plus, d’identifier les opérations
effectuées dans un programme comme un ensemble de patrons de programmation (ou
patterns). Ces patterns seront ensuite responsables de la parallélisation implicite des
opérations séquentielles du code de l’utilisateur. Les patrons proposent un haut niveau
d’abstraction. Par exemple, ce type de solutions cache généralement la navigation dans50 Chapitre 2. Etat de l’art
les structures de données, la notion d’itérateur n’est alors plus nécessaire. Nous allons
décrire ici deux grandes familles de solutions à patrons. Tout d’abord, le domaine des
squelettes algorithmiques sera décrit et quelques unes des nombreuses bibliothèques de
ce domaine seront étudiées. Puis, quelques autres solutions à patrons seront décrites.
2.4.4.1 Squelettes algorithmiques.
Les squelettes algorithmiques parallèles ont été introduits en 1988 par Muray
Cole [40]. Ils représentent des patrons de parallélisation fonctionnels, en d’autres termes
des abstractions de schémas de parallélisme, que l’on retrouve de façon récurrente dans
les applications parallèles. Ainsi, en théorie, n’importe quel programme parallèle peut
s’exprimer comme une suite ou une imbrication de squelettes algorithmiques fonctionnels.
Aucune norme n’a été définie pour écrire des squelettes, ni même aucun consensus.
Toutefois, le travail de Cole [39] indique quelques règles de conception pour produire
des squelettes adaptés et donc plus utilisés. Un squelette a idéalement un champ d’application
le plus large possible, afin de pouvoir être utilisé dans un grand nombre de
cas, sa sémantique doit être compréhensible des utilisateurs, et enfin il ne doit pas être
redondant avec d’autres squelettes.
Les squelettes algorithmiques se découpent en trois grandes classes, les squelettes pour
le parallélisme de données (map, reduce, zip etc.), les squelettes pour le parallélisme de
tâches (farm, pipeline etc.), et enfin les squelettes dits de résolution (divide and conquer,
branch and bound). Des détails sur l’ensemble de ces squelettes peuvent être trouvés
dans la thèse de Legaux [84]. Nous n’allons ici décrire que quelques squelettes pour le
parallélisme de données, auxquels nous feront référence dans cette thèse. Nous pouvons,
tout d’abord, noter les trois squelettes de base les plus connus et les plus simples à
comprendre. Le premier s’appelle map et permet d’appliquer une fonction locale à un
ensemble de données d’entrée en parallèle. Une fonction locale est alors une fonction
dont le calcul ne dépend que d’un élément d’entrée sans aucune dépendance avec les
autres éléments. Le squelette peut alors distribuer la structure de données et appliquer
la fonction à chacun des éléments séparément. Le squelette prend alors un vecteur de
données d’entrée [x1, x2, . . . , xn], retourne un vecteur de données de sortie [y1, y2, . . . , yn]
et applique une fonction f telle que
map f [x1, x2, . . . , xn] = [f(x1), f(x2), . . . , f(xn)] = [y1, y2, . . . , yn].
Le second squelette de base est le squelette zip qui est une extension de map pour
deux vecteurs d’entrée. Il distribue deux vecteurs de données d’entrée [x1, x2, . . . , xn] et
[x
0
1
, x0
2
, . . . , x0
n
], de même taille, et retourne un nouvel vecteur de sortie [y1, y2, . . . , yn] en
appliquant une fonction f telle que
zip f ([x1, x2, . . . , xn], [x
0
1
, x0
2
, . . . , x0
n
]) = [f(x1, x0
1
), f(x2, x0
2
), . . . , f(xn, x0
n
)]
= [y1, y2, . . . , yn].
Enfin, le squelette reduce permet de réduire un vecteur de données d’entrée [x1, x2, . . . , xn]
en un unique élément e suite à l’appel d’une opération de réduction, que nous noterons2.4. Le parallélisme implicite 51
⊕, telle que
reduce ⊕ [x1, x2, . . . , xn] = x1 ⊕ x2 ⊕ . . . ⊕ xn = e.
Les squelettes map et zip sont des squelettes qui ne peuvent appliquer que des calculs
locaux, de par leur construction. En d’autres termes, il n’est pas possible avec uniquement
ces squelettes d’effectuer des calculs de type stencil. La fonction décrite par l’utilisateur
ne décrit, en effet, que l’opération à effectuer sur un élément de l’ensemble de départ. Un
calcul stencil dépendant d’un certain voisinage de l’élément courant, il est nécessaire de
faire appel au squelette shift. Ce squelette va prendre un vecteur d’entrée [x1, x2, . . . , xn],
et retourner un vecteur de sortie [y1, y2, . . . , yn] égal à l’ensemble d’entrée décalé (le
décalage appliqué étant précisé par l’utilisateur). Par exemple, pour un décalage de un
élément vers la droite nous obtiendront
[y1, y2, . . . , yn] = [×, x1, x2, . . . , xn−1].
De cette manière en accédant au deuxième élément des ensembles [x1, x2, . . . , xn] et
[×, x1, x2, . . . , xn−1], il est possible de faire des opérations sur x2 et x1 en même temps.
Avec ces quatre squelettes de base, on peut très facilement observer les limites de l’approche
par squelettes pour des simulations scientifiques complexes. Pour cette raison, des
squelettes de type stencil sont apparus, notamment dans la bibliothèque SkelCL [21,111].
Cette bibliothèque implémente des squelettes de base pour les GPU et multi-GPU en utilisant
le langage OpenCL [112]. Il s’agit donc également d’un code portable. Elle propose
un squelette de stencil simple nommé MapOverlap qui permet de décrire une opération
de stencil simple, et un squelette de stencil plus complexe, nommé Stencil permettant
notamment de décrire des opérations stencil itératives. Afin de pouvoir effectuer les calculs
de type stencil, une distribution contenant des éléments fantômes est mise en place
dans la bibliothèque de squelettes, et n’existe pas dans les autres solutions. De plus, les
échanges à effectuer entre les processeurs sont automatiquement détectés par les arguments
utilisés dans le stencil. Notons que SkelCL ne fonctionne que pour les structures
de données de type vecteur ou matrices.
Parmi les bibliothèques de squelettes permettant de faire du parallélisme de données
et écrites en C++, on peut noter OSL [72], SkeTo [76], SkePu [52], et Muesli [37], chacune
ayant ses propres particularités. SkeTo, par exemple, est la seule bibliothèque proposant
une solution de squelettes sur les arbres [90]. SkePu propose une implémentation GPU,
et Muesli une implémentation hybride MPI/OpenMP des squelettes algorithmiques de
base. Enfin, OSL propose des optimisations à base de méta-programmation C++ [71,84].
Bien que les squelettes algorithmiques parallèles proposent un niveau d’abstraction
intéressant, ce domaine est très peu utilisé pour des simulations scientifiques complexes.
A notre connaissance, aucune simulation complexe n’a été écrite avec des squelettes algorithmiques,
et leur utilisation se limite à des cas “jouet” comme la résolution de l’équation
de la chaleur. Avec l’arrivée de nouveaux squelettes spécifiquement écrits pour le calcul
stencil [21], l’utilisation des squelettes algorithmiques est enclin à se développer dans
cette discipline. Toutefois, dans le domaine des mathématiques appliquées, les langages
de programmation enseignés aux scientifiques sont très souvent des langages impératifs
comme Fortran, C et C++. L’utilisation de langages fonctionnels, et donc de squelettes52 Chapitre 2. Etat de l’art
algorithmiques parallèles, demande un effort d’apprentissage supplémentaire qui pourrait
éloigner certains numériciens. Toutefois, notons qu’un langage fonctionnel peut être appris
très rapidement et très facilement par les mathématiciens car il s’agit d’un langage
plus proche des mathématiques.
2.4.4.2 D’autres solutions à patrons.
L’entreprise Google est à l’origine de la démocratisation de l’utilisation du modèle
MapReduce [47]. Dans ce modèle il est considéré que tout calcul peut être décomposé en
une série d’association du squelette map et du squelette reduce. Cette solution a permis
de démocratiser les squelettes algorithmiques, grâce à l’association intelligente de deux
concepts simples, dont la mise en œuvre est facilitée par un certain nombre d’outils.
Ainsi, par exemple, le framework Hadoop [127], très connnu et très utilisé, propose un
système de fichiers distribués et une implémentation de MapReduce. Il est alors possible
de faciliter la création d’applications distribuées ainsi que leur déploiement sur des milliers
de processeurs. Enfin, ce type de systèmes embarque généralement la gestion des pannes
du programme ou du matériel, ce qui augmente encore l’intérêt des scientifiques, dont les
simulations peuvent être très longues et coûteuses.
Google est également à l’origine d’un modèle de parallélisme simple pour les traitements
parallèles sur les graphes dirigés, Pregel [88]. Dans l’état de l’art de ce travail,
Pregel est comparé à PBGL et CGMGraph (décrits précédemment), et le principal
argument avancé pour préférer son utilisation est la tolérance aux pannes. Toutefois, le
type d’approche est très différent. En effet, Pregel conserve une idée proche des squelettes
algorithmiques et se base également sur le modèle BSP pour structurer de façon générale
des opérations sur des graphes dirigés. Dans Pregel, le graphe est tout d’abord distribué
sur les différents processeurs. Un calcul dans Pregel est ensuite composé de plusieurs
itérations, que l’on peut comparer à des super-étapes du modèle BSP. Dans chacune
de ces étapes, le framework Pregel appelle une fonction utilisateur qu’il applique sur
chaque nœud du graphe distribué. La fonction spécifie le comportement d’un unique
nœud général v pour une étape S. Cette fonction peut recevoir des messages envoyés à v
à l’étape S − 1, et peut envoyer des messages à d’autres nœuds qui seront reçus à l’étape
S + 1. On retrouve alors la notion de fonction utilisateur de MapReduce, ou de tout
autre squelette, et l’on retrouve également l’application de cette fonction sur chacun des
nœuds, tout comme dans les squelettes algorithmiques. Toutefois le modèle Pregel est
une solution plus générale que les squelettes algorithmiques habituels et ne représente
pas un patron de parallélisation unique. La fonction utilisateur peut, en effet, décrire des
problèmes très variés et offre une plus grande liberté de codage que dans l’utilisation des
squelettes algorithmiques. Il est important de noter que les algorithmes sur les graphes
peuvent être exprimés comme des chaînes d’appels à MapReduce [38, 75]. Toutefois,
le modèle Pregel propose de meilleures performances. En effet, il conserve la même
distribution de graphe d’une étape à l’autre du calcul, et utilise uniquement l’envoi et la
réception de messages pour obtenir les informations d’autres processeurs. L’utilisation
de MapReduce implique, quant à elle, tout d’abord (1) une distribution initiale des
données, puis (2) l’application du map, puis pour terminer (3) des communications pour2.4. Le parallélisme implicite 53
l’application du reduce, ce qui revient à communiquer toutes les données résultantes du
map à chaque appel d’un mapreduce. Giraph [7] est une alternative à Pregel et utilise
les même concepts.
Là encore il s’agit de solutions de parallélisme implicite très intéressantes et avec un
certain nombre d’avantages. L’utilisation de ce type de solutions semble, tout d’abord,
simplifier encore davantage la création de programmes parallèles, et la classification des
différentes opérations d’un programme en patrons ne semble pas extrêmement difficile
à élaborer. De plus, ces solutions utilisent deux types de spécificités pour mettre au
point des optimisations : les structure de données distribuées, et les patrons utilisés. Les
possibilités de performances paraissent donc plus importantes que dans les solutions dites
générales. Cependant, un certain nombre de problèmes peuvent être notés avec ce type
de solution. Tout d’abord, et comme nous l’avons décrit, chaque opération décrite à l’aide
d’un patron, ou d’un squelette, est en fait une opération simple. À l’exception de Pregel,
ces solutions sont très proches de la programmation fonctionnelle. Ainsi, si des calculs
complexes doivent être mis en œuvre, un grand nombre d’appels imbriqués sera nécessaire,
ce qui peut complexifier l’écriture, la lecture et la compréhension des programmes. Dans
cette solution, de nouveau, il semble possible que la difficulté de programmation parallèle
soit déportée vers l’utilisation de nouveaux concepts, et notamment vers les difficultés de
la programmation fonctionnelle, non connue de la plupart des scientifiques.
2.4.5 Solutions spécifiques à un domaine
Nous avons donc vu que les solutions générales de parallélisme implicite sont uniquement
spécifiques aux types de conteneurs utilisés, ce qui peut limiter les optimisations du
programme parallèle. Les solutions à patrons de parallélisme sont, quant à elles, spéci-
fiques aux types de conteneurs mais aussi aux types de patrons utilisés, ce qui augmente
les possibilités d’optimisations pour le problème posé. Dans cette dernière partie, nous
allons voir le niveau d’abstraction et de spécificité le plus haut qui est proposé dans les solutions
de parallélisme implicite pour le calcul scientifique. Dans ce cas, la solution, qu’elle
soit une bibliothèque, un framework ou un langage dédié (noté DSL), est spécifiquement
implémentée pour un problème spécifique et propose des optimisations de performances
dues à cette spécificité, qu’on ne pourrait donc pas retrouver dans les solutions plus géné-
rales. La définition de “spécifique” peut être très variée. Par exemple, STAPL peut être vu
comme un langage dédié à la programmation par conteneurs parallèles. Toutefois, nous
rattacherons ici, et dans le reste de cette thèse, une solution dite spécifique (de type DSL,
bibliothèque etc.) à une solution spécifique au calcul scientifique. Le domaine du calcul
scientifique reste un domaine très vaste, même si il est beaucoup plus spécifique que les
domaines traités par STAPL, PBGL ou les squelettes algorithmiques. Pour cette raison,
de nombreuses solutions spécifiques ont été mises au point pour divers sous-problèmes
du calcul scientifique. Certaines solutions sont plus spécifiques que d’autres, tout le problème
étant de trouver le niveau d’abstraction idéal pour l’utilisation qui sera faite du
langage.
Parmi les solutions parallèles spécifiques aux applications scientifiques, on peut tout54 Chapitre 2. Etat de l’art
d’abord noter ScaLAPACK [19] qui est une bibliothèque haute performance pour les
calculs de l’algèbre linéaire, implémentée pour les architectures parallèles à mémoire
distribuée. On peut ensuite noter FFTW [55], pour le calcul parallèle de la transformée de
Fourier discrète, et donc notamment pour des problèmes de traitement du signal. Ce DSL
est implémenté pour des architectures à mémoire partagée et distribuée. SPIRAL [104]
est, quant à lui, un DSL plus récent permettant, de façon plus générale que FFTW,
d’effectuer des traitements du signal numérique.
Dans cette thèse, nous nous intéressons plus particulièrement à la résolution des EDP
par des méthodes numériques basées sur des maillages, et donnant lieu à des schémas
numériques explicites. Nous nous intéressons donc aux problèmes stencils pour tout type
de maillages, et nous allons évoquer avec plus d’attention, dans le reste de cette section,
les DSL, bibliothèques et frameworks spécifiquement développés pour ce type de calculs
que l’on peut appeler plus généralement des DSS pour Domain Specific Solutions.
2.4.5.1 EDP et EDO sur maillages structurés
Commençons par évoquer les solutions de parallélisme implicite spécifiques au calcul
de type stencil sur les maillages structurés. Il en existe en très grand nombre, et il ne
s’agit pas ici d’une liste exhaustive de ces solutions mais des quelques travaux qui paraissent
proches des solutions présentées dans cette thèse. Notons tout d’abord l’une des
solutions les plus utilisées et les plus connues du monde de la simulation scientifiques,
PETSc [10–12]. PETSc est une solution très vaste qui permet d’écrire des applications
scientifiques, modélisées par des EDP, en parallèle. Cette solution est composée d’outils
permettant d’effectuer des opérations sur des vecteurs et des matrices, de solveurs
d’équations linéaires et non linéaires, mais également d’outils graphiques permettant la
visualisation des résultats de l’application. PETSc est implémenté pour les architectures à
mémoire partagée CPU et GPU grâce aux modèles pthreads, CUDA et OpenCL, pour les
architectures à mémoire distribuée, grâce à l’utilisation de MPI, et pour les architectures
à mémoire hybrides aux travers des associations MPI-pthreads et MPI-GPU. PETSc est
basé sur un ensemble de structures de données distribuées et sur un ensemble de fonctions
ou routines spécialisées pour ce type de traitements. PETSc est donc identifiable à une
bibliothèque sur conteneurs, tout comme STAPL ou PSTL, mais dont les interfaces et
les algorithmes sont spécifiques au traitement des EDP. Nous pouvons également noter
la bibliothèque spécifique Trilinos [68] qui est très proche de PETSc.
Nous pouvons également noter des solutions spécifiques plus récentes, comme par
exemple le framework développé à Berkeley permettant de générer automatiquement un
code parallèle, adapté à l’architecture à mémoire partagée et au matériel utilisé (dit
auto-tuned), uniquement à l’aide de l’expression d’un stencil en Fortran [74]. Dans cette
même famille de framework auto-tuned, on peut également noter PATUS [36] qui génère
du code parallèle CPU et GPU à partir de l’expression d’un stencil et d’une stratégie de
parallélisation. PATUS évalue ensuite la meilleure parallélisation pour le matériel utilisé.
Évoquons également Panorama [86] qui utilise des techniques particulières pour minimiser
les défauts de cache, et Pochoir [116] qui permet la définition de stencils à n dimensions
en C++. Physis [89] ne propose pas de solution auto-tuned mais permet lui aussi de2.4. Le parallélisme implicite 55
définir une expression stencil à l’aide d’un DSL, et d’en produire automatiquement des
applications parallèles MPI et CUDA.
2.4.5.2 EDP sur maillages non-structurés
De nombreuses solutions de parallélisme implicte, spécifiques aux calculs de type
stencil, sont donc disponibles pour les maillages structurés. Lorsque le problème des
maillages non-structurés est abordé, les outils se font plus rares, mais il en existe également.
Nous pouvons, tout d’abord, évoquer le plus ancien d’entre eux, OP2 [59, 60, 94].
OP2, développé à l’université d’Oxford, est une révision du framework OPlus [23], initié
en 1993, qui permettait d’écrire des applications basées sur un maillage non-structuré
et sur la méthode des éléments finis. OPlus a notamment été utilisé pour paralléliser, en
1995, une simulation d’écoulement des fluides non visqueux sur un maillage complexe
représentant un avion [45]. OPlus était implémenté pour les architectures à mémoire
distribuée et implémenté en MPI. OP2 est une version plus moderne et plus récente de
OPlus qui est implémentée pour les architectures à mémoire partagée CPU et GPU.
Le framework OP2 charge l’utilisateur de quatre parties : (1) définir des ensembles
d’éléments qui vont définir les éléments du maillage, (2) définir des liens entre ces
ensembles pour former le maillage, (3) définir des données sur les ensembles, et enfin (4)
implémenter des opérations sur les ensembles d’éléments. Il est ainsi possible de définir
un maillage non-structuré de toute forme, ainsi que sa topologie. Le framework dispose
d’un compilateur permettant de transformer le code OP2 en un code C++, qui pourra
à son tour être compilé. Le DSL Liszt [50] permet également de coder des simulations
sur maillages non-structurés en parallèle. Toutefois, le niveau d’abstraction proposé à
l’utilisateur est légèrement différent. En effet, le niveau d’abstraction de OP2 est plus
proche du niveau d’abstraction des squelettes algorithmiques puisque l’utilisateur n’a pas
à définir ses boucles, alors que Liszt permet de rester plus proche d’un code séquentiel
avec la gestion des boucles par l’utilisateur. Le langage Liszt est une sous-partie du
langage de programmation Scala [99], et utilise une version modifiée de son compilateur.
Liszt supporte une implémentation MPI, OpenMP et CUDA/OpenCL.
Dans une solution de parallélisme implicite spécifique, comme celles qui ont été évoquées
ici, il est nécessaire de doser convenablement le niveau de spécificité de la solution.
D’une part, si le niveau de spécificité est trop important, cela peut nuire au nombre
d’utilisateurs. D’autre part, et à l’inverse, si le niveau de spécificité est trop faible, la
solution peut s’avérer trop généraliste et risque de ne pas répondre aux attentes des utilisateurs.
Toutefois, en trouvant un niveau de spécificité adéquat, ces solutions sont souvent
celles qui procurent les meilleures performances, et la plus grande notoriété auprès des
utilisateurs non-informaticiens.56 Chapitre 2. Etat de l’art
2.5 Calculs de performances et difficulté de programmation
Dans cette thèse est proposée l’implémentation d’une solution de parallélisme implicite
pour les simulations basées sur des maillages. L’évaluation de cette implémentation
passe donc par deux volets, tout d’abord l’évaluation des performances produites par la
solution de parallélisme implicite, mais également l’évaluation de la difficulté de codage
liée à l’utilisation cette solution. Il existe un lien fort entre les performances d’une solution
de parallélisme implicite et sa simplicité de codage, puisque le fait de cacher des
opérations parallèles peut engendrer un certain sur-coût. Une solution de parallélisme
implicite idéale sera à la fois performante et très simple d’utilisation. Cette dernière section
de notre état de l’art va donc tout d’abord introduire les mesures de performances,
puis les métriques d’effort utilisées dans cette thèse.
2.5.1 Mesures de performances
En science informatique, on appelle benchmarking une méthode permettant de quantifier
et d’évaluer les résultats expérimentaux d’un code ou d’un programme. Plus particulièrement,
en calcul parallèle, le benchmarking est souvent associé aux méthodes
permettant d’évaluer les performances d’un programme, de façon absolue, ou de façon
relative à un autre programme. L’idée de base est de calculer le temps d’exécution d’un
programme, ou d’une sous-partie du programme, représentative du problème à évaluer.
Ce temps d’exécution peut ensuite être utilisé pour évaluer plusieurs types de métriques
comme le temps d’exécution total et moyen du programme, l’accélération du programme,
le débit des échanges de données par le programme (exprimés en bits par seconde), ou
encore la puissance du programme (exprimé en nombre d’opérations flottantes, par seconde).
Certaines de ces métriques peuvent être comparées de façon absolue avec un idéal
de référence. C’est le cas, par exemple, de la puissance du programme qui ne peut en
théorie pas dépasser les capacités matérielle des machines utilisées. D’autres métriques,
en revanche, ne sont utiles que dans le cas d’une comparaison avec d’autres programmes,
comme par exemple le temps d’exécution.
Dans cette thèse deux métriques en particulier seront utilisées pour évaluer les performances
des solutions proposées. La première est la représentation de l’accélération d’un
programme, qui nous permettra d’évaluer la montée en charge des programmes parallèles
implémentés. Nous appellerons cette métrique la scalabilité. Il existe deux méthodes
pour évaluer la scalabilité d’un programme parallèle. La première est appelée la scalabilité
faible, la seconde la scalabilité forte. Notons T(p, n) le temps nécessaire pour exécuter
un programme en utilisant p processeurs et pour une taille de problème n. On définit
alors l’accélération du programme, pour un problème de taille n et pour p processeurs,
par
speedup(p, n) = Tseq(1, n)
T(p, n)
, (2.19)2.5. Calculs de performances et difficulté de programmation 57
où Tseq(1, n) représente le meilleur temps séquentiel connu pour la résolution du problème
courrant, alors que T(p, n) représente le temps du programme parallèle à évaluer. Il
ne s’agit donc pas du même programme et le temps Tseq(1, n) est considéré comme la
référence du problème. Cette définition de l’accélération permet d’évaluer une scalabilité
dite forte et comparable entre différentes verions parallèles. La taille du problème n’est pas
modifiée entre l’exécution séquentielle (sur un unique processeur) et l’exécution parallèle
(sur p processeurs). Toutefois, étant donné qu’il est nécessaire de disposer de Tseq(1, n)
pour évaluer cette l’accélération, une version modifiée de cette définition est généralement
utilisée, et sera utilisée dans cette thèse. L’accélération est alors définie par
speedup(p, n) = T(1, n)
T(p, n)
. (2.20)
Dans ce cas c’est le temps séquentiel du programme à évaluer qui est utilisé comme temps
de référence. Cette accélération est moins intéressante et ne permet pas une comparaison
intéressante de deux versions parallèles différentes. Toutefois, elle permet d’observer la
scalabilité du programme à évaluer.
Une deuxième définition de l’accélération du programme, pour un problème de taille
n et pour p processeurs, est
speedup(p, n) = T(1, n)
T(p, p × n)
.
Dans ce cas, la scalabilité évaluée est dite faible car la taille du problème est multipliée
par le nombre de processeurs utilisés. Ainsi, la quantité de travail assignée à chaque processeur
reste constante et le nombre de processeurs utilisés (et donc la taille du problème
général) augmente. Cette accélération est idéale si le temps de calcul reste constant avec
l’augmentation du nombre de processeurs et de la taille du problème. Cette accélération
peut être utile dans plusieurs cas. Tout d’abord si le programme parallèle contient
une fraction de code séquentielle et une fraction de code parallèle, cette accélération
peut donner des indications sur le temps représenté par la fraction séquentielle et sur
la nécessité de réduire cette fraction. Une fraction de code parallèle que nous appelons
classique, c’est à dire utilisant relativement peu de communications (les plus proches
voisins par exemple), ne rencontre pas de problème de scalabilité dans le cas d’une accélération
faible. Si, en revanche, le programme parallèle utilise des communications très
lourdes, telles que des communications collectives dont le coût augmente avec le nombre
de processeurs, certains problèmes peuvent être détectés en représentant cette accélération.
Enfin, si le programme consomme beaucoup de mémoire et ne peut, par exemple,
pas être exécuté en séquentiel, cette accélération peut permettre d’évaluer tout de même
son accélération. Dans cette thèse, nous utiliserons la définition de l’accélération forte
modifiée (2.20) pour évaluer la scalabilité des programmes.
Si l’on évalue l’accélération (2.20) d’un programme parallèle en utilisant P processeurs,
on représente généralement une courbe de l’ensemble des valeurs de l’accélération
entre 1 et P processeurs. Cette courbe représente donc l’accélération du programme
parallèle en fonction du nombre de processeurs utilisés. Étant donné la définition de l’accélération
(2.20), il peut être déduit que l’accélération idéale d’un programme est égale58 Chapitre 2. Etat de l’art
à p pour tout p dans [1, P]. L’accélération idéale est alors représentée par la fonction
f(p) = p. Il en résulte qu’un bon speedup sera idéalement le plus proche possible de la
droite f(p) = p, et idéalement linéaire quelque soit le nombre de processeurs utilisés.
Toutefois la réalité sur l’accélération d’un programme peut être différente de ces déductions
théoriques. Il est en effet possible de dépasser l’accélération idéale théorique. C’est
ce qu’on appelle une accélération super-linéaire. Ce phénomène peut être dû à plusieurs
facteurs. La première raison concerne les architectures à mémoire distribuées. Imaginons
alors que le programme séquentiel utilise trop de mémoire, il est alors possible que les
données du programme ne tiennent plus en mémoire vive et soient stockées sur la mémoire
disque de la machine (ce qu’on appelle du swapping). Dans ce cas, le temps d’exécution
séquentiel peut être anormalement long. Ainsi, en augmentant le nombre de processeurs,
et donc en réduisant l’emprunte mémoire du programme pour chaque processeur, l’accé-
lération peut être facilement supérieure à p. La deuxième raison qui peut être à l’origine
d’une super-linéarité est proche de la première mais non restreinte aux architectures à
mémoire distribuée. Elle ne concerne plus le passage de la mémoire vive à l’espace disque,
mais le passage de la mémoire cache à la mémoire vive. En réduisant la taille du problème
(du fait du nombre de processeurs utilisés), il peut arriver que la taille des structures de
données sur lesquelles sont effectués les calculs soit inférieure ou égale à la taille des
lignes de cache, ce qui réduit le nombre d’accès à la mémoire vive depuis le cache, et
ce qui augmente l’efficacité du programme. Cependant, lorsqu’un phénomène de cache
se produit et qu’il conduit à une accélération super-linéaire, il peut être intéressant de
modifier l’algorithme séquentiel afin que celui-ci traite des blocs de données plus petits,
limitant ainsi les chargements de données en cache pendant les calculs. De cette façon,
la super-linéarité est souvent réduite et l’accélération observée sera probablement plus
réaliste.
L’évaluation de la scalabilité forte d’un programme est un bon indicateur des performances
du programme parallèle. Toutefois, l’accélération définie par (2.20), et utilisée
dans cette thèse, souffre de certaines faiblesses lorsque l’on cherche à comparer les performances
de deux implémentations différentes. Tout d’abord l’accélération d’un programme
est liée au temps d’exécution séquentiel du programme. On ne peut donc pas comparer
l’accélération de deux implémentations n’ayant pas le même temps d’exécution séquentiel.
De même, meilleure est l’implémentation, plus difficile est l’obtention d’une bonne
accélération, car la version moins optimisée passera plus de temps dans les calculs et
aura probablement une accélération linéaire sur un plus grand nombre de processeurs.
Une accélération est donc un bon indicateur de scalabilité pour un programme, mais
la définition (2.20) n’est pas une bonne métrique pour comparer deux implémentations
différentes. Pour cette raison nous utilisons une deuxième métrique dans cette thèse. Elle
représente simplement le temps d’exécution des programmes et nous permettra de comparer
de façon objective les temps d’exécution de plusieurs implémentations parallèles
d’une même simulation scientifique. Notons que nous avons fait le choix, dans la plupart
de nos résultats, de représenter les temps d’exécution avec une échelle logarithmique.
Cette échelle nous permet, tout d’abord, de faciliter la lisibilité des temps d’exécution,2.5. Calculs de performances et difficulté de programmation 59
mais permet également de comparer à la fois les temps d’exécution et la linéarité des
accélérations des implémentations.
2.5.2 Effort de programmation
Il existe diverses métriques permettant d’évaluer l’effort à fournir pour écrire un
code. Certaines métriques permettent d’évaluer la difficulté d’un programme à partir du
nombre de fonctionnalités à implémenter [4,80]. Ce type de métriques est utilisé dans la
conception et le génie logiciel, mais ne nous sera pas utile pour comparer deux versions
parallèles possédant les mêmes fonctionnalités. La complexité cyclomatique [91] est une
métrique qui base la difficulté de programmation sur le comportement d’un programme.
Elle est basée sur un graphe qui représente les différentes exécutions possibles d’un même
programme, pour en estimer sa complexité. En d’autres termes, cette métrique s’intéresse
aux branches conditionnelles du programme. De nouveau, nous ne pourrons utiliser cette
métrique pour comparer deux implémentations d’une même simulation. Nous pouvons
noter deux métriques qui pourraient être utilisées dans notre cas. Tout d’abord, la mé-
trique SLOC (Source Lines of Code) se base uniquement sur le nombre de lignes dans un
code pour évaluer la difficulté d’un programme. Il s’agit d’une première indication sur
l’effort à fournir pour écrire un programme. Mais nous allons plus particulièrement nous
concentrer sur les métriques de Halstead [65], qui offrent des indicateurs plus révélateurs
sur l’effort de programmation à fournir pour écrire un code.
Les métriques de Halstead sont basées sur le dénombrement des opérateurs et des
opérandes d’un code source. De ce dénombrement, directement appliqué dans le code,
sont obtenues quatre mesures représentées dans la table 2.2. Afin d’évaluer correctement
ces mesures il est important de définir ce que l’on considère comme un opérateur et un
opérande. Peu d’informations sur ce sujet sont données dans la littérature. Dans nos
codes C++, nous avons considéré que les opérandes étaient l’ensemble des variables et
constantes définies par l’utilisateur. Les opérateurs sont l’ensemble des opérations numériques,
affectations et opérateurs de comparaison (+,∗,−,/,=,==,&&,<= etc.), l’ensemble
des mots clés du C++ (static, class, template etc.), l’ensemble des types (int,
const, float, ∗ etc.), l’ensemble des instructions du C++ (for, while, do, if /elseif /else
etc.), les symboles délimiteur ;, les parenthèses et les appels de fonctions.
Symbole Mesure
N1 Nombre total d’opérateurs
N2 Nombre total d’opérandes
η1 Nombre d’opérateurs distincts
η2 Nombre d’opérandes distincts
Table 2.2 – Mesures directes dans le code
Grâce à ces quatre mesures, les métriques de Halstead peuvent être calculées et sont
représentées dans la table 2.3. La première représente le vocabulaire du programme, la
deuxième la longueur du programme, qui n’est pas directement liée aux nombre de lignes60 Chapitre 2. Etat de l’art
de code mais au nombre total d’opérandes et d’opérateurs. La troisième métrique repré-
sente le volume du programme. Ce volume est le produit de la longueur du programme
et du logarithme en base deux du vocabulaire. Comme ce volume est basé sur le nombre
d’opérations effectuées et d’opérandes gérées dans le programme, il est moins sensible à
la disposition du code que les mesures SLOC. La métrique suivante représente la diffi-
culté, et la propension à l’erreur, d’un programme. Cette métrique est calculée comme un
produit entre le vocabulaire des opérateurs et la fréquence d’apparition des opérandes.
Elle part donc du principe que plus le nombre d’opérateurs distincts est grand, plus il
est difficile d’implémenter le programme, et que plus les même opérandes sont utilisées
dans le programme, plus la propension à l’erreur est grande. Enfin la dernière métrique
représente l’effort nécessaire à l’écriture du programme et est égale au produit du volume
par la difficulté. Ainsi, plus un programme est volumineux et difficile, plus l’effort de
programmation à fournir sera important.
Symbole Valeur Métrique
η η1 + η2 Vocabulaire
N N1 + N2 Longueur
V N × log2 η Volume
D
η1
2 ×
N2
η2
Difficulté
E D × V Effort
Table 2.3 – Métriques de Halstead
Les métriques de Halstead proposent donc des concepts intéressants et permettent de
pouvoir comparer deux implémentations différentes, en terme d’effort de programmation,
ce qui n’est pas le cas des autres métriques. Même si ces métriques ont été proposées
pour des programmes séquentiels, elles s’appliquent, de notre point de vue, à des programmes
parallèles. Toutefois, notons que ces métriques comportent des faiblesses pour
exprimer l’effort de programmation d’un programme parallèle. Tout d’abord, dans un
programme parallèle, un effort plus important est demandé aux utilisateurs pour utiliser
des opérateurs parallèles et des opérandes distribuées, que pour utiliser des opérateurs
et opérandes classiques de la programmation séquentielle. De plus, dans la conception
d’un programme parallèle, les appels à des opérateurs parallèles (comme par exemple
les routine de MPI), et l’utilisation d’opérandes distribuées ne sont pas les seuls diffi-
cultés. En effet, l’un des points les plus difficiles dans la programmation parallèle est la
conception du programme. C’est, en effet, le développeur qui doit réfléchir à la façon
dont le programme va pouvoir fonctionner en parallèle et ce n’est pas une difficulté qui
peut transparaître dans le dénombrement des opérandes et des opérateurs. Il paraît très
difficile de pouvoir évaluer ce type de difficulté, aussi les métriques de Halstead restent,
de notre point de vue, les métriques les plus adaptées à l’utilisation que nous souhaitons
en faire dans cette thèse.2.6. Conclusion et positionnement du travail 61
2.6 Conclusion et positionnement du travail
Cette thèse vise à proposer des solutions de parallélisme implicite pour le cas spé-
cifique des simulations numériques scientifiques. Pour cette raison, cet état de l’art a,
tout d’abord, évoqué les architectures parallèles, les paradigmes et les modèles de programmation
et leur évolution au fil du temps, ainsi que la discrétisation et les méthodes
numériques de résolution des EDP. Dans les concepts introduits dans la section 2.2 de cet
état de l’art, nous nous intéressons plus particulièrement aux résolutions d’EDP basées
sur des maillages quelconques, en utilisant les méthodes numériques introduites dans la
partie 2.2.4. Le travail présenté dans cette thèse se limite, dans les chapitre 3 et 4, aux
calculs de schémas numériques explicites (2.3), toutefois le chapitre 5 évoquera et traitera
le cas de schémas numériques implicites (2.4) également. Cette thèse propose des modèles
et des implémentations basés sur le paradigme de parallélisme de données et sur le paradigme
SPMD. Pour cette raison, le problème de partitionnement des données est un point
à aborder et que nous traitons plus particulièrement dans le chapitre 5. Nous présentons
dans cette thèse un modèle de programmation implicite nommé SIPSim (pour Structured
Implicit Parallelism for Scientific SIMulations ), puis par la suite son implémentation
pour des architectures à mémoire distribuée, nommée SkelGIS, qui permet de valider le
modèle. L’approche SIPSim s’applique, a priori, à tout type de maillage, toutefois cette
thèse s’intéresse à l’implémentation de deux cas particuliers : les maillages cartésiens à
deux dimensions et la composition de maillages sous forme de réseaux. Le modèle SIPSim
permet de générer des programmes parallèles SPMD du type de l’algorithme 2, en
conservant une programmation séquentielle comme introduite dans l’algorithme 1. En-
fin, l’implémentation actuelle de l’approche SIPSim (SkelGIS) est effectuée en utilisant
le modèle MPI, introduit dans cet état de l’art.
C’est dans la partie 2.4 de cet état de l’art qu’a été introduit le cœur de cette thèse
en décrivant les modèles et les solutions de parallélisme implicite. Les avantages et les
inconvénients de chaque vision du parallélisme implicite ont été donnés et analysés, ce
qui nous permet de positionner notre travail dans ce contexte. La figure 2.12 résume ce
positionnement, que l’on peut aussi résumer ainsi :
— Des bibliothèques générales de parallélisme implicite, notre travail tente de conserver
une certaine flexibilité, ou souplesse, qui permet de répondre notamment à des
cas particuliers de simulations. Nous héritons par exemple du concept très important
d’itérateur de STAPL ou de PSTL, sous une forme différente.
— Des solutions à patrons, et des bibliothèques de squelettes algorithmiques, notre
travail hérite d’un haut niveau d’abstraction. L’utilisateur définit, en effet, des
fonctions séquentielles qui sont appliquées au travers de patrons où les communications
entre les processeurs lui sont cachées. Nos travaux sont notamment proches
des concepts introduits par le modèle Pregel, proche de BSP.
— Enfin, des langages et bibliothèques spécifiques, notre travail cherche à retrouver
une efficacité propre aux problèmes spécifiquement traités, par le biais d’optimisations.
Le framework OP2 et le DSL Liszt sont les solutions spécifiques les plus
proches de nos travaux.62 Chapitre 2. Etat de l’art
Solutions spécifiques Patrons et squelettes
SIPSim
Solutions générales
Optimisation Abstraction
Flexibilité
Figure 2.12 – Placement de notre travail par rapport à l’existant.
Enfin, afin de comprendre les résultats présentés dans cette thèse, nous avons terminé
cet état de l’art par une présentation des mesures de performance et des mesures de
difficulté de programmation.3
SIPSim : Structured Implicit
Parallelism for scientific
Simulations
Sommaire
4.1 SIPSim pour les maillages réguliers à deux dimensions . . . . . 74
4.1.1 Structure de données distribuée . . . . . . . . . . . . . . . . . . . . . . . 74
4.1.2 Applicateurs et opérations . . . . . . . . . . . . . . . . . . . . . . . . . . 77
4.1.3 Interfaces de programmation . . . . . . . . . . . . . . . . . . . . . . . . . 78
4.1.4 Spécialisation partielle de template . . . . . . . . . . . . . . . . . . . . . 80
4.2 Résolution numérique de l’équation de la chaleur . . . . . . . . 82
4.2.1 Équation et résolution numérique . . . . . . . . . . . . . . . . . . . . . . 82
4.2.2 Parallélisation avec SkelGIS . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.2.3 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
4.3 Résolution numérique des équations de Saint Venant . . . . . . 89
4.3.1 Équations de Saint Venant . . . . . . . . . . . . . . . . . . . . . . . . . . 89
4.3.2 Résolution numérique et programmation . . . . . . . . . . . . . . . . . . 90
4.3.3 Parallélisation avec SkelGIS . . . . . . . . . . . . . . . . . . . . . . . . . 92
4.3.4 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
6364 Chapitre 3. SIPSim : Structured Implicit Parallelism for scientific Simulations
Dans cette thèse nous nous intéressons aux simulations scientifiques dont les équations
aux dérivées partielles sont résolues par des méthodes numériques qui discrétisent l’espace
et le temps. On appelle ces simulations des simulations basées sur des maillages. Nous
nous intéressons plus précisément, et dans un premier temps, aux simulations dont les
schémas numériques sont explicites et donc de la forme de l’équation (2.3) présentée
dans la section 2.2.3.2. En informatique, ce type de calcul est appelé un calcul stencil.
Le parallélisme implicite pour des calculs de type stencil est un domaine très actif de la
recherche en informatique. Dans ce chapitre est présentée la méthode SIPSim, qui signifie
Structured Implicit Parallelism for scientific Simulations. SIPSim permet d’obtenir une
vision systématique des besoins pour proposer une solution de parallélisme implicite
pour ce type de simulations. SIPSim peut donc être considéré comme un modèle de
programmation parallèle implicite pour les simulations scientifiques.
Afin de définir une approche pertinente pour élaborer des solutions de parallélisme
implicite pour les simulations scientifiques, il faut tout d’abord étudier la parallélisation
de ces simulations scientifiques. Comme nous l’avons déjà décrit dans l’état de l’art 2.4,
Pingali et Al [103] ont défini “The TAO of Parallelism in Algorithms”, qui propose une
classification intéressante des différents types de problèmes à paralléliser. Une fois un
problème classifié dans le “TAO”, des solutions connues de parallélisation peuvent être
appliquées. La parallélisation est donc facilitée grâce à cette classification, mais en aucun
cas cachée, comme nous cherchons à le faire. Comme nous l’avons déjà détaillé dans la
section 2.4.1 de l’état de l’art, le type de simulations auxquelles nous nous intéressons
dans ce travail (sur maillages fixes et schémas numériques explicites) sont classifiées
dans le “TAO” comme des algorithmes topology-driven, dont l’ensemble des éléments du
maillage sont identifiés comme les nœuds actifs (active nodes) de l’algorithme, et peuvent
être traités de façon non-ordonnée dans l’algorithme. Enfin, les calculs sont considérés
comme locaux car ne modifiant pas le maillage d’entrée.
Comme il l’a déjà été évoqué précédemment, pour des architectures parallèles à mé-
moire distribuée, ce genre de simulations est généralement parallélisé en utilisant l’approche
SPMD (Simple Program Multiple Data) décrite dans l’état de l’art. Cette approche
se prête bien aux simulations basées sur les maillages puisqu’elle consiste alors
à partitionner le maillage en plusieurs parties, chacune confiées à des processeurs diffé-
rents qui exécuteront le même code sur leur sous-partie du maillage. L’algorithme 2 de
la partie 2.2.5 illustre ce type de parallélisation, et représente la base de l’analyse de
l’approche SIPSim. Nous rappelons ici cet algorithme avec plus de détails. Nous notons
Sb le schéma numérique à appliquer aux éléments de la bordure physique du maillage,
qui correspond donc à calculer les conditions limites. Nous notons, de plus, S le schéma
numérique permettant le calcul des quantités pour les autres éléments du maillage.
Cet algorithme parallèle peut très clairement être apparenté au modèle BSP, introduit
lui aussi dans l’état de l’art. En effet, dans cet algorithme peuvent être identifiées trois
super-étapes. Tout d’abord une super-étape de communication est effectuée au début de
chaque itération de temps. Dans cette étape, chaque processeur reçoit les valeurs sur le
voisinage N(x), qu’il ne possède pas dans son sous-maillage, afin de pouvoir calculer,
de façon correcte, l’ensemble des nouvelles valeurs pour la nouvelle itération de temps.65
Algorithme 3 : Algorithme parallèle SPMD d’une simulation basée sur un
maillage.
Création du maillage µ
Partitionnement du maillage µ = {µ0, µ1, . . . µp−1}
Création des quantités à simuler appliquées à µ
Initialisation des quantités et des paramètres
Définition du pas de temps, commun à tous les processeurs : t
Définition du temps maximal, commun à tous les processeurs : tmax
tant que t struct DMatrix
template struct DMatrix
template struct DMatrix
template struct DMatrix
Figure 4.4 – Spécialisation partielle de template pour l’objet DMatrix : T est le type de donnée
à stocker dans l’instance, Or est l’ordre de la simulation, et box est le type de connectivité
souhaitée. Ce paramètre a une valeur par défaut à false (star est le choix par défaut).
Trois paramètres de template sont définis pour l’objet DMatrix. Le premier paramètre,
T, indique le type de données qui va être stocké dans l’instance de l’objet. Le82 Chapitre 4. SkelGIS pour des maillages réguliers à deux dimensions
paramètre Or indique ensuite l’ordre nécessaire pour l’instance de l’objet DMatrix. Ce
paramètre peut sembler inutile pour l’objet DMatrix en lui-même, puisque l’ordre est
une indication qui concerne la simulation et non chaque quantité simulée. Toutefois, il
est important de demander cette information au niveau de l’objet DMatrix pour rendre
la solution plus efficace. En effet, dans une simulation, toutes les quantités à simuler
sont nécessaires au calcul du ou des schémas numériques de type (2.3), toutefois, toutes
les quantités à simuler ne participent pas aux calculs faisant intervenir N(x). Demander
l’ordre pour chaque instance de l’objet DMatrix permet donc d’éviter des communications
inutiles lorsque l’instance n’a pas besoin de voisinages. Enfin, le troisième paramètre
de la classe template, box, est un booléen avec une valeur par défaut à false. Ce paramètre
indique la connectivité du maillage qui va être définie en instanciant l’objet DMatrix. En
effet, rappelons ici que l’objet DMatrix a la particularité de regrouper deux composants
de la méthode SIPSim, la structure de données distribuée (DDS), et l’application de
données sur cette structure de données (DPMap). L’instanciation d’un objet DMatrix
correspond donc bien à la définition d’un maillage et il n’est pas impossible qu’une simulation
complexe instancie différents types de connectivités pour ses différentes quantités
à simuler.
Trois spécialisations partielles des paramètres de cette classe sont proposées et données
dans la figure 4.4. Tout d’abord, en conservant la valeur par défaut du paramètre
box, le paramètre Or est spécialisé avec la valeur 0. Cette spécialisation permet d’indiquer
qu’une quantité utilisée dans la simulation ne participe pas aux calculs faisant intervenir
N(x). Autrement dit, ce type de quantité est utilisé localement, sans notion de voisinage.
Cette spécialisation est très importante pour les performances de la solution puisqu’alors
aucune communication MPI ne sera nécessaire. La deuxième spécialisation fixe le paramètre
box avec une valeur à true. Cette spécialisation active donc la connectivité box. Dans
cette spécialisation, les interfaces de voisinage proposées à l’utilisateur seront différentes.
Enfin la troisième spécialisation fixe le paramètre Or à 0 et le paramètre box à true, ce qui
combine les deux spécialisations précédemment décrites. Chaque spécialisation de l’objet
DMatrix propose une implémentation de la classe qui lui est propre, ce qui alourdit considérablement
le code de la bibliothèque (mais pas le code utilisateur). Cependant, cette
solution est très intéressante puisque l’utilisateur ne manipule qu’une unique classe. De
plus, les performances obtenues sont également très intéressantes puisque, dans le code,
les conditions concernant l’ensemble de ces paramètres disparaissent. Enfin, le choix de
la bonne implémentation de classe est effectué à la compilation et non à l’exécution ce
qui rend cette solution efficace.
4.2 Résolution numérique de l’équation de la chaleur
4.2.1 Équation et résolution numérique
L’équation de la chaleur à deux dimensions est définie par
∂u
∂t =
∂
2u
∂x2
+
∂
2u
∂y2
,4.2. Résolution numérique de l’équation de la chaleur 83
où u(x, y, t) représente la température au point (x, y) et à l’itération de temps t.
Le schéma explicite des différences finies est le schéma le plus simple pour résoudre
l’équation de la chaleur. Il consiste en une discrétisation du domaine en espace avec le
maillage {xi
, yj}i,j , avec xi = i∆x et yj = j∆y. ∆x = xi+1 − xi et ∆y = yi+1 − yi sont
les intervalles en espace suivant les deux dimensions. Soit ∆t l’intervalle de temps entre
chaque itération, supposons qu’à un temps tn = n∆t, la valeur u
n
i,j = u(xi
, yj , tn) est
connue pour chaque élément du maillage. Alors, en utilisant le développement polynomial
de Taylor, la solution à l’instant tn+1 est donnée par le schéma suivant :
u
n+1
i,j − u
n
i,j
∆t
=
u
n
i+1,j − 2u
n
i,j + u
n
i−1,j
∆x
2
+
u
n
i,j+1 − 2u
n
i,j + u
n
i,j−1
∆y
2
.
En supposant que ∆x = ∆y, alors le schéma devient :
u
n+1
i,j = (1 − 4λ)u
n
i,j + λ(u
n
i+1,j + u
n
i−1,j + u
n
i,j+1 + u
n
i,j−1
), (4.9)
où λ := ∆t
∆x2 ≤
1
2
garantit la stabilité du schéma numérique.
4.2.2 Parallélisation avec SkelGIS
Le schéma numérique de l’équation (2.3) offre toutes les informations nécessaires
pour coder la simulation en utilisant SkelGIS. Tout d’abord, seule la quantité u nécessite
d’être manipulée dans le schéma. Ensuite, comme le calcul pour l’itération de temps n+1
dépend des résultats de l’itération de temps n, deux instanciations de l’objet DMatrix
sont nécessaires pour stocker successivement les données d’entrée et de sortie. De plus,
le schéma nous donne l’indication qu’une connectivité de type star est nécessaire pour
chaque calcul. En effet, les éléments (i + 1, j) (droit), (i − 1, j) (gauche), (i, j + 1) (bas)
et (i, j − 1) (haut) sont utilisés par le schéma. L’ordre de la simulation est égal à 1 car
aucun élément aux positions i ± 2 ou j ± 2 ne sont nécessaires. Enfin, il y a un unique
schéma à appliquer à chaque itération de temps, ce qui nous indique qu’un unique appel
à un applicateur sera nécessaire pour cette résolution.
La figure 4.5 donne le code de la fonction main du programme de résolution de
l’équation de la chaleur en utilisant SkelGIS. Deux instanciations de l’objet DMatrix sont
tout d’abord effectuées (lignes 12 et 14). Par la suite, la boucle en temps est initialisée
(ligne 15). A chaque itération de temps, l’applicateur est appelé avec l’opération laplacien
(ligne 17) pour résoudre le schéma. Enfin, les DMatrix d’entrée et de sortie sont échangées
pour l’itération en temps suivante (lignes 18 à 20). Notons ici que la création de m3 à la
ligne 18 ne fait que copier l’adresse du pointeur qui est caché derrière l’objet m. Cette
étape n’est donc pas coûteuse en temps d’exécution. Il reste toutefois quelques détails
non précisés dans la figure 4.5. Les instructions INIT SKELGIS et ENDSKELGIS,
tout d’abord, permettent d’initialiser de façon implicite la bibliothèque MPI et certaines
variables utiles à SkelGIS. La classe HEADER permet simplement de définir l’en-tête
d’un maillage cartésien à deux dimensions suivant une largeur et une hauteur (width et
height) et suivant une coordonnée en haut à gauche du maillage (x et y). Il est également84 Chapitre 4. SkelGIS pour des maillages réguliers à deux dimensions
1 #include " s k e l g i s / s k e l g i s . hpp"
2 using namespace s k e l g i s ;
3
4 int main ( int argc , char∗∗ argv )
5 {
6 INITSKELGIS ;
7 HEADER head ;
8 head . x=0; head . y=0;
9 head . width =100; head . h ei g h t =100;
10 head . s p a ci n g =1; head . nodata=−9999;
11
12 DMatrix m( head , 0 ) ;
13 m. se tGl o b alMid dleV alue ( 1 ) ;
14 DMatrix m2( head , 0 ) ;
15 for ( int i =0; i <100; i++)
16 {
17 ApplyUnary:: apply ( l a p l a c i e n ,m,m2 ) ;
18 DMatrix m3(m) ;
19 m = m2;
20 m2 = m3;
21 }
22 ENDSKELGIS;
23 }
Figure 4.5 – Fonction main du programme de résolution de l’équation de la chaleur avec
SkelGIS.
possible de préciser un nombre flottant représentant la hauteur et la largeur d’une maille,
et de pouvoir identifier une valeur qui représente une maille sans donnée. Son nom est
historiquement conservé de l’en-tête des fichiers représentant le terrain dans les SIG
(Système d’Information Géographiques). Enfin, la méthode setGlobalM iddleV alue(1)
permet d’initialiser une valeur à 1 au centre du maillage. Notons qu’il aurait également
été possible d’initialiser ce maillage par un fichier.
La figure 4.6 donne ensuite le code de l’opération laplacien qui est appliquée dans
la fonction main. Cette opération calcule le schéma numérique (4.9) et est appliquée à
chaque itération de temps. Tout d’abord un itérateur est initialisé au début de la DMatrix
d’entrée. Un autre itérateur est initialisé à la fin de cette même DMatrix (lignes 4 et 5).
Pour chaque élément du maillage (ligne 6), le schéma est calculé (ligne 8 à 10) et le résultat
est écrit dans la DMatrix de sortie (ligne 11). Les macros C++ “BEGINApplyUnary”
et “END” aux lignes 1 et 13, servent à identifier le début et la fin de la définition de
l’opération laplacien.
Cet exemple illustre que le code SkelGIS reste très proche d’un code séquentiel. Aucune
difficulté n’est introduite dans ce code puisque les interfaces et les paramètres demandés
sont connus de l’utilisateur. Il peut aussi être noté qu’aucune utilisation de
pointeurs n’est nécessaire dans le code SkelGIS, ce qui simplifie son utilisation. La bibliothèque
gère en effet elle-même la création et la destruction des pointeurs dont elle4.2. Résolution numérique de l’équation de la chaleur 85
1 BEGINApplyUnary ( l a p l a c i e n ,m, double , 1 ,m2, double , 1 )
2 {
3 double a = 0 . 0 5 ;
4 i t e r a t o r i t = m. be gi n ( ) ;
5 i t e r a t o r itEnd = m. end ( ) ;
6 for ( i t ; i t h
DMatrix u
DMatrix v
Figure 4.11 – Déclaration des variables h, u et v
type double, le paramètre Or est égal à 2 et la valeur par défaut du paramètre box est
utilisée. Notons que les autres variables de la simulation sont, pour la plupart, soit du
type DM atrix < double, 2 > soit du type local DM atrix < double, 0 >.
L’algorithme 7 illustre la fonction principale de la simulation. Bien entendu, FullSWOF2D
est un logiciel complexe écrit en langage objet C++, la fonction main de cette
application ne ressemble donc pas réellement à celle présentée ici. Toutefois, nous essayons
ici de mettre en avant les concepts de l’utilisation de SkelGIS. La fonction principale
d’une telle simulation consisterait donc, tout d’abord, en l’instanciation de l’objet DMatrix
pour les trois quantités simulées ainsi que pour l’ensemble des variables nécessaires
aux calculs de la simulation. Tout comme dans le programme séquentiel, ces variables et
quantités seraient ensuite initialisées. Pour cela des opérations peuvent être définies et
appelées par l’intermédiaire d’applicateurs. Il est aussi possible de mettre une valeur par
défaut dans ces variables, ou encore de les initialiser à l’aide d’un fichier de données. Une
fois ces initialisations effectuées, la boucle principale de la simulation en temps est démarrée.
Elle est suivie, tout comme dans l’algorithme séquentiel, d’une boucle for de deux
itérations permettant d’appliquer les schémas à l’ordre 2 pour plus de précision. Dans
cette boucle est ensuite appelé un applicateur. Notons ici qu’un ensemble d’applicateurs
aurait aussi pu être appelé pour partitionner la simulation et l’organiser de façon plus4.3. Résolution numérique des équations de Saint Venant 93
claire. Tout dépend du code séquentiel initial et des dépendances entre les données, tout
comme dans l’implémentation séquentielle. Nous présentons ici une solution ne faisant
appel qu’à un applicateur, pour simplifier l’explication. La véritable implémentation de
FullSWOF2D se décompose en plusieurs appels à des applicateurs répartis dans différents
objets du code. Pour terminer, un deuxième applicateur est appelé afin d’effectuer les
calculs nécessaires pour appliquer le schéma à l’ordre 2.
Algorithme 7 : Fonction main codée par l’utilisateur
DM atrix < double, 2 > h
DM atrix < double, 2 > u
DM atrix < double, 2 > v
...
Initialisation des quantités et des paramètres
Définition du pas de temps : t
Définition du temps maximal : tmax
while t < tmax do
for i dans J0, 2J do
apply_list({h,u,v,etc.},fullswof)
end
apply_list({h,u,v,etc.},heun)
end
Le premier applicateur appelé dans l’algorithme 7 va donc être en charge d’appliquer
une opération contenant le calcul des conditions limites, de la reconstruction, des flux,
du schéma numérique et des frottements. Cette opération est décrite dans l’algorithme 8.
Pour rappel, la méthode SIPSim recommande de proposer au moins deux itérateurs
différents dans l’interface de programmation, le premier pour parcourir les éléments de
la bordure physique sans surcoût de conditions, et le deuxième pour les autres éléments
du maillage. Cette recommandation a été suivie dans l’implémentation de SkelGIS pour
les maillages cartésiens, comme cela a été décrit dans la partie 4.1.3. Pour cette raison,
l’opération fullswof va tout d’abord parcourir les éléments de la bordure physique du
maillage grâce aux itérateurs adaptés (qui sont en fait au nombre de quatre). L’opérateur
[] et les fonctions de voisinage sont ensuite utilisés afin de calculer les conditions limites
de la simulation. Par la suite, l’itérateur contigu mis en place dans SkelGIS est utilisé
afin de naviguer dans l’ensemble des éléments du maillage qui ne font pas partie de la
bordure physique. Une fois encore, l’opérateur [] et les fonctions de voisinage sont utilisés
afin de calculer, le schéma de reconstuction, les flux numériques, le schéma numérique et
enfin les frottements appliqués à l’écoulement du fluide. Notons, de nouveau, qu’il s’agit
d’une simplification de la simulation. En effet, le calcul complet de la reconstruction
hydrostatique est nécessaire avant le calcul des flux numériques, par exemple. Il n’est
donc en théorie pas possible de calculer les deux informations pour un même élément du
maillage dans la même boucle. Comme nous l’avons évoqué précédemment, suivant le code
de la simulation, plusieurs applicateurs peuvent être appelés dans la fonction principale.94 Chapitre 4. SkelGIS pour des maillages réguliers à deux dimensions
Algorithme 8 : Opération séquentielle permettant de décrire le calcul des schémas
numériques des équations de Saint Venant.
Data : {DMatrix}
Result : Modification de {DMatrix}
ItB := itérateur de début sur les bordures physiques
endItB := itérateur de fin sur les bordures physiques
while ItB≤endItB do
Application des conditions limites avec : h[ItB], u[ItB], v[ItB],
h.getRight(ItB,1), v.getX(ItB,2) ...
ItB++
end
It= itérateur de début sur les éléments du maillage
endIt := itérateur de fin sur les éléments du maillage
while It≤endIt do
Calculs avec h[It], u[It], v[It], h.getRight(It,1), v.getX(It,2) ...
Calcul de la reconstruction hydrostatique
Calcul des flux numériques
Calcul du schéma numérique
Calcul des frottements
It++
end
Chaque applicateur effectuera les boucles et les calculs dont il est responsable. Ces choix
d’implémentation sont à la charge de l’utilisateur tout comme s’il codait un algorithme
en séquentiel.
4.3.4 Résultats
Nous allons maintenant présenter les résultats obtenus sur la simulation des équations
de Saint Venant (4.10) décrites précédemment. Ces expériences sont basées sur
deux implémentations parallèles du logiciel FullSWOF. Ces deux implémentations ont
été effectuées de façon simultanée pendant le projet CEMRACS 2012 (Centre d’Eté Mathématique
de Recherche Avancée en Calcul Scientifique) et dans une durée limitée d’environ
trois semaines. La première est une version MPI, que nous appellerons FS_MPI, et
la deuxième la version SkelGIS, que nous appellerons FS_SK. Ces deux implémentations
sont basées sur une même version séquentielle du logiciel FullSWOF2D. FS_MPI a été
implémenté par un ingénieur en mathématiques appliquées ayant les connaissances de
base sur MPI, la version FS_SK, après une courte période de formation sur les concepts
de SkelGIS, a été implémentée par un numéricien. FS_MPI a été implémenté de façon
standard en MPI, en utilisant une décomposition de domaine, une topologie cartésienne
ainsi que des types dérivés. Cette version MPI part du même code séquentiel que l’implémentation
SkelGIS, et tout comme pour l’équation de la chaleur, les codes séquentiels
de calculs ne sont ni modifiés ni optimisés dans ces versions parallèles. Seules les struc-4.3. Résolution numérique des équations de Saint Venant 95
tures de données sont ré-implémentées pour être distribuées sur les processeurs. Le code
séquentiel de calcul n’a donc pas été modifié ou amélioré, les deux versions parallèles du
code sont donc comparables. En revanche, il ne s’agit pas des versions parallèles les plus
efficaces possibles pour cette simulation. Nous ne proclamons d’ailleurs pas que SkelGIS
soit aussi efficace qu’un code parallèle spécifiquement optimisé pour les équations de Saint
Venant. L’objectif du modèle SIPSim, et donc de SkelGIS, est de permettre de coder en
séquentiel un programme qui sera parallèle. L’efficacité du programme dépendra donc de
l’efficacité du code séquentiel en lui-même.
Les expériences menées et présentées ici sont de deux types. Tout d’abord FS_MPI
et FS_SK sont comparés en terme de performances sur les nœuds thin nodes du supercalculateur
TGCC-Curie du CEA, vingtième dans le classement top500 de novembre
2013. Son architecture matérielle est détaillée dans la table 4.5. Chaque expérience a
été effectuée quatre fois et moyennée. L’écart type noté sur l’ensemble des expériences
n’a pas excédé 2%. Par la suite, les métriques de Halstead [65], déjà présentées dans la
partie 2.5, sont utilisées afin de comparer les deux implémentations en terme de difficulté
de codage.
Calculateur TGCC Curie
Processeur 2×SandyBridge
(2.7 GHz)
Cœurs/nœud 16
Mémoire/nœud 64 GB
Compilateur [-O3] Bullxmpi
Réseau Infiniband
Table 4.5 – Spécifications matérielles des nœuds thin du TGCC-Curie
4.3.4.1 Performances
Nous allons tout d’abord comparer en terme de performances FS_MPI et FS_SK qui
sont deux versions parallèles comparables car basées sur le même code séquentiel. Quatre
expériences ont été menées pour évaluer les performances de ces simulations parallèles
et sont décrites dans la table 4.6. Ces expériences font varier la taille du domaine (expé-
riences 1, 3 et 4) ou le nombre d’itérations en temps (expériences 1 et 2). L’ensemble des
temps d’exécution obtenus (en secondes) sont présentés dans la table 4.7. Une représentation
graphique de ces résultats est également proposée dans les figures 4.12, 4.13, 4.14
et 4.15.
Pour l’ensemble des expériences effectuées nous pouvons observer des similarités. Tout
d’abord, nous pouvons noter que les temps d’exécution obtenus pour FS_SK sont, hormis
les valeurs en rouge, meilleurs que pour FS_MPI. Etant donné que la même version
séquentielle de code a été utilisée au départ, il s’agit d’une remarque intéressante pour la
solution SkelGIS. En effet, cette performance provient de l’objet DMatrix. Cet objet est
le seul objet qui n’est pas utilisé dans la version séquentielle, et qui peut être producteur96 Chapitre 4. SkelGIS pour des maillages réguliers à deux dimensions
Taille du maillage Nombre d’itérations
Expérience 1 5k × 5k 5k
Expérience 2 5k × 5k 20k
Expérience 3 10k × 10k 5k
Expérience 4 20k × 20k 5k
Table 4.6 – Expériences de performance sur FS_MPI et FS_SK.
Cœurs Exp1 (sec) Exp2 (sec) Exp3 (sec) Exp4 (sec)
MPI SkelGIS MPI SkelGIS MPI SkelGIS MPI SkelGIS
32 4868.43 3494.92
64 2317.7 1780.4 9353.47 7391.96
128 1154.25 898.219 4578.28 3768.54 45588 31332.9
256 578.65 460.715 2282.53 1988.8 22089.9 17385.6 90974,2 68017.1
512 277.39 284.585 1118.01 1117.09 11299.4 9436.11 45487.1 35112.2
1024 144.26 155.85 557.621 602.66 5739.52 5127.93 22299.1 19821.3
2048 67.49 103.363 273.785 407.73 2930.48 3196.71 11867.4 10986.8
Table 4.7 – Temps d’exécution (en secondes) obtenus pour l’ensemble des expériences sur
FS_MPI et FS_SK.
d’une amélioration de performances (et non de surcoûts) de la version FS_SK. Dans la
version FS_SK, l’utilisateur n’a plus à se soucier de coder ses propres structures de données
et leur accès efficace. Ce travail est confié à la bibliothèque SkelGIS, ce qui simplifie
tout d’abord le code, et ce qui permet d’obtenir une structure optimisée “gratuitement”,
sans aucun effort. Ce constat a d’ailleurs également été fait pour l’équation de la chaleur.
Coeurs (log2)
Temps d'exécution (log2)
SkelGIS
32 64 128 256 512 1024 2048
11
9
7
Figure 4.12 – Logarithme des temps d’exécution de l’expérience 1 pour FS_MPI et FS_SK.
Cependant, nous pouvons également noter que la pente des courbes des fi-
gures 4.12, 4.13, 4.14 et 4.15 est plus accentuée et donc meilleure pour FS_MPI que4.3. Résolution numérique des équations de Saint Venant 97
Coeurs (log2)
Temps d'exécution (log2)
MPI
SkelGIS
64 128 256 512 1024 2048
13 11
9
Figure 4.13 – Logarithme des temps d’exécution de l’expérience 2 pour FS_MPI et FS_SK.
Coeurs (log2)
Temps d'exécution (log2)
MPI
SkelGIS
128 256 512 1024 2048
15 13
Figure 4.14 – Logarithme des temps d’exécution de l’expérience 3 pour FS_MPI et FS_SK.
Coeurs (log2)
Temps d'exécution (log2)
MPI
SkelGIS
256 512 1024 2048
16 15
Figure 4.15 – Logarithme des temps d’exécution de l’expérience 4 pour FS_MPI et FS_SK.
pour FS_SK. En effet, ces figures représentent les temps d’exécution sur une échelle logarithmique.
Cette représentation a la particularité de permettre de comparer les temps
d’exécution mais également de connaître la linéarité du speedup de la simulation. Si
le temps d’exécution présenté est linéaire, le speedup le sera également, et la pente du98 Chapitre 4. SkelGIS pour des maillages réguliers à deux dimensions
temps d’exécution représente également la pente du speedup. Ainsi, il semble que pour
l’ensemble des expériences, le speedup de FS_MPI soit légèrement meilleur que celui de
FS_SK. Ce phénomène traduit, à l’inverse, les surcoûts de la solution SkelGIS, comme
cela a été noté pour l’équation de la chaleur également. En effet, si l’objet DMatrix peut,
de son côté, être à l’origine d’un gain de performances, du simple fait que la structure
de données qui y est implémentée est plus efficace, les autres objets SkelGIS tels que
les applicateurs et les itérateurs provoquent des appels supplémentaires et donc des surcoûts.
Notons que ces surcoûts sont plus accentués sur les expériences 1 et 2, ce qui
montre qu’il y a plus d’impact sur le nombre d’itérations en temps que sur la taille du
domaine à traiter. Ce phénomène s’explique assez bien. À chaque itération de temps, des
applicateurs sont appelés. Comme cela a déjà été expliqué, les applicateurs procèdent,
tout d’abord, aux communications nécessaires pour les calculs, puis, appellent l’opération
de l’utilisateur. Cette opération va ensuite créer des itérateurs et parcourir le maillage.
Si le nombre d’itérations en temps augmente, les surcoûts liés aux applicateurs et aux
itérateurs sont multipliés, alors que si la taille du domaine augmente, seul le parcours
des éléments du maillage est plus long mais les surcoûts, eux, restent identiques.
Pour conclure sur les performances de SkelGIS, il semble tout d’abord évident que,
partant d’un code séquentiel commun, SkelGIS obtient de très bonnes performances aussi
bien en temps d’exécution qu’en passage à l’échelle. SkelGIS offre des perspectives très
intéressantes par le biais de l’objet DMatrix. De façon plus générale, la méthode SIPSim
offre des performances intéressantes grâce à son composant DDS. En effet, dans le cas d’un
maillage cartésien, la structure de données mise en place reste très simple. Dans le cas
de maillages plus complexes, ce composant peut se montrer primordial comme cela sera
illustré dans le chapitre 5. Si SkelGIS provoque malgré tout des surcoûts qui peuvent nuire
à la linéarité de ses speedup, SkelGIS reste tout de même une solution de parallélisme
implicite très efficace sur les maillages cartésiens et qui propose des performances proches
d’une version MPI comparable.
4.3.4.2 Effort de programmation
L’approche SIPSim vise à proposer des solutions de parallélisme implicite pour les
simulations scientifiques. Pour cette raison, SkelGIS se doit d’être une solution simple
d’utilisation. Nous allons donc présenter les résultats qui ont été obtenus en terme de
difficulté de codage, toujours en comparant FS_MPI et FS_SK. Pour ce faire, les mé-
triques de Halstead [65] ont de nouveau été mesurées pour ces deux versions parallèles
de FullSWOF. Les résultats obtenus sont présentés dans la table 4.8.
Nous pouvons tout d’abord observer, dans ces résultats, que l’effort de programmation
E à fournir est environ vingt fois moins important pour FS_SK que pour FS_MPI.
Ce résultat montre donc que l’ambition de SIPSim, pour proposer des solutions de parallélisme
implicite simples, est atteinte. Rappelons que le résultat de l’effort de programmation
dans les métriques de Halstead est égal à la multiplication du volume du
programme V par la difficulté de codage du programme D. Nous pouvons observer dans
ce résultat que le volume de code V produit dans FS_SK est environ cinq fois moindre
que dans FS_MPI et que la difficulté D est environ quatre fois moindre dans FS_SK4.4. Conclusion 99
Métriques MPI SkelGIS Gain %
N1 7895 2673 66
N2 45147 8507 81
η1 414 297 28.3
η2 414 353 14.7
V 537.1K 104.5K 80.5
D 13274 3576 73
E 7130M 373M 94.7
Table 4.8 – Métriques de Halstead mesurées pour FS_MPI et FS_SK.
que dans FS_MPI. Ce résultat est intéressant puisqu’il montre deux aspects différents de
simplicité d’utilisation dans SkelGIS. Tout d’abord, le volume du programme parallèle de
FullSWOF écrit avec SkelGIS est cinq fois moins important que le volume du programme
MPI. Nous avons d’ores et déjà expliqué ce résultat, il est dû à l’utilisation de l’objet
DMatrix. En effet, l’utilisation de cet objet permet de s’abstraire de la programmation
d’une structure de données dans le code utilisateur, cette structure de données étant entièrement
gérée par SkelGIS. De plus, la répartition de cette structure de données sur les
différents processeurs est elle aussi entièrement implicite ce qui allège encore davantage
le volume du code final. Le second point de simplicité de SkelGIS, illustré par ces résultats,
est qu’il est quatre fois plus difficile de coder FS_MPI que FS_SK. Cette métrique
est fortement liée au nombre total et distinct d’opérateurs et d’opérandes dans les deux
implémentations. Une solution SIPSim ne fait appel qu’à quatre composants principaux
et délègue dans ces quatre composants les structures de données, les décompositions de
domaine et les communications MPI. Pour cette raison la complexité du code en terme
de nombre de variables et d’appels de fonctions est moins importante dans FS_SK.
Pour finir, et comme cela a déjà été abordé dans l’état de l’art, les métriques de
Halstead ne s’intéressent qu’à des concepts de programmation séquentiels. Ainsi, l’appel
à une fonction MPI aura le même coût que l’appel à une fonction classique d’un code
séquentiel. Aucune métrique existante ne tient compte de la difficulté des concepts parallèles
et de la difficulté de penser le programme en parallèle. Il est très difficile de mettre
en œuvre de telles métriques, toutefois il semble évident, dans ce cas, que la véritable
difficulté de programmation D de FS_MPI soit supérieure à celle trouvée par les mé-
triques de Halstead. SkelGIS de son côté, ne fait appel à aucune notion de parallélisme
et est aussi simple à mettre en œuvre, conceptuellement, qu’un code séquentiel.
4.4 Conclusion
Dans ce chapitre nous avons décrit l’implémentation de SkelGIS dans le cas particulier
des maillages cartésiens à deux dimensions. Nous avons tout d’abord détaillé l’implémentation
de cette solution en suivant les composants du modèle SIPSim, puis nous avons100 Chapitre 4. SkelGIS pour des maillages réguliers à deux dimensions
exposé deux cas d’application réels. Le premier sur la résolution de l’équation de la chaleur,
et le deuxième sur la résolution des équations de Saint Venant, en suivant la méthode
appliquée dans le logiciel FullSWOF2D. Un ensemble de résultats a été présenté, tout
d’abord sur les performances de la solution, mais aussi sur l’effort de programmation à
fournir pour utiliser SkelGIS. Ces résultats ont été comparés à ceux d’une implémentation
MPI implémentée à partir d’un même code séquentiel. Le modèle SIPSim, et donc la
bibliothèque SkelGIS, laissant à la charge de l’utilisateur le code séquentiel qui décrit les
schémas numériques à calculer, la performance du code final dépend également du code
séquentiel implémenté. Il était donc important de partir pour ces deux implémenetations
d’une même version séquentielle sans y ajouter d’optimisations séquentielles particulières
mais en proposant toutefois une implémentation MPI efficace. Les résultats obtenus sont
très intéressants et montrent qu’il est possible de proposer une implémentation du modèle
SIPSim efficace, d’autant plus que toutes les implémentations possibles n’ont pas
été mises en place, comme par exemple l’utilisation des registres de vectorisation. Cette
première implémentation de SkelGIS a donc illustré la viabilité du modèle SIPSim sur
des maillages cartésiens à deux dimensions.
Il est donc possible, grâce au modèle SIPSim d’implémenter des solutions de parallé-
lisme implicite efficace pour les maillages de type cartésiens. Une extension de ce travail
peut d’ailleurs proposer une solution pour des maillages cartésiens à n dimensions. De
plus, grâce aux travaux OP2 [59, 60, 94] et Liszt [50], nous savons que les concepts du
modèle SIPSim peuvent s’appliquer au cas des maillages non-structurés. En effet, OP2
et Liszt proposent des modèles de programmation parallèle implicite proches de ceux
proposés par l’approche SIPSim. Le reste de cette thèse propose une implémentation du
modèle SIPSim pour un cas d’application qui n’a, à notre connaissance, jamais été traité
dans des solutions de parallélisme implicite : les simulations sur des réseaux.5
SkelGIS pour des simulations
sur réseaux
Sommaire
6.1 Bilan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
6.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
101102 Chapitre 5. SkelGIS pour des simulations sur réseaux
Le chapitre précédent a présenté l’implémentation de SkelGIS pour les simulations
sur des maillages cartésiens à deux dimensions. Dans ce chapitre est abordé un cas plus
complexe d’implémentation de la méthode SIPSim. La bibliothèque SkelGIS a, en effet,
été implémentée dans le cas de simulations sur des réseaux pouvant être représentés sous
forme de graphes dirigés acycliques (DAG). Un réseau n’est pas considéré comme un
maillage, même s’il peut s’y apparenter par certains côtés. Dans ce chapitre sera tout
d’abord décrite la notion de réseau afin de comprendre pourquoi la méthode SIPSim peut
être appliquée à ce type de simulations. Par la suite, l’implémentation de SkelGIS pour
les réseaux sera détaillée. Cette implémentation, plus complexe que le cas des maillages
cartésiens à deux dimensions, nécessitera une partie supplémentaire décrivant avec précision
l’implémentation de la structure de données distribuée. Un cas d’application réel sera
ensuite présenté, afin d’évaluer les performances de SkelGIS. Il s’agit d’une simulation
d’écoulement du sang dans le réseau artériel. L’implémentation de cette simulation avec
SkelGIS sera comparée avec une version OpenMP, et sera évaluée sur différents types de
clusters. Enfin, des travaux plus récents seront présentés sur le problème de partitionnement
des réseaux. Nous étudierons l’implémentation actuelle de partitionnement dans
SkelGIS, puis deux méthodes plus proches du véritable problème de partitionnement des
réseaux.
5.1 Les réseaux
Afin de faciliter la compréhension de ce chapitre nous allons définir ce qui est appelé
un réseau et les caractéristiques qui en découlent. Cette notion est utilisée dans diverses
simulations, toutefois, malgré son utilisation fréquente, les détails sur ce qu’est exactement
appelé un réseau sont peu abordés dans la littérature. Nous allons illustrer ici qu’un
réseau peut être assimilé, par certains côtés, à un maillage. Toutefois un réseau n’est pas
un maillage pour plusieurs raisons qui seront présentées.
Tout d’abord, il est évident qu’un réseau, en terme de simulation, est une structure
permettant de simuler des phénomènes réels de réseaux tels que les réseaux routiers,
sanguins, fluviaux, pétrolifères etc. Un réseau permet de discrétiser le domaine en espace
en deux types d’éléments différents : les nœuds et les arêtes. Dans le cas d’une simulation
d’écoulement du sang dans le réseau artériel, par exemple, les arêtes du graphe
sont assimilées aux artères, et les nœuds du graphe aux points de rencontre de plusieurs
artères, aussi appelés conjonctions. Les points de rencontre des artères n’ayant pas tous
la même connectivité, un réseau est une structure irrégulière. Cette discrétisation peut
être apparentée à un graphe dirigé ou non, avec ou sans cycles et projeté dans R
2 ou
R
3
. Les deux types d’éléments sont donc les nœuds et les arêtes et à chacun de ces deux
types pourront être appliqués deux discrétisations et deux schémas numériques différents
(figure 5.1). Un réseau permet donc de résoudre des problèmes représentant deux phé-
nomènes physiques différents mais liés entre eux. La notion de réseau rappelle alors les
maillages avancés par blocs ou hybrides, qui ont été évoqués dans la section 2.2.2.2 de
cette thèse.
Un réseau peut être assimilé à un maillage pour deux raisons :5.1. Les réseaux 103
Figure 5.1 – Illustration d’un réseau à gauche et d’un exemple de simulation multi-physique à
droite avec deux types de discrétisation. Les nœuds subissent une discrétisation cartésienne de
l’espace et les arêtes subissent une discrétisation non-structurée de l’espace.
— La construction d’un réseau consiste en la dicrétisation du domaine en deux types
d’éléments.
— Un réseau représente une connectivité entre ses éléments sous la forme d’un
graphe.
Pour ces deux raisons, certaines ressemblances avec un maillage, en particulier avec un
maillage irrégulier, peuvent être trouvées et utilisées pour l’implémentation. En revanche,
un réseau n’est pas un maillage pour deux autres raisons :
— Le graphe formé par un réseau ne représente pas des faces ou des cellules, et les
calculs appliqués ne porteront pas sur des cellules, contrairement aux maillages.
— Le graphe ne forme pas l’objet simulé mais le représente avec deux types d’élé-
ments différents, potentiellement très grands, sur lesquels seront effectués des calculs
qui peuvent à nouveau discrétiser l’espace.
Afin de rendre plus claire la différence entre un maillage et un réseau nous allons
essayer d’en donner des définitions par l’intermédiaire de la théorie des graphes. Nous
avons d’ores et déjà vu qu’un maillage est un graphe connexe, sans isthme dont la planarité
est systématique dans R
2 mais pas dans R
3
. Un réseau est un graphe connexe
mais qui peut contenir des isthmes. Autrement dit, les nœuds d’un réseau ne forment
pas des faces, ou cycles élémentaires. De plus un réseau, même s’il est plaqué dans R
2
,
n’est pas nécessairement planaire contrairement à un maillage. Prenons deux exemples
simples qui montrent qu’un réseau n’est pas obligatoirement un graphe planaire, même
sur R
2
. Dans un réseau représentant les fleuves et rivières, par exemple, il arrive qu’il
existe des rivières souterraines avec un point d’entrée et un point de sortie en surface,
comme c’est le cas pour la résurgence de la Loire, appelée le Loiret, par exemple. Par
conséquent les arêtes, qui représentent les rivières et fleuves peuvent se croiser sans pour
autant qu’un point de conjonction ne soit présent à cette intersection. La même remarque
peut être faite sur un réseau routier dans lequel il y aurait des tunnels souterrains, ce qui
superposerait plusieurs routes qui ne se rencontrent pas. Un réseau est donc un graphe
connexe quelconque. La figure 5.2(a) illustre un graphe planaire qui ne forme pas un104 Chapitre 5. SkelGIS pour des simulations sur réseaux
maillage mais un réseau, et la figure 5.2(b) illustre un réseau où des arêtes peuvent se
croiser sans l’existence d’un nœud à la conjonction de ces arêtes.
(a) Graphe planaire qui ne repré-
sente pas un maillage.
(b) Graphe connexe quelconque représentant
un réseau.
Figure 5.2 – Maillages et réseaux.
Dans une simulation sur les réseaux deux discrétisations du domaine peuvent être
effectuées. La première pour construire le réseau et la deuxième sur chaque élément du
réseau, c’est-à-dire l’ensemble des nœuds et des arêtes. De cette façon il est possible
d’appliquer des schémas numériques à l’ensemble du domaine tout en définissant deux
comportements différents lors de la simulation. Dans un réseau deux types de schémas
numériques différents peuvent donc être appliqués, un à chaque type d’élément, les nœuds
et les arêtes. Ces deux schémas numériques ont la particularité d’être liés dans une même
itération de temps, c’est-à-dire que l’un des deux impacte le résultat de l’autre. Par
conséquent, dans une simulation sur les réseaux, même si chaque schéma numérique est
explicite et ne crée pas de dépendance parmi les éléments d’une même itération de temps
(comme c’est le cas dans l’équation (2.3)), une dépendance peut être créée entre les deux
schémas numériques. Il en résulte, soit l’obtention de nouveaux schémas numériques
explicites, soit plus généralement l’obtention de nouveaux schémas numériques implicites
(équation (2.4)). Si un ou plusieurs schémas implicites sont obtenus, suite à la mise en
réseau de chaque schéma explicite, l’un des deux types d’éléments du réseau devra être
calculé avant l’autre et son résultat impactera le deuxième dans une même itération de
temps. Ainsi si l’on note T1 et T2 les arêtes et les nœuds du réseau, ou vice-versa, une
simulation sur un réseau sera typiquement constituée de quatre étapes :
1. communication des éléments T1 à t − 1,
2. calcul des éléments T2 à t,
3. communication des éléments T2 à t − 1 ou/et t,
4. calcul des éléments T1 à t.5.1. Les réseaux 105
L’étape 3 est l’étape qui caractérise le fait que les schémas numériques sont explicites ou
implicites. En effet, si l’étape 4, pour être calculée, a besoin des éléments T2 uniquement
à l’instant t−1, nous considérons les schémas comme explicites. Si, en revanche, l’étape 4
nécessite les éléments T2 à l’itération t alors les schémas sont implicites. Notons que si les
schémas numériques sont explicites alors les étapes peuvent être organisées différemment :
1. communication des éléments T1 et T2 à t − 1,
2. calcul des éléments T1 et T2 à t,
La nature des schémas numériques (explicite ou implicite) n’est pas le seul élément
impacté par la liaison des schémas numériques d’un réseau. En effet, la notion de voisinage
N(x) (ou stencil) est elle aussi modifiée. Dans les schémas numériques d’un réseau, chaque
schéma numérique (implicite ou non) possède un voisinage défini par N(x) = Nin(x) ∪
Nout(x). Nin(x) représente le N(x) que l’on peut trouver dans une simulation classique
définissant un seul maillage et un seul schéma numérique, il s’agit des éléments voisins
de x dans le maillage local. Nout(x) représente le voisinage issu du réseau. En effet, dans
un réseau, comme illustré dans la figure 5.1, les différents maillages, et donc les différents
schémas numériques sont liés entre eux. Cette liaison se traduit par Nout(x). Notons
qu’un élément interne au maillage local n’est pas concerné par la liaison avec un autre
maillage et alors Nout(x) = ∅. La définition du voisinage Nout d’un réseau sera étudiée
en détails dans la partie 5.2.4.2, et est illustrée dans la figure 5.3.
Enfin une dernière caractéristique des réseaux doit être abordée dans cette partie.
Un maillage est concerné par ce qui est appelé une bordure physique. Comme il l’a
été expliqué précédemment, lorsqu’une simulation est effectuée, l’espace doit être borné
alors que le phénomène réel ne l’est pas. Pour cette raison des conditions limites sont
ajoutées aux EDP et permettent de simuler de façon plus réaliste ce qui se passe aux
bords du domaine. Un réseau, tout comme un maillage, discrétise le domaine initial, il
existe donc également une notion de bordure physique dans un réseau. Dans un réseau
général, représenté par un graphe quelconque, dirigé ou non, les bordures physiques vont
être représentées par certains nœuds indiqués au préalable comme bordures physiques
du domaine.
Dans le reste de ce chapitre, la définition générale d’un réseau n’est pas utilisée. En
effet, nous nous intéressons ici à une sous-partie des réseaux qui peuvent être représentés
par un graphe dirigé acyclique, ou DAG. Dans ce cas, les nœuds représentant la bordure
physique du domaine sont les nœuds racines et les nœuds feuilles du DAG. Le reste de ce
chapitre s’intéresse également à des simulations où les schémas numériques appliqués aux
éléments du réseau sont définis dans une unique dimension. Ce travail donne donc une
première solution de parallélisme implicite pour les simulations sur les réseaux et étudie
sa faisabilité. A notre connaissance, aucun travail similaire n’existe à l’heure actuelle.106 Chapitre 5. SkelGIS pour des simulations sur réseaux
5.2 SIPSim pour les réseaux
Tout comme pour l’implémentation de SkelGIS pour les maillages cartésiens, nous allons
tout d’abord décrire l’implémentation des quatre composants de la méthode SIPSim
pour le cas des simulations sur les réseaux.
5.2.1 Structure de données distribuée
Tout comme pour l’implémentation de la méthode SIPSim pour les grilles carté-
siennes à deux dimensions, le premier composant de la méthode SIPSim à implémenter
est la structure de données distribuée (DDS) permettant de représenter le maillage et sa
connectivité. Comme il l’a été décrit précédemment, un réseau ne peut pas être considéré
comme un maillage, toutefois il s’en approche puisque, tout comme un maillage, il
consiste à discrétiser le domaine en éléments et à en représenter leur connectivité. Pour
cette raison la structure de données distribuée qui représente le réseau doit posséder les
mêmes caractéristiques qu’un maillage, et la méthode SIPSim s’applique donc parfaitement
à ce type de simulations. La structure de données doit donc garantir un accès
efficace aux éléments (nœuds et arêtes) et aux voisinages Nout. Ce DDS, là encore, va
être responsable de l’efficacité de la solution, et l’ensemble de l’implémentation de la
méthode SIPSim pour les réseaux repose sur ce premier composant. Rappelons que nous
nous intéressons ici à la sous classe des réseaux pouvant être représentés sous forme de
DAG. La DDS pour ces réseaux est nommée DDAG. L’implémentation de ce DDS est
complexe, et la section 5.3 décrira en détails cette implémentation. Bien évidemment, la
difficulté majeure se trouve dans le fait qu’un réseau est une structure irrégulière où la
connectivité est différente pour chaque élément, là où elle est régulière pour les grilles
cartésiennes.
Une structure de données irrégulière va donc tout d’abord poser un problème d’efficacité
pour accéder aux éléments et à leur voisinage. La résolution de ce premier problème
sera entièrement décrite dans la section 5.3. Mais outre cette difficulté, une structure irré-
gulière pose un autre problème, qui lui aussi impacte de façon significative l’efficacité de
la solution. En effet la méthode SIPSim implémente des solutions SPMD ce qui implique
une bonne décomposition de domaine pour obtenir de très bonnes performances. Dans
le cas des réseaux, cette décomposition de domaine va se traduire par un problème de
partitionnement de graphe. Le problème du partitionnement de graphe est un problème
connu et NP-complet, ce qui signifie que des heuristiques sont appliquées pour approcher
au mieux la solution idéale en un temps raisonnable. Le partitionnement de réseau
est particulier par rapport à un partitionnement de graphe classique où il est considéré
que des calculs sont faits soit sur les nœuds, soit sur les arêtes. Dans le cas d’un ré-
seau des calculs sont effectués sur les deux types d’éléments et impactent l’équilibrage
de charge. L’heuristique implémentée dans le prototype actuel de SkelGIS ainsi que deux
autres algorithmes seront étudiés dans la section 5.5. En effet, dans la version actuelle de
SkelGIS, une heuristique de rattachement des arêtes sœurs a été implémentée. Cette solution
propose des résultats raisonnablement bons, comme nous le verrons dans la partie
d’évaluation 5.4, toutefois il est probable qu’avec les deux autres solutions étudiées dans5.2. SIPSim pour les réseaux 107
la section 5.5, qui utilisent du partitionnement d’hypergraphe, les performances soient
meilleures.
Lors d’un partitionnement de graphe, et donc d’un partitionnement de réseau, la
solution idéale n’est que rarement trouvée et il persiste toujours un léger déséquilibre
dans la solution de partitionnement. Pour cette raison, un point essentiel pour améliorer
les performances de la solution est d’opérer un recouvrement des communications avec
les calculs locaux. En effet, dans un programme parallèle de type SPMD pour du calcul
stencil, chaque sous-domaine en espace appartenant à chaque processeur peut être dé-
composé en deux parties. Une première partie est dite locale-interne. Cette partie peut
être calculée sans aucun échange avec les autres processeurs. La deuxième partie localeexterne,
en revanche, nécessite des communications avec les autres processeurs afin de
connaître les valeurs au bord du domaine local. Dans un mécanisme de recouvrement des
communications par les calculs, le programme se découpe alors en quatre étapes :
1. les communications non bloquantes MPI sont initialisées
2. les calculs sur la partie locale-interne sont effectués
3. les communications non bloquantes MPI sont terminées
4. les calculs sur la partie locale-externe sont effectués
Ce mécanisme a été mis en place pour l’implémentation de la méthode SIPSim sur les
réseaux (SkelGIS pour les réseaux). Ce mécanisme est possible par l’optimisation de la
structure de données distribuée qui sera décrite dans la section 5.3.
5.2.2 Application de données
L’objet DDAG renferme donc une structure de données lourde et complexe, contrairement
à l’implémentation de l’objet DMatrix. Cette complexité est due au fait qu’il
est nécessaire, pour chaque élément de la structure, de retenir la connectivité qui lui
est propre. Chaque élément a, en effet, potentiellement une connectivité différente. Pour
cette raison, l’implémentation de SkelGIS pour les réseaux reste fidèle à la méthode SIPSim.
En effet, pour l’implémentation des DMatrix le choix a été fait d’embarquer le
composant DPMap dans le DDS lui-même, celui-ci étant léger. Dans le cas des réseaux,
le DDS DDAG étant beaucoup plus lourd, il sera instancié une seule fois pour chaque
type de réseau de la simulation, puis des objets plus légers se chargeront d’appliquer les
données sur ce DDS. Ces objets sont de deux types, un pour appliquer des données sur
les nœuds du réseau, et l’autre pour appliquer des données sur les arêtes du réseau. Ils
sont nommés respectivement DPMap_Nodes et DPMap_Edges. Ce sont ces objets qui
seront instanciés pour définir les quantités simulées dans les schémas numériques et ainsi
pour obtenir σ.
5.2.3 Applicateurs et opérations
Une fois le DDAG défini et les quantités à simuler instanciées, il faut appliquer les
schémas numériques séquentiels. L’utilisateur va alors, comme pour les DMatrix, définir
des opérations séquentielles qui vont représenter ses schémas numériques. Libre à lui de108 Chapitre 5. SkelGIS pour des simulations sur réseaux
définir autant d’opérations que nécessaire, sa seule contrainte est d’appliquer ses opérations
par le biais d’applicateurs. Il en existe deux à l’heure actuelle pour les réseaux, ils
s’appellent apply_list et apply_listi. Ce sont des procédures définies par :
apply_list : {DPM ap_Edges} × {DPM ap_Nodes} × Op (5.1)
apply_listi : {T1} × {T2} × Op1 × Op2 (5.2)
où {DPM ap_Edges}, {DPM ap_Nodes}, {T1} et {T2} sont des ensembles d’instances
des objets DPM ap_Edges et DPM ap_Nodes, et Op, Op1 et Op2 des opérations.
Le premier applicateur effectue tout d’abord les communications afin d’obtenir les valeurs
voisines, et non locales, nécessaires aux calculs des quantités (DPMap) indiquées en
argument. L’applicateur appelle ensuite l’opération Op de l’utilisateur. Ce premier applicateur
peut être particulièrement intéressant pour l’application de schémas numériques
explicites car il a la particularité d’offrir beaucoup de libertés à l’utilisateur. En effet,
l’utilisateur peut librement écrire une opération qui agira sur les nœuds comme sur les
arêtes, dans l’ordre souhaité. Les schémas numériques étant explicites, seules les communications
effectuées avant l’appel à l’opération sont nécessaires. Toutefois, ces opérations,
très générales, ne peuvent être mises en place pour des schémas numériques implicites,
puisqu’alors des communications sont nécessaires entre les phases de calcul. Cependant,
il est tout de même possible d’appliquer des schémas numériques implicites avec ce premier
applicateur. Dans ce cas, il sera nécessaire d’appeler l’applicateur à chaque phase
du calcul afin d’effectuer implicitement les échanges de données nécessaires. Il n’est alors
pas évident de définir l’utilisation de l’applicateur, ni de comprendre son utilisation. Pour
cette raison, un deuxième applicateur est proposé et permet d’effectuer des calculs implicites
en quatre étapes, comme présenté dans la partie 5.1. Cet applicateur commencera
par (1) effectuer une première phase de communication des éléments de type T1 (calculés
à l’itération t − 1), puis (2) appellera l’opération Op2 sur les éléments de type T2. Par
la suite, (3) une deuxième phase de communication aura lieu pour échanger les éléments
de type T2 venant d’être calculés ( à l’itération t donc), pour enfin (4) appeler l’opération
Op1 qui effectue les calculs sur les éléments T1. Notons, de nouveau, que T1 et T2
peuvent alors être associés indifféremment aux nœuds ou aux arêtes du réseau.
5.2.4 Interfaces de programmation
Enfin afin de pouvoir programmer une opération le dernier composant de la méthode
SIPSim doit être implémenté. Il s’agit des interfaces de programmation qui sont regroupées
en trois types précédemment décrits, les itérateurs, les accesseurs, et les fonctions
pour accéder aux voisinages des éléments.
5.2.4.1 Itérateurs
Les itérateurs permettent de se déplacer dans des données appliquées à un DDS. Dans
le cas des réseaux, les itérateurs permettent donc de se déplacer dans des instances des
objets DPMap_Nodes et DPMap_Edges. Il existe huit itérateurs pour les réseaux, trois
pour l’objet DPMap_Edges et cinq pour l’objet DPMap_Nodes.5.2. SIPSim pour les réseaux 109
Rappelons que, tout comme pour les DMatrix, l’ordre de parcours de l’ensemble des
nœuds ou de l’ensemble des arêtes du réseau n’a pas d’importance, et que la solution
obtenue sera la même si l’ordre de parcours est modifié. En effet, comme expliqué dans
la partie 5.1, le seul ordre de traitement peut venir des phases de calcul sur les nœuds
ou sur les arêtes. Ceci est dû au fait que les deux schémas numériques explicites (2.3)
de départ n’introduisent pas de dépendances entre les nœuds d’une même itération de
temps, ou entre les arêtes d’une même itération de temps.
Nous allons décrire les trois itérateurs communs aux objets DPMap_Nodes et DPMap_Edges.
Tout d’abord, un premier itérateur permet simplement de parcourir l’ensemble
des nœuds/arêtes du réseau et cet itérateur garantit que l’ensemble des nœuds/arêtes
est bien parcouru. Cet itérateur est ensuite divisé en deux itérateurs qui vont permettre
de parcourir les nœuds/arêtes locaux-internes et locaux-externes précédemment
décrits. Ces deux itérateurs seront utilisés pour effectuer le recouvrement des communications
MPI par les calculs locaux dans les applicateurs. Deux itérateurs supplémentaires
ont été implémentés afin de naviguer dans la bordure physique du domaine. Il a été décrit
dans la section 5.1 que les bordures physiques, dans le cas d’un réseau de type DAG,
étaient représentées par deux types particuliers de nœuds, les racines et les feuilles du
DAG. Un premier itérateur sur les bordures physiques permet donc de naviguer dans les
racines du DAG, et un deuxième dans les feuilles du DAG. Tout comme pour les DMatrix,
ces deux itérateurs sont très importants pour éviter des conditions inutiles dans
le code utilisateur afin de déterminer si le nœud courant est une racine, une feuille ou
un nœud interne. Avec l’ensemble de ces itérateurs, l’utilisateur peut naviguer dans la
bordure physique et dans les nœuds internes sans conditions dans le code. Notons que
l’implémentation de ces itérateurs est possible, là encore, grâce aux optimisations de la
DDS DDAG qui sera décrite dans la section 5.3.
5.2.4.2 Voisinages
La notion de voisinage est l’une des notions les plus importantes de la méthode
SIPSim puisqu’elle rend possible les calculs stencil et donc la résolution des EDP. Il
est important, tout d’abord, de définir quel voisinage Nout est nécessaire autour d’un
nœud et d’une arête du réseau pour qu’ils puissent être calculés. La figure 5.3 illustre le
voisinage nécessaire. Pour un nœud du réseau, le voisinage nécessaire peut être constitué
des arêtes entrantes et sortantes. Pour une arête du réseau, les informations nécessaires
sont les nœuds source et destination de l’arête. Par conséquent, les interfaces permettant
de connaître le voisinage d’un nœud sont constituées de deux fonctions pour obtenir une
liste des arêtes entrantes et sortantes, la première notée getInEdges, et la deuxième notée
getOutEdges. Ces fonctions retournent un vecteur d’itérateurs sur les arêtes entrantes et
sortantes. Quant aux interfaces pour le voisinage d’une arête il s’agit de deux fonctions,
l’une pour connaître le nœud source, notée getSrcNode, et l’autre pour connaître le nœud
destination, notée getDstNode.
Cependant ce voisinage peut être plus complexe dans certains cas. En effet, comme
nous l’avons évoqué précédemment, une simulation sur les réseaux est une sous-partie
des simulations multi-physiques. Cela signifie que potentiellement deux discrétisation110 Chapitre 5. SkelGIS pour des simulations sur réseaux
ARÊTES
ENTRANTES ET
SORTANTES
NOEUD
SOURCE
VOISINAGE DES NOEUDS VOISINAGE DES ARÊTES
NOEUD
DESTINATION
Figure 5.3 – Voisinage d’un nœud et d’une arête d’un réseau.
différentes peuvent être effectuées dans les nœuds et les arêtes afin de simuler deux
phénomènes liés ensemble par un réseau. SkelGIS se limite, comme nous l’avons vu,
aux discrétisations à une dimension dans les nœuds et les arêtes. SkelGIS offre donc la
possibilité de définir que chaque arête ou nœud contient un tableau et non un unique
élément. Cette notion est très importante pour pouvoir appliquer des schémas numériques
à une dimension sur les arêtes ou les nœuds. Bien entendu, cette notion pourrait être
étendue à un schéma numérique à deux dimensions et plus, mais le prototype actuel de
SkelGIS n’implémente pas ces fonctionnalités. Par exemple, dans une simulation sanguine
sur le réseau artériel, l’écoulement du sang dans une artère est simulé par des équations
d’écoulement des fluides. Par conséquent, il faut simuler l’écoulement dans une artère
par un maillage, que nous supposerons à une dimension. Dans ce cas il est important
de se demander ce que devient le voisinage nécessaire pour un nœud. Ce voisinage est
alors lié, tout comme pour les DMatrix, à l’ordre du schéma numérique appliqué dans
les arêtes du réseau. La figure 5.4 illustre ce voisinage dans le cas d’un schéma d’ordre
2. En effet, dans ce cas, le nœud source de l’arête n’a pas besoin de connaître l’ensemble
du maillage 1D géré par l’arête, mais uniquement ses deux premières valeurs. De même
le nœud destination n’a besoin de connaître que les deux dernières valeurs du maillage
de l’arête.
ordre=2
Figure 5.4 – Voisinage pour le cas particulier d’un maillage 1D dans les arêtes.
Cette notion avancée de voisinage est très importante afin de ne pas échanger des données
inutiles lors des communications MPI. En d’autres termes, il est très important, pour
l’efficacité du programme parallèle, que les communications MPI effectuées représentent
réellement le voisinage Nout nécessaire. Il serait en effet dommage de communiquer tout
le tableau deux fois pour chaque arête. Cette notion peut paraître compliquée, toutefois5.2. SIPSim pour les réseaux 111
nous allons voir dans la partie qui suit, que l’utilisation des spécialisations partielles de
templates simplifie l’utilisation de ces concepts.
5.2.5 Spécialisation partielle de template
Tout comme dans le cas des maillages cartésiens à deux dimensions, le mécanisme de
spécialisation de template a été utilisé pour SkelGIS dans son implémentation pour les
réseaux. Une fois encore, la détermination des bons paramètres de template permet d’éviter
des conditions coûteuses dans le code et permet d’éviter la mise en place du système
d’héritage virtuel du C++, coûteux à l’exécution. Nous avons vu pour l’objet DMatrix
que ses spécialisations étaient liées à la valeur de son ordre, ainsi qu’à la définition de sa
connectivité. Pour les réseaux, les paramètres sont également liés au voisinage nécessaire
(l’ordre de la simulation) mais également au type de données appliquées aux arêtes ou
aux nœuds du réseau.
Tout d’abord, contrairement à l’objet DMatrix de SkelGIS, l’objet DDAG ne concerne
que la définition du réseau et sa connectivité et non les données qui lui sont associées.
Pour cette raison, conformément à la méthode SIPSim, cet objet est peu manipulé par
l’utilisateur. Bien que l’objet DDAG soit responsable de l’efficacité de l’ensemble de
la solution, et que l’ensemble de l’implémentation repose sur lui, les spécialisations de
templates ne portent pas sur lui mais sur les données qui y sont appliquées, les DPMap.
De cette manière, les choix effectués pour les voisinages ne sont pas figés pour toutes les
données de la simulation, ce qui laisse plus de liberté à l’utilisateur. Comme nous l’avons
vu précédemment, certaines quantités à simuler peuvent en effet participer au schéma
explicite (2.3) par le calcul de σ(x, t − 1), mais pas par le calcul de σ(y, t − 1); y ∈ N(x).
Il est donc important pour l’efficacité de la solution de laisser la notion de voisinage au
niveau des quantités à simuler et non au niveau du réseau. La figure 5.5 donne la définition
des objets DPMap_Edges et DPMap_Nodes. Le premier paramètre de template, appelé
T, indique le type de données à appliquer sur le réseau. Le deuxième paramètre, appelé
node_access va donner des indications sur la participation de l’instance au calcul de
N(x).
template struct DPMap_Edges
template struct DPMap_Nodes
Figure 5.5 – Définition des objets DPMap_Edges et DPMap_Nodes.
Les deux paramètres T et node_access sont liés dans leur spécialisation. Deux cas
de spécialisation se présentent pour le paramètre T, et suivant ce cas la spécialisation
de node_access sera différente. Le paramètre T représente le type de données qui va
être appliqué au réseau. Ce peut être (1) soit un type de base du C++, comme int,
float, double etc., (2) soit un pointeur d’un type de base, autrement dit un tableau à
une dimension, comme int∗, float∗, double∗ etc.
1. Dans le premier cas, cela signifie que la donnée associée à chaque nœud ou chaque
arête du réseau ne contiendra qu’une unique valeur. Dans ce cas node_access pourra112 Chapitre 5. SkelGIS pour des simulations sur réseaux
prendre seulement deux valeurs, 0 ou 1. Si node_access = 0, alors cela signifie que
la quantité instanciée n’est pas concernée par les calculs du type N(x), et que cette
quantité est donc uniquement utilisée localement. Dans ce cas les échanges MPI
n’auront pas lieu sur cette quantité ce qui améliorera les performances. À l’inverse,
si node_access = 1, la quantité sera utilisée dans les calculs du type N(x) et les
échanges MPI seront effectués.
2. Dans le cas où T est un type pointeur, ce qui signifie que chaque nœud ou chaque
arête du réseau est associé à un tableau de valeurs, nous aurons, node_access ∈
J0, nK où n est le nombre d’éléments dans le tableau. Comme dans le cas précédent
si node_access = 0 alors la quantité à simuler n’interviendra pas dans les calculs
du type N(x) et les échanges MPI n’auront pas lieu. Si node_access > 0 alors la
valeur de node_access indique l’ordre du schéma numérique qui sera appliqué dans
les nœuds ou dans les arêtes, et indique donc l’échange nécessaire pour effectuer le
calcul. Notons que si node_access = 1, il s’agit d’un cas plus simple à gérer, une
spécialisation de ce cas est donc implémentée.
Les cinq spécialisations de templates nécessaires à l’objet DPMap_Edges, pour gérer ces
cas, sont présentées dans la figure 5.6.
template struct DPMap_Edges
template struct DPMap_Edges
template struct DPMap_Edges
template struct DPMap_Edges
template struct DPMap_Edges
template struct DPMap_Edges
Figure 5.6 – Spécialisations partielles de template pour l’objet DPMap_Edges
Les notions complexes de voisinage présentées dans la section précédente sont donc
entièrement gérées grâce à deux paramètres de template spécialisés. L’utilisateur n’a
qu’à se soucier du type d’éléments dans les nœuds et les arêtes et de l’ordre du schéma
numérique 1D appliqué, pour que l’ensemble soit optimisé en terme de communications
MPI.
5.3 Structure de données distribuée pour les réseaux
Dans la section précédente, le DDS DDAG pour les simulations sur les réseaux a été
présenté. Nous détaillons dans cette partie l’implémentation de cette structure de données
distribuée [44]. Comme toute DDS de la méthode SIPSim, cet objet est en grande
partie responsable de l’efficacité de la solution. Son implémentation dérive du format
Compressed Sparse Row (CSR) que nous allons tout d’abord décrire. L’adaptation et
la parallélisation du format CSR seront ensuite présentées pour enfin expliquer comment
s’articule l’implémentation générale de SkelGIS pour les réseaux autour de ce DDS.
Notons qu’une version parallèle du format CSR a déjà été proposée, et fait partie de5.3. Structure de données distribuée pour les réseaux 113
la bibliothèque PBGL [51, 62]. Toutefois, cette implémentation n’est pas spécifiquement
développée pour les simulations scientifiques basées sur des maillages. Notre implémentation
propose un certain nombre d’optimisations propres aux réseaux et aux simulations,
que nous allons décrire dans cette section.
5.3.1 Le format Compressed Sparse Row
La variation à trois tableaux du format Compressed Sparse Row (CSR) permet de
stocker des matrices creuses de façon relativement légère puisqu’il permet de ne stocker
que les éléments qui ne sont pas des zéros, aussi appelés des éléments non-nuls dans le
reste de ce travail. Ce format est donc constitué de trois tableaux dont voici la description :
— values contient les valeurs des éléments non-nuls qui sont stockés ligne après
ligne.
— columns est de même taille que le tableau précédent. L’élément i du tableau
columns contient l’index de colonne associé à l’élément i du tableau values.
— rowIndex est le dernier tableau du format dans lequel l’élément i contient l’index,
dans le tableau values, du premier élément non-nul de la ligne i de la matrice.
Notons qu’un premier élément factice, égal à zéro, est ajouté au début du tableau
rowIndex de telle sorte que la ligne i contient rowIndex[i+1]−rowIndex[i] éléments nonnuls.
Pour pouvoir accéder à un élément non-nul, avec le format CSR, en connaissant
ses index de ligne et de colonne (i, j), il faut trouver la valeur j entre les éléments
columns[rowIndex[i]] et columns[rowIndex[i + 1] − 1]. L’index k auquel est trouvée
la valeur j représente alors l’index dans le tableau values où se trouve l’élément nonnul
recherché. Pour cette raison, le format CSR est peu efficace pour manipuler, de
façon répétée, des accès aux éléments d’une matrice creuse avec les index de lignes et
de colonnes. Cependant, nous allons montrer que ce format peut être très efficace pour
stocker la connectivité d’un graphe.
Un graphe non-orienté est défini par G = (V, E) où V est un ensemble fini de nœuds
et E ⊆ V × V est un ensemble fini d’arêtes. La matrice Sp(G) associée au graphe G
représente la matrice d’adjacence du graphe G, comme illustré dans la figure 5.7. Dans
une matrice d’adjacence, chaque élément non-nul de la matrice représente une arête
e ∈ E du graphe G, et les index de ligne et de colonne représentent les deux nœuds aux
extrémités de l’arête. Notons donc que pour un graphe non-orienté, la matrice Sp(G) est
symétrique.
Dans un graphe G = (V, E), vi et vj ∈ V sont appelés des nœuds voisins si (vi
, vj ) ∈ E.
En d’autres termes, deux nœuds sont voisins si deux éléments non-nuls existent dans la
matrice Sp(G) aux emplacements (vi
, vj ) et (vj , vi). Pour tout v ∈ V, N(v) est l’ensemble
des nœuds voisins du nœud v. Le degré d’un nœud v ∈ V , noté deg(v), est le nombre
d’arêtes incidentes de v, ce qui signifie que deg(v) = |N(v)|. Dans la ligne v de la matrice
Sp(G), N(v) représente les index des colonnes où des éléments non-nuls sont présents.
Définition 2 Dans un graphe non-orienté G = (V, E) où V = {v0, ..., vn−1}, le degré
cumulé d’un nœud vi ∈ V est noté cdeg(vi) et est défini par cdeg(vi) = Pi
j=0 deg(vj ).114 Chapitre 5. SkelGIS pour des simulations sur réseaux
0
1 2
3 4
5 6 7
1
1
10 0 0 0 0 01
1 1
1
1
1 1 1
1
1
1
0 0 0 0 0
0 0 0 0 0 0 0
0 0 0 0 0 0 0
0 0 0 0
0 0 0 0 0 0 0
0 0 0 0 0 0 0
0 0 0 0 0 0 0
0 1 2 3 4 5 6 7
0
1
2
3
4
5
6
7
Figure 5.7 – Graphe non orienté G et sa matrice d’adjacence Sp(G).
Dans la matrice Sp(G), cdeg(vi) représente le nombre d’éléments non-nuls de la ligne
vi additionné au nombre d’éléments non-nuls des lignes précédentes. Il est donc possible
de représenter G avec deux tableaux :
— Le premier, de taille n + 1 = |V | + 1, et appelé cdeg, est défini par cdeg[i + 1] =
cdeg(vi), ∀i ∈ J0, nJ, où cdeg[0] = cdeg(v−1)
def = 0.
— Le deuxième, appelé N est de taille cdeg[n] = cdeg(vn−1) et est défini pour tout
vi ∈ V par, N(vi) = {vN[j]
|j ∈ [cdeg[i], cdeg[i + 1][}.
Cette représentation, en utilisant deux tableaux pour stocker un graphe G, correspond
en fait au format CSR pour la matrice Sp(G). En effet, les tableaux cdeg et N de G
correspondent aux tableaux rowIndex et columns de Sp(G). La figure 5.7 nous donne un
graphe et sa matrice d’adjacence. Dans ce graphe le nœud 0 a deux nœuds voisins, 1 et
2, nous avons alors la deuxième valeur du tableau cdeg égale à 2, et les deux premières
valeurs de N égales à 1 et 2. Le nœud 1 a ensuite trois voisins, la troisième valeur de
cdeg est alors cdeg[2] = 2 + 3 = 5. En procédant ainsi pour chaque nœud du graphe,
nous obtenons, cdeg = [0, 2, 5, 6, 7, 11, 12, 13, 14] et N = [1, 2, 0, 3, 4, 0, 1, 1, 5, 6, 7, 4, 4, 4].
Grâce à cette représentation du graphe avec deux tableaux, il est possible, par exemple,
d’accéder très facilement au voisinage du nœud 4. En effet, cdeg[4] = 7 et cdeg[5]−1 = 10
indiquent le premier et le dernier index de N où se trouvent les voisins du nœud 4. Les
nœuds voisins du nœud 4 sont donc les nœuds 1, 5, 6 et 7. De façon plus générale,
supposons que les données associées à chaque nœud soient stockées dans un troisième
tableau X tel que |X| = |V |. Alors, pour accéder aux valeurs voisines d’un nœud vi
, il
suffit d’accéder aux éléments N[cdeg[i]] à N[cdeg[i + 1] − 1] dans X.
Le format CSR, initialement fait pour stocker des matrices creuses, est donc un format
très intéressant pour stocker la connectivité d’un graphe et pour retrouver en O(1) les
voisins d’un nœud du graphe.5.3. Structure de données distribuée pour les réseaux 115
5.3.2 Format pour les DAG distribués
Comme nous l’avons indiqué dans la section 5.1, l’implémentation actuelle de SkelGIS
n’a été développée que pour le sous-cas des réseaux pouvant être représentés par des DAG
(par exemple celui de la figure 5.8). Cette partie va étudier l’adaptation du format CSR,
décrit dans la partie précédente, pour les DAG. Nous allons décrire comment ce format
a été optimisé pour le cas des simulations scientifiques, et comment il a été parallélisé.
Un graphe orienté G = (V, E) est un graphe pour lequel chaque arête e = (v1, v2) ∈ E
est dirigée de v1 vers v2, et où v1 et v2 sont respectivement appelés le nœud source et
le nœud destination de l’arête e. Un graphe orienté acyclique (DAG) est un graphe
G = (V, E) orienté tel que pour tout v ∈ V , il n’y a pas de chemin, en suivant les arêtes
successives, de v vers lui même.
Dans les simulations scientifiques sur les DAG, pour être calculé, un nœud peut
avoir besoin de ses arêtes entrantes et de ses arêtes sortantes. De son côté, pour être
calculée, une arête a uniquement besoin de son nœud source et de son nœud destination
(figure 5.3). Dans un DAG G = (V, E), pour un nœud v ∈ V et une arête e ∈ E, S(e)
est le nœud source de e et D(e) est le nœud destination de e. N
+
V
(v) décrit l’ensemble
des nœuds sortants de v ∈ V et est défini par N
+
V
(v) = {v
0
|(v, v0
) ∈ E}. N
+
E
(v) est
l’ensemble des arêtes sortantes de v ∈ V et est défini par N
+
E
(v) = {e ∈ E|S(e) = v}. De
façon symétrique, N
−
V
(v) et N
−
E
(v) sont définis comme les ensembles de nœuds et arêtes
entrantes de v ∈ V . Un nœud racine v ∈ V d’un DAG G vérifie que |N
−
E
(v)| = 0. À
l’inverse, un nœud feuille v ∈ V vérifie que |N
+
E
(v)| = 0.
La définition 2 doit alors être adaptée au cas des DAG pour les éléments entrants dans
un nœud et ceux sortants d’un nœud. Dans un DAG G = (V, E), où V = {v0, ..., vn−1},
pour un nœud vi ∈ V , cdeg+(vi) = Pi
j=0 |N
+
E
(vj )| définit le degré cumulé sortant pour
le nœud vi
, cdeg−(vi) = Pi
j=0 |N
−
E
(vj )| définit le degré cumulé entrant pour le nœud vi
.
Notons ici que les degrés cumulés ont la particularité d’être les mêmes pour les arêtes et
les nœuds d’un DAG. En effet, pour un nœud v ∈ V , le nombre de nœuds entrants est
égal au nombre d’arêtes entrantes. De même le nombre de nœuds sortants est égal au
nombre d’arêtes sortantes : ∀vj ∈ V , |N
+
E
(vj )| = |N
+
V
(vj )| et |N
−
E
(vj )| = |N
−
V
(vj )|.
Comme dans la partie précédente, les tableaux cdeg+ et cdeg−, de taille |V |+1 = n+1,
sont définis par cdeg+[i + 1] = cdeg+(vi) et cdeg−[i + 1] = cdeg−(vi), où cdeg+[0] =
cdeg−[0] = 0. Enfin il est également possible de définir les tableaux N
+
E
et N
−
E
de taille
cdeg+[n] et cdeg−[n] qui représentent les index de voisinage associés aux degrés cumulés.
Enfin, deux tableaux S et D de taille |E| représentent l’ensemble des nœuds sources et
destinations pour chaque arête de telle sorte que S[i] = S(ei) et D[i] = D(ei), ∀ei ∈ E.
La figure 5.8 représente un DAG simple que nous allons prendre comme exemple
pour cette nouvelle structure de données. Le nœud 0 n’a pas de voisin entrant mais a
deux voisins sortants. Par conséquent, la deuxième valeur de cdeg− est égale à 0, et la
deuxième valeur de cdeg+ est égale à 2. Les index des voisinages associés sont stockés
dans N
+
E
et N
−
E
. Nous obtenons les tableaux suivants :
cdeg+ = [0, 2, 4, 4, 4, 7, 7, 7, 7], cdeg− = [0, 0, 1, 2, 3, 4, 5, 6, 7]
N
+
E = [0, 1, 2, 3, 4, 5, 6], N −
E = [0, 1, 2, 3, 4, 5, 6]116 Chapitre 5. SkelGIS pour des simulations sur réseaux
S = [0, 0, 1, 1, 4, 4, 4], D = [1, 2, 3, 4, 5, 6, 7]
0
1 2
3 4
5 6 7
0 1
2 3
4 5 6
Figure 5.8 – Graphe orienté acyclique correspondant au graphe 5.7.
La structure de données ainsi obtenue est adaptée aux DAG. En revanche, cette
structure de données ne comporte aucune optimisation spécifique pour les simulations
scientifiques et n’est pas non plus encore une structure de données distribuée. Nous
allons décrire ces deux points dans le reste de cette partie. Notons que cette section
ne s’intéresse pas au partitionnement d’un graphe orienté acyclique, que nous verrons
dans la section 5.5, mais uniquement à la structure de données permettant de stocker les
informations locales à chaque processeur de façon efficace.
Une fois le partitionnement de graphe effectué, chaque processeur reçoit donc une
partie du graphe de départ avec ses index globaux. Étant donné que la structure de
données, vue précédemment, repose sur une indexation contiguë commençant à 0 pour les
tableaux, cela implique tout d’abord qu’une ré-indexation locale va être nécessaire pour
la version distribuée de la structure. La figure 5.9 montre un graphe global partitionné
pour quatre processeurs. Nous nous intéressons à la partie bleue de ce graphe global, qui
va être distribuée au processeur 1. Ce sous-graphe G1 = (V1, E1) possède |V1| = 8 nœuds
et |E1| = 7 arêtes. La partie bleue de ce DAG n’est toutefois pas la seule partie à laquelle
devra s’intéresser le processeur 1. En effet, pour gérer comme il se doit les voisinages des
nœuds et des arêtes, des informations supplémentaires, provenant d’autres processeurs,
seront nécessaires. La figure 5.10(a) montre les nœuds et arêtes dont le processeur 1 aura
besoin pour effectuer convenablement ses calculs. On y retrouve la partie bleue du graphe
global mais également des nœuds et arêtes additionnels en pointillés. Ces nœuds et ces
arêtes sont des données qui ne sont pas locales au processeur 1 mais dont le processeur
1 aura besoin pour effectuer ses calculs. Ces données devront donc être insérées dans
la structure pour permettre les calculs et être accessibles efficacement pour assurer de
bonnes performances.
Le premier point auquel s’intéresser pour distribuer la structure de données est donc5.3. Structure de données distribuée pour les réseaux 117
0
2
0
3
1
6
5
7
6 7
1
2
4
3
5
4
8
8
9
9
10
10
11
11
12
12
13
13
14
14
15
15
16
16 17
17
18
18
19
21
22
22
23
23
24
24
26 27
25
28
Figure 5.9 – DAG global partitionné pour quatre processeurs. Le processeur 1 récupère la partie
bleue de ce partitionnement.
de ré-indexer le graphe local de chaque processeur afin de pouvoir utiliser les tableaux
présentés précédemment. La ré-indexation des arêtes est la plus simple. Elle peut être
quelconque. Dans la figure 5.10 la ré-indexation consiste à numéroter les arêtes de haut en
bas et de gauche à droite. La ré-indexation des nœuds locaux, quant à elle, a été pensée
afin d’optimiser l’utilisation des lignes de cache et de limiter les défauts de cache. Cette
optimisation est liée au fait que l’on cherche à résoudre des simulations scientifiques et à
leurs caractéristiques particulières. L’optimisation de la ré-indexation des nœuds consiste
à ordonner les nœuds par classe de façon à pouvoir se déplacer dans la classe de nœuds
de façon contiguë en mémoire. Quatre classes de nœuds ont été identifiées. Tout d’abord,
il a été présenté dans la section 5.2 l’intérêt d’un recouvrement des communications par118 Chapitre 5. SkelGIS pour des simulations sur réseaux
0
2
7
3
7
8
10 11
15 16 17 18
6
0 1
8
2
9
3 9 10
12
4
13
5
14
6
11 12 13 14 15
(a) Partie du graphe global qui intéresse le processeur
1 pour gérer ses données locales et les
voisinages nécessaires.
8
2
7
9
3
8
10 11
12 13 14 15
0
0 1
7
2
1
3 9 10
6
4
4
5
5
6
11 12 13 14 15
(b) Ré-indexation du sous-graphe géré par le
processeur 1.
Figure 5.10 – Sous-graphe géré par le processeur 1 avant et après ré-indexation.
les calculs, afin de limiter le déséquilibrage de charge d’un partitionnement du domaine
pour les différents processeurs. Cette technique connue du parallélisme repose sur le
fait que les communications, nécessaires pour calculer les éléments au bord du domaine
local, sont recouvertes par les calculs purement locaux qui peuvent d’ores et déjà être
effectués. Pour cette raison les deux premières classes de nœuds de la ré-indexation sont
les nœuds locaux-internes du domaine et les nœuds locaux-externes du domaine. Les
premiers ne nécessitent pas de communications avec les autres processeurs pour être
calculés, à l’inverse des seconds. Il a également été présenté dans les sections 2.2 et
5.1 que les simulations scientifiques, pour être plus réalistes sur le phénomène simulé,
opèrent des comportements particuliers pour les éléments de la bordure physique du
domaine global étudié. De plus, dans un réseau de type DAG, les nœuds de la bordure
physique ne sont autres que les feuilles et les racines du DAG. Les deux autres classes de
nœuds concernées par la ré-indexation sont donc les feuilles, puis les racines. Le passage
de la figure 5.10(a) à la figure 5.10(b) illustre cette ré-indexation des nœuds locaux (en
traits continus) en quatre classes, et la figure 5.11 résume ce système de ré-indexation.
Cette ré-indexation des éléments locaux à un processeur possède deux avantages en
terme de performances. Tout d’abord, elle favorise la bonne utilisation des lignes de mé-
moire cache. En effet, dans une simulation scientifique sur les réseaux, toutes les racines
vont être explorées afin de décrire leur comportement, de même pour les feuilles. Ces5.3. Structure de données distribuée pour les réseaux 119
Noeuds
locaux-internes
Noeuds
locaux-externes
RacinesFeuilles Noeuds en pointillés
sur la Figure 5.12
Arêtes en pointillés
sur la Figure 5.12
Arêtes locales
Figure 5.11 – Parallélisation de la structure et ré-indexation.
explorations d’éléments se feront donc de façon à éviter les défauts de cache en mémoire
puisque la lecture entière d’une ligne de cache chargée sera favorisée avant qu’une autre
ne se charge. Pour ce qui est des nœuds locaux-internes et locaux-externes le même phé-
nomène se produit puisque lors d’un recouvrement des communications par les calculs les
nœuds locaux-internes seront tout d’abord explorés, puis par la suite les nœuds locauxexternes.
Le deuxième avantage de cette ré-indexation est le fait d’éviter des conditions
coûteuses dans le code. En effet, une solution naïve pour les bordures physiques serait
d’explorer tous les nœuds du DAG et, pour chacun, de tester si il s’agit d’une racine,
d’une feuille, ou d’un nœud interne. Cela signifierait qu’à chaque itération de temps
et pour chaque élément du domaine (potentiellement très grand), deux tests seraient
effectués. Ces conditions seraient extrêmement coûteuses en performances. Dans cette
solution les racines et les feuilles sont regroupées et les itérateurs (expliqués précédemment)
seront utilisés pour naviguer dans l’une ou l’autre des classes. De même, pour le
recouvrement des communications par les calculs, une solution naïve serait de tester pour
chaque élément si il s’agit d’un nœud local-interne ou local-externe ce qui nuirait aux
performances.
Étant donnée la ré-indexation locale du processeur 1, présentée dans la figure 5.10(b)
et sans prendre en compte les nœuds et arêtes en pointillés, les six tableaux de la structure
de données locale au processeur 1 sont :
cdeg+ = [0, 2, 5, 7, 7, 7, 7, 7, 7], cdeg− = [0, 1, 2, 2, 3, 4, 5, 6, 7]
N
+
E = [2, 3, 4, 5, 6, 0, 1], N −
E = [0, 3, 1, 5, 6, 4, 2]
S = [2, 2, 0, 0, 1, 1, 1], D = [0, 3, 7, 1, 6, 4, 5]
La ré-indexation locale permet donc d’optimiser les performances de la structure de
données et permet également de pouvoir exprimer les huit tableaux locaux à chaque
processeur. Toutefois il est encore nécessaire de paralléliser cette structure de données en
insérant les nœuds et arêtes en pointillés. La première étape de cette parallélisation est
de continuer la ré-indexation commencée avec les éléments locaux à chaque processeur,
sur les éléments en pointillés. Les index des éléments en pointillés doivent être supérieurs
aux index des éléments locaux. Ainsi, étant donnée une arête ei en pointillés, et étant
donnée la ré-indexation des arêtes locales E = {e0, e1, ..., em−1} telle que |E| = m, alors120 Chapitre 5. SkelGIS pour des simulations sur réseaux
la ré-indexation de ei est notée ej où j ≥ m. De même, étant donné un nœud vi en
pointillés, et étant donnée la ré-indexation des nœuds locaux V = {v0, v1, ..., vn−1} tel
que |V | = n, alors la ré-indexation de vi est notée vj où j ≥ n. La fin de cette ré-
indexation est illustrée de la figure 5.10(a) à la figure 5.10(b) et dans la figure 5.11. En
ré-indexant de cette façon les éléments en pointillés, les optimisations mises en place,
pour l’utilisation des lignes de cache et les conditions, sont conservées.
Pour comprendre l’insertion des éléments pointillés dans la structure de données,
continuons à utiliser l’exemple du processeur 1. Dans la figure 5.10(b), il peut être noté
que les nœuds 2 et 3 doivent recevoir chacun une arête entrante du processeur 0. Pour
cette raison, comme illustré dans la figure 5.12, le tableau cdeg− est modifié aux index 3
et 4 en ajoutant 1 à chacun. Comme cdeg− représente les degrés cumulés, l’addition de
ces éléments doit être reportée sur tous les éléments suivants du tableau. Pour continuer
cet exemple, le nœud 2 reçoit en entrée l’arête 7 du processeur 0, et le nœud 3 reçoit
en entrée l’arête 8 du processeur 0. En d’autres termes, les arêtes 7 et 8 font partie du
voisinage entrant des nœuds 2 et 3. Pour cette raison les index 7 et 8 doivent être insérés
dans le tableau N
−
E
comme illustré dans la figure 5.12. En procédant comme suit, la
structure de données distribuée obtenue pour le processeur 1 est :
cdeg+ = [0, 2, 5, 7, 9, 11, 14, 14, 14], cdeg− = [0, 1, 2, 3, 5, 6, 7, 8, 9]
N
+
E = [2, 3, 4, 5, 6, 0, 1, 9, 10, 11, 12, 13, 14, 15], N −
E = [0, 3, 7, 1, 8, 5, 6, 4, 2]
cdeg - = 0 1 2 2 3 4 5 6 7 cdeg- = 0 1 2 3 5 6 7 8 9
+1
+1
N -
E = 0 3 1 5 6 4 2 NE
= 0 3 7 1 8 5 6 4 2
Figure 5.12 – Système de ré-indexation.
En procédant de cette façon pour paralléliser la structure de données, la caracté-
ristique du format CSR qui permet d’accéder au voisinage d’un nœud d’un graphe en
O(1), est conservée pour tous les éléments de la structure, qu’ils proviennent d’autres
processeurs ou pas. De plus, l’optimisation de cache mise en place est conservée.
Il reste un dernier point à aborder afin que la structure de données soit entièrement
parallélisée. En effet, le travail décrit jusqu’à présent permet d’exprimer, pour chaque
processeur, la connectivité de son DAG local y compris avec les éléments qui vont être
communiqués par d’autres processeurs. Afin de pouvoir effectuer les communications
nécessaires, une sorte de cartographie des communications est nécessaire. Grâce à elle,
chaque processeur saura à qui envoyer et de qui recevoir des nœuds et des arêtes. Cette
cartographie va reposer de nouveau sur les degrés cumulés. Le tableau cdegtor, de taille
p + 1, où p est le nombre de processeurs, indique le nombre d’éléments à recevoir de5.3. Structure de données distribuée pour les réseaux 121
chacun des autres processeurs de façon cumulée. À l’inverse, le tableau cdegtos, de taille
p + 1 indique le nombre d’éléments à envoyer à chacun des autres processeurs, de façon
cumulée là encore. Les tableaux complémentaires Ntor
E
, Ntos
E
, Ntor
V
et Ntos
V
indiquent les
index des éléments à recevoir et à envoyer en suivant les tableaux de degrés cumulatifs,
comme cela est le cas pour les tableaux déjà détaillés.
Étant donné un DAG G = (V, E) partitionné en p sous-graphes Gi = (Vi
, Ei), i ∈
[0, p[, tel que V =
S
i
Vi et E =
S
i Ei
, alors la table 5.1 indique la taille des tableaux
locaux à chaque processeur mis en place dans le DDS DDAG présenté.
Tableau Taille
cdeg+ |Vi
|
cdeg− |Vi
|
S |Ei
|
D |Ei
|
N
+
E + N
−
E
P|Vi|
j=0 deg(vj )
cdegtor p
cdegtos p
Ntor
E
cdegtor[p]
Ntor
V
cdegtor[p]
Ntos
E
cdegtos[p]
Ntos
V
cdegtos[p]
Table 5.1 – Taille des tableaux du DDS DDAG.
La taille totale représentée par cette structure de donnée, pour chaque processeur,
est donc
T aille = L + P + Conn + Comm, (5.3)
avec
L = 2 × |Vi
| + 2 × |Ei
|,
P = 2 × p,
Conn =
X
|Vi|
j=0
deg(vj ),
Comm = 2 × cdegtor[p] + 2 × cdegtos[p].
La taille du DDS DDAG pour chaque processeur dépend donc du partitionnement
du réseau pour les opérandes L et Comm, mais également de la connectivité du réseau
pour l’opérande Conn, et enfin du nombre de processeurs utilisés pour l’opérande P de
l’équation (5.3). La structure de données présentée ici peut fonctionner quel que soit
le partitionnement choisi au préalable. Toutefois, nous pouvons très bien noter que le
partitionnement va impacter la taille de la structure de donnée locale à chaque processeur.
Un bon partitionnement est donc aussi important que l’implémentation de la structure de122 Chapitre 5. SkelGIS pour des simulations sur réseaux
données afin d’obtenir de bonnes performances pour la solution de parallélisme implicite.
Le partitionnement implémenté dans SkelGIS, ainsi que deux études de partitionnements
supplémentaires seront détaillés dans la section 5.5.
La suite de cette section permet d’expliquer comment est implémenté chaque composant
de la méthode SIPSim dans SkelGIS pour les réseaux, en fonction de l’implémentation
de la DDS DDAG qui vient d’être détaillée.
5.3.3 Implémentation de SkelGIS pour les réseaux
Nous venons de présenter en détails l’implémentation du DDS DDAG de SkelGIS.
Comme cela a été décrit dans le chapitre 3, le DDS est l’objet principal de la solution et
tout le reste de l’implémentation repose sur lui. Dans cette section, nous allons expliquer
comment chaque composant de la méthode SIPSim utilise l’objet DDAG et sa structure
de données.
Dans la méthode SIPSim, un DPMap permet d’appliquer des données sur un DDS
dans un objet léger. Comme nous l’avons vu, dans un réseau, deux DPMap sont nécessaires,
DPMap_Nodes et DPMap_Edges. L’objet DPMap peut alors être comparé au
tableau values du format CSR. Les objets DPMap_Nodes et DPMap_Edges stockent
leur données dans un simple tableau à une dimension, ce qui permet d’obtenir des objets
très légers. Ce tableau à une dimension, dont les indices vont suivre la ré-indexation
de l’objet DDAG, vont donc représenter les tableaux à une dimension de la figure 5.11.
Pour reprendre l’exemple de la figure 5.10, pour le processeur 1, l’élément 4 du tableau
du DPMap_Nodes correspondra donc à une valeur sur le nœud 13 du DAG général. Un
DPMap est donc lié à une instance de DDAG à sa création et se servira de cette instance
de façon systématique dans son implémentation et pour ses interfaces. L’utilisateur va
instancier un certain nombre de DPMap, autant qu’il a besoin de quantités sur le réseau
pour sa simulation.
C’est à partir des instances de DPMap que l’utilisateur va accéder aux interfaces
de programmation afin de coder sa simulation. La première d’entre elles est l’interface
d’itération. Les itérateurs présents dans SkelGIS pour les réseaux ont déjà été présentés.
L’ensemble de ces itérateurs va pouvoir être initialisé par le biais de deux méthodes des
objets DPMap. L’une permettra de se placer au commencement de la classe des éléments
et l’autre permettra de se placer à la fin de la classe des éléments. Chaque objet d’itération
est ensuite un objet indépendant qui va se charger d’incrémenter le positionnement grâce
à l’opérateur ++ et de le comparer grâce aux opérateurs ≤, ≥, et ==. L’opérateur ++
ne peut, bien entendu, être efficace que grâce à l’indexation contiguë des éléments d’une
même classe qui a été mise en œuvre dans l’objet DDAG.
Enfin, le dernier composant de la méthode SIPSim implémenté dans SkelGIS est lui
aussi lié à l’implémentation du DDAG. Il s’agit de l’applicateur qui a été décrit dans
la section 5.2.3. Un applicateur permet d’appliquer une opération séquentielle, codée
par l’utilisateur grâce aux instances de DPMap et aux interfaces de programmation, sur
un ensemble de quantités à simuler. Un applicateur permet de cacher à l’utilisateur les
échanges MPI qui se produisent avant une opération. L’applicateur pour les réseaux cache
lui aussi les échanges nécessaires à chaque instance de DPMap, en appelant les méthodes5.4. Simulation 1D d’écoulement du sang dans les artères 123
de communication des objets DPMap. Ces méthodes, bien entendu, utilisent directement
les tableaux cdegtor
, cdegtos
, Ntor
E
, Ntos
E
, Ntor
V
et Ntos
V
décrits dans la section 5.3.2.
L’implémentation de la méthode SIPSim mise en place dans SkelGIS, pour le cas des
réseaux, est une solution aboutie et optimisée qui cache à l’utilisateur une très grande
complexité de code. Tous les composants de la méthode SIPSim dépendent de l’implé-
mentation et de l’efficacité de l’objet DDAG et tous ces composants sont liés les uns aux
autres pour fournir une solution adaptée à l’utilisateur, et efficace.
5.4 Simulation 1D d’écoulement du sang dans les artères
Dans cette section est détaillé un cas d’application réel de SkelGIS pour les réseaux.
La simulation présentée étudie l’écoulement du sang dans un réseau artériel. La parallélisation
de cette simulation a été effectuée en collaboration avec Pierre-Yves Lagrée,
Jose-Maria Fullana et Xiaofei Wang [42]. Dans cette section nous allons tout d’abord
expliquer brièvement le modèle mathématique utilisé puis les méthodes numériques appliquées
afin de coder la simulation. Nous détaillerons ensuite la parallélisation de la
simulation en utilisant SkelGIS et présenterons des résultats expérimentaux.
5.4.1 Simulation 1D d’écoulement du sang dans le réseau artériel
Les détails du modèle mathématique et des méthodes numériques utilisées peuvent
être trouvés dans les travaux de Wang et Al [126]. Dans cette section, les informations
utilisées dans cette thèse seront présentées, mais nous ne rentrerons que peu dans les
détails mathématiques de la simulation.
5.4.1.1 Modèle mathématique
Le système d’équations de Navier-Stokes [73] a déjà été décrit dans la section 4.3.1,
il permet d’étudier l’évolution temporelle d’un fluide dans un domaine Ω de l’espace R
3
.
Ces équations peuvent donc également modéliser les écoulements sanguins dans un ré-
seau artériel en trois dimensions. Toutefois, cette simulation est connue pour être très
coûteuse en temps d’exécution et en mémoire utilisée, ce qui la rend généralement uniquement
utilisable de façon locale, sur une unique artère ou sur une confluence de plusieurs
artères, par exemple. Le travail de Wang et Al [126] étudie une simulation sur une unique
dimension pour plusieurs raisons. Tout d’abord, cette simulation étant plus légère elle
peut être exécutée sur un réseau artériel complet. Il est, de plus, possible d’envisager une
simulation en temps réel pour la médecine, en couplant la légèreté de cette simulation
au parallélisme. Enfin, le système 1D capture de façon intéressante le comportement des
ondes sanguines provoquées par les pulsations cardiaques, ce qui donne des informations,
elles aussi intéressantes, sur le système cardio-vasculaire. La simulation présentée traite
le système d’équations de Navier-Stokes suivant une dimension, en intégrant ces équations
sur la section de l’artère, autrement dit en moyennant une solution dans les deux124 Chapitre 5. SkelGIS pour des simulations sur réseaux
dimensions représentant la section du tube artériel. La simulation est alors représentée
par deux EDP qui font le lien entre trois variables : la section de l’artère noté A, le
débit volumétrique Q et la pression artérielle P toutes trois fonctions de x, la dimension
spatiale, et t la dimension temporelle. Ces deux équations sont les suivantes :
( ∂A
∂t +
∂Q
∂x = 0
∂Q
∂t +
∂
∂x (
Q2
A
) + A
ρ
∂P
∂x = −Cf
Q
A
(5.4)
où x représente l’axe longitudinal de l’artère, t représente le temps, et −Cf
Q
A
représente
le coefficient de frottement (avec Cf le coefficient de frottement de la paroi artérielle) et
où ρ représente la densité du sang.
5.4.1.2 Résolution numérique et programmation
La simulation proposée dans les travaux de Wang et Al [126] établie une relation
entre A et P, telle que P = Pext + β(
√
A −
√
A0) + νs
∂A
∂t , où β est le coefficient de raideur
d’une artère, A0 la section de l’artère non déformée, et Pext la pression extérieure des
vaisseaux, et νs le coefficient de viscosité du sang.
Ainsi, si nous posons
U =
A
Q
, Fc =
Q
Q2
A +
β
3ρ
A3/2
!
, Fv =
0
−Cv
∂Q
∂x
, F = Fc + Fv
et
S =
0
−Cf
Q
A +
A
ρ
(
∂(β
√
A0)
∂x −
2
3
√
A
∂β
∂x!
, Cv =
Aνs
ρ
,
alors le système d’équations (5.4) s’écrit sous la forme :
∂U
∂t +
∂F
∂x = S. (5.5)
Dans cette équation il est considéré que Pext est constant suivant l’axe x. Dans l’équation
(5.5), U représente la variable conservative de la loi de conservation présentée à
l’équation (2.9) de la section 2.2.4.2, F le flux et S est un terme supplémentaire appelé
le terme source. Le problème s’apparente donc à la loi de conservation de la masse et de
la quantité de mouvement à une dimension.
Les méthodes des différences finies et des volumes finis ont été utilisées dans les
travaux de Wang et Al pour obtenir différents schémas numériques de la simulation et
comparer les résultats obtenus. La méthode des volumes finis correspond alors à la description
qui en a été faite dans la section 2.2.4.2 puisque la même forme d’équation de
conservation à une dimension est traitée (hormis le terme source). Un schéma de résolution
numérique explicite est donc obtenu pour la simulation au sein de chaque artère
(équation (2.14)). Notons que dans cette simulation la variable U est traitée à l’ordre
2. Afin de résoudre les problèmes d’oscillations provoqués par les méthodes utilisées,5.4. Simulation 1D d’écoulement du sang dans les artères 125
la reconstruction MUSCL (Monotonic Upwind Scheme for Conservative Law) est utilisée
[126] et engendre l’utilisation de variables supplémentaires et de cinq calculs stencils
supplémentaires. Comme dans toute résolution d’EDP, des conditions initiales et des
conditions aux limites du domaine sont spécifiées pour permettre de réduire le spectre
des solutions. Notons que l’EDP, à résoudre ici, simule l’écoulement du sang dans une
unique artère et non sur le réseau. Le calcul des conditions aux limites pour chaque artère
est donc nécessaire au calcul de l’EDP. La particularité des conditions limites de cette
simulation vient du fait qu’il s’agit d’une simulation sur un réseau. Pour cette raison les
conditions limites d’une artère sont liées aux conditions limites des artères auxquelles elle
est connectée. Par conséquent, les conditions limites, dans cette simulation ne sont autre
que les nœuds du réseau. Il s’agit donc d’un cas simple de simulation sur un réseau, où les
nœuds ne représentent pas une simulation à part entière, mais simplement les conditions
aux limites de chaque arête arrivant à une conjonction.
Afin de comprendre le comportement d’un nœud, prenons l’exemple d’un nœud ayant
une artère mère et deux artères filles. Étant donné qu’en chaque artère les quantités A
et Q sont simulées, on a alors en ce nœud l’arrivée de six conditions aux limites des
artères : An+1
p
et Qn+1
p pour les conditions limites de l’artère mère, et A
n+1
d1
, A
n+1
d2
, Q
n+1
d1
et Q
n+1
d2
pour les conditions limites des deux artères filles. Un nœud respecte alors la loi
de conservation des flux suivante
Q
n+1
p − Q
n+1
d1 − Q
n+1
d2 = 0 (5.6)
et la conservation de la quantité de mouvement suivante
1
2
ρ
Qn+1
p
A
n+1
p
!2
+ P
n+1
p −
1
2
ρ
Q
n+1
di
A
n+1
di
!2
− P
n+1
di
= 0, ∀i ∈ {1, 2} (5.7)
L’algorithme 9 reprend l’algorithme 1, de la section 2.2.5, avec les spécificités de la
simulation décrite ici. Il représente donc l’algorithme séquentiel de cette simulation.
5.4.2 Parallélisation avec SkelGIS
La simulation d’écoulement du sang, qui vient d’être décrite, est donc un cas particulier
de simulation sur les réseaux. En effet, dans cette simulation les nœuds servent à
exprimer le lien entre les conditions limites des artères du réseau. C’est l’une des façons
d’utiliser un réseau, parmi d’autres. Toutefois, cette simulation se prête parfaitement à
un premier cas d’application du prototype actuel de SkelGIS. Précisons, tout d’abord
que dans cette simulation les types d’éléments T1 et T2 sont respectivement associés
aux arêtes et aux nœuds du réseau. La simulation est alors organisée en quatre phases,
comme cela a été décrit dans la section 5.1 :
1. communication des arêtes calculées à t − 1,
2. calcul des nœuds à t,
3. communication des nœuds calculés à t,126 Chapitre 5. SkelGIS pour des simulations sur réseaux
Algorithme 9 : Algorithme séquentiel de la simulation artérielle.
Création ou lecture du réseau
Création ou lecture du domaine discrétisé pour chaque artère
Création des variables appliquées sur le réseau (artères et nœuds)
Initialisation des variables
Définition du pas de temps : t
Définition du temps maximal : tmax
while t < tmax do
calcul des conditions limites du réseau (racines et feuilles) pour t
for chaque nœud du réseau do
calcul des schémas (5.4) et (5.5)
end
for chaque artère du réseau do
for chaque élément du maillage x do
calcul du schéma numérique (5.3) pour t et x
end
end
end
4. calcul des arêtes à t.
La description de la simulation nous offre ensuite toutes les clés permettant de coder cette
simulation en utilisant SkelGIS. Tout d’abord cette simulation n’instancie qu’un unique
réseau qui représente le réseau artériel à étudier. Une unique instanciation de l’objet
DDAG est donc nécessaire. Il est ensuite possible d’identifier les variables principales de
la simulation, à savoir A et Q, qui représentent des données appliquées sur les arêtes
du réseau. Elles nécessitent donc deux instanciations de l’objet DPMap_Edges. Au sein
d’une arête, une discrétisation suivant une dimension est effectuée et un schéma numé-
rique d’ordre 2 est appliqué à chaque itération de temps. Pour cette raison, le paramètre
de template T est pour les deux variables double∗
, et le paramètre node_access est égal
à 2 comme illustré dans la figure 5.13. Afin d’effectuer les calculs de condition aux limites
DPMap_Edges A
DPMap_Edges Q
Figure 5.13 – Déclaration des variables A et Q
sur les nœuds du réseau, l’instanciation d’une donnée plaquée sur les nœuds est ensuite
nécessaire, même si les nœuds ne lisent et n’écrivent que des données sur les arêtes. La
figure 5.14 illustre cette instanciation qui est très simple. Aucune discrétisation n’est
effectuée au sein des nœuds du réseau (équations (5.6) et (5.7)). D’autres variables, qui
n’ont pas été détaillées sont nécessaires au codage de la simulation, notamment pour la
méthode de reconstruction MUSCL évoquée précédemment. Le principe reste cependant
le même pour toutes les variables de la simulation appliquées aux arêtes ou aux nœuds.5.4. Simulation 1D d’écoulement du sang dans les artères 127
DPMap_Nodes nd
Figure 5.14 – Déclaration d’une variable nd sur les nœuds du réseau
Enfin, outre les instanciations de variables, les paramètres qui caractérisent les arêtes
et les nœuds du réseau doivent être instanciés. Dans ce cas, ces données sont utilisées
localement et pour cette raison le node_access du DPMap correspondant est positionné
à 0. Une fois le réseau, les variables, et les paramètres de la simulation instanciés, les
itérations de temps peuvent commencer ainsi que la résolution des schémas numériques.
L’algorithme 10 illustre la fonction main codée par l’utilisateur. Cette fonction reste très
proche de la version séquentielle, à l’exception près qu’elle définit les objets SkelGIS qui
viennent d’être évoqués.
Algorithme 10 : Fonction main codée par l’utilisateur
Création ou lecture du réseau DDAG
Création des variables appliquées sur le réseau (artères et nœuds) :
DPM ap_Edges < double∗, 2 > A
DPM ap_Edges < double∗, 2 > Q
DPM ap_Nodes < double, 0 > nd
...
Initialisation des variables de paramètres
Définition du pas de temps : t
Définition du temps maximal : tmax
while t < tmax do
apply_listi({A,Q,etc.},{nd,etc.},bloodflow1,bloodflow2)
end
On peut observer que la différence entre cette fonction principale et sa version sé-
quentielle est d’appeler, dans la boucle d’itérations en temps, l’applicateur apply_listi.
Comme cela a déjà été expliqué dans la section 5.2, l’applicateur apply_listi permet d’appliquer
des schémas numériques implicites en quatre étapes. Cette simulation convient
donc à l’utilisation de cet applicateur. Cet appel est très important puisqu’il est en charge
de cacher à l’utilisateur les échanges nécessaires aux calculs dans les phases 1 et 3 de la
simulation. Les opérations bloodflow1 et bloodflow2, données en paramètres de l’applicateur,
sont les fonctions séquentielles utilisateur qui contiennent le code de calcul des
phases 2 et 4 décrites précédemment.
Les algorithmes 11 et 12 illustrent les opérations bloodflow1 et bloodflow2. Les
structures de ces opérations sont, là encore, très proches de la version séquentielle. La
seule contrainte imposée à l’utilisateur, tout comme dans la fonction main, est d’utiliser
les notions propres à SkelGIS pour manipuler les instances des objets DPMap_Edges
et DPMap_Nodes : les itérateurs ; les accesseurs ; et les fonctions de voisinages. La
première opération, décrite dans l’algorithme 11 représente donc le code de la phase
2 de la simulation. Ce code consiste, tout d’abord à calculer les conditions limites du128 Chapitre 5. SkelGIS pour des simulations sur réseaux
réseau, à savoir les racines et les feuilles. Pour cela, les itérateurs spécifiques à ces deux
classes d’éléments sont utilisés ainsi que l’opérateur [] et les fonctions de voisinage d’un
nœud. Par la suite, les conditions aux limites des artères sont calculées. Ces calculs se
produisent aux points de conjonction (nœuds), et sont effectués en fonction des résultats
obtenus à l’itération précédente sur les artères qui se rencontrent en ce nœud. Les autres
nœuds du réseau sont donc ensuite calculés dans l’opération en appliquant les schémas
numériques (5.6) et (5.7). La deuxième opération, décrite dans l’algorithme 12 repré-
Algorithme 11 : Opération bloodflow1 décrivant les calculs effectués à chaque
itération de temps sur les nœuds.
Data : {DPMap}
Result : Modification de {DPMap}
ItR := itérateur de début sur les racines
endItR := itérateur de fin sur les racines
while ItR≤endItR do
Application des conditions limites pour les racines avec : A[ItR], Q[ItR],
nd[ItR], A.getInEdges(ItR), Q.getOutEdges(ItR) ...
ItR++
end
ItL := itérateur de début sur les feuilles
endItL := itérateur de fin sur les feuilles
while ItL≤endItL do
Application des conditions limites pour les feuilles avec : A[ItL], Q[ItL],
nd[ItL], A.getInEdges(ItL), Q.getOutEdges(ItL) ...
ItL++
end
ItC= itérateur de début sur les nœuds
endItC := itérateur de fin sur les nœuds
while ItC≤endItC do
Application des schémas numériques des nœuds (5.4) et (5.5) avec : A[ItC],
Q[ItC], nd[ItC], A.getInEdges(ItC), Q.getOutEdges(ItC) ...
ItC++
end
sente, quant à elle, le code de la phase 4 de la simulation. Ce code consiste à appliquer
le schéma numérique issu de la méthode des volumes finis appliquée à l’équation (5.5).
Pour cela, les itérateurs spécifiques à ces deux classes d’éléments sont utilisés ainsi que
l’opérateur [] et les fonctions de voisinage d’une arête.
L’utilisation de SkelGIS pour coder cette simulation d’écoulement du sang dans les
artères répond donc aux attentes annoncées, et propose une solution très proche du sé-
quentiel, aussi bien en terme de structure de programme qu’en terme de programmation.
En effet, aucune difficulté technique n’est introduite par la solution et aucun code pa-5.4. Simulation 1D d’écoulement du sang dans les artères 129
Algorithme 12 : Opération bloodflow2 décrivant les calculs effectués à chaque
itération de temps sur les arêtes.
Data : {DPMap}
Result : Modification de {DPMap}
ItA= itérateur de début sur les artères
endItA := itérateur de fin sur les artères
while ItA≤endItA do
for chaque élément du maillage de l’artère x do
calcul du schéma numérique issu de l’équation (5.4) pour t et x avec :
A[ItA], Q[ItA], nd[ItA], A.getSrcNode(ItA), Q.getDstNode(ItA) ...
end
ItA++
end
rallèle n’a été produit par l’utilisateur. Dans la prochaine section vont être étudiés en
détails les résultats expérimentaux obtenus sur cette version SkelGIS de la simulation.
5.4.3 Résultats
Dans cette section, nous allons présenter les résultats que nous avons obtenus sur
la simulation d’écoulement du sang dans le réseau artériel décrite précédemment, et codée
avec la bibliothèque SkelGIS. Nous appellerons cette simulation bloodflow-SkelGIS.
Les résultats expérimentaux se découpent en trois parties. Tout d’abord, l’efficacité du
recouvrement des communications par les calculs a été évaluée. Cette optimisation du
code parallèle est, en effet, possible grâce à l’indexation mise en place dans la structure
de données. Nous avons décrit ce point dans les sections 5.2 et 5.3.2. Les expériences
suivantes utilisent toutes le recouvrement des communications par les calculs. L’implé-
mentation bloodflow-SkelGIS sera ensuite comparée à une version OpenMP de la même
simulation, que nous noterons bloodflow-OpenMP. Trois comparaisons seront effectuées,
les temps d’exécution, les accélérations des programmes ainsi que les métriques de Halstead
[65]. Enfin, une dernière phase d’expérimentation donnera les temps d’exécution
et les accélérations de bloodflow-SkelGIS sur deux grappes du top500 international de
novembre 2013, avec des tailles variables de réseaux. Les machines utilisées dans l’ensemble
de ces expériences sont détaillées dans la table 5.2. Il y a tout d’abord la grappe
“Babbage”, de l’Institut Jean le Rond d’Alembert UMR CNRS Université de Paris 6, qui
est une grappe de taille moyenne mais bien équipée, les nœuds thin du super-calculateur
TGCC-Curie classé vingtième dans le top500 de novembre 2013, et enfin les nœuds IBM
Blue Gene/Q de super-calculateur Juqueen en Allemagne classé huitième sur la même
liste. Notons que Juqueen nous permet également de valider SkelGIS sur une architecture
très différente des autres clusters. Ces machines nous ont permis de procéder à des tests
de performances allant de 8 à 8192 cœurs.
Afin de détailler au mieux les expériences effectuées, notons que la simulation
bloodflow-SkelGIS est exclusivement composée d’opérations sur des variables à double-130 Chapitre 5. SkelGIS pour des simulations sur réseaux
Calculateur Babbage TGCC Curie Juqueen
Processeur 2×Intel Xeon 2×SandyBridge IBM PowerPC
(3 GHz) (2.7 GHz) (1.6 GHz)
Cœurs/nœud 12 16 16
Mémoire/nœud 24 GB 64 GB 16 GB
Compilateur [-O3] OpenMPI Bullxmpi MPICH2
Réseau Infiniband Infiniband 5D Torus 40 GBps
Table 5.2 – Spécifications matérielles des machines utilisées
précision et que chaque expérience présentée dans cette partie a été lancée quatre fois
chacune, puis moyennée. Enfin, l’écart type noté sur l’ensemble des exécutions de la
simulation est très faible, et inférieur à 2%.
5.4.3.1 Recouvrement des communications par les calculs
La première expérience effectuée est celle qui permet de valider l’optimisation de
recouvrement des communications par les calculs. Cette expérience a été menée sur le
cluster “Babbage” de l’Université de Paris 6, sur un réseau de type arbre contenant 15.000
arêtes et 15.000 nœuds et un degré maximal très faible de 3. La table 5.3 donne l’ensemble
des temps d’exécution obtenus de 16 à 384 processeurs utilisés, et la figure 5.15 illustre,
de son côté, l’accélération de la simulation bloodflow-SkelGIS avec et sans l’optimisation
de recouvrement.
Cœurs Sans recouvrement Avec recouvrement Gain de temps %
16 12715.9 12386.2 2.59
32 6462.38 6189.79 4.22
64 3491.87 3124.74 10.5
128 1912.89 1581.46 17.3
256 1225.55 843.103 31.2
384 1166.18 612.787 47.45
Table 5.3 – Temps d’exécution en secondes de bloodflow-SkelGIS avec et sans l’optimisation de
recouvrement des communications par les calculs.
Tout d’abord, l’optimisation mise en place est efficace, comme cela pouvait être attendu.
On note, en effet, une différence très nette, à la fois pour les temps d’exécution et
sur les accélérations, entre la simulation sans le recouvrement et la simulation avec le recouvrement.
Cependant, il paraît presque surprenant d’obtenir des gains de performance
aussi importants. La version sans recouvrement fait émerger une faiblesse du prototype
SkelGIS. En effet, même si de meilleures performances étaient attendues avec cette optimisation
de recouvrement, on observe que le speedup de la version sans recouvrement
devient moins bon à partir de 128 processeurs. Cette faiblesse n’a pas été étudiée avec
précision. Nous pensons que le problème peut venir du partitionnement de graphes mis5.4. Simulation 1D d’écoulement du sang dans les artères 131
Coeurs
Accélération
sans recouvrement
avec recouvrement
idéal
16 64 128 256 384
16 64 128 256 384
Figure 5.15 – Accélération de la simulation bloodflow-SkelGIS sans et avec le recouvrement des
communications par les calculs.
en place dans le prototype actuel de SkelGIS, qui sur un grand nombre de processeurs,
fournit une distribution moyennement équilibrée. Les résultats de ce partitionnement
seront présentés en détails dans la section 5.5.1. Ce résultat montre, quoi qu’il en soit,
l’importance de l’optimisation mise en place dans la structure de données DDAG.
5.4.3.2 Comparaison avec OpenMP
La méthode SIPSim et son prototype implémenté SkelGIS, se proclame comme une
solution de parallélisme implicite très simple d’utilisation, car adaptée aux simulations
scientifiques, et proposant de très bonnes performances parallèles. De son côté, le langage
OpenMP est reconnu et utilisé dans les domaines scientifiques de par sa simplicité
d’utilisation, tout en sachant que les performances obtenues ne sont pas nécessairement
excellentes. Une comparaison des deux approches paraît donc être une bonne expérience,
aussi bien en terme de performances qu’en terme de difficulté de programmation.
Une version OpenMP de la simulation d’écoulement du sang dans le réseau artériel
a été développée par les mathématiciens à l’origine de cette simulation. La parallélisation
OpenMP dite à grain fin (fine-grain), est la parallélisation la plus utilisée par les
non-informaticiens et consiste à déclarer des boucles parallèles dans le code par la simple
directive #pragma omp parallel for. Ces boucles sont alors automatiquement réparties
entre les différents processus (threads) créés, ce qui rend la solution totalement implicite.
La simulation OpenMP qui a été implémentée ici n’est toutefois pas une implémentation
fine-grain. Il s’agit d’une parallélisation à gros grain (coarse-grain), où la directive plus
générale #pragma omp parallel est utilisée. Ce type de parallélisation OpenMP n’est
pas totalement implicite, et donc plus complexe qu’une parallélisation fine-grain. Une
parallélisation coarse-grain ressemble, dans son principe, à une parallélisation MPI. En
effet, une zone parallèle générale est déclarée comme entre les fonctions MPI_Init et
MPI_Finalize. Dans cette zone parallèle, plusieurs threads sont créés et vont, sauf précision
inverse de l’utilisateur, exécuter la même zone de code. Aucun transfert de données
n’est nécessaire entre les processus qui partagent la même mémoire, toutefois des syn-132 Chapitre 5. SkelGIS pour des simulations sur réseaux
chronisations sont implicitement effectuées entre les processus pour garantir la cohérence
des données et pour contrôler leur accès. Ce type de parallélisation permet de mettre
en place des programmes parallèles en suivant le paradigme SPMD et le parallélisme
de données, tout comme le modèle PGAS le propose. Ce type de parallélisation obtient
dans les cas complexes de meilleures performances que la parallélisation fine-grain, mais
n’est pas totalement implicite aux yeux de l’utilisateur [109]. En effet, étant donné que
tous les threads exécutent le même code, il est nécessaire de gérer une distribution des
données entre les threads. Cette distribution est à la charge de l’utilisateur ce qui rend
la solution plus complexe à mettre en œuvre. De plus, une réflexion est nécessaire pour
déclarer les variables partagées et locales. Cette parallélisation ayant été effectuée par
des mathématiciens, elle donne un aperçu des performances qu’il est possible d’obtenir
en utilisant OpenMP sans connaissances poussées en informatique.
La table 5.4 indique les temps d’exécution obtenus sur un unique nœud thin du
super-calculateur TGCC-Curie. Comme indiqué dans la table 5.2, un nœud contient 16
cœurs. La figure 5.16 trace les temps d’exécution obtenus en fonction du nombre de
cœurs utilisés, avec une échelle logarithmique, ce qui permet de mieux apprécier cette
comparaison.
Cœurs OpenMP SkelGIS Gain de temps %
1 2209.77 2006.92 9.2
2 2068.33 959.095 53.6
4 1122.73 497.424 55.7
8 621.72 273.011 56
16 341.95 156.59 54.2
Table 5.4 – Temps d’exécution en secondes de bloodflow-OpenMP et bloodflow-SkelGIS.
Coeurs (log2)
Temps d'exécution (log2)
OpenMP
SkelGIS
1 2 4 8 16
250 500 1000 2000
Figure 5.16 – Comparaison des temps d’exécution entre bloodflow-OpenMP et
bloodflow-SkelGIS avec une échelle logarithmique.
La table 5.4 et la figure 5.16 montrent que la version OpenMP obtient un très mauvais
temps d’exécution avec deux cœurs, et que ce problème se répercute, par conséquent, sur5.4. Simulation 1D d’écoulement du sang dans les artères 133
le reste des temps d’exécution. La figure 5.17 montre l’accélération des simulations. On
peut alors voir que le speedup obtenu par la version OpenMP n’est pas mauvais, car
proche du linéaire, outre le pallier entre 1 et 2 cœurs. La version SkelGIS, de son côté,
obtient de très bonnes performances. Le temps d’exécution séquentiel est tout d’abord
meilleur que le temps séquentiel de la version OpenMP de 9%. De plus, l’accélération du
programme étant quasi linéaire, et proche de l’idéal (figure 5.17), cette performance est
conservée en augmentant le nombre de processeurs. Le résultat de la version OpenMP
nuit à une bonne comparaison des deux approches. Cependant, notons que la pente
de l’accélération de la version OpenMP est moins importante que celle de la version
SkelGIS. Pour cette raison, si la version OpenMP était retravaillée afin de résoudre le
pallier à 2 cœurs, les temps d’exécution et les accélérations obtenus seraient toujours
moins performants pour la version OpenMP.
Coeurs
Accélération
OpenMP
SkelGIS
idéal
1 2 4 8 16
1
2
4
8 16
Figure 5.17 – Comparaison des accélérations entre bloodflow-OpenMP et bloodflow-SkelGIS.
Mais le point de la comparaison n’est pas réellement ici. En effet, qu’une version
OpenMP meilleure que la version SkelGIS n’existe ou pas, la version SkelGIS obtient
des performances très intéressantes et qui pourraient elles aussi être améliorées. En plus
des performances, il paraît intéressant de comparer la difficulté de programmation des
deux programmes. Pour expérimenter ce dernier point, les métriques de Halstead ont une
nouvelle fois été utilisées pour obtenir une évaluation du volume du programme écrit, de
la difficulté de programmation, et de l’effort à fournir. La table 5.5 donne les métriques
calculées pour chacune des deux simulations : bloodflow-OpenMP et bloodflow-SkelGIS.
L’effort à fournir pour écrire la version SkelGIS est environ 45% moins grand que
l’effort à fournir pour écrire la version OpenMP coarse-grain. Pourtant un programme
OpenMP ne consiste qu’en un ensemble de directives de compilation à appliquer à son
code, alors pourquoi un tel écart ? Comme le montre le tableau des métriques, cet écart
vient principalement d’un facteur, celui du volume du programme écrit qui est 30% plus
important dans la version OpenMP. Il s’agit d’un point très important pour la méthode
SIPSim et pour SkelGIS. En effet, SkelGIS gère, par l’intermédiaire de l’objet DDAG,
l’ensemble de la structure de données de façon transparente pour l’utilisateur. Ce point
simplifie énormément le code utilisateur puisque celui-ci n’a plus à se soucier de coder
une structure de données, qui peut être complexe suivant les cas. Pour les DMatrix, cet134 Chapitre 5. SkelGIS pour des simulations sur réseaux
Métriques OpenMP SkelGIS Gain %
N1 2607 2692 -3.2
N2 10737 7424 30.8
n1 365 231 36.7
n2 501 282 43.7
V 130213.73 91072.48 30
D 3911.18 3040.68 22.2
E 509.3M 276.9M 45.6
Table 5.5 – Métriques de Halstead pour les versions bloodflow-OpenMP et bloodflow-SkelGIS.
avantage était moins évident puisqu’une matrice est une structure de données très simple
à coder. Dans le cas des réseaux, l’intérêt du composant DDS, de la méthode SIPSim,
prend tout son sens et simplifie de façon significative le code de la simulation. La mé-
thode SIPSim étant une solution spécifique de parallélisme implicite en comparaison de
OpenMP, ce résultat devait être observé. Cependant, notons qu’un autre phénomène apporte
du poids au volume de code à fournir pour la version OpenMP. En effet, le fait
que la version OpenMP étudiée produise une parallélisation de type coarse-grain ajoute
du travail à l’utilisateur. Comme nous l’avons déjà décrit, cette version de parallélisation
OpenMP est proche d’une parallélisation MPI et l’utilisateur doit procéder à la décomposition
du domaine par lui-même. Cela nuit au parallélisme implicite, mais cela nuit
également au volume de code à fournir.
La simulation bloodflow-SkelGIS est donc plus intéressante en tout point par rapport
à la version bloodflow-OpenMP. La version SkelGIS obtient, en effet, de très bonnes
performances et de très bonnes métriques de Halstead.
5.4.3.3 Performances de SkelGIS
La méthode SIPSim et son implémentation SkelGIS sont conçues pour être exécutées
sur des architectures à mémoire distribuée. Bien qu’un programme parallèle MPI
fonctionne très convenablement sur une architecture à mémoire partagée, comme nous
venons de le voir, ce n’est pas son objectif premier. Cette nouvelle série d’expériences
permet donc d’estimer les performances de la bibliothèque SkelGIS sur des données de
taille importante et variable et sur des machines de configuration et de taille variables.
La table 5.6 référence les expériences qui ont été menées.
Nombre de nœuds et d’arêtes calculateur utilisé
Expérience 1 15k TGCC-Curie
Expérience 2 50k Juqueen
Expérience 3 100k Juqueen
Expérience 4 500k Juqueen
Table 5.6 – Expériences de performance sur bloodflow-SkelGIS.5.4. Simulation 1D d’écoulement du sang dans les artères 135
Les temps d’exécution obtenus pour l’ensemble de ces expériences sont réunis dans
la table 5.7. Le nombre de cœurs utilisés pour chaque expérience n’est pas le même
pour plusieurs raisons. Tout d’abord, la longueur des traitements et le nombre d’heures
qui nous étaient allouées sur chaque calculateur ne nous permettaient pas d’effectuer
des expériences trop longues. Pour cette raison, les expériences sur les réseaux de taille
50k et 100k ne commencent pas à 8 cœurs, et l’expérience sur un réseau de taille 500k
commence elle à 1024 cœurs. De plus, les clusters utilisés sont très demandés et le nombre
d’utilisateurs est très important. Des files d’attente pour les expériences sont donc mises
en place sur ces machines. Plus il y a de cœurs réservés pour une expérience, plus le délai
d’attente pour que l’expérience soit lancée est long. Pour cette raison, nous n’avons pas
réservé plus de 1024 cœurs sur le TGCC-Curie, et nous ne sommes pas montés au delà
de 8192 cœurs pour Juqueen. Enfin, sur Juqueen notamment, des contraintes très fortes
sur l’utilisation des machines sont mises en place. Le temps de calcul alloué à chaque
cœur possède un minimum et un maximum à respecter, aussi nous n’avons pu descendre
sous 256 cœurs pour les traitements sur les réseaux de taille 50k et 100k. Afin de mieux
appréhender les résultats obtenus, les accélérations de la simulation bloodflow-SkelGIS
pour chacune des expériences sont représentées dans les figures 5.18, 5.19 et 5.20.
Cœurs 15k TGCC 50k Juqueen 100k Juqueen 500k Juqueen
8 10080.1
16 5288.56
32 2680.21
64 1372.12
128 743.103
256 416.919 12602.20 24170.50
512 247.537 6976.98 12650.60
1024 178.8 3869.46 7043.42 30615.20
2048 2624.44 4122.97 16239.50
4096 1254.94 2657.76 8959.82
8192 5606.09
Table 5.7 – Temps d’exécution en secondes de bloodflow-SkelGIS.
Concernant la première expérience, le même jeu de données que dans l’expérience
sur le recouvrement a été utilisé. Hors, nous pouvons remarquer dans la figure 5.15 que
l’accélération est meilleure que dans la figure 5.18. En d’autres termes, l’accélération de
l’expérience semble meilleure sur la grappe “Babbage” que sur le TGCC-Curie. Cette
différence de performances peut être due au fait que le code SkelGIS réagit mieux à la
configuration matérielle du cluster “Babbage”. Toutefois cette explication parait étonnante.
Toutefois, notons que les performances sont tout de même très bonnes sur un
réseau de taille très modeste.
Dans les expériences suivantes, la taille des réseaux est augmentée et l’architecture
utilisée reste identique ce qui permet d’analyser le passage à l’échelle de SkelGIS. Il peut
être observé dans les figures 5.19 et 5.20 que les accélérations obtenues sont très convain-136 Chapitre 5. SkelGIS pour des simulations sur réseaux
Coeurs
Accélération
15k
idéal
8 64 256 512 1024
8 256 512 1024
Figure 5.18 – Accélération de bloodflow-SkelGIS sur un DAG de 15k arêtes et nœuds sur le
TGCC.
Coeurs
Accélération
50k
100k
idéal
256 1024 2048 4098
256 1024 2048 4098
Figure 5.19 – Accélération de bloodflow-SkelGIS sur des DAGs de 50k et 100k arêtes et nœuds
sur Juqueen.
Coeurs
Accélération
500k
idéal
1024 2048 4098 8192
2048 4098 8192
Figure 5.20 – Accélération de bloodflow-SkelGIS sur un DAG de 500k arêtes et nœuds sur
Juqueen.5.5. Partitionnement de réseaux 137
cantes. Le passage à l’échelle y est clairement bon puisque proche d’un résultat linéaire
jusqu’à 4098 processeurs. Sur la taille de réseau la plus importante, les performances sont
très bonnes jusqu’à 8192 processeurs.
Les résultats analysés dans cette section montrent que SkelGIS est convainquant en
plusieurs aspects. Tout d’abord l’optimisation de recouvrement rend la solution très performante,
et le passage à l’échelle est vérifié jusqu’à un très grand nombre de processeurs.
De plus, en comparaison avec une version coarse-grain OpenMP, SkelGIS montre des
performances très bonnes sur une architecture à mémoire partagée. OpenMP étant une
référence dans le parallélisme implicite, les résultats des métriques de Halstead montrent
que SkelGIS est très simple d’utilisation et qu’il peut même être plus simple qu’une
version séquentielle, du fait de la structure de données implicite. Pour finir, le passage
à l’échelle d’une simulation implémentée avec SkelGIS est bon et semble robuste sur
différentes configurations matérielles.
5.5 Partitionnement de réseaux
Dans cette section nous allons expliquer le choix d’implémentation qui a été mis en
place pour partitionner un réseau dans SkelGIS. Cette solution a montré des résultats
intéressants, comme nous l’avons vu dans la section 5.4.3. Les détails de cette méthode
de partitionnement seront décrits dans cette section, et nous verrons qu’elle contient un
certain nombre de désavantages. Un travail récent, en collaboration avec Rob Bisseling,
a permis d’étudier avec plus de précision le problème de partitionnement qui est posé
par les réseaux, mais aussi la façon dont on peut résoudre ce problème en utilisant le
partitionneur Mondriaan [120]. Les deux méthodes de partitionnement récemment mises
en place sont également introduites et évaluées dans cette section.
5.5.1 Partitionnement par regroupement d’arêtes sœurs
Il faut tout d’abord remarquer que dans le type de simulations qui nous intéresse des
calculs sont effectués à la fois sur les nœuds et sur les arêtes du graphe qui représente le
réseau. Nous avons donc deux solutions pour partitionner le graphe. On peut tout d’abord
choisir de distribuer les deux types d’éléments sur les processeurs, ce qui représente le
véritable problème de partitionnement d’un réseau. Ce problème est toutefois complexe
à résoudre, et il conduit également à une gestion des communications plus complexe.
L’autre solution est alors de ne distribuer que les nœuds ou que les arêtes et de dupliquer
les nœuds ou les arêtes manquantes aux coupures, afin de permettre les calculs. Dans
ce cas, les communications sont moins difficiles à gérer dans la solution de parallélisme
implicite. L’implémentation choisie dans le prototype actuel de SkelGIS pour les réseaux
a été de partitionner les arêtes sur les processeurs, où le calcul était considéré comme
plus lourd, et de dupliquer les nœuds sur les différents processeurs, aux coupures des
différentes parties, où le calcul était considéré comme plus léger. Nous avons donc fait
le choix, dans un premier temps, de simplifier le problème en ne partitionnant que les138 Chapitre 5. SkelGIS pour des simulations sur réseaux
arêtes du réseau et en dupliquant les nœuds. De plus, nous avons également limité, et
donc modifié, le problème en considérant une sous-partie des réseaux qui peuvent être
représentés par des DAG.
Comme cela a déjà été décrit dans l’état de l’art 2.3, un partitionnement de graphe
découpe l’ensemble des nœuds d’un graphe G = (V, E) en p parties distinctes V0, . . . , Vp−1
telles que pour i 6= j, Vi∩Vj = ∅ et telles que V =
S
i
Vi
. Le partitionnement doit répondre
à la contrainte d’équilibrage de charge suivante
ω(Vi) ≤ (1 + )
ω(V )
p
(5.8)
où est le pourcentage de non-équilibrage accepté. peut être choisi soit automatiquement
par la solution, soit par l’utilisateur. Enfin, le partitionnement doit minimiser le
nombre d’arêtes coupées, aussi appelé edge-cut.
Dans le prototype de SkelGIS, nous avons choisi de partitionner les arêtes du graphe.
Le problème de partitionnement doit donc être transposé aux arêtes. Ce problème n’est
pas nouveau et les travaux de Kim et Al [81] se sont, par exemple, intéressés à partitionner
les arêtes en coupant les nœuds et en les dupliquant sur chaque processeur. Nous avons
toutefois développé notre propre méthode de partitionnement afin d’essayer de tirer parti
des DAG et du cas particulier des simulations numériques sur les réseaux. Notre méthode
de partitionnement transforme tout d’abord le DAG en un graphe G0 plus grossier que
nous appelons méta-graphe. En reprenant les définitions introduites dans la section 5.3,
nous allons décrire la construction du graphe G0
. Les arêtes sortantes et entrantes d’un
nœud v ∈ V sont respectivement notées N
+
E
(v) et N
−
E
(v). Deux arêtes ei et ej sont
considérées comme étant sœurs si S(ei) = S(ej ) et D(ei) 6= D(ej ). L’ensemble des
arêtes sœurs d’un nœud v ∈ V est défini comme égal à N
+
E
(v). Le méta-graphe G0 du
réseau G est alors défini comme le graphe G0 = (V
0
, E0
) où V
0 = {N
+
E
(v), ∀v ∈ V } et
E0 = {(N
+
E
(v1), N +
E
(v2)) ∈ V
0 × V
0
, ∀v1 ∈ V, v2 ∈ N
+
V
(v1)}. La figure 5.21 illustre le
réseau de type DAG G et le méta-graphe G0 associé.
Figure 5.21 – Exemple de réseau G (à gauche) de type DAG, et du méta-graphe G0 associé (à
droite).5.5. Partitionnement de réseaux 139
Nombre de nœuds Degré maximum
Arbre 1 10k 10
Arbre 2 10k 2
Arbre 3 16k 5
Table 5.8 – Type d’arbres utilisés pour évaluer le partitionnement.
Dans le méta-graphe G0
les nœuds sont les blocs d’arêtes sœurs du graphe G, et les
arêtes représentent les liens entre ces blocs par l’intermédiaire des nœuds de G. Notons
que les nœuds de G0
sont assortis d’un poids, qui est égal au nombre d’arêtes sœurs de
G représentées par le nœud de G0
. En d’autres termes, pour un nœud v ∈ V et un nœud
v
0 = N
+
E
(v) ∈ V
0
, on associe un poids ω(v
0
) = |N
+
E
(v)|. En partitionnant ce méta-graphe
G0 deux problèmes sont résolus à la fois :
— Le problème de partitionnement posé redevient un problème standard de partitionnement
des nœuds d’un graphe.
— Le partitionnement des nœuds de G0
, en tenant compte de leur poids, revient
à un partitionnement de blocs d’arêtes sœurs dans G, ce qui favorise la localité
géographique du résultat.
En revenant ainsi à un problème de partitionnement standard de type edge-cut, il aurait
été possible d’utiliser un partitionneur de graphe comme METIS [77] ou Scotch [100].
Toutefois, nous ne connaissions pas ces solutions au moment du développement de ce
prototype de SkelGIS. Cette solution pourra être envisagée dans les prespectives de ce
travail pour comparer avec plus de détail les différentes approches de partitionnementpossible.
Nous pouvons également noter qu’en envisageant ce prototype de SkelGIS nous
avons préféré une solution simple et sans dépendance pour partitionner uniquement les
DAG, et non tous les graphes comme le proposent METIS et Scotch.
Afin d’évaluer les limites du partitionnement de SkelGIS, nous avons effectué quelques
expériences en calculant le nombre d’arêtes dont chaque processeur a la charge, et les
communications effectuées par chaque processeur, en terme de nombre d’octets et de
temps effectif. Nous avons mené ces expériences sur trois types d’arbres différents, générés
aléatoirement, dont la description est résumée dans la table 5.8. Le premier arbre ainsi
obtenu est un arbre plutôt large et peu profond alors que le second arbre est à l’inverse
un arbre profond et peu large. Enfin, le dernier arbre est un arbre qui peut être considéré
comme assez équilibré en profondeur et en largeur.
La table 5.22 donne le nombre moyen d’arêtes dont chaque processeur est en charge
à chaque itération de simulation, et l’écart type maximal obtenus par rapport à cette valeur
moyenne. Ainsi, plus l’écart type est proche de la valeur moyenne, plus l’équilibrage
de charge peut être considéré comme mauvais. On peut observer, dans cette table, que
l’équilibrage de charge en terme de nombre d’arêtes est bon puisque l’écart type obtenu
est très faible comparé à la valeur moyenne. On peut également observer que le partitionnement
effectué est meilleur pour les arbres 2 et 3 que pour un arbre large comme
l’arbre 1.
La table 5.23 représente le nombre moyen d’octets que chaque processeur doit échan-140 Chapitre 5. SkelGIS pour des simulations sur réseaux
Arbre 1 Arbre 2 Arbre 3
Nb de processeurs moy ect moy ect moy ect
4 2499.75 2.68 2499.75 0.43 4036.25 0.43
8 1249.87 1.45 1249.87 0.78 2018.12 0.6
16 624.94 1.25 624.94 0.66 1009.06 0.24
32 312.47 1.6 312.47 1.03 504.53 0.83
64 156.23 1.66 156.23 0.88 252.26 0.71
128 78.12 1.52 78.12 0.75 126.13 0.74
256 39.06 1.59 39.06 0.71 63.06 0.65
Figure 5.22 – Moyenne (moy) et écart type (ect) du nombre d’arêtes obtenu pour chaque
processeurs suite au partitionnement.
ger en une itération de temps et pour un unique DPMap, donc une unique quantité de
la simulation. Cette table représente également l’écart type maximal obtenus par rapport
à cette valeur moyenne. Ainsi, de nouveau, plus l’écart type est proche de la valeur
moyenne, plus l’équilibrage des communications effectuées par chaque processeur peut
être considéré comme mauvais. On peut observer ici que l’équilibrage de charge en terme
de communications est assez mauvais dans ce partitionnement. Cependant l’équilibrage
des communications n’est généralement pas considéré dans les problèmes de partitionnements,
où l’on cherche plutôt à minimiser le nombre total de communications (pour le
partitionnement de graphes) ou le volume total de communications (pour le partitionnement
d’hypergraphes). Tout ce que l’on peut conclure de ce résultat est que tous les
processeurs n’ont pas la même charge de communications à effectuer et que cette charge
peut même aller du simple au double. Cela explique peut être partiellement l’accélération
obtenue dans la figure 5.15, sans recouvrement des communications par les calculs.
Arbre 1 Arbre 2 Arbre 3
Nb processeurs moy ect moy ect moy ect
4 616.0 168.09 112.0 53.66 148.0 76.84
8 598.0 377.95 98.0 38.31 128.0 42.14
16 437.0 214.77 107.0 42.41 128.0 49.79
32 390.5 238.87 86.5 40.81 135.0 61.18
64 327.0 214.73 95.75 40.02 111.5 42.33
128 266.12 154.3 94.25 31.29 107.5 39.66
256 209.19 113.43 84.25 31.34 94.0 32.52
Figure 5.23 – Moyenne (moy) et écart type (ect) du nombre d’octets à échanger pour chaque
processeur, pour chaque DPMap et pour une unique itération de temps de la simulation, suite
au partitionnement des arbres de la table 5.8.
Afin de mieux percevoir la charge d’échanges de chaque processeur dans une simulation
complète, prenons l’exemple de la simulation artérielle décrite dans la section 5.4, en
utilisant les arbres de la table 5.8. Dans la simulation artérielle, il y a onze DPMap néces-5.5. Partitionnement de réseaux 141
sitant des échanges de données, et quatre-vingt mille itérations de temps. La table 5.24
représente alors le nombre moyen total d’octets échangés pour chaque processeur lors de
la simulation complète.
Nb processeurs Arbre 1 Arbre 2 Arbre 3
4 542 Mo 98.6 Mo 130.2 Mo
8 526.2 Mo 86.2 Mo 112.6 Mo
16 384.6 Mo 94.2 Mo 112.6 Mo
32 343.6 Mo 76.1 Mo 118.8 Mo
64 287.8 Mo 84.3 Mo 98.1 Mo
128 234.2 Mo 82.9 Mo 94.6 Mo
256 184.1 Mo 74.1 Mo 82.7 Mo
Figure 5.24 – Moyenne du nombre d’octets total à échanger pour chaque processeur, dans le
cadre de la simulation artérielle de la section 5.4, en utilisant les arbres de la table 5.8.
Les résultats obtenus sont donc relativement bons en terme d’équilibrage de charge.
Et les performances obtenues sur bloodflow-SkelGIS sont elles aussi relativement bonnes
grâce à la mise en place d’un recouvrement des communications par les calculs, comme
nous l’avons vu dans la section 5.4.3. Cependant, les performances sont également limitées
par les choix qui ont été effectués pour mettre en place un partitionnement. Tout d’abord,
notre partitionnement actuel ne s’adresse qu’aux réseaux de type DAG. De plus, nous ne
profitons pas de l’efficacité et de l’expertise des partitionneurs existants comme Scotch ou
METIS, ni de leur version parallélisées. Enfin, en dupliquant les nœuds, nous ne traitons
pas le véritable problème de partitionnement des réseaux et nous ne pouvons garantir son
efficacité dans tous les types de simulations et sur tous les types de graphes. En effet, nous
avons considéré que les calculs sur les nœuds étaient presque négligeables par rapport
aux calculs sur les arêtes, ce qui n’est pas toujours le cas suivant les simulations. De plus,
les expériences mesurées dans cette section semblent montrer la nécessité d’améliorer le
partitionnement du prototype de SkelGIS. C’est la raison pour laquelle nous avons étudié
d’autres méthodes de partitionnement, présentées dans la suite de cette thèse.
5.5.2 Partitionnement avec Mondriaan
Des travaux plus récents sur SkelGIS s’intéressent au véritable problème de partitionnement
posé par les réseaux, sans duplication des nœuds. Nous étudions ici la formalisation
du problème et deux méthodes de partitionnement. Notons que le but de ce travail
est également de retourner vers une définition plus générale des réseaux. Nous prenons
en compte ici tout type de réseau, et non plus seulement ceux pouvant être représentés
par un graphe dirigé acyclique. En étudiant le véritable problème de partitionnement,
nous évitons également la duplication des nœuds sur les processeurs.142 Chapitre 5. SkelGIS pour des simulations sur réseaux
5.5.2.1 Formalisation du problème de partitionnement des réseaux
Comme expliqué précédemment, une simulation sur un réseau implique le calcul de
deux schémas numériques différents, reliés entre eux par le réseau, créant une certaine
dépendance de calcul aux bordures physiques, Nout. À partir de deux schémas numériques
explicites, il est donc possible d’obtenir un ensemble explicite lui aussi, ou à l’inverse
implicite. L’ensemble général obtenu dépend de la simulation en elle-même et ne peut
être connu à l’avance. Toutefois, il est possible de définir de façon générale, comme
nous l’avons décrit dans la section 5.1, quatre super-étapes dans une simulation sur les
réseaux, que nous rappelons ici. Notons T1 et T2 les deux types d’éléments du réseau
qui peuvent être indifféremment associés aux nœuds ou aux arêtes. Une itération t d’une
simulation sur un réseau est alors, de façon générale, représentée par les quatre super-
étapes suivantes :
1. Communication des éléments T1 à t − 1
2. Calcul des éléments T2 à t
3. Communication des éléments T2 à t − 1 ou/et t
4. Calcul des éléments T1 à t
Il est possible de représenter l’ensemble des cas de simulation sur les réseaux en parallèle
avec cette définition en quatre super-étapes BSP. Le partitionnement consiste donc en
deux problèmes, tout d’abord équilibrer la charge de travail entre les processeurs pour
les étapes 2 et 4, et réduire au maximum le volume de communications nécessaire aux
étapes 1 et 3. On peut noter que l’étape 2 consiste à calculer T2 et a besoin au préalable
des communications des éléments T1 pour effectuer ce calcul. On parlera alors d’une
communication de T1 vers T2. L’équilibrage de charge consiste donc à équilibrer les
deux types d’éléments T1 et T2, et la réduction du volume de communication consiste à
minimiser les communications de T1 à T2 et de T2 à T1. Ces deux contraintes doivent
être résolues de la même façon quelque soit leur ordre d’apparition et quelque soit donc
l’association des types T1 et T2 aux nœuds et aux arêtes. Pour simplifier la suite de
ce travail, nous étudierons le cas précis de la simulation de l’écoulement du sang dans
les artères qui a été décrite dans la section 5.4, et dont les quatre super-étapes sont les
suivantes :
1. Communication des arêtes à t − 1
2. Calcul des nœuds à t
3. Communication des nœuds à t
4. Calcul des arêtes à t
La particularité du problème de partitionnement pour les réseaux est donc que des
calculs et des communications sont effectués à la fois sur les arêtes et sur les nœuds du
graphe. Si les équilibrages de charge des nœuds et des arêtes peuvent être traités de
façon distincte, les communications engendrées par leur affectation sont, en revanche,
non-distinctes et reliées par le réseau. Tout d’abord, afin de pouvoir traiter à la fois le
partitionnement des nœuds et des arêtes en utilisant les outils classiques, qui ne traitent5.5. Partitionnement de réseaux 143
que les nœuds d’un graphe, nous commençons par changer la représentation du graphe
du réseau. Le graphe G = (V, E) avec n nœuds v0, . . . , vn−1 et m arêtes e0, . . . , em−1 est
transformé en un nouveau graphe G0 = (V
0
, E0
) où |V
0
| = n + m et |E0
| = 2m. Pour
chaque arête ek = (vi
, vj ) ∈ E, un nœud v
0
n+k
est ajouté, et l’arête ek est coupée en
deux arêtes e
0
k = (vi
, v0
n+k
) et e
0
2k = (v
0
n+k
, vj ). Le graphe G0
représente donc les arêtes
du graphe G comme des nœuds supplémentaires, tout en conservant la connectivité du
graphe G. La figure 5.25 illustre un graphe G et le graphe associé G0
. Notons que G0
Figure 5.25 – Transformation du graphe G d’un réseau en graphe G0
.
est un graphe biparti avec deux sous-ensembles de nœuds, les rouges et les bleus. Nous
n’avons alors dans ce graphe que des liens du type bleu-rouge mais pas de liens du type
bleu-bleu ou rouge-rouge. Dans ce nouveau graphe G0
, les étapes de communications 1
et 3, représentées dans les figures 5.26(a) et 5.26(b), deviennent :
— Communication des nœuds rouges vers les nœuds bleus
— Communication des nœuds bleus vers les nœuds rouges
(a) Étape de communication
1, des nœuds rouges
vers les nœuds bleus de G
0
.
(b) Étape de communication 3,
des nœuds bleus vers les nœuds
rouges de G
0
.
Figure 5.26 – Étapes de communication 1 et 3.144 Chapitre 5. SkelGIS pour des simulations sur réseaux
Dans la suite, les nœuds bleus représenteront donc les nœuds du réseau initial G, et
les nœuds rouges les arêtes du réseau initial G. Étant donné le graphe biparti G0 ainsi
défini, l’ensemble des nœuds V
0 du graphe est composé de deux parties V
r
et V
b
, telles
que V
0 = V
r ∪V
b
et V
r ∩V
b = ∅. Le problème de partitionnement du graphe G0
consiste
alors à partitionner V
r
et V
b
en p parties telles que V
r =
S
i
V
r
i
et V
b =
S
i
V
b
i
et telles
que pour i 6= j ∈ J0, pJ, V r
i ∩V
r
j = ∅ et V
b
i ∩V
b
j = ∅. Le partitionnement de G0 ainsi défini
doit minimiser le volume de communications entre les processeurs, tout en répondant
aux deux contraintes d’équilibrage de charge suivantes :
ω(V
r
i
) ≤ (1 + )
ω(V
r
)
p
(5.9)
ω(V
b
i
) ≤ (1 + )
ω(V
b
)
p
(5.10)
où ω(A) représente le poids total des nœuds d’un ensemble A ∈ V , et où représente le
pourcentage de tolérance dans l’équilibrage de charge.
Pour résoudre ce problème de partitionnement, le modèle de partitionnement d’hypergraphe
(défini dans la section 2.3 de cette thèse) est utilisé sur le graphe G0
. Deux
méthodes de partitionnement différentes sont étudiées et sont détaillées dans les deux
sections suivantes.
5.5.2.2 Méthode à partitionnement unique
La première méthode qui a été étudiée, appelée la méthode à partitionnement unique,
est composée de deux étapes que nous allons expliquer en détails dans cette partie :
1. L’étape de communication des nœuds bleus vers les nœuds rouges est, tout d’abord,
transformée en un problème de partitionnement d’hypergraphe, qui permet de distribuer
les nœuds rouges sur les différents processeurs.
2. Une heuristique est ensuite appliquée pour distribuer les nœuds bleus sur les processeurs,
tout en prenant en compte la distribution des nœuds rouges qui a été faite
au préalable.
Afin d’effectuer la première étape de cette méthode, une matrice A de taille m×n est
créée et a pour but de représenter les communications des nœuds bleus vers les nœuds
rouges. Les lignes de la matrice A représentent les nœuds bleus du graphe G0
, et les
colonnes de la matrice A représentent, quant à elles, les nœuds rouges du graphe G0
.
Si une communication est nécessaire d’un nœud bleu vers un nœud rouge, une valeur
1 est placée dans A aux coordonnées correspondantes. Si l’on distribue les colonnes
de la matrice A (les nœuds rouges) aux processeurs, le volume de communication sera
minimisé si et seulement si les éléments non nuls de chaque ligne sont répartis sur le
minimum de processeurs différents. La distribution des colonnes de la matrice A revient
en fait à procéder à un partitionnement d’hypergraphe suivant une dimension. Il s’agit
donc du partitionnement row-net model [29], décrit dans l’état de l’art de cette thèse
dans la section 2.3, qui consiste à distribuer les colonnes de la matrice A (les nœuds de5.5. Partitionnement de réseaux 145
l’hypergraphe), tout en cherchant à minimiser le nombre de coupures sur une ligne de A
(une hyper-arête). La figure 5.27 donne un exemple de réseau, la matrice A qui lui est
associée, et enfin l’hypergraphe Hr(A) qui lui est également associé.
0 1
2 3 4
5 6
0 1 2
3 4 5 6
0
1
2
3
4
5
6
0 1 2 3 4 5 6
1 1
1
1 1
1 1 1 1
1
1 1
1 1
0 0 0 0 0
0 0 0 0 0 0
0 0 0 0 0
0 0 0
0 0 0 0 0 0
0 0 0 0 0
0 0 0 0 0
0 1 2
3 4
5
6
0 2
3 51
6 4
Figure 5.27 – Exemple de réseau G0 avec la matrice A et les hypergraphes Hr et Hc qui y sont
associés
Le partitionnement de l’hypergraphe Hr associé à un réseau initial G peut être effectué
avec le partitionneur Mondriaan [120] dans un mode à une dimension. Les nœuds
rouges de G0
, c’est-à-dire les arêtes du réseau, sont alors distribués en respectant la
contrainte (5.9) et en cherchant à minimiser les communications des nœuds bleus vers
les nœuds rouges.
Une fois cette première étape effectuée, le partitionnement de V
r
est terminé et
respecte la contrainte d’équilibrage (5.9). Les nœuds rouges et bleus de G0
étant connectés
par le réseau, il est important de trouver une heuristique permettant de distribuer les
nœuds bleus en tenant compte de la distribution des nœuds rouges, afin de minimiser le
nombre de communications nécessaires. Le problème de partitionnement pour les nœuds
bleus est illustré dans la figure 5.28. En effet, étant donné quatre nœuds rouges déjà
distribués aux processeurs p0, p1 et p2, comment choisir parmi ces trois processeurs celui
qui sera attribué au nœud bleu.
Afin d’expliquer l’heuristique mise en place pour le partitionnement des nœuds bleus,
quelques définitions sont nécessaires. Pour un nœud v ∈ V
b
, deg(v) représente le nombre
de nœuds rouges adjacents à v dans G0
, ou en d’autres termes le nombre d’arêtes adjacentes
à v dans G. deg(v, Pi) représente le nombre de nœuds rouges adjacents à v et
qui ont été distribués au processeur Pi
. L’heuristique choisit d’attribuer le nœud v au
processeur Pi de façon à maximiser deg(v, Pi), et de façon à vérifier la contrainte d’équilibrage
(5.10). Notons que si il existe i, j ∈ J0, pJ qui satisfont deg(v, Pi) = deg(v, Pj ),
alors P(v) = Pi si et seulement si ω(V
b
i
) < ω(V
b
j
), sinon P(v) = Pj . Grâce à cette
heuristique les nœuds bleus de G0
sont partitionnés en tentant de respecter la contrainte
d’équilibrage de charge (5.10), tout en minimisant les communications des nœuds rouges146 Chapitre 5. SkelGIS pour des simulations sur réseaux
P0
P0
P1
P2
Quel P {P0,P1,P2} ?
Figure 5.28 – Problème de partitionnement pour les nœuds bleus de G0
.
vers les nœuds bleus. En effet, en reprenant l’exemple de la figure 5.28, l’heuristique
décrite choisie idéalement d’assigner le nœud au processeur P0. Dans ce cas seules deux
communications des nœuds rouges vers les nœuds bleus sont nécessaires. À l’inverse, si un
autre processeur avait été choisi, trois communications des nœuds rouges vers les nœuds
bleus auraient été nécessaires.
5.5.2.3 Méthode à partitionnement double
La deuxième méthode de partitionnement qui a été étudiée, appelée la méthode à
partitionnement double, est elle composée des trois étapes suivantes :
1. Tout comme dans la première méthode, l’étape de communication des nœuds bleus
vers les nœuds rouges est transformée en un problème de partitionnement d’hypergraphe,
qui permet de distribuer les nœuds rouges sur les différents processeurs.
2. L’étape de communication des nœuds rouges vers les nœuds bleus est ensuite transformée
en un problème de partitionnement d’hypergraphe, qui permet de distribuer
les nœuds bleus à leur tour.
3. Une dernière étape de permutation est mise en place pour permettre de réaffecter
certains processeurs à certaines partitions et ainsi d’améliorer la minimisation du
nombre de communications.
La première étape de cette méthode est exactement la même que la première étape
de la méthode à partitionnement unique décrite précédemment. Les communications
des nœuds bleus vers les nœuds rouges y sont exprimées dans une matrice creuse A
correspondant à la matrice d’incidence du graphe G. Puis la matrice A est transposée en
un hypergraphe Hr, où les lignes de A représentent les hyper-arêtes et les colonnes les
nœuds de Hr. Un partitionnement row-net à une dimension est effectué sur l’hypergraphe
Hr avec le partitionneur Mondriaan [120].
La deuxième étape de cette méthode est, quant à elle, la transposée de la première
étape. Les communications des nœuds rouges vers les nœuds bleus peuvent être représentées
par la matrice AT
, transposée de la matrice A. Cette matrice pourrait à son tour être
transformée en un hypergraphe Hr(AT
) sur lequel serait appliqué un partitionnement à5.5. Partitionnement de réseaux 147
une dimension de type row net. Toutefois, il est plus simple de conserver la matrice A
mais d’y appliquer un partitionnement à une dimension de type column net sur un hypergraphe
noté Hc(A) = Hr(AT
) qui va, de la même façon, partitionner les nœuds bleus
et réduire les communications des nœuds rouges vers les nœuds bleus. La figure 5.27
illustre ces deux premières étapes du partitionnement et les deux hypergraphes Hr(A) et
Hc(A).
La différence principale entre la première et la deuxième étape de cette méthode
est le nombre de nœuds présents dans chaque hyper-arête. En effet, dans la première
étape, le nombre de nœuds dans chaque hyper-arête est égal au degré du nœud bleu
correspondant. Dans la deuxième étape, en revanche, le nombre de nœuds dans chaque
hyper-arête est égal à deux puisque chaque nœud rouge de G0
est uniquement relié à
deux nœuds bleus. Par conséquent, le partitionnement d’hypergraphe row-net (columnnet)
appliqué dans la deuxième étape de la méthode est équivalent à un partitionnement
de graphe standard où le nombre d’arêtes coupées doit être minimisé. Un partitionneur de
graphe pourrait donc être utilisé pour résoudre la deuxième étape de la méthode, comme
par exemple METIS [77] ou Scotch [100]. Toutefois, il est également possible d’utiliser le
même partitionneur d’hypergraphes Mondriaan [120], et ainsi d’en abuser légèrement [53]
tout en payant le coût supplémentaire en temps CPU. En effet, le partitionnement d’un
hypergraphe n’est qu’une généralisation du partitionnement de graphe, cette méthode
peut donc être utilisée pour le partitionnement de graphe mais demandera plus de calculs
du fait de la généralisation qui y est appliquée.
Une fois la première et la deuxième étape effectuées, les nœuds rouges et les nœuds
bleus du graphe G0
sont attribués parmi les processeurs disponibles en respectant les deux
contraintes d’équilibrage (5.9) et (5.10). Toutefois les deux partitionnements qui ont été
effectués sont totalement indépendants et ne tiennent donc pas compte des connections
qui relient les nœuds bleus et les nœuds rouges dans le réseau.
La troisième étape va servir à prendre en compte ces liaisons et ainsi à réduire les communications
engendrées par les deux partitionnements distincts. On obtient donc deux
partitionnements, et l’on souhaite pouvoir réaffecter les processeurs dans ces distributions
afin d’améliorer le volume de communications. Il s’agit donc d’un problème d’affectation
dans un graphe biparti. Ce problème est équivalent à effectuer une permutation des processeurs
de façon optimale. Tout d’abord, nous définissons une matrice W de taille p × p
(p étant le nombre de processeurs) pour exprimer le nombre de communications évitées si
une permutation était effectuée entre deux processeurs donnés. Le calcul de cette matrice
W est basée sur la matrice A, puisque celle-ci représente les communications des nœuds
bleus vers les nœuds rouges, et à l’inverse, en utilisant sa transposée, des nœuds rouges
vers les nœuds bleus.
Dans la matrice A, ai,j = 1 si un nœud bleu i est relié à un nœud rouge j. Une
fois le partitionnement des nœuds bleus et rouges effectués, Φ(i) représente le processeur
attribué pour le nœud bleu i, et Ψ(j) représente le processeur attribué pour le nœud
rouge j. La matrice W est alors définie comme suit
ws,t =
X
i : Φ(i)=s
δi(t) (5.11)148 Chapitre 5. SkelGIS pour des simulations sur réseaux
δi(t) = (
1 si ∃j : ai,j = 1 ∧ Ψ(j) = t
0, sinon.
(5.12)
La taille de la matrice W dépend du nombre de processeurs utilisés et la matrice est
généralement dense. L’élément ws,t de la matrice représente le nombre de communications
évitées, des nœuds bleus vers les nœuds rouges, si le processeur s est permuté avec le
processeur t. La matrice W peut donc être identifiée comme un graphe biparti complet
Gw, illustré dans la figure 5.29. Un moyen de calculer la meilleure permutation possible de
processeurs est alors de calculer le couplage ou l’appariement (ou le matching en anglais)
maximum du graphe biparti complet Gw.
p-1
p-1
W =
ws,t
t
s
0 1 s p-1
0 1 t p-1
ws,t
Figure 5.29 – La matrice W et le graphe biparti complet auquel la matrice peut être identifiée
Gw.
Le couplage maximum de Gw est équivalent à un problème d’assignement qui peut être
résolu en O(p
4
) en utilisant l’algorithme Hongrois, publié par Harold Kuhn en 1955 [83] ;
et qui peut également être résolu en O(p
3
) en utilisant une amélioration de cet algorithme.
Si le nombre de processeurs p est grand, des approximations linéaires de cet algorithme
peuvent également être utilisées.
La matrice W représente les communications évitées, mais uniquement pour les communications
des nœuds bleus vers les rouges. Le problème similaire peut être résolu pour
la matrice AT
et permettra de réduire les communications des nœuds rouges vers les
nœuds bleus également. Une matrice W0
est alors calculée n’est pas égale à WT
. Toutefois,
en calculant de la même façon que W la matrice W0
, en utilisant AT au lieu de A,
la valeur w
0
(s, t) de W0
représente le nombre de communications évitées en échangeant
le processeur t avec le processeur s. Afin de maximiser les communications évitées par
permutation, l’algorithme Hongrois doit alors être appliqué sur W = W + (W0
)
T
.
Cette deuxième méthode respecte donc les deux contraintes d’équilibrage (5.9)
et (5.10) en appliquant deux partitionnements d’hypergraphe à une dimension sur la
matrice A. Par la suite, afin de lier les deux distributions obtenues et d’en minimiser le
volume des communications obtenu, un couplage maximum est appliqué sur la matrice
W.5.5. Partitionnement de réseaux 149
5.5.2.4 Résultats
A l’heure actuelle aucun résultat n’a encore été établi pour ces deux nouvelles mé-
thodes de partitionnement des réseaux. Ces nouvelles méthodes s’inscrivent dans un
cadre plus général que l’implémentation actuelle de SkelGIS, puisqu’elles généralisent
le problème aux graphes et non plus seulement aux DAG. Un certain nombre d’adaptations
est en cours pour permettre l’utilisation de ces méthodes de partitionnement,
puis pour les évaluer sur le cas de test présenté dans la section 5.4. Une intuition sur
les résultats attendus est toutefois possible. Il semble, à première vue, que la méthode à
partitionnement simple soit plus intéressante. En effet, elle répond strictement aux deux
contraintes d’équilibrage de charges des équations (5.9) et (5.10), tout comme la méthode
à double partitionnement. Toutefois, elle distribue directement les sommets bleus en tenant
compte des sommets rouges, alors que la méthode à double partitionnement effectue
deux partitionnements totalement indépendants avant d’essayer de les rapprocher par un
matching. Cela laisse penser que malgré le matching effectué la méthode à partitionnement
double ne pourra être aussi efficace, en terme de volume de communications, que
dans la première méthode. Mais essayons de décrire un modèle de coût pour prévoir les
résultats de ces méthodes de façon plus formelle.
Étant donné une simulation sur les réseaux implémentée en SkelGIS, nous pouvons
noter T
i
comp le temps passé dans les calculs pour le processeur i. Étant donné T
i
1comp
et
T
i
2comp
, le temps écoulé dans le calcul des nœuds et des arêtes du réseau (ou vice versa),
pour le processeur i, nous considérons que T
i
comp = T
i
1comp + T
i
2comp
. Les deux méthodes
présentées dans cette section respectent strictement les deux contraintes d’équilibrage
de charges (5.9) et (5.10). Cela signifie que pour tout processeurs i et j, tel que i 6= j,
T
i
1comp ≈ T
j
1comp
et T
i
2comp ≈ T
j
2comp
. On peut alors considérer que le temps total de
calcul de la simulation, Tcomp, est égale à max
0≤i.
HAL Id: tel-01067475
https://tel.archives-ouvertes.fr/tel-01067475
Submitted on 23 Sep 2014
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of scientific
research documents, whether they are published
or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est
destin´ee au d´epˆot et `a la diffusion de documents
scientifiques de niveau recherche, publi´es ou non,
´emanant des ´etablissements d’enseignement et de
recherche fran¸cais ou ´etrangers, des laboratoires
publics ou priv´es.UNIVERSITÉ PIERRE ET MARIE CURIE
ÉCOLE DOCTORALE INFORMATIQUE, TÉLÉCOMMUNICATIONS ET ÉLECTRONIQUE
Analyse de sécurité de logiciels système
par typage statique
— Application au noyau Linux—
ÉTIENNE MILLON
sous la direction d’Emmanuel Chailloux et de Sarah Zennou
THÈSE
pour obtenir le titre de
Docteur en Sciences
mention Informatique
Soutenue le 10 juillet 2014 devant le jury composé de
Rapporteurs
Sandrine Blazy IRISA
Pierre Jouvelot MINES ParisTech
Directeurs
Emmanuel Chailloux Université Pierre et Marie Curie
Sarah Zennou Airbus Group Innovations
Examinateurs
Gilles Muller Université Pierre et Marie Curie
Vincent Simonet Google
Invité
Olivier Levillain ANSSIi
“
Many C programmers believe that « strong
typing » just means pounding extra hard on
the keyboard.
Peter van den Linden
”ii
REMERCIEMENTS
Enfin la dernière page à écrire ! Combien de fois ai-je entendu que "les remerciements,
c’est le plus facile". Et pourtant, je suis partagé entre la satisfaction d’arriver au bout de ce
travail, et la crainte d’oublier une des nombreuses personnes qui m’ont aidé à y arriver.
Je tiens à commencer par remercier mes encadrants de thèse, Emmanuel Chailloux et
Sarah Zennou. Sans leurs conseils pertinents et leurs nombreuses relectures, je n’aurais pas
pu arriver au bout de ce travail.
Merci également à Sandrine Blazy et à Pierre Jouvelot d’avoir accepté de rapporter mon
manuscrit, et pour leurs remarques qui ont permis d’améliorer sa qualité. Je veux également
remercier les autres membres du jury, Gilles Muller et Vincent Simonet, ainsi qu’Olivier Levillain
qui y a sa place en tant qu’invité.
Si cette aventure a pu être menée à bien, c’est également grâce au travail réalisé par
l’équipe de l’école doctorale, et en particulier à Marylin Galopin et Christian Queinnec qui
ont toujours su m’aider dans cette véritable quête administrative qu’est le doctorat. Je souhaite
d’ailleurs le meilleur à Bertrand Granado pour reprendre les rênes de l’EDITE.
Le pendant du travail de recherche est traditionnellement celui de l’enseignement ; dans
mon cas l’expérience pédagogique a été un peu courte, mais elle a été très agréable grâce aux
équipes enseignantes des cours de Programmation et Données Génériques (LI220, « l’UE des
chefs ») et de Techniques Évenementielles et Réactives (LI357, « l’UE Magnum »).
Ce projet a commencé chez Airbus Group Innovations (alors EADS Innovation Works),
alors que je n’étais qu’un étudiant ingénieur intéressé par la compilation. Merci à Wenceslas
Godard et Charles Hymans de m’avoir offert ce stage, puis de l’étendre à ce projet de thèse.
La suite a été plus quelque peu nébuleuse, et je remercie chaudement Axel Tillequin et toute
l’équipe SE/IT pour la confiance qu’il ont pu m’offrir en m’accueillant dans un cadre exceptionnel
pour un jeune chercheur. Merci une fois de plus à Sarah d’avoir accepté de reprendre
ce projet.
Mes remerciements vont également à une autre équipe qui m’a accueilli pendant ces années
: l’équipe APR, et en particulier sa directrice Michèle Soria. Les différentes thématiques
de recherche abordées dans le couloir on permis d’étendre mes horizons de doctorant. Je remercie
également le personnel administratif qui a facilité mes conditions de travail durant
toutes ces années.
Une partie de ce projet a également été financée par le projet CERCLES². Je remercie en
particulier Pascal Manoury pour l’accueil qu’il a pu m’apporter dans le laboratoire PPS de
Si vous êtes juste là pour l’Université Paris Diderot.
les blagues, ça commence
ici. Le bureau 26-00-325 a participé à sa manière à l’élaboration de ce document. La pause
café et sa pistonnade rituelle annoncée par Alberto ont permis de débattre jour après jour
des avantages de la programmation générique (et Ramzy), des foncteurs applicatifs, de la
meilleure manière d’écrire un interprète Basic en Rust ou de la stratégie qui nous permettrait
d’en venir à bout de ce niveau 5 de Jamestown, le tout bien sûr schémas, rébus et contrepè-
teries à l’appui.
Merci donc à Vivien (dont je n’écorcherai pas le nom — contrairement à d’autres), Philippe
(dont on sait où il se cache), Benjamin (pour son bon goût), Mathias (parce qu’il a la
classe), Guillaume (pour ses deals de café du 9-3, tu me remettras 1kg de rouge t’as vu ?), Aurélien
(le type-classieux de Rochechouart), Jérémie (λ-traître devant l’éternel) et tous ceux
qui sont passés par là un peu moins longtemps.iii
On raconte que la thèse c’est un ascenseur émotionnel. C’est cliché, mais pas complètement
faux. Pour partager les moments agréables et faciliter les moments de doutes, un grand
merci à mes amis qui ont toujours été là. Merci aussi à ma famille qui m’a toujours donné les
moyens de poursuivre mes projets. D’ailleurs sans mes premières lignes de code sur l’Amstrad
CPC 6128+ familial, j’aurais sûrement tourné différemment !
Enfin, merci à toi, Anaïs. Tu es certainement celle qui a vu le plus les coulisses de ce travail
de longue haleine, jouant à la fois le rôle de confidente et d’attachée de presse, en répondant
toujours « Bientôt ! » à la question « Alors Étienne, il soutient quand ? ». Aujourd’hui j’ai ma
réponse : ça se passe le 10 Juillet et vous êtes tous invités.
Spéciale dédicace à Tarpuy, Mato, Lady of the Pad, la dame des crêpes, aux thèmes de Guile
et de l’invité surprise ainsi qu’à toute l’équipe de Final Form Games.
Aucun λ-terme n’a été maltraité lors de la réalisation de ce document.TABLE DES MATIÈRES
Table des matières iv
1 Introduction 1
1.1 Rôle d’un système d’exploitation . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.2 Séparation entre espace noyau et espace utilisateur . . . . . . . . . . . . . . . . 3
1.3 Systèmes de types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Langages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.5 L’analyse statique dans l’industrie aéronautique . . . . . . . . . . . . . . . . . . 7
1.6 De l’avionique à l’informatique d’entreprise . . . . . . . . . . . . . . . . . . . . 9
1.7 Objectifs et contributions de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.8 Plan de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
I Méthodes formelles pour la sécurité 13
2 Systèmes d’exploitation 15
2.1 Architecture physique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.2 Tâches et niveaux de privilèges . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.3 Appels système . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4 Le Confused Deputy Problem . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3 Analyses statiques existantes 21
3.1 Taxonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.2 Méthodes syntaxiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3 Analyse de valeurs et interprétation abstraite . . . . . . . . . . . . . . . . . . . . 22
3.4 Typage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.5 Langages sûrs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.6 Logique de Hoare . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.7 Assistants de preuve . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Conclusion de la partie I 31
II Un langage pour l’analyse de code système : SAFESPEAK 33
4 Syntaxe et sémantique d’évaluation 35
4.1 Notations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
4.2 Syntaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.3 Mémoire et valeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.4 Interprète . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.5 Opérations sur les valeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.6 Opérations sur les états mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.7 Accesseurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
ivTABLE DES MATIÈRES v
4.8 Contextes d’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.9 Valeurs gauches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.10 Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.11 Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
4.12 Erreurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.13 Phrases et exécution d’un programme . . . . . . . . . . . . . . . . . . . . . . . . 58
4.14 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
5 Typage 63
5.1 Environnements et notations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.2 Expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
5.3 Instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.4 Fonctions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.5 Phrases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
5.6 Sûreté du typage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.7 Typage des valeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.8 Propriétés du typage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.9 Progrès et préservation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
6 Extensions de typage 81
6.1 Exemple préliminaire : les entiers utilisés comme bitmasks . . . . . . . . . . . 82
6.1.1 Modifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
6.1.2 Exemple : ! x & y . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.2 Analyse de provenance de pointeurs . . . . . . . . . . . . . . . . . . . . . . . . . 85
6.2.1 Extensions noyau pour SAFESPEAK . . . . . . . . . . . . . . . . . . . . . 86
6.2.2 Extensions sémantiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.2.3 Insuffisance des types simples . . . . . . . . . . . . . . . . . . . . . . . . 89
6.2.4 Extensions du système de types . . . . . . . . . . . . . . . . . . . . . . . 90
6.2.5 Sûreté du typage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Conclusion de la partie II 95
III Expérimentation 97
7 Implantation 99
7.1 NEWSPEAK et chaîne de compilation . . . . . . . . . . . . . . . . . . . . . . . . . 99
7.2 L’outil ptrtype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
7.3 Exemple . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
7.4 Performance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
8 Étude de cas : le noyau Linux 111
8.1 Spécificités du code noyau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
8.2 Appels système sous Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
8.3 Risques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
8.4 Premier exemple de bug : pilote Radeon KMS . . . . . . . . . . . . . . . . . . . . 113
8.5 Second exemple : ptrace sur architecture Blackfin . . . . . . . . . . . . . . . . 115
8.6 Procédure expérimentale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117vi TABLE DES MATIÈRES
Conclusion de la partie III 123
9 Conclusion 125
9.1 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
9.2 Différences avec C . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
9.3 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
A Module Radeon KMS 133
B Syntaxe et règles d’évaluation 137
B.1 Syntaxe des expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
B.2 Syntaxe des instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
B.3 Syntaxe des opérateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
B.4 Contextes d’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
B.5 Règles d’évaluation des erreurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
B.6 Règles d’évaluation des valeurs gauches et expressions . . . . . . . . . . . . . . 140
B.7 Règles d’évaluation des instructions, phrases et programmes . . . . . . . . . . 141
B.8 Règles d’évaluation des extensions noyau . . . . . . . . . . . . . . . . . . . . . . 142
C Règles de typage 143
C.1 Règles de typage des constantes et valeurs gauches . . . . . . . . . . . . . . . . 143
C.2 Règles de typage des opérateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
C.3 Règles de typage des expressions et instructions . . . . . . . . . . . . . . . . . . 145
C.4 Règles de typage des valeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
C.5 Règles de typage des extensions noyau . . . . . . . . . . . . . . . . . . . . . . . . 146
D Preuves 147
D.1 Composition de lentilles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
D.2 Progrès . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
D.3 Préservation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
D.4 Progrès pour les extensions noyau . . . . . . . . . . . . . . . . . . . . . . . . . . 156
D.5 Préservation pour les extensions noyau . . . . . . . . . . . . . . . . . . . . . . . 157
Liste des figures 159
Liste des définitions 161
Liste des théorèmes et lemmes 161
Références web 163
Bibliographie 165C H A P I T R E
1
INTRODUCTION
Communication, audiovisuel, transports, médecine : tous ces domaines se sont transformés
dans les dernières décennies, en particulier grâce à la révolution numérique. En effet
le plus petit appareil électrique contient maintenant des composants matériels programmables.
En 2014, on pense bien sûr aux téléphones portables dont la fonctionnalité et la complexité
les rapprochent des ordinateurs de bureau. Par exemple, le système d’exploitation
Android de Google est fondé sur le noyau Linux, destiné à la base aux micro-ordinateurs.
Le noyau d’un système d’exploitation est chargé de faire l’intermédiaire entre le maté-
riel (processeur, mémoire, périphériques, . . . ) et les applications exécutées sur celui-ci (par
exemple un navigateur web, une calculatrice ou un carnet d’adresses).
Il doit aussi garantir la sécurité de celles-ci : en tant qu’intermédiaire de confiance, le
noyau a un certain nombre de responsabilités et est le seul à avoir accès à certaines informations
sensibles. Il est capital de s’assurer qu’il est bien le seul à pouvoir y accéder. En particulier,
il faut pouvoir vérifier que les requêtes faites par l’utilisateur au noyau ne peuvent pas,
volontairement ou involontairement, détourner ce dernier et lui faire fuiter des informations
confidentielles.
Le problème est que, comme tous les logiciels, les noyaux de système d’exploitation sont
écrits par des humains qui ne sont pas parfaits. Les activités de relecture et de débogage ont
beau prendre la majeure partie du temps de développement, il est facile de laisser passer des
défauts de programmation.
Ces erreurs, ou bugs, peuvent avoir des conséquences dramatiques sur le plan matériel ou
humain. À titre d’exemple, un Airbus A320 embarque près de 10 millions de lignes de code :
il est capital de vérifier que celles-ci ne peuvent pas mettre en danger la sûreté des passagers.
Une technique efficace est de réaliser des tests, c’est-à-dire exécuter le programme sous
un environnement contrôlé. On peut alors détecter des comportements non désirés. Mais
même avec une grande quantité de tests il n’est pas possible de couvrir tous les cas d’utilisation.
Une autre approche est d’analyser le code source du programme avant de l’exécuter et
de refuser de lancer les programmes qui contiennent certaines constructions dangereuses.
C’est l’analyse statique de programmes.
Une des techniques d’analyse statique les plus répandues et les plus simples est le typage
statique, qui consiste à associer, à chaque morceau de programme, une étiquette décrivant
quel genre de valeur sera produite par son évaluation. Par exemple, si n est le nom d’une
variable entière, alors n +2 produira toujours une valeur entière. Cela permet de savoir si les
programmes manipuleront des données incompatibles entre elles.
12 CHAPITRE 1. INTRODUCTION
Pour en revenir aux noyaux de système d’exploitation, ceux-ci manipulent à la fois des
données sensibles et des données provenant du monde extérieur, pour lesquelles on n’a aucune
garantie. On veut pouvoir distinguer ces deux classes de données.
Plus précisément, un des points cruciaux pour garantir l’isolation d’un noyau de système
d’exploitation est de restreindre la manière dont sont traitées les informations provenant des
programmes utilisateur.
Le but de cette thèse est de montrer que le typage statique peut être utilisé pour détecter
et interdire ces manipulations dangereuses.
1.1 Rôle d’un système d’exploitation
Un ordinateur est constitué de nombreux composants matériels : microprocesseur, mé-
moire, et divers périphériques. Et au niveau de l’utilisateur, des dizaines de logiciels permettent
d’effectuer toutes sortes de calculs et de communications. Le système d’exploitation
permet de faire l’interface entre ces deux échelles.
Au cours de l’histoire des systèmes informatiques, la manière de les programmer a beaucoup
évolué. Au départ, les programmeurs avaient accès au matériel dans son intégralité :
toute la mémoire pouvait être accédée, toutes les instructions pouvaient être utilisées.
Néanmoins cela était un peu restrictif, puisque cela ne permet qu’à une personne d’interagir
avec le système. Dans la seconde moitié des années 1960, sont apparus les premiers
systèmes « à temps partagé », permettant à plusieurs utilisateurs de travailler en même temps.
Permettre l’exécution de plusieurs programmes en même temps est une idée importante,
mais elle n’est pas sans difficultés techniques : en effet les ressources de la machine doivent
être aussi partagées entre les utilisateurs et les programmes. Par exemple, plusieurs programmes
vont utiliser le processeur les uns à la suite des autres ; et chaque programme aura
à sa disposition une partie de la mémoire principale, ou du disque dur.
Si plusieurs programmes s’exécutent de manière concurrente sur le même matériel, il
faut s’assurer que l’un ne puisse pas écrire dans la mémoire de l’autre, et aussi que les deux
n’utilisent pas la carte réseau en même temps. Ce sont des rôles du système d’exploitation.
Ainsi, au lieu d’accéder directement au matériel via des instructions de bas niveau, les
programmes communiquent avec le noyau, qui centralise donc les appels au matériel, et abstrait
certaines opérations.
Par exemple, comparons ce qui se passe concrètement lors de la copie de données depuis
un cédérom ou une clef USB.
• Dans le cas du cédérom, il faut interroger le bus SATA, interroger le lecteur sur la pré-
sence d’un disque dans le lecteur, activer le moteur, calculer le numéro de trame des
données sur le disque, demander la lecture, puis déclencher une copie de la mémoire.
• Avec une clef, il faut interroger le bus USB, rechercher le bon numéro de périphérique,
le bon numéro de canal dans celui-ci, lui appliquer une commande de lecture au bon
numéro de bloc, puis copier la mémoire.
Ces deux opérations, bien qu’elles aient la même intention (copier de la mémoire depuis
un périphérique amovible), ne sont pas effectuées en extension de la même manière. C’est
pourquoi le système d’exploitation fournit les notions de fichier, lecteur, etc : le programmeur
n’a plus qu’à utiliser des commandes de haut niveau (« monter un lecteur », « ouvrir un
fichier », « lire dans un fichier ») et, selon le type de lecteur, le système d’exploitation effectuera
les actions appropriées.
En résumé, un système d’exploitation est l’intermédiaire entre le logiciel et le matériel,
et en particulier est responsable de la gestion de la mémoire, des périphériques et des pro-1.2. SÉPARATION ENTRE ESPACE NOYAU ET ESPACE UTILISATEUR 3
cessus. Les détails d’implantation ne sont pas présentés à l’utilisateur ; à la place, il manipule
des abstractions, comme la notion de fichier. Pour une explication détaillée du concept de
système d’exploitation ainsi que des cas d’étude, on pourra se référer à [Tan07].
1.2 Séparation entre espace noyau et espace utilisateur
Puisque le noyau est garant d’une utilisation sûre du matériel, il ne doit pas pouvoir être
manipulé directement par l’utilisateur ou les programmes exécutés. Ainsi, il est nécessaire de
mettre en place des protections entre les espaces noyau et utilisateur.
Au niveau matériel, on utilise la notion de niveaux de privilèges pour déterminer s’il est
possible d’exécuter une instruction.
D’une part, le processeur contient un niveau de privilège intrinsèque. D’autre part,
chaque zone mémoire contenant du code ou des données possède également un niveau de
privilège minimum nécessaire. L’exécution d’une instruction est alors possible si et seulement
si le niveau de privilège du processeur est supérieur à celui de l’instruction et des opé-
randes mémoires qui y sont présentes 1.
Par exemple, supposons qu’un programme utilisateur contienne l’instruction « déplacer
le contenu du registre EAX vers l’adresse mémoire a », où a fait partie de l’espace mémoire de
l’utilisateur. Alors aucune erreur de protection mémoire n’est déclenchée.
Ainsi, pour une instruction manipulant des données en mémoire, les accès possibles sont
décrits dans le tableau suivant. En cas d’impossibilité, une erreur se produit et l’exécution
s’arrête. Par exemple, l’avant-dernière ligne indique que, si un programme tente de lire une
variable du noyau, celui-ci sera arrêté par une exception.
Mode du processeur Privilège (code) Privilège (données) Accès possible
Noyau Noyau Noyau Oui
Noyau Noyau Utilisateur Oui
Noyau Utilisateur Noyau Oui
Noyau Utilisateur Utilisateur Oui
Utilisateur Noyau Noyau Non
Utilisateur Noyau Utilisateur Non
Utilisateur Utilisateur Noyau Non
Utilisateur Utilisateur Utilisateur Oui
En plus de cette vérification, certains types d’instructions sont explicitement réservés au
mode le plus privilégié : par exemple les lectures ou écritures sur des ports matériels, ou celles
qui permettent de définir les niveaux de privilèges des différentes zones mémoire.
Comme les programmes utilisateur ne peuvent pas accéder à ces instructions de bas niveau,
ils sont très limités dans ce qu’ils peuvent faire. En utilisant seulement les seules instructions
non privilégiées, on peut uniquement réaliser des calculs, sans réaliser d’opérations
visibles depuis l’extérieur du programme.
Pour utiliser le matériel ou accéder à des abstractions de haut niveau (comme créer un
nouveau processus), ils doivent donc passer par l’intermédiaire du noyau. La communication
entre le noyau et les programmes utilisateur est constituée du mécanisme des appels système.
1. Ici « supérieur » est synonyme de « plus privilégié ». Dans l’implantation d’Intel présentée dans le chapitre 2,
les niveaux sont numérotés de 0 à 3, où le niveau 0 est le plus privilégié.4 CHAPITRE 1. INTRODUCTION
Lors d’un appel système, une fonction du noyau est invoquée (en mode noyau) avec des
paramètres provenant de l’utilisateur. Il faut donc être particulièrement précautionneux dans
le traitement de ces données.
Par exemple, considérons un appel système de lecture depuis un disque : on passe au
noyau les arguments (d,o,n,a) où d est le nom du disque, o (pour offset) l’adresse sur le
disque où commencer la lecture, n le nombre d’octets à lire et a l’adresse en mémoire où
commencer à stocker les résultats.
Dans le cas d’utilisation prévu, le noyau va copier la mémoire lue dans a. Le processeur
est en mode noyau, en train d’exécuter une instruction du noyau manipulant des données
utilisateur. D’après le tableau de la page 3, aucune erreur ne se produit.
Mais même si ce cas ne produit pas d’erreur à l’exécution, il est tout de même codé de
manière incorrecte. En effet, si on passe à l’appel système une adresse a faisant partie de
l’espace noyau, que se passe-t-il ?
L’exécution est presque identique : au moment de la copie on est en mode noyau, en train
d’exécuter une instruction du noyau manipulant des données noyau. Encore une fois il n’y a
pas d’erreur à l’exécution.
On peut donc écrire n’importe où en mémoire. De même, une fonction d’écriture sur un
disque (et lisant en mémoire) permettrait de lire de la mémoire du noyau. À partir de ces
primitives, on peut accéder aux autres processus exécutés, ou détourner l’exécution vers du
code arbitraire. L’isolation est totalement brisée à cause de ces appels système.
La cause de ceci est qu’on a accédé à la mémoire en testant les privilèges du noyau au lieu
de tester les privilèges de celui qui a fait la requête (l’utilisateur). Ce problème est connu sous
le nom de confused deputy problem [Har88].
Pour implanter un appel système, il est donc nécessaire d’interdire le déréférencement
direct des pointeurs dont la valeur peut être contrôlée par l’utilisateur. Dans le cas du passage
par adresse d’un argument, il aurait fallu vérifier à l’exécution que celui-ci a bien les mêmes
privilèges que l’appelant.
Il est facile d’oublier d’ajouter cette vérification, puisque le cas « normal » fonctionne.
Avec ce genre d’exemple on voit comment les bugs peuvent arriver si fréquemment et pourquoi
il est aussi capital de les détecter avant l’exécution.
1.3 Systèmes de types
La plupart des langages de programmation incorporent la notion de type, dont un des
buts est d’empêcher de manipuler des données incompatibles entre elles.
En mémoire, les seules données qu’un ordinateur manipule sont des nombres. Selon les
opérations effectuées, ils seront interprétés comme des entiers, des adresses mémoire ou des
caractères. Pourtant il est clair que certaines opérations n’ont pas de sens : par exemple, multiplier
un nombre par une adresse ou déréférencer le résultat d’une division sont des comportements
qu’on voudrait pouvoir empêcher.
En un mot, le but du typage est de classifier les objets et de restreindre les opérations possibles
selon la classe d’un objet : en somme, « ne pas ajouter des pommes et des oranges ». Le
modèle qui permet cette classification est appelé système de types et est en général constitué
d’un ensemble de règles de typage, comme « un entier plus un entier égale un entier ».
Typage dynamique Dans ce cas, chaque valeur manipulée par le programme est décorée
d’une étiquette définissant comment interpréter la valeur en question. Les règles de typage
sont alors réalisées à l’exécution. Par exemple, l’opérateur « + » vérifie que ses deux opérandes
ont une étiquette « entier », et construit alors une valeur obtenue en faisant l’addition des1.3. SYSTÈMES DE TYPES 5
deux valeurs, avec une étiquette « entier ». C’est ce qui se passe par exemple dans le langage
Python [☞4].
Typage statique Dans ce cas on fait les vérifications à la compilation. Pour vérifier ceci, on
donne à chaque fonction un contrat comme « si deux entiers sont passés, et que la fonction
renvoie une valeur, alors cette valeur sera un entier ». Cet ensemble de contrats peut être
vérifié statiquement par le compilateur, à l’aide d’un système de types statique.
Par exemple, on peut dire que l’opérateur « + » a pour type (INT, INT) → INT. Cela veut dire
que, si on lui passe deux entiers (INT, INT), alors la valeur obtenue est également un entier.
A contrario, si autre chose qu’un entier est passé à cet opérateur, le programme ne compile
pas.
Typage fort ou faible Indépendamment du moment où est faite cette analyse, on peut avoir
plus ou moins de garanties sur les programmes sans erreurs de typage. En poussant à l’extrême,
les systèmes de types forts garantissent que les valeurs ont toujours le type attendu.
Avec du typage statique, cela permet d’éliminer totalement les tests de typage à l’exécution.
Mais souvent ce n’est pas le cas, car il peut y avoir des constructions au sein du langage qui
permettent de contourner le système de types, comme un opérateur de transtypage. On parle
alors de typage faible.
Polymorphisme Parfois, il est trop restrictif de donner un unique type à une fonction. Si
on considère une fonction ajoutant un élément à une liste, ou une autre triant un tableau en
place, leur type doit-il faire intervenir le type des éléments manipulés ?
En première approximation, on peut imaginer fournir une version du code par type de
données à manipuler. C’est la solution retenue par le langage C, ou par les premières versions
du langage Pascal, ce qui rendait très difficile l’écriture de bibliothèques [Ker81]. On parle
alors de monomorphisme.
Une autre manière de procéder est d’autoriser plusieurs fonctions à avoir le même nom,
mais avec des types d’arguments différents. Par exemple, on peut définir séparément l’addition
entre deux entiers, entre deux flottants, ou entre un entier et un flottant. Selon les informations
connues à la compilation, la bonne version sera choisie. C’est ainsi que fonctionnent
les opérateurs en C++. On parle de polymorphisme ad hoc, ou de surcharge.
Une autre technique est de déterminer la fonction appelée non pas par le type de ses
arguments, mais par l’objet sur lequel on l’appelle. Cela permet d’associer le comportement
aux données. On parle alors de polymorphisme objet. Dans ce cas, celui-ci repose sur le soustypage
: si A1 et A2 sont des sous-types de B, on peut utiliser des valeurs de type A1 ou A2 là
où une valeur de type B est attendue. Dans ce cas, la fonction correspondante sera appelée.
La dernière possibilité est le polymorphisme paramétrique, qui consiste à utiliser le
même code quel que soit le type des arguments. Dans ce cas, on utilise une seule fonction
pour traiter une liste d’entiers ou une liste de flottants, par exemple. Au lieu d’associer à
chaque fonction un type, dans certains cas on lui associe un type paramétré, instanciable
en un type concret. Dans le cas des fonctions de traitement de liste, l’idée est que lorsqu’on
ne touche pas aux éléments, alors le traitement est valable quel que soit leur type. Cette technique
a été décrite en premier dans [Mil78].
Pour un tour d’horizon de différents systèmes de types statiques, avec en particulier du
polymorphisme, on pourra se référer à [Pie02].6 CHAPITRE 1. INTRODUCTION
1.4 Langages
Le système Unix, développé à partir de 1969, a tout d’abord été développé en assembleur
sur un mini-ordinateur PDP-7, puis a été porté sur d’autres architectures matérielles. Pour
aider ce portage, il a été nécessaire de créer un « assembleur portable », le langage C [KR88,
ISO99]. Son but est de fournir des abstractions au dessus du langage d’assemblage. Les structures
de contrôle (if, while, for) permettent d’utiliser la programmation structurée, c’est-
à-dire en limitant l’utilisation de l’instruction goto. Les types de données sont également
abstraits de la machine : ainsi, int désigne un entier machine, indépendamment de sa taille
concrète. Son système de types, bien que statique (il peut y avoir des erreurs de typage à la
compilation), est assez rudimentaire : toutes les formes de transtypage sont acceptées, certaines
conversions sont insérées automatiquement par le compilateur, et la plupart des abstractions
fournies par le langage sont perméables. Le noyau Linux est écrit dans un dialecte
du langage C. Le noyau du système Mac OS X d’Apple est également un dérivé d’Unix, et est
donc aussi écrit dans ce langage.
Néanmoins ce langage n’est pas facile à analyser, car il est conçu pour être facilement écrit
par des programmeurs humains. Certaines constructions sont ambigües 2, et de nombreux
comportements sont implicites 3.
Si on veut analyser des programmes, il est plus pratique de travailler sur une représentation
intermédiaire plus simple afin d’avoir moins de traitements dupliqués. Dans ce cas on
ajoute une phase préliminaire à l’analyse, qui consiste à convertir le code à étudier vers cette
représentation. On présente quelques langages qui peuvent servir ce rôle :
Middle-ends
Les premiers candidats sont bien entendu les représentations intermédiaires utilisées
dans les compilateurs C. Elles ont l’avantage d’accepter, en plus du C standard, les diverses
extensions (GNU, Microsoft, Plan9) utilisées par la plupart des logiciels. En particulier, le
noyau Linux repose fortement sur les extensions GNU.
GCC utilise une représentation interne nommée GIMPLE [Mer03]. Il s’agit d’une structure
d’arbre écrite en C, reposant sur de nombreuses macros afin de cacher les détails d’implantation
interne pouvant varier entre deux versions. Cette représentation étant réputée difficile
à manipuler, le projet MELT [Sta11] permet de générer un plugin de compilateur écrit dans
un dialecte de Lisp.
LLVM [LA04] est un compilateur développé par la communauté open-source puis sponsorisé
par Apple. À la différence de GCC, sa base de code est écrite en C++. Il utilise une repré-
sentation intermédiaire qui peut être manipulée sous forme d’une structure de données C++,
d’un fichier de code-octet compact, ou textuelle.
Cmm est une représentation interne utilisée pour la génération de code lors de la compilation
d’OCaml [LDG+10, CMP03], et disponible dans les sources du compilateur (il s’agit
donc d’une structure de données OCaml). Ce langage a l’avantage d’être très restreint, mais
2. Selon qu’il existe un type nommé a, l’expression (a)-(b) sera interprétée comme le transtypage de -(b)
dans le type a, ou la soustraction des deux expressions (a) et (b).
3. Par exemple, une fonction acceptant un entier long peut être appelée avec un entier de taille plus petite.
Celui-ci sera alors converti implicitement.1.5. L’ANALYSE STATIQUE DANS L’INDUSTRIE AÉRONAUTIQUE 7
malheureusement il n’existe pas directement de traducteur permettant de compiler C vers
Cmm.
C- - [PJNO97] [☞1], dont le nom est inspiré du précédent, est un projet qui visait à unifier
les langages intermédiaires utilisés par les compilateurs. L’idée est que, si un front-end peut
émettre du C- - (sous forme de texte), il est possible d’obtenir du code machine efficace. Le
compilateur Haskell GHC, par exemple, utilise une représentation intermédiaire très similaire
à C- -.
Langages intermédiaires ad hoc
Comme le problème de construire une représentation intermédiaire adaptée à une analyse
statique n’est pas nouveau, plusieurs projets ont déjà essayé d’y apporter une solution.
Puisqu’ils sont développés en parallèle des compilateurs, le support des extensions est en
général moins important dans ces langages.
CIL [NMRW02] est une représentation en OCaml d’un programme C, développée depuis
2002. Grâce à un mécanisme de plugins, elle permet de prototyper rapidement des analyses
statiques de programmes C.
CompCert C, Clight et Cminor sont des langages intermédiaires utilisés dans Compcert,
un compilateur certifié pour C [BDL06, AB07]. C’est-à-dire que les transformations sémantiques
sont faites de manière prouvée. Ces langages intermédiaires sont utilisés pour les passes
de front-end et de middle-end.
1.5 L’analyse statique dans l’industrie aéronautique
En face du problème théorique et technique décrit dans la section 1.2, il faut mettre en
perspective les problématiques industrielles liées à celui-ci. Les travaux présentés ici ont en
effet été réalisés dans l’équipe de sécurité et sûreté logicielle d’EADS Innovation Works, dans
le cadre d’une convention industrielle de formation par la recherche (CIFRE).
Aujourd’hui, la réussite de nombreuses missions dépend de logiciels dont la taille est de
plus en plus grande. Ainsi, en cas de fautes dans ce genre de logiciel, on peut se retrouver
face à de grands impacts économiques, voire risquer des vies humaines. On comprend bien
que les phases de vérification et de certification sont au cœur du cycle de vie des logiciels
avioniques. A titre d’exemple, l’échec du premier vol d’Ariane 5 aurait certainement pu être
évité si le logiciel de contrôle de vol avait été vérifié plus efficacement [Lan96].
Plusieurs méthodes existent pour éliminer les risques de fautes. En fait, deux approches
duales sont nécessaires : les tests et les méthodes formelles. La première consiste à mettre
le logiciel dans des situations concrètes et à vérifier que la sortie correspond au résultat attendu
: c’est la technique des tests. Les tests « boîte noire » consistent à tester en ayant à disposition
uniquement les spécifications des modules à différentes échelles (par exemple : logiciel,
module, classe, méthode). Au contraire, les tests dits « boîte blanche » sont écrits en
ayant à disposition l’implémentation. Cela permet par exemple de s’assurer que chaque chemin
d’exécution est emprunté. Cette manière de procéder est similaire à la preuve par neuf
enseignée aux enfants : il est possible de prouver l’erreur, mais pas que le programme est
correct.8 CHAPITRE 1. INTRODUCTION
L’approche des méthodes formelles, au contraire, permet de s’assurer de l’absence d’erreurs
à l’exécution. Par exemple, l’analyse statique par interprétation abstraite permet d’étudier
les relations exposées entre les variables afin d’en déduire les ensembles de valeurs dans
lesquels elles évoluent. En s’assurant que ceux-ci sont « sûrs », on prouve l’absence d’erreurs
de manière automatisée.
L’interprétation abstraite repose sur l’idée suivante : au lieu de considérer que les variables
possèdent une valeur, on utilise un domaine abstrait qui permet de voir les variables
comme possédant un ensemble de valeurs possibles.
On dit que l’approche est sound si l’abstraction d’un ensemble de valeurs est un surensemble
de l’ensemble concret. Autrement dit, on réalise une surapproximation.
La zone « sûre » (correspondant aux exécutions sans erreurs) a une forme souvent assez
simple compte tenu des erreurs considérées : c’est un produit d’ensembles simples, comme
des intervalles. L’ensemble des comportements réels du programme est au contraire d’une
forme plus complexe et non calculable.
En calculant une approximation de ce dernier, de forme plus simple, on peut tester plus
facilement que les comportements sont dans la zone sûre : le fait que l’analyse soit sound,
c’est-à-dire que l’approximation ne manque aucun comportement, permet de prouver l’absence
d’erreurs.
La figure 1.1 résume cette approche : l’ensemble des valeurs dangereuses est représenté
par un ensemble hachuré, l’ensemble des valeurs sûres est en blanc, l’ensemble des comportements
réels du programme est noté par des points, et l’approximation en gris. Plusieurs cas
peuvent se produire. Dans la figure 1.1(a), on a prouvé à la compilation que le programme ne
pourra pas comporter d’erreurs à l’exécution. Dans la figure 1.1(b), l’approximation recouvre
les cas dangereux : on émet une alarme par manque de précision. Dans la figure 1.1(c) l’approximation
n’est pas sound (par construction, on évite ce cas). Enfin, dans la figure 1.1(d),
on émet une alarme à raison, car il existe des comportements erronés. Toute la difficulté est
donc de construire une surapproximation correcte mais conservant une précision suffisante.
Pour construire cette surapproximation, on peut employer divers outils. Par exemple, un
entier pourra être représenté par sa valeur minimale et sa valeur maximale (domaine abstrait
des intervalles), et un pointeur sur un tableau peut être représenté par un ensemble de variables
associé à un décalage (offset) par rapport au début de la zone mémoire (domaine des
pointeurs sur tableaux).
Le projet Penjili
Dans ce sens, des outils fondés sur l’interprétation abstraite ont été développés chez
EADS Innovation Works dans le cadre du projet Penjili [AH07].
Ces analyses statiques ne manipulent pas directement du code C, mais un langage intermédiaire
appelé NEWSPEAK [HL08]. Celui-ci est suffisamment expressif pour compiler la
plupart des programmes C, y compris de nombreuses extensions GNU utilisées dans le noyau
Linux (section 8.1), et des traducteurs automatiques depuis C et Ada existent (section 7.1).
Ensuite, ses instructions sont orthogonales et minimales : il existe en général une seule
manière de faire les choses. Par exemple, le flot de contrôle est restreint à la boucle infinie et
au saut en avant (« break » généralisé).
Enfin, lorsque certaines constructions sont ambigües, un choix est fait. Par exemple, l’évaluation
des arguments d’une fonction est faite dans un ordre précis, les tailles des types sont
indiquées à chaque déclaration de variable, etc.
Séparer le langage intermédiaire de la phase d’analyse permet de beaucoup simplifier
l’analyseur statique. D’une part, les constructions redondantes comme les différents types1.6. DE L’AVIONIQUE À L’INFORMATIQUE D’ENTREPRISE 9
(a) (b)
(c) (d)
FIGURE 1.1 : Surapproximation. L’ensemble des états erronés est hachuré. L’ensemble des
états effectifs du programme, noté par des points, est approximé par l’ensemble en gris.
de boucles ne sont traitées qu’une fois. D’autre part, lorsque le langage source est étendu
(en supportant une nouvelle extension de C par exemple), l’analyseur n’a pas besoin d’être
modifié.
Le langage NEWSPEAK, ainsi que les outils permettant de le manipuler, sont disponibles
sous license libre sur [☞3]. L’analyseur statique Penjili, reposant sur ces outils, a été utilisé
pour analyser des logiciels embarqués critiques de plusieurs millions de lignes de code. Ce
dernier n’est pour le moment pas open-source. Tous ces outils sont écrits dans le langage
OCaml [LDG+10, CMP03].
1.6 De l’avionique à l’informatique d’entreprise
Vérifier la sûreté des logiciels avioniques est critique, mais cela présente l’avantage que
ceux-ci sont développés avec ces difficultés à l’esprit. Il est plus simple de construire un système
sécurisé en connaissant toutes les contraintes d’abord, plutôt que de vérifier a posteriori
qu’un système existant peut répondre à ces contraintes de sûreté.
Néanmoins cette manière de concevoir des logiciels est très coûteuse. Pour des composants
qui sont moins critiques, il peut donc être intéressant de considérer des logiciels ou
bibliothèques existants, en particulier dans le monde de l’open-source.
Ces logiciels sont plus difficiles à analyser, car ils sont écrits sans contraintes particulières.
Non seulement toutes les constructions du langage sont autorisées, même celles qui sont
difficiles à traiter (transtypage, allocation dynamique, récursion, accès au système de fichiers,
etc), mais aussi des extensions non standards peuvent être utilisées.10 CHAPITRE 1. INTRODUCTION
Programmes non autosuffisants La grande majorité des programmes ne se suffisent pas
à eux-mêmes. En effet, ils interagissent presque toujours avec leur environnement ou appellent
des fonctions de bibliothèque.
Cela veut dire qu’un fichier en cours d’analyse peut contenir des appels à des fonctions
inconnues. Non seulement on n’a pas accès à leur code source, mais en plus on ne connaît
pas a priori leur spécification. Une solution peut être de prévoir un traitement particulier
pour celles-ci (par exemple en leur attribuant un type prédéfini).
Certaines interagissent directement avec le système d’exploitation, comme les fonctions
d’ouverture ou d’écriture dans un fichier. D’autres modifient totalement le mode d’exécution
du programme. Par exemple, pthread_create(&t, NULL, f, NULL) lance l’exécution
de f(NULL) tout en continuant l’exécution de la fonction en cours dans un fil d’exécution
concurrent.
Extensions du langage Par exemple, la figure 1.2 démontre l’influence de l’attribut packed
(supporté par GCC) sur la compilation d’une structure. Sans celui-ci, les champs sont alignés
de manière à faciliter les accès à la mémoire, par exemple en faisant démarrer les adresses
de chaque champ sur un multiple de 4 octets (en gras). Cela nécessite d’introduire des octets
de padding (en gris) qui ne sont pas utilisés. La taille totale de cette structure est donc de 12
octets.
struct s {
char a;
int b;
short c;
};
a b c
struct s {
char a;
int b;
short c;
} __attribute__((packed));
a b c
FIGURE 1.2 : Utilisation de l’attribut non-standard packed
Au contraire, l’utilisation de packed supprime totalement le padding et permet de diminuer
alors la taille de la structure à 7 octets seulement. Puisque b et c ne sont pas alignés, leur
accès sera fait de manière moins efficace.
De manière générale, les compilateurs permettent de personaliser finement le code émis
grâce à des extensions. Elles changent parfois le mode d’exécution des programmes d’une
manière subtile et pas toujours bien spécifiée ni documentée.
1.7 Objectifs et contributions de la thèse
Le but de ce travail est de définir et d’implanter des analyses statiques « légères » sur le
langage C (c’est-à-dire plus simples que les analyses de valeurs par interprétation abstraite)
pour détecter les utilisations dangereuses de pointeurs utilisateur. Nous proposons d’étendre
NEWSPEAK pour analyser des propriétés de sécurité par typage sur du code non avionique. En
effet, les types permettent de modéliser l’environnement d’exécution d’un programme (ici,
les paramètres d’appels système) avec un grain assez grand, alors qu’être plus fin est difficile
et nécessite de modéliser l’environnement.1.8. PLAN DE LA THÈSE 11
Nos contributions sont les suivantes :
• Une première étape est de définir un sous-ensemble sûr du langage source. En effet, le
langage C permet des conversions non sûres entre données, ce qui limite l’intérêt du
typage. On définit alors un langage impératif avec un modèle mémoire de plus haut
niveau, interdisant ces constructions : SAFESPEAK. Celui-ci est un modèle inspiré du
langage NEWSPEAK, déjà utilisé pour d’autres analyses statiques.
• Sur ce langage on définit une sémantique opérationnelle, qui permet de raisonner sur
les exécutions des programmes. On profite du caractère structuré des états mémoire
pour exprimer cette sémantique en terme de lentilles bidirectionnelles, permettant de
décrire la modification en profondeur de la mémoire.
• Au cœur de notre travail se trouve un système de types sûrs pour SAFESPEAK, ainsi que
deux extensions. La première permet d’illustrer l’approche typage en détectant les entiers
utilisés comme ensembles de bits, et la seconde permet de résoudre notre problème
de base, qui est la vérification des accès aux pointeurs utilisateur (présentés dans
la section 1.2).
• Notre formalisation est accompagnée d’un prototype, basé sur NEWSPEAK. Cela permet
d’appliquer les règles de typage précédemment définies sur des programmes écrits en
C, grâce aux outils existants développés par EADS. En particulier, cela permet d’analyser
des parties du noyau Linux. Ce prototype est disponible sous une license libre.
1.8 Plan de la thèse
Cette thèse est organisée en trois parties. La première décrit le contexte de ces travaux,
ainsi que les solutions existantes. La deuxième expose notre solution, SAFESPEAK, d’un point
de vue théorique. La troisième rend compte de la démarche expérimentale : comment la solution
a été implantée et en quoi elle est applicable en pratique.
Dans la partie I, on présente tout d’abord le fonctionnement général d’un système d’exploitation.
On y introduit aussi les problèmes de manipulation de pointeurs contrôlés par
l’utilisateur. Ceux-ci sont centraux puisqu’on désire les restreindre. On fait ensuite un tour
d’horizon des techniques existantes permettant de traiter ce problème par analyse statique
de code source.
Dans la partie II, on décrit notre solution : le langage SAFESPEAK. Sa syntaxe y est d’abord
décrite, puis sa sémantique ainsi qu’un système de types statiques. À ce niveau on a un bon
support pour décrire des analyses statiques sur un langage impératif. On propose alors deux
extensions du système de types. La première consiste à bien typer les entiers utilisés comme
bitmasks. La seconde capture les problèmes d’adressage mémoire présents dans les systèmes
d’exploitation, décrits dans la section 1.2. Pour ce faire, on ajoute des pointeurs contrôlés par
l’utilisateur à la sémantique et au système de types. À chaque étape, c’est-à-dire avant et après
ces ajouts, on établit une propriété de sûreté de typage reliant la sémantique d’exécution aux
types statiques.
Dans la partie III, on documente la démarche expérimentale associée à ces travaux. L’implantation
du système de types sur le langage NEWSPEAK est d’abord décrite, reposant sur
l’algorithme W de Damas et Milner. La manière de compiler depuis du code C est également
présentée. Ensuite, on applique cette implantation à deux cas d’étude concrets dans le noyau12 CHAPITRE 1. INTRODUCTION
Linux. L’un est un bug ayant touché un pilote de carte graphique, et l’autre un défaut dans
l’implantation de la fonction ptrace. Dans chaque cas, un pointeur dont la valeur est contrô-
lée par l’utilisateur crée un problème de sécurité, car un utilisateur malveillant peut lire ou
écrire dans l’espace mémoire réservé au noyau. En lançant notre prototype, l’analyse de la
version non corrigée lève une erreur alors que, dans la version corrigée, un type correct est
inféré. On montre ainsi que le système de types capture précisément ce genre d’erreur de
programmation.
On conclut enfin en décrivant les possibilités d’extensions autant sur le point théorique
qu’expérimental.Première partie
Méthodes formelles pour la sécurité
Après avoir décrit le contexte général de ces travaux, nous décrivons leurs enjeux.
Le chapitre 2 explore plus en détail le fonctionnement d’un système d’exploitation,
y compris la séparation du code en plusieurs niveaux de privilèges. L’architecture
Intel 32 bits est prise comme support. En particulier, le mécanisme des appels
système est décrit et on montre qu’une implantation naïve de la communication
entre espaces utilisateur et noyau casse toute isolation.
Le chapitre 3 consiste en un tour d’horizon des techniques existantes en analyses
de programmes. Ces analyses se centrent autour des problèmes liés à la vé-
rification de code système ou embarqué, y compris le problème de manipulation
mémoire évoqué dans le chapitre 2.
On conclut en introduisant notre solution : SAFESPEAK, un langage permettant
de typer des programmes impératifs, plus précisément en ajoutant des types pointeurs
abstraits.
13C H A P I T R E
2
SYSTÈMES D’EXPLOITATION
Le système d’exploitation est le programme qui permet à un système informatique d’exé-
cuter d’autres programmes. Son rôle est donc capital et ses responsabilités, multiples. Dans
ce chapitre, nous allons voir à quoi il sert, et comment il peut être implanté. Pour ce faire,
nous présentons ici de quoi est constitué un système Intel 32 bits et ce dont on se sert pour y
implanter un système d’exploitation.
2.1 Architecture physique
Un système informatique est principalement constitué d’un processeur (ou CPU pour
Central Processing Unit), de mémoire principale (ou RAM pour Random Access Memory) et
de divers périphériques.
Le processeur est constitué de plusieurs registres internes qui permettent d’encoder l’état
dans lequel il se trouve : quelle est l’instruction courante (registre EIP), quelle est la hauteur
de la pile système (registre ESP), etc. Son fonctionnement peut être vu de la manière la plus
simple qui soit comme la suite d’opérations :
• charger depuis la mémoire la prochaine instruction ;
• (optionnel) charger depuis la mémoire les données référencées par l’instruction ;
• effectuer l’instruction ;
• (optionnel) stocker en la mémoire les données modifiées ;
• continuer avec l’instruction suivante.
Les instructions sont constituées d’un opcode (mnémonique indiquant quelle opération
faire) et d’un ensemble d’opérandes. La signification des opérandes dépend de l’opcode,
mais en général ils permettent de désigner les sources et la destination (on emploiera ici
la syntaxe AT&T, celle que comprend l’assembleur GNU). Les opérandes peuvent avoir plusieurs
formes : une valeur immédiate ($4), un nom de registre (%eax) ou une référence à la
mémoire (directement : addr ou indirectement : (%ecx) 1 ). On décrit les opcodes les plus
utilisés, permettant de compiler un cœur de langage impératif :
• mov src, dst copie le contenu de src dans dst ;
• add src, dst calcule la somme des contenus de src et dst et place ce résultat dans
dst ;
1. Cela consiste à interpréter le contenu du regitre ECX comme une adresse mémoire.
1516 CHAPITRE 2. SYSTÈMES D’EXPLOITATION
• push src place src sur la pile, c’est-à-dire que cette instruction enlève au pointeur de
pile ESP la taille de src, puis place src à l’adresse mémoire de la nouvelle valeur ESP ;
• pop src réalise l’opération inverse : elle charge le contenu de la mémoire à l’adresse
ESP dans src puis incrémente ESP de la taille correspondante ;
• jmp addr saute à l’adresse addr : c’est l’équivalent de mov addr, %eip ;
• call addr sert aux appels de fonction : cela revient à push %eip puis jmp addr ;
• ret sert à revenir d’une fonction : c’est l’équivalent de pop %eip.
Certaines de ces instructions font référence à la pile par le biais du registre ESP. Cette
zone mémoire n’est pas gérée de manière particulière. Elle permet de gérer la pile des appels
de fonction en cours grâce à la manière dont jmp et ret fonctionnent. Elle sert aussi à stocker
les variables locales des fonctions.
À l’aide de ces quelques instructions on peut implanter des algorithmes impératifs. Mais
pour faire quelque chose de visible, comme afficher à l’écran ou envoyer un paquet sur le
réseau, cela ne suffit pas : il faut parler au reste du matériel.
Pour ceci, il y a deux techniques principales. D’une part, certains périphériques sont
dits memory-mapped : ils sont associés à un espace mémoire particulier, qui ne permet pas
de stocker des informations mais de lire ou d’écrire des données dans le périphérique. Par
exemple, écrire à l’adresse 0xB8000 permet d’écrire des caractères à l’écran. L’autre système
principal est l’utilisation des ports d’entrée/sortie. Cela correspond à des instructions spé-
ciales in %ax, port et out port, %ax où port est un numéro qui correspond à un périphérique
particulier. Par exemple, en écrivant dans le port 0x60, on peut contrôler l’état des
indicateurs lumineux du clavier PS/2.
2.2 Tâches et niveaux de privilèges
Alternance des tâches
Sans mécanisme particulier, le processeur exécuterait uniquement une suite d’instructions
à la fois. Pour lui permettre d’exécuter plusieurs tâches, un système de partage du temps
existe.
À des intervalles de temps réguliers, le système est programmé pour recevoir une interruption.
C’est une condition exceptionnelle (au même titre qu’une division par zéro) qui fait
sauter automatiquement le processeur dans une routine de traitement d’interruption. À cet
endroit le code peut sauvegarder les registres et restaurer un autre ensemble de registres, ce
qui permet d’exécuter plusieurs tâches de manière entrelacée. Si l’alternance est assez rapide,
cela peut donner l’illusion que les programmes s’exécutent en même temps. Comme
l’interruption peut survenir à tout moment, on parle de multitâche préemptif.
En plus de cet ordonnancement de processus, l’architecture Intel permet d’affecter des
niveaux de privilège à ces tâches, en restreignant le type d’instructions exécutables, ou en
donnant un accès limité à la mémoire aux tâches de niveaux moins élevés.
Le matériel permet 4 niveaux de privilèges (nommés aussi rings) : le ring 0 est le plus
privilégié, le ring 3, le moins privilégié. Dans l’exemple précédent, on pourrait isoler l’ordonnanceur
de processus en le faisant s’exécuter en ring 0 alors que les autres tâches seraient en
ring 3.2.3. APPELS SYSTÈME 17
Mémoire virtuelle
À partir du moment où plusieurs processus s’exécutent de manière concurrente, un problème
d’isolation se pose : si un processus peut lire dans la mémoire d’un autre, des informations
peuvent fuiter ; et s’il peut y écrire, il peut en détourner l’exécution.
Le mécanisme de mémoire virtuelle permet de donner à deux tâches une vue différente
de la mémoire : c’est-à-dire que vue de tâches différentes, une adresse contiendra une valeur
différente (figure 2.1).
Processus 1 Mémoire Processus 2
FIGURE 2.1 : Mécanisme de mémoire virtuelle.
Ce mécanisme est contrôlé par la valeur du registre CR3 : les 10 premiers bits d’une
adresse virtuelle sont un index dans le répertoire de pages qui commence à l’adresse contenue
dans CR3. À cet index, se trouve l’adresse d’une table de pages. Les 10 bits suivants de
l’adresse sont un index dans cette page, donnant l’adresse d’une page de 4 kio (figure 2.2).
Plus de détails sur l’utilisation de ce mécanisme seront donnés dans la section 8.2.
31 2122 1112 0
Répertoire
de pages
Table de
pages
Page de
4 kio CR3
FIGURE 2.2 : Implantation de la mémoire virtuelle
2.3 Appels système
Avec une telle isolation, tout le code qui est exécuté en ring 3 a une expressivité limitée.
Il ne peut pas contenir d’instructions privilégiées comme in ou out, ni faire référence à des
périphériques mappés en mémoire. C’est en effet au noyau d’accéder au matériel, et pas au
code utilisateur.
Il est donc nécessaire d’appeler une routine du noyau depuis le code utilisateur. C’est le
but des appels système. Cela consiste à coupler une fonction du ring 3 à une fonction du
ring 0 : en appelant la fonction non privilégiée, le flot d’exécution se retrouve dans le noyau
avec les bons privilèges.18 CHAPITRE 2. SYSTÈMES D’EXPLOITATION
Bien sûr, il n’est pas possible de faire directement un call puisque cela consisterait à faire
un saut vers une zone plus privilégiée. Il y a plusieurs manières d’implanter ce mécanisme.
Nous décrivons ici la technique historique à l’aide d’interruptions.
Le processeur peut répondre à des interruptions, qui sont des événements extérieurs.
Cela permet d’écrire du code asynchrone. Par exemple, une fois qu’un long transfert mémoire
est terminé, une interruption est reçue. D’autres interruptions dites logicielles peuvent arriver
lorsqu’une erreur se produit. Par exemple, diviser par zéro provoque l’interruption 0, et
tenter d’exécuter une instruction privilégiée provoque l’interruption 14. On peut aussi provoquer
manuellement une interruption par une instruction int dédiée.
Une table globale définit, pour chaque numéro d’interruption, quelle est la routine à appeler
pour la traiter, avec quel niveau de privilège, ainsi que le niveau de privilège requis pour
pouvoir déclencher celle-ci avec l’instruction int.
Il est donc possible de créer une interruption purement logicielle (on utilise en général
le numéro 128, soit 0x80), déclenchable en ring 3 et traitée en ring 0. Les registres sont pré-
servés, donc on peut les utiliser pour passer un numéro d’appel système (par exemple 3 pour
read() et 5 pour open()) et leurs arguments.
2.4 Le Confused Deputy Problem
On a vu que les appels système permettent aux programmes utilisateur d’accéder aux
services du noyau. Ils forment donc une interface particulièrement sensible aux problèmes
de sécurité.
Comme pour toutes les interfaces, on peut être plus ou moins fin. D’un côté, une interface
pas assez fine serait trop restrictive et ne permettrait pas d’implanter tout type de logiciel. De
l’autre, une interface trop laxiste (« écrire dans tel registre matériel ») empêche toute isolation.
Il faut donc trouver la bonne granularité.
Nous allons présenter ici une difficulté liée à la manipulation de mémoire au sein de certains
types d’appels système.
Il y a deux grands types d’appels système. D’une part on trouve ceux qui renvoient un
simple entier, comme getpid qui renvoie le numéro du processus appelant.
pid_t pid = getpid();
printf("%d\n", pid);
Ici, pas de difficulté particulière : la communication entre le ring 0 et le ring 3 est faite
uniquement à travers les registres, comme décrit dans la section 8.2.
Mais la plupart des appels système communiquent de l’information de manière indirecte,
à travers un pointeur. L’appellant alloue une zone mémoire dans son espace d’adressage et
passe un pointeur à l’appel système. Ce mécanisme est utilisé par exemple par la fonction
gettimeofday (figure 2.3).
Considérons une implantation naïve de cet appel système qui écrirait directement
à l’adresse pointée. Si le pointeur fourni est dans l’espace d’adressage du processus, on est
dans le cas d’utilisation normal et l’écriture est donc possible.
Si l’utilisateur passe un pointeur dont la valeur correspond à la mémoire réservée au
noyau, que se passe-t-il ? Comme le déréférencement est fait dans le code du noyau, il est
également fait en ring 0, et va pouvoir être réalisé sans erreur : l’écriture se fait et potentiellement
une structure importante du noyau est écrasée.
Un utilisateur malveillant peut donc utiliser cet appel système pour écrire à n’importe
quelle adresse dans l’espace d’adressage du noyau. Ce problème vient du fait que l’appel2.4. LE CONFUSED DEPUTY PROBLEM 19
struct timeval tv;
struct timezone tz;
int z = gettimeofday(&tv, &tz);
if (z == 0) {
printf( "tv.tv_sec = %ld\ntv.tv_usec = %ld\n"
"tz.tz_minuteswest = %d\ntz.tz_dsttime = %d\n",
tv.tv_sec, tv.tv_usec,
tz.tz_minuteswest, tz.tz_dsttime
);
}
FIGURE 2.3 : Appel de gettimeofday
système utilise les privilèges du noyau au lieu de celui qui contrôle la valeur des paramètres
sensibles. Cela s’appelle le Confused Deputy Problem[Har88].
La bonne solution est de tester dynamiquement la valeur du pointeur : s’il pointe en espace
noyau, il faut indiquer une erreur plutôt que d’écrire. Sinon, il peut toujours y avoir une
erreur, mais au moins le noyau est protégé.
Dans le noyau, un ensemble de fonctions permet d’effectuer des copies sûres. La fonction
access_ok réalise le test décrit précédemment. Les fonctions copy_from_user et copy_to_
user réalisent une copie de la mémoire après avoir fait ce test. Ainsi, l’implantation correcte
de l’appel système gettimeofday fait appel à celle-ci (figure 2.4).
SYSCALL_DEFINE2(gettimeofday, struct timeval __user *, tv,
struct timezone __user *, tz)
{
if (likely(tv != NULL)) {
struct timeval ktv;
do_gettimeofday(&ktv);
if (copy_to_user(tv, &ktv, sizeof(ktv)))
return -EFAULT;
}
if (unlikely(tz != NULL)) {
if (copy_to_user(tz, &sys_tz, sizeof(sys_tz)))
return -EFAULT;
}
return 0;
}
FIGURE 2.4 : Implantation de l’appel système gettimeofday
Pour préserver la sécurité du noyau, il est donc nécessaire de vérifier la valeur de tous
les pointeurs dont la valeur est contrôlée par l’utilisateur. Cette conclusion est assez contraignante,
puisqu’il existe de nombreux endroits dans le noyau où des données proviennent
de l’utilisateur. Il est donc raisonnable de vouloir vérifier automatiquement et statiquement
l’absence de tels défauts.C H A P I T R E
3
ANALYSES STATIQUES EXISTANTES
Dans ce chapitre, nous présentons un tour d’horizon des techniques existantes permettant
d’analyser des programmes. En particulier, on s’intéresse à la propriété d’isolation dé-
crite dans le chapitre 2, mais on ne se limite pas à celle-ci : il est également intéressant de
considérer des analyses développées pour d’autres propriétés (comme par exemple s’assurer
de l’absence d’erreurs à l’exécution), celles-ci pouvant potentiellement s’adapter.
L’analyse statique de programmes est un sujet de recherche actif depuis l’apparition de
l’informatique en tant que science. On commence par en présenter une classification, puis
on montrera des exemples pertinents permettant d’analyser du code système ou embarqué.
3.1 Taxonomie
Techniques statiques et dynamiques L’analyse peut être faite au moment de la compilation
ou au moment de l’exécution. En général on peut obtenir des informations plus précises
de manière dynamique, mais cela ne prend en compte que les parties du programme qui seront
vraiment exécutées. Un autre problème des techniques dynamiques est qu’il est souvent
nécessaire d’instrumenter l’environnement d’exécution (ce qui — dans le cas où cela est possible
— peut se traduire par un impact en performances). L’approche statique, en revanche,
nécessite de construire à l’arrêt une carte mentale du programme, ce qui n’est pas toujours
possible dans certains langages.
Les techniques dynamiques sont néanmoins les plus répandues, puisqu’elles sont plus
simples à mettre en œuvre et permettent de trouver des erreurs pendant le processus de dé-
veloppement. De plus, on peut considérer qu’un programme avec une forte couverture par
les tests a de grandes chances d’être correct pour toutes les entrées. Par exemple, dans l’avionique
civile, le processus de développement demande d’être très rigoureux pour les tests
fonctionnels et structurels afin de détecter le code ou les branchements non atteints.
Mais pour s’assurer de la correction d’un programme, on ne peut pas s’appuyer uniquement
sur les tests — ou de manière générale sur des analyses dynamiques — car il est souvent
impossible d’étudier l’ensemble complet de tous les comportements possibles. Par exemple,
si un bug se présente lors d’une interaction entre deux composants qui n’a pas été testée, il
passera inaperçu durant la phase de tests unitaires. Pour cette raison, la plupart des analyses
présentées ici sont statiques.
Cohérence et complétude Le but d’une analyse statique est de catégoriser les programmes
selon s’ils satisfont ou non un ensemble de propriétés fixées à l’avance. Malheureusement,
2122 CHAPITRE 3. ANALYSES STATIQUES EXISTANTES
cela n’est que rarement possible, car l’ensemble des valeurs possibles lors de l’exécution d’un
programme quelconque n’est pas un ensemble calculable (théorème de Rice [Ric53]). Autrement
dit, il ne peut exister une procédure de décision prenant un programme et le déclarant
correct ou incorrect. Un résultat similaire est qu’on ne peut pas écrire une procédure qui dé-
termine si un programme arbitraire boucle indéfiniment ou pas (le problème de l’arrêt).
Il n’est donc pas possible d’écrire un analyseur statique parfait, détectant exactement les
problèmes. Toute technique statique va donc de se retrouver dans au moins un des cas suivants
:
• un programme valide (pour une propriété donnée) est rejeté : on parle de faux positif.
• un programme invalide n’est pas détecté : on parle de faux négatif.
En général, et dans notre cas, on préfère s’assurer que les programmes acceptés possèdent
la propriété recherchée, quitte à en rejeter certains. C’est l’approche que nous retiendrons.
Tolérer les faux négatifs n’est cependant pas toujours une mauvaise idée. Par exemple,
si le but est de trouver des constructions dangereuses dans les programmes, on peut signaler
certains cas qui empiriquement valent d’être vérifiés manuellement.
Par ailleurs la plupart des techniques ne concernent que les programmes qui terminent.
On étudie donc la correction, ou les propriétés des termes convergents. Prouver automatiquement
que l’exécution ne boucle pas est une propriété toute autre qui n’est pas ici considérée.
3.2 Méthodes syntaxiques
L’analyse la plus simple consiste à traiter un programme comme du texte, et à y rechercher
des motifs dangereux. Ainsi, utiliser des outils comme grep permet parfois de trouver
un grand nombre de vulnérabilités [Spe05].
On peut continuer cette approche en recherchant des motifs mais en étant sensible à la
syntaxe et au flot de contrôle du programme. Cette notion de semantic grep est présente dans
l’outil Coccinelle [BDH+09, PTS+11] : on peut définir des patches sémantiques pour détecter
ou modifier des constructions particulières.
Ces techniques sont utiles parce qu’elles permettent de plonger rapidement dans le code,
en identifiant par exemple des appels à des fonctions dangereuses. En revanche, cela n’est
possible que lorsque les propriétés que l’on recherche sont plutôt locales. Elles offrent également
peu de garantie puisqu’elles ne prennent pas en compte la sémantique d’exécution du
langage : il faudra en général vérifier manuellement la sortie de ces analyses.
3.3 Analyse de valeurs et interprétation abstraite
L’interprétation abstraite est une technique d’analyse générique qui permet de simuler
statiquement tous les comportements d’un programme [CC77, CC92]. Un exemple d’application
est de calculer les bornes de variation des variables pour s’assurer qu’aucun débordement
de tableau n’est possible [AH07].
L’idée est d’associer à chaque ensemble concret de valeurs une représentation abstraite.
Sur celle-ci, on peut définir des opérations indépendantes de la valeur exacte des données,
mais préservant l’abstraction (figure 3.1). Par exemple, les règles comme « − » × « − » = « + »
définissent le domaine abstrait des signes arithmétiques. Les domaines ont une structure
de treillis, c’est-à-dire qu’ils possèdent les notions d’ordre partiel et d’union de valeurs. En
calculant les extrêmes limites d’une variable, on obtient le domaine des intervalles.3.3. ANALYSE DE VALEURS ET INTERPRÉTATION ABSTRAITE 23
�
− 0 +
⊥
γ (−) = R−
γ (0) = {0}
γ (+) = R+
FIGURE 3.1 : Domaine des signes
De tels domaines ne capturent aucune relation entre variables. Ils sont dits non relationnels.
Lorsque plusieurs variables sont analysées en même temps, utiliser de tels domaines
consiste à considérer un produit cartésien d’ensembles abstraits (figure 3.2(a)).
Des domaines abstraits plus précis permettent de retenir celles-ci. Pour ce faire, il faut
modéliser l’ensemble des valeurs des variables comme un tout. Parmi les domaines relationnels
courants on peut citer : le domaine des polyèdres [CH78], permettant de retenir tous
les invariants affines entre variables (figure 3.2(b)) ; le domaine des zones [Min01a], permettant
de représenter des relations affines de la forme vi − v j ≤ c (figure 3.2(c)) ; ou encore le
domaine des octogones [Min01b] qui est un compromis entre les polyèdres et les zones. Il
permet de représenter les relations ±vi ± v j ≤ c (figure 3.2(d)).
(a) Domaine non relationnel (b) Domaine des polyèdres
(c) Domaine des zones (d) Domaine des octogones
FIGURE 3.2 : Quelques domaines abstraits
En plus des domaines numériques, il est nécessaire d’employer des domaines spécialisés
dans la modélisation de la mémoire. Cela est nécessaire pour pouvoir prendre en compte
les pointeurs. Par exemple, on peut représenter un pointeur par un ensemble de variables
possiblement pointées et une valeur abstraite représentant le décalage (offset) du pointeur
par rapport au début de la zone mémoire. Cette valeur peut elle-même être abstraite par un
domaine numérique.
Au delà des domaines eux-mêmes, l’analyse se fait sous forme d’un calcul de point fixe.24 CHAPITRE 3. ANALYSES STATIQUES EXISTANTES
La manière la plus simple est d’utiliser un algorithme de liste de travail, décrit par exemple
dans [SRH96]. Les raffinements en revanche sont nombreux.
Dès [CC77] il est remarqué que la terminaison de l’analyse n’est assurée que si le treillis
des valeurs abstraites est de hauteur finie, ou qu’un opérateur d’élargissement (widening) ∇
est employé. L’idée est qu’une fois qu’on a calculé quelques termes d’une suite croissante,
on peut réaliser une projection de celle-ci. Par exemple, dans le domaine des intervalles,
[0; 2] ∇ [0; 3] = [0;+∞[. On atteint alors un point fixe mais qui est plus grand que celui qu’on
aurait obtenu sans cette accélération : on perd en précision. Pour en gagner, on peut redescendre
sur le treillis des points fixes avec une suite d’itérations décroissantes [Gra92, GGTZ07].
En termes d’ingéniérie logicielle, implanter un analyseur statique est un défi en soi. En
plus des domaines abstraits, d’un itérateur, il faut traduire le code source à analyser dans
un langage intermédiaire, et traduire les résultats de l’analyse en un ensemble d’alarmes à
présenter à l’utilisateur.
Cette technique est très puissante : si un interprète abstrait sound (réalisant une surapproximation,
c’est-à-dire ne manquant aucun programme incorrect) analyse un programme
et ne renvoie pas d’erreur, alors on a prouvé que le programme est correct (par rapport aux
propriétés que vérifient les domaines abstraits). Cela a été appliqué avec succès avec les analyseurs
Astrée [Mau04, CCF+05, CCF+09] chez Airbus ou CGS [VB04] à la NASA par exemple.
Cependant, ces analyses sont difficiles à mettre en œuvre. Avec des domaines abstraits
classiques comme ceux présentés ci-dessus, les premières analyses peuvent remonter un
nombre prohibitif de fausses alarmes. Pour « aider » l’analyse, il faut soit annoter le code soit
développer des domaines abstraits ad hoc au programme à analyser.
Il existe également des analyseurs statiques combinant l’interprétation abstraite avec
d’autres techniques et qui ne sont pas sound, c’est-à-dire qu’ils peuvent manquer des comportements
erronés. Leur approche est plus d’aider le programmeur à détecter certains types
de bugs pendant le développement. On peut citer l’exemple de Coverity [BBC+10], qui publie
régulièrement des rapports de qualité sur certains logiciels open-source. Néanmoins, de part
leur aspect non sound, les analyses réalisées ne peuvent pas être assimilées à de la vérification
formelle en tant que telle.
Enfin, l’interprétation abstraite n’est pas la seule technique pour analyser finement les
valeurs d’un programme. Par exemple, le système Saturn [ABD+07], conçu pour analyser
du code système écrit en C, utilise des clauses logiques et un solveur SAT pour manipuler
des invariants sur la mémoire. En particulier il traite le problème des pointeurs utilisateur
en utilisant une analyse de forme « pointe-sur » [BA08]. Un autre exemple est le model checking
[CE81], qui consiste à explorer l’ensemble des états que peut atteindre un système. Ce
graphe est potentiellement infini ; donc il peut être impossible de l’explorer pour détecter
les cas d’erreur. Plusieurs techniques permettent de résoudre ce problème. Le bounded model
checking [BCC+03] explore uniquement les états atteints en moins de k étapes. Cela peut
permettre de trouver des cas d’erreur, mais pas de montrer que le système est correct (seulement
qu’il l’est pour les exécutions de moins de k étapes). Il est aussi possible de réduire le
nombre d’états de l’automate [Pel93]. Comme l’interprétation abstraite, ces analyses sont très
précises, au détriment d’un temps de calcul important à cause de l’explosion combinatoire.
3.4 Typage
Le typage, introduit dans la section 1.3, peut aussi être utilisé pour la vérification de programmes.
On peut le voir comme une manière de catégoriser les types de données manipulés
par la machine, mais également, à plus haut niveau, comme une manière d’articuler les différents
composants d’un programme. Mais on peut aussi programmer avec les types, c’est-3.4. TYPAGE 25
à-dire utiliser le compilateur (dans le cas statique) ou l’environnement d’exécution (dans le
cas dynamique) pour vérifier des propriétés écrites par le programmeur.
Systèmes ad hoc Les systèmes de types les plus simples expriment des contrats esssentiellement
liés à la sûreté d’exécution, pour ne pas utiliser des valeurs de types incompatibles
entre eux. Mais il est possible d’étendre le langage avec des annotations plus riches,
par exemple en vérifiant statiquement que des listes ne sont pas vides [KcS07] ou, dans le
domaine de la sécurité, d’empêcher des fuites d’information [LZ06].
Qualificateurs de types Dans le cas particulier des vulnérabilités liées à une mauvaise utilisation
de la mémoire, les développeurs du noyau Linux ont ajouté un système d’annotations
au code source. Un pointeur peut être décoré d’une annotation __kernel ou __user selon
s’il est sûr ou pas. Celles-ci sont ignorées par le compilateur, mais un outil d’analyse statique
ad-hoc nommé Sparse [☞6] peut être utilisé pour détecter les cas les plus simples d’erreurs. Il
demande aussi au programmeur d’ajouter de nombreuses annotations dans le programme.
Cette solution se rapproche de la solution décrite dans ce manuscrit. Ce système d’annotations
sur les types a été formalisé sous le nom de qualificateurs de types [FJKA06] : chaque
type peut être décoré d’un ensemble de qualificateurs (à la manière de const), et des règles
de typage permettent d’établir des propriétés sur le programme.
Plus précisément, les jugements de typage de la forme Γ � e : t sont remplacés par des
jugements de typage qualifiés Γ � e : t q. Les qualificateurs q permettent d’exprimer plusieurs
jugements. Par exemple, on peut étudier le fait qu’une variable soit constante ou pas,
que sa valeur soit connue à la compilation, ou encore qu’elle puisse être nulle ou pas. La spé-
cificité de ce système est que les qualificateurs sont ordonnés, du plus spécifique au moins
spécifique, et que l’on forme alors un treillis à partir de ces informations. Partant des deux
caractéristiques précédentes, on forme le treillis de la figure 3.3. Le qualificateur const dé-
signe les données dont la valeur ne change pas au cours de l’exécution ; dynamic celles qui
ne peuvent pas être connues à la compilation ; et nonzero celles qui ne peuvent jamais être
nulles. Le cube sur lequel se trouvent les qualificateurs correspond à une relation d’ordre,
du plus spécifique (en bas) au plus général (en haut). ø correspond à un ensemble vide de
qualificateurs.
dynamic
ø const dynamic dynamic nonzero
const nonzero const dynamic nonzero
const nonzero
FIGURE 3.3 : Treillis de qualificateurs
Cette relation d’ordre � entre qualificateurs induit une relation de sous-typage � entre
les types qualifiés : si q � q�
, alors t q � t q�
.
Ces analyses ont été implantées dans l’outil CQual. Ce système peut servir à inférer les annotations
const [FFA99], à l’analyse de souillure pour les chaînes de format [STFW01] (pouvant
poser des problèmes de sécurité [New00]) et à déterminer des propriétés dépendantes
du flot de contrôle, comme des invariants sur les verrous [FTA02], à rapprocher du concept26 CHAPITRE 3. ANALYSES STATIQUES EXISTANTES
de typestates [SY86]. Il a également été appliqué à la classe de vulnérabilités sur les pointeurs
utilisateur dont il est question ici [JW04].
Cette approche est assez proche de la nôtre : on donne un type différent aux pointeurs
selon leur provenance. Néanmoins cela est très différent. Une première différence est dans
le langage considéré. CQual s’applique sur un lambda-calcul à références, alors que, pour
étudier du code C, nous présentons un modèle mémoire avec pile explicite plus proche de
la machine. D’autre part, le système de types de CQual est fondamentalement modifié pour
prendre en compte ces opérations, alors que dans le nôtre il s’agit d’une simple extension qui
ne nécessite pas de modifier toutes les règles de typage. La conclusion de la partie II, page 95,
sera dédiée à une comparaison entre ces solutions.
Le système Flow Caml [Sim03] repose également sur cette approche, en ajoutant une étiquette
de sécurité à chaque type. Par exemple, les entiers sont typés ’a int où ’a est le
niveau de sécurité associé. Couplé à un système d’effets, cela permet de suivre la provenance
de chaque expression. Cette technique d’analyse de flot permet d’encoder de nombreuses
propriétés de sécurité [SM03].
Ces techniques de typage sont séduisantes parce qu’elles sont en général simples à mettre
en place : à l’aide d’un ensemble de règles, on attribue un type à chaque expression. Si le
typage se termine sans erreur, alors on est assuré de la correction du programme (par rapport
aux propriétés capturées par le système de types).
Le typage statique peut également être implanté de manière efficace. Même si l’inférence
peut, dans certains cas, atteindre une complexité exponentielle [Mai90] (voire être indécidable),
la plupart des systèmes de types peuvent être vérifiés en pratique dans un temps linéaire
en la taille du programme considéré [McA03].
3.5 Langages sûrs
Une autre approche est de concevoir un langage à la fois bas niveau et sûr, permettant
d’exprimer des programmes proches de la machine tout en interdisant les constructions dangereuses.
Le langage Cyclone [JMG+02] est conçu comme un C « sûr ». Afin d’apporter plus de
sûreté au modèle mémoire de C, des tests dynamiques sont ajoutés, par exemple aux endroits
où des conversions implicites peuvent poser problème. Le langage se distingue par le
fait qu’il possède plusieurs types de pointeurs : des pointeurs classiques (int *), des pointeurs
« jamais nuls » (int @ ; un test à l’exécution est alors inséré) et des « pointeurs lourds »
(int ? ; qui contiennent des informations sur la zone mémoire pointée). L’arithmétique des
pointeurs n’est autorisée que sur ces derniers, rendant impossibles les débordements de tableaux
(ceux-ci étant détectés au pire à l’exécution). Le problème des pointeurs fous 1 est
résolu en utilisant un système de régions [GMJ+02], inspiré des travaux de Jouvelot, Talpin et
Tofte [TJ92, TT94]. Cela permet d’interdire statiquement les constructions où l’on déréfé-
rence un pointeur faisant référence à une région de mémoire qui n’est plus allouée (par
exemple en évitant de retourner l’adresse d’une variable locale). Cette approche peut également
servir à suivre les provenances de données sensibles [BGH10].
Le langage Rust [☞5] développé par Mozilla prend une approche similaire en distinguant
plusieurs types de pointeurs pour gérer la mémoire de manière plus fine. Les managed poin-
1. Les pointeurs fous, encore appelés pointeurs fantômes ou dangling pointers, correspondent à une zone
mémoire invalide ou expirée. Il y a deux sources principales de pointeurs fous : les variables de type pointeur
non initialisées, et les pointeurs vers des objets dont la mémoire a été libérée. C’est par exemple ce qui arrive aux
adresses de variables locales une fois que la fonction dans laquelle elles ont été définies retourne.3.6. LOGIQUE DE HOARE 27
ters (notés @int) utilisent un ramasse-miettes pour libérer la mémoire allouée lorsqu’ils ne
sont plus accessibles. Les owning pointers (notés ~int) décrivent une relation 1 à 1 entre
deux objets, comme les std::unique_ptr de C++ : la mémoire est libérée lorsque le pointeur
l’est. Les borrowed pointers (notés &int) correspondent aux pointeurs obtenus en prenant
l’adresse d’un objet, ou d’un champ d’un objet. Une analyse statique faite lors de la compilation
s’assure que la durée de vie de ces pointeurs est plus courte que l’objet pointé, afin
d’éviter les pointeurs fous. Cette analyse est également fondée sur les régions. Une fonction
qui retourne l’adresse d’une variable locale sera donc rejetée par le compilateur. Enfin, le dernier
type est celui des raw pointers (notés *int), pour lesquels le langage n’apporte aucune
garantie (il faut d’ailleurs encapsuler chaque utilisation dans un bloc marqué explicitement
unsafe). Ils sont équivalents aux pointeurs de C.
Les systèmes de types de ces projets apportent dans le langage différents types de pointeurs.
Cela permet de manipuler finement la mémoire, à la manière des smart pointers de
C++. Ceux-ci sont des types de données abstraits permettant de déterminer quelle partie du
code est responsable de la libération de la mémoire associée au pointeur.
De cette approche on retient surtout l’analyse de régions de Rust qui permet de manipuler
de manière sûre les adresses des variables locales, et les pointeurs lourds de Cyclone, qui
apportent une sûreté à l’arithmétique de pointeurs, au prix d’un test dynamique.
Ces techniques sont utiles pour créer des nouveaux programmes sûrs, mais on ne peut
pas les appliquer pour étudier la correction de logiciels existants. Dans cette perspective, le
langage CCured [NCH+05] a pour but d’ajouter un système de types forts à C (y compris pour
des programmes existants). Dans les cas où il n’est pas possible de prouver que le programme
s’exécutera correctement, des vérifications à l’exécution sont ajoutées. Cependant, cela né-
cessite une instrumentation dynamique qui se paye en performances et interdit la certification,
car l’environnement d’exécution doit être inchangé. Le compilateur Fail-Safe C [Oiw09]
utilise une approche similaire permettant de garantir la sûreté d’exécution des programmes
C tout en respectant la totalité de la norme C89.
3.6 Logique de Hoare
Une technique pour vérifier statiquement des propriétés sur la sémantique d’un programme
a été formalisée par Robert Floyd [Flo67] et Tony Hoare [Hoa69].
Elle consiste à écrire les invariants qui sont maintenus à un point donné du programme.
Ces propositions sont écrites dans une logique L . Chaque instruction i est annotée d’une
pré-condition P et d’une post-condition Q, ce que l’on note {P} i {Q}. Cela signifie que, si P
est vérifiée et que l’exécution de i se termine, alors Q sera vérifiée.
En plus des règles de L , des règles d’inférence traduisent la sémantique du programme ;
par exemple la règle de composition est :
{P} i1 {Q} {Q} i2 {R}
{P} i1;i2 {R}
(HOARE-SEQ)
Les pré-conditions peuvent être renforcées et les post-conditions relâchées :
�L P� ⇒ P {P} i {Q} �L Q ⇒Q�
{P�
} i {Q�
}
(HOARE-CONSEQUENCE)28 CHAPITRE 3. ANALYSES STATIQUES EXISTANTES
Il est alors possible d’annoter le programme avec ses invariants formalisés de manière
explicite dans L . Ceux-ci seront vérifiés à la compilation lorsque c’est possible, sinon à l’exé-
cution.
La règle de conséquence permet de séparer les propriétés du programme lui-même :
plusieurs niveaux d’annotations sont possibles, du moins précis au plus précis. En fait, il
est même possible d’annoter chaque point de contrôle par l’ensemble d’annotations vide :
{T } i {T } est toujours vrai.
Augmenter graduellement les pré- et post-conditions est néanmoins assez difficile, puisqu’il
peut être nécessaire de modifier l’ensemble des conditions à la fois. Cette difficulté est
mentionnée dans [DRS03], où un système de programmation par contrats est utilisé pour
vérifier la correction de routines de manipulation de chaînes en C.
Ce type d’annotations a été implanté par exemple pour le langage Java dans le système
JML [LBR06] ou pour le langage C# dans Spec# [BLS05]. Il est aussi possible d’utiliser cette
technique pour annoter du code assembleur de bas niveau [MG07].
3.7 Assistants de preuve
Avec un système de types classique, le fait qu’un terme (au sens « expression » ou « instruction
») soit bien typé amène quelques propriétés sur son exécution, par exemple, le fait
que seulement un ensemble réduit d’erreurs puisse arriver (comme la division par zéro).
En enrichissant le langage des types, on peut augmenter l’expressivité du typage. Par
exemple, on peut former des types « entier pair », « vecteur de n entiers », ou encore « liste
triée d’entiers ».
Habituellement, les termes peuvent dépendre d’autres termes (par composition) ou de
types (par des annotations). Les types peuvent également dépendre d’autres types (par composition
de types : par exemple, un couple de a et de b a pour type a ∗b). Enrichir l’expressivité
du typage revient essentiellement à introduire des termes dans les types, comme n
dans l’exemple précédent du vecteur de n entiers. C’est pourquoi on parle de types dépendants.
Parmi les langages proposant ces types on peut citer Coq [The04], Agda [BDN09] ou
Isabelle [NPW02].
Dans un langage classique, la plupart des types sont habités, c’est-à-dire qu’il existe des
termes ayant ces types. En revanche, avec les types dépendants ce n’est pas toujours vrai : par
exemple « vecteur de −1 entiers » n’a pas d’habitants. Ainsi, pouvoir construire un terme d’un
type donné est une information en soi.
On peut voir ce phénomène sous un autre angle : les termes sont à leur type ce que les
preuves sont à leur théorème. Exhiber un terme ayant un type revient à donner la preuve d’un
théorème. À l’aide de cette correspondance, il est possible de voir un algorithme de vérification
de typage comme un algorithme de vérification de preuve automatique. Ces preuves ne
portent pas forcément sur des programmes. Par exemple, le théorème des 4 couleurs a été
prouvé en Coq [Gon07].
Cette technique est très complexe à mettre en œuvre, puisqu’il faut encoder toutes les
propriétés voulues dans un formalisme de très bas niveau (du niveau de la théorie des ensembles).
De plus, l’inférence de types devient rapidement indécidable.
Conclusion
Il existe de nombreuses techniques pour vérifier du code système ou embarqué. Il y a
divers choix à faire entre l’expressivité, l’intégration de tests dynamiques ou la facilité de mise3.7. ASSISTANTS DE PREUVE 29
en œuvre.
Pour résoudre le problème des pointeurs utilisateur dans les noyaux, le typage statique
est une solution performante et assez pragmatique, puisqu’elle peut s’appliquer à des programmes
existants. Son expressivité limitée nous empêche de reposer entièrement sur elle
pour garantir l’absence d’erreur dans les programmes systèmes (par exemple, le typage est
mal adapté pour détecter les divisions par zéro). C’est pourquoi nous approchons la sûreté
de la manière suivante :
• Tout d’abord, on utilise le typage pour manipuler les données de manière compatible :
les types des opérations et fonctions sont vérifiés à la compilation.
• Ensuite, les accès aux tableaux et aux pointeurs sont vérifiés dynamiquement. Dans
le cas où une erreur est déclenchée, l’exécution s’arrête plutôt que de corrompre la
mémoire. La pile est également nettoyée à chaque retour de fonction afin d’éviter les
pointeurs fous.
• Enfin, les pointeurs provenant de l’espace utilisateur sont repérés statiquement afin
que leur déréférencement se fasse au sein de fonctions sûres. Cela permet de préserver
l’isolation entre le noyau et l’espace utilisateur.CONCLUSION DE LA PARTIE I
Nous avons montré que l’écriture de noyaux de systèmes d’exploitation nécessite de manipuler
des données provenant d’une zone non sûre, l’espace utilisateur. Parmi ces données,
il arrive de récupérer des pointeurs qui servent à passer des données par référence à
l’appelant, dans certains appels système. Si on déréférence ces pointeurs sans vérifier qu’ils
pointent bien vers une zone mémoire également contrôlée par l’appelant, on risque de lire
ou d’écrire dans des zones mémoires réservées au noyau seul.
Nous proposons une technique de typage pour détecter ces cas dangereux. Elle est plus
adaptée qu’une analyse de valeurs, car le grain pour distinguer les pointeurs sensibles des
pointeurs sûrs n’a pas besoin d’être très fin.
Pour décrire ces analyses, on commence par définir un langage impératif bien typable
que nous appellerons SAFESPEAK. Celui-ci s’inspire du langage NEWSPEAK, qui est un langage
intermédiaire développé par EADS dans le but de vérifier la sûreté de programmes C
embarqués. À ce titre, il existe un compilateur qui est capable de traduire du code C vers
NEWSPEAK.
Définir la syntaxe et la sémantique de SAFESPEAK permet d’écrire et d’évaluer des programmes.
Mais cela reste trop permissif, car on ne rejette pas les programmes qui manipulent
les données de manière incohérente. On définit donc un système de types pour classifier les
expressions et fonctions selon la classe de valeurs que leur évaluation produit.
Une fois SAFESPEAK défini et étendu d’un système de types, nous lui ajoutons des constructions
permettant d’écrire du code noyau, et en particulier on lui ajoute des pointeurs utilisateur.
Il s’agit de pointeurs dont la valeur est contrôlée par un utilisateur interagissant via un
appel système. Ces pointeurs ont un type distinct des pointeurs habituels.
En résumé, le but de cette thèse est de définir un langage intermédiaire proche de C, mais
bien typé ; puis de définir une analyse de typage qui vérifie que les pointeurs utilisateur sont
manipulés sans causer de problèmes de sécurité.
31Deuxième partie
Un langage pour l’analyse de code
système : SAFESPEAK
Dans cette partie, nous allons présenter un langage impératif modélisant une
sous-classe « bien typable » du langage C. Le chapitre 4 décrit sa syntaxe, ainsi que
sa sémantique d’exécution. À ce point, de nombreux programmes acceptés peuvent
provoquer des erreurs à l’exécution.
Afin de rejeter ces programmes incorrects, on définit ensuite dans le chapitre 5
une sémantique statique s’appuyant sur un système de types simples. Des proprié-
tés de sûreté de typage sont ensuite établies, permettant de catégoriser l’ensemble
des erreurs à l’exécution possibles.
Le chapitre 6 commence par étendre notre langage avec une nouvelle classe
d’erreurs à l’exécution, modélisant les accès à la mémoire utilisateur catégorisés
comme dangereux dans le chapitre 2. Une extension au système de types du chapitre
5 est ensuite établie, et on prouve que les programmes ainsi typés ne peuvent
pas atteindre ces cas d’erreur.
Trois types d’erreurs à l’exécution sont possibles :
• les erreurs liées aux valeurs : lorsqu’on tente d’appliquer à une opération des
valeurs incompatibles (additionner un entier et une fonction par exemple).
L’accès à des variables qui n’existent pas rentre aussi dans cette catégorie.
• les erreurs mémoire, qui résultent d’un débordement de tableau, du déréfé-
rencement d’un pointeur invalide ou d’arithmétique de pointeur invalide.
• les erreurs de sécurité, qui consistent en le déréférencement d’un pointeur
dont la valeur est contrôlée par l’espace utilisateur. Celles-ci sont uniquement
possibles en contexte noyau.
L’introduction des types simples enlève la possibilité de rencontrer le premier
cas. Il reste en revanche toujours possible de rencontrer des erreurs mémoire ainsi
que des divisions par zéro. Éliminer ces erreurs dépasse le cadre de ce travail.
En présence d’extensions permettant de manipuler des pointeurs utilisateur,
une extension naïve du système de types ne suffit pas à empêcher la présence d’erreurs
de sécurité. Celles-ci sont évitées par l’ajout de règles de typage supplémentaires.
33C H A P I T R E
4
SYNTAXE ET SÉMANTIQUE D’ÉVALUATION
Dans ce chapitre, on décrit le support de notre travail : un langage impératif nommé SAFESPEAK,
sur lequel s’appuieront les analyses de typage des chapitres 5 et 6.
Le langage C [KR88] est un langage impératif, conçu pour être un « assembleur portable ».
Ses types de données et les opérations associées sont donc naturellement de très bas niveau.
Ses types de données sont établis pour représenter les mots mémoire manipulables par
les processeurs : essentiellement des entiers et flottants de plusieurs tailles. Les types composés
correspondent à des zones de mémoire contigües, homogènes (dans le cas des tableaux)
ou hétérogènes (dans le cas des structures).
Une des spécificités de C est qu’il expose au programmeur la notion de pointeur, c’est-
à-dire de variables qui représentent directement une adresse en mémoire. Les pointeurs
peuvent être typés (on garde une indication sur le type de l’objet stocké à cette adresse) ou
« non typés ». Dans ce dernier cas, ils ont en fait le type void *, qui est compatible avec n’importe
quel type pointeur.
Son système de types rudimentaire ne permet pas d’avoir beaucoup de garanties sur la
sûreté du programme. En effet, aucune vérification n’est effectuée en dehors de celles faites
par le programmeur.
Le but ici est de définir SAFESPEAK, un langage plus simple mais qui permettra de raisonner
sur une certaine classe de programmes C.
Tout d’abord, on commence par présenter les notations qui accompagneront le reste des
chapitres. Cela inclut la notion de lentille, qui est utilisée pour définir les accès profonds
à la mémoire. Cela permet de résoudre le problème de mettre à jour une sous-valeur (par
exemple un champ de structure) d’une variable. Les lentilles permettent de définir de manière
déclarative que, pour faire cette opération, il faut obtenir l’ancienne valeur de la variable,
puis calculer une nouvelle valeur en remplaçant une sous-valeur, avant de replacer
cette nouvelle valeur à sa place en mémoire. En pratique, on définira deux lentilles : une qui
relie un état mémoire à la valeur d’une variable, et une qui relie une valeur à une de ses sousvaleurs.
Avec cette technique, on peut définir en une seule fois les opérations de lecture et
d’écriture de sous-valeurs imbriquées.
Ensuite, on présente SAFESPEAK en soi, c’est-à-dire sa syntaxe, ainsi que ses caractéristiques
principales. En particulier, le modèle mémoire est détaillé, ainsi que les valeurs manipulées
par le langage.
Enfin, on décrit une sémantique opérationnelle pour ce langage. Cela permet de définir
précisément l’exécution d’un programme SAFESPEAK au niveau de la mémoire.
L’implantation de ces analyses est faite dans le chapitre 7. Puisque SAFESPEAK n’est qu’un
modèle, il s’agira d’adapter ces règles de typage sur NEWSPEAK, qui possède un modèle mé-
3536 CHAPITRE 4. SYNTAXE ET SÉMANTIQUE D’ÉVALUATION
moire plus bas niveau.
4.1 Notations
Inférence
La sémantique opérationnelle consiste en la définition d’une relation de transition · → ·
entre états de l’interprète 1.
Cette relation est définie inductivement sur la syntaxe du programme. Plutôt que de pré-
senter l’induction explicitement, elle est représentée par des jugements logiques et des règles
d’inférence, de la forme :
P1 ... Pn
C
(NOM)
Les Pi sont les prémisses, et C la conclusion. Cette règle s’interprète de la manière suivante
: si les Pi sont vraies, alors C est vraie.
Certaines règles n’ont pas de prémisse ; ce sont des axiomes :
A
(AX)
Compte-tenu de la structure des règles, la dérivation d’une preuve (l’ordre dans lequel les
règles sont appliquées) pourra donc être vue sous la forme d’un arbre où les axiomes sont les
feuilles, en haut, et la conclusion est la racine, en bas.
A1
(R3)
A2
(R4)
B1
(R2)
A3
(R6)
B2
(R5)
C
(R1)
Listes
X ∗ est l’ensemble des suites finies de X, indexées à partir de 1. Si u ∈ X ∗, on note |u| le
nombre d’éléments de u (le cardinal de son domaine de définition). Pour i ∈ [1;|u|], on note
ui = u(i) le i-ème élément de la suite.
On peut aussi voir les suites comme des listes : on note [ ] la suite vide, telle que |[ ]| = 0.
On définit en outre la construction de suite de la manière suivante : si x ∈ X et u ∈ X ∗, la liste
x :: u ∈ X ∗ est la liste v telle que :
v1 = x
∀i ∈ [1;|u|], vi+1 = ui
Cela signifie que la tête de liste (x dans la liste x :: u) est toujours accessible à l’indice 1.
1. Dans le chapitre 5, la relation de typage · � · : · sera définie par la même technique.4.1. NOTATIONS 37
Lentilles
Dans la définition de la sémantique de SAFESPEAK, on utilise des lentilles bidirectionnelles.
Cette notion n’est pas propre à la sémantique des programmes. Il s’agit d’une technique
permettant de relier la modification d’un objet à la modification d’un de ses souscomposants.
Cela a plusieurs applications possibles. En programmation fonctionnelle pure
(sans mutation), on ne peut pas mettre à jour partiellement les valeurs composées comme
des enregistrements (records). Pour simuler cette opération, on a en général une opération
qui permet de définir un nouvel enregistrement dans lequel seul un champ a été mis à jour.
C’est ce qui se passe avec le langage Haskell [OGS08] : r { x = 5 } représente une valeur
enregistrement égale à r sur tous les champs, sauf pour le champ x où elle vaut 5. Utiliser
des lentilles revient à ajouter dans le langage la notion de champ en tant que valeur de première
classe. Elles ont l’avantage de pouvoir se composer, c’est-à-dire que, si on a un champ
nommé x qui contient un champ nommé y, alors on peut modifier le champ du champ automatiquement.
Dans ce cadre, les lentilles ont été popularisées par Van Laarhoven [vL11]. Puisque cela
sert à manipuler des données arborescentes, on peut aussi appliquer cet outil aux systèmes
de bases de données ou aux documents structurés comme par exemple en XML [FGM+07].
Dans notre cas, cela permettra par exemple de modifier un élément d’un tableau qui est
un champ de structure de la variable nommée x dans le 3e cadre de pile.
Définition 4.1 (Lentille). Étant donnés deux ensembles R et A, une lentille L ∈ LENSR,A (ou
accesseur) est un moyen d’accéder en lecture ou en écriture à une sous-valeur appartenant à
A au sein d’une valeur appartenant à R (pour record). Elle est constituée des opérations suivantes
:
• une fonction de lecture getL : R → A
• une fonction de mise à jour putL : (A ×R) → R
telles que pour tour a ∈ A,a� ∈ A, r ∈ R :
putL (getL (r ), r ) = r (GETPUT)
getL (putL (a, r )) = a (PUTGET)
putL (a�
,putL (a, r )) = putL (a�
, r ) (PUTPUT)
On note L = 〈getL |putL 〉.
GETPUT signifie que, si on lit une valeur puis qu’on la réécrit, l’objet n’est pas modifié ;
PUTGET décrit l’opération inverse : si on écrit une valeur dans le champ, c’est la valeur qui
sera lue ; enfin, PUTPUT évoque le fait que chaque écriture est totale : quand deux écritures se
suivent, seule la seconde compte.
Une illustration se trouve dans la figure 4.1.
Exemple 4.1 (Lentilles de tête et de queue de liste). Soit E un ensemble. On rappelle que E ∗
désigne l’ensemble des listes d’éléments de E.
On définit les fonctions suivantes. Notons qu’elles ne sont pas définies sur la liste vide [ ],
qui pourra être traitée comme un cas d’erreur.
getT (t :: q) = t putT (t
�
,t :: q) = t� :: q
getQ(t :: q) = q putQ(q�
,t :: q) = t :: q�38 CHAPITRE 4. SYNTAXE ET SÉMANTIQUE D’ÉVALUATION
getL ( ) =
putL ( , ) =
FIGURE 4.1 : Fonctionnement d’une lentille
Alors T = 〈getT |putT 〉 ∈ LENSE∗,E et Q = 〈getQ|putQ〉 ∈ LENSE∗,E∗ .
On a par exemple :
getT (1 :: 6 :: 1 :: 8 :: [ ]) = 1 putQ(4 :: 2 :: [ ], 3 :: 6 :: 1 :: 5 :: [ ]) = 3 :: 4 :: 2 :: [ ]
Définition 4.2 (Lentille indexée). Les objets de certains ensembles R sont composés de plusieurs
sous-objets accessibles à travers un indice i ∈ I. Une lentille indexée est une fonction Δ
qui associe à un indice i une lentille entre R et un de ses champs Ai :
∀i ∈ I,∃Ai ,Δ(i) ∈ LENSR,Ai
On note alors :
r [i]Δ
def
== getΔ(i)(r )
r [i ← a]Δ
def
== putΔ(i)(a, r )
Un exemple est illustré dans la figure 4.2.
getΔ(b)(
a b
c d
) =
getΔ(c)(
a b
c d
) =
putΔ(b)( ,
a b
c d
) =
a b
c d
putΔ(c)( ,
a b
c d
) =
a b
c d
FIGURE 4.2 : Fonctionnement d’une lentille indexée4.1. NOTATIONS 39
Exemple 4.2 (Lentille « ne élément d’un tuple »). Soient n ∈ N, et n ensembles E1,...,En.
Pour tout i ∈ [1;n], on définit :
gi((x1,...,xn)) = xi
pi(y, (x1,...,xn)) = (x1,...,xi−1, y,xi+1,...,xn)
Définissons T (i) = 〈gi |pi〉. Alors T (i) ∈ LENS(E1×...×En),Ei .
Donc T est une lentille indexée, et on a par exemple :
(3, 1, 4, 1, 5)[2]T = getT (2)((3, 1, 4, 1, 5))
= 1
(9, 2, 6, 5, 3)[3 ← 1]T = putT (3)(1, (9, 2, 6, 5, 3))
= (9, 2, 1, 5, 3)
La notation 3 ← 1 peut surprendre, mais elle est à interpréter comme « en remplaçant
l’élément d’indice 3 par 1 ».
Définition 4.3 (Composition de lentilles). Soient L1 ∈ LENSA,B et L2 ∈ LENSB,C .
La composition de L1 et L2 est la lentille L ∈ LENSA,C définie de la manière suivante :
getL (r ) = getL2
(getL1
r )
putL (a, r ) = putL1 (putL2 (a, getL1
r ), r )
On notera alors L = L1≫L2 (« L1 flèche L2 »).
getL1
putL2
putL1
getL1
getL2
FIGURE 4.3 : Composition de lentilles
Cette définition est illustrée dans la figure 4.3. Une preuve que la composition est une
lentille est donnée en annexe D.1.40 CHAPITRE 4. SYNTAXE ET SÉMANTIQUE D’ÉVALUATION
Constantes c ::= n Entier
| d Flottant
| NULL Pointeur nul
| ( ) Valeur unité
Expressions e ::= c Constante
| � e Opération unaire
| e � e Opération binaire
| l v Accès mémoire
| l v ← e Affectation
| &l v Pointeur
| f Fonction
| e(e1,...,en) Appel de fonction
| {l1 : e1;...;ln : en} Structure
| [e1;...;en] Tableau
Valeurs
gauches
l v ::= x Variable
| l v.lS Accès à un champ
| l v[e] Accès à un élément
| ∗e Déréférencement
Fonctions f ::= fun(x1,...,xn){i} Arguments, corps
FIGURE 4.4 : Syntaxe des expressions
4.2 Syntaxe
Les figures 4.4 et 4.5 présentent notre langage intermédiaire. Il contient la plupart des
fonctionnalités présentes dans les langages impératifs comme C.
Parmi les expressions, les constantes comportent les entiers et flottants, ainsi que le pointeur
NULL qui correspond à une valeur par défaut pour les pointeurs, et la valeur unité ( ) qui
pourra être retournée par les fonctions travaillant par effets de bord uniquement.
Les accès mémoire en lecture et écriture se font au travers de valeurs gauches (left values
ou lvalues) : comme en C, elles tiennent leur nom du fait que ce sont ces constructions qui
sont à gauche du signe d’affectation. En plus des variables, on obtient une valeur gauche en
accédant par nom à un champ ou par indice à un élément d’une valeur gauche, ou encore
en appliquant l’opérateur * de déréférencement à une expression. Pour assister le typage,
l’accès à un champ doit être décoré du type complet S, mais cette annotation est ignorée lors
de l’évaluation. Les valeurs gauches correspondent aussi à l’unité d’adressage : c’est-à-dire
que les pointeurs sont construits en prenant l’adresse d’une valeur gauche avec l’opérateur &.
Les fonctions sont des expressions comme les autres, contrairement à C où elles sont
forcément déclarées globalement. Cela veut dire qu’on peut affecter une fonction f à une va-4.3. MÉMOIRE ET VALEURS 41
Instructions i ::= PASS Instruction vide
| i;i Séquence
| e Expression
| DECL x = e IN{i} Déclaration de variable
| IF(e){i}ELSE{i} Alternative
| WHILE(e){i} Boucle
| RETURN(e) Retour de fonction
Phrases p ::= x = e Variable globale
| e Évaluation d’expression
Programme P ::= (p1,...,pn) Phrases
FIGURE 4.5 : Syntaxe des instructions
riable x et l’appeller avec x(a1,a2). Il est aussi possible de déclarer une fonction au sein d’une
fonction. Cependant cela ne respecte pas l’imbrication lexicale : dans la fonction interne il
n’est pas possible de faire référence à des variables locales de la fonction externe, seulement
à des variables globales. En mémoire les fonctions sont donc uniquement représentées par
leur code : il n’y a pas de fermetures.
Enfin, on trouve aussi des expressions permettant de construire des valeurs composées :
les structures et les tableaux.
Les instructions sont typiques de la programmation impérative. SAFESPEAK comporte
bien sûr l’instruction vide qui ne fait rien et la séquence qui chaîne deux instructions.
Une expression peut être évaluée dans un contexte d’instruction, pour ses effets de bord.
Remarquons que l’affectation est une expression, qui renvoie la valeur affectée. Cela permet
d’écrire x ← (y ← z), comme dans un programme C où on écrirait x = y = z.
Il est également possible de déclarer une variable locale avec DECL x = v IN{i}. x est alors
une nouvelle variable visible dans i avec pour valeur initiale v.
L’alternative et la conditionnelle sont classiques ; en revanche, on ne fournit qu’un seul
type de boucle et pas de saut (instruction goto).
Les opérateurs sont donnés dans la figure 4.6. Ils correspondent à ceux du langage C. La
différence principale est que les opérations sur les entiers, flottants et pointeurs sont annotées
avec le type de données sur lequel ils travaillent. Par exemple « + » désigne l’addition sur
les entiers et « +. » l’addition sur les flottants. Les opérations de test d’égalité, en revanche,
sont possibles pour les types numériques, les pointeurs, ainsi que les types composés de
types comparables.
4.3 Mémoire et valeurs
L’interprète que nous nous apprêtons à définir manipule des valeurs qui sont associées
aux variables du programme.42 CHAPITRE 4. SYNTAXE ET SÉMANTIQUE D’ÉVALUATION
Opérateurs
binaires
� ::= +,−,×,/,% Arithmétique entière
| +.,−.,×.,/. Arithmétique flottante
| +p,−p Arithmétique de pointeurs
| ≤,≥,<,> Comparaison sur les entiers
| ≤ .,≥ .,< .,> . Comparaison sur les flottants
| =,�= Tests d’égalité
| &,|,^ Opérateurs bit à bit
| &&,|| Opérateurs logiques
| �,� Décalages
Opérateurs
unaires
� ::= +,− Arithmétique entière
| +.,−. Arithmétique flottante
| ∼ Négation bit à bit
| ! Négation logique
FIGURE 4.6 : Syntaxe des opérateurs
La mémoire est constituée de variables (toutes mutables), qui contiennent des valeurs.
Ces variables sont organisées, d’une part, en un ensemble de variables globales et, d’autre
part, en une pile de contextes d’appel (qu’on appellera donc aussi cadres de pile, ou stack
frames en anglais). Cette structure empilée permet de représenter les différents contextes à
chaque appel de fonction : par exemple, si une fonction s’appelle récursivement, plusieurs
instances de ses variables locales sont présentes dans le programme. Le modèle mémoire
présenté ici ne permet pas l’allocation dynamique sur un tas. Cette limitation sera détaillée
dans le chapitre 9.
La structure de pile des variables locales permet de les organiser en niveaux indépendants
: à chaque appel de fonction, un nouveau cadre de pile est créé, comprenant ses paramètres
et ses variables locales. Au contraire, pour les variables globales, il n’y a pas de système
d’empilement, puisque ces variables sont accessibles depuis tout point du programme.
Pour identifier de manière non ambigüe une variable, on note simplement x la variable
globale nommée x, et (n,x) la variable locale nommée x dans le ne cadre de pile 2.
Les affectations peuvent avoir la forme x ← e où x est une variable et e est une expression,
mais pas seulement. En effet, à gauche de ← on trouve en général non pas une variable mais
une valeur gauche (par définition). Pour représenter quelle partie de la mémoire doit être accédée
par cette valeur gauche, on introduit la notion de chemin ϕ. Un chemin est une valeur
gauche évaluée : les cas sont similaires, sauf que tous les indices sont évalués. Par exemple,
ϕ = (5,x).p représente le champ « p » de la variable x dans le 5e cadre de pile. C’est à ce moment
qu’on évalue les déréférencements qui peuvent apparaître dans une valeur gauche.
Les valeurs, quant à elles, peuvent avoir les formes suivantes (résumées sur la figure 4.7) :
• c� : une constante. La notation circonflexe permet de distinguer les constructions syn-
2. Les paramètres de fonction sont traités comme des variables locales et se retrouvent dans le cadre correspondant.4.4.
INTERPRÈTE 43
taxique des constructions sémantiques. Par exemple, à la syntaxe 3 correspond la valeur
�3.
Les valeurs entières sont les entiers signés sur 32 bits, c’est-à-dire entre −231 à 231 − 1.
Mais ce choix est arbitraire : on aurait pu choisir des nombres à 64 bits, par exemple.
Les flottants sont les flottants IEEE 754 de 32 bits [oEE08].
Il n’y a pas de distinction entre procédures et fonctions ; toutes les fonctions doivent
renvoyer une valeur. Celles qui ne retournent pas de valeur « intéressante » renvoient
alors une valeur d’un type à un seul élément noté ( ), et donc le type sera noté UNIT.
Cette notation évoque un n-uplet à 0 composante.
• &� ϕ : une référence mémoire. Ce chemin correspond à un pointeur sur une valeur
gauche. Par exemple, l’expression &x s’évalue en &� ϕ = & (5, � x) si x désigne lexicalement
une variable dans le 5e cadre de pile.
• [v�1;...; vn] : un tableau. C’est une valeur composée qui contient un certain nombre
(connu à la compilation) de valeurs d’un même type, par exemple 100 entiers. On accède
à ces valeurs par un indice entier. C’est une erreur (Ωar r ay ) d’accéder à un tableau
en dehors de ses bornes, c’est-à-dire en dehors de [0;n − 1] pour un tableau à n élé-
ments. Pareillement, [
�·] permet de désigner les valeurs tableau. Par exemple, si x vaut 2
et y vaut 3, l’expression [x; y] s’évaluera en la valeur [2; 3] �
• {l1 : v�1;...;ln : vn} : une structure. C’est une valeur composée mais hétérogène. Les différents
éléments (appelés champs) sont désignés par leurs noms li (pour label). Dans
le programme, le nom de champ li est décoré de la définition complète de la structure
S. Celle-ci n’est pas utilisée dans l’évaluation et sera décrite au chapitre 5. Comme
précédemment, on note {
�·} pour dénoter les valeurs.
• f
� : une fonction. On garde en mémoire l’intégralité de la définition de la fonction (liste
de paramètres, de variables locales et corps). Même si les fonctions locales sont possibles,
il n’est pas possible d’accéder aux variables de la portée entourante depuis la
fonction intérieure (il n’y a pas de fermetures). Contrairement à C, les fonctions ne sont
pas des cas spéciaux. Par exemple, les fonctions globales sont simplement des variables
globales de type fonctionnel, et les « pointeurs sur fonction » de C sont remplacés par
des variables de type fonction.
• Ω : une erreur. Par exemple le résultat l’évaluation de 5/0 est Ωd i v .
Les erreurs peuvent être classifiées en deux grand groupes : d’une part, Ωf i eld , Ωvar et
Ωt yp sont des erreurs de typage dynamique, qui arrivent lorsqu’on accède dynamiquement
à des données qui n’existent pas ou qu’on manipule des types de données incompatibles.
D’autre part, Ωd i v , Ωar r ay et Ωp t r correspondent à des valeurs mal utilisées. Le but du système
de types du chapitre 5 sera d’éliminer complètement les erreurs du premier groupe.
4.4 Interprète
La figure 4.8 résume comment ces valeurs sont organisées. Une pile est une liste de cadres
de piles, et un cadre de pile est une liste de couples (nom, valeur). Un état mémoire m est un
couple (s, g ) où s est une pile et g un cadre de pile (qui représente les variables globales). On
note |m| = |s| la hauteur de la pile (en nombre de cadres).
Enfin, l’interprétation est définie comme une relation · → · entre états Ξ ; ces états sont
d’une des formes suivantes :44 CHAPITRE 4. SYNTAXE ET SÉMANTIQUE D’ÉVALUATION
Valeurs v ::= c� Constante
| &� ϕ Référence mémoire
| {l1 : v�1;...;ln : vn} Structure
| [v�1;...; vn] Tableau
| f
� Fonction
| Ω Erreur
Chemins ϕ ::= a Adresse
| ϕ�.l Accès à un champ
| ϕ[
�n] Accès à un élément
Adresses a ::= (n, x) Variable locale
| (x) Variable globale
Erreur Ω ::= Ωar r ay Débordement de tableau
| Ωp t r Erreur de pointeur
| Ωd i v Division par zéro
| Ωf i eld Erreur de champ
| Ωvar Variable inconnue
| Ωt yp Données incompatibles
FIGURE 4.7 : Valeurs
Pile s ::= [ ] Pile vide
| {x1 �→ v1;...;xn �→ vn} :: s Ajout d’un cadre
État mémoire m ::= (s, {x1 �→ v1;...;xn �→ vn}) Pile, globales
État d’interprète Ξ ::= 〈e,m〉 Expression, mémoire
| 〈i,m〉 Instruction, mémoire
| Ω Erreur
FIGURE 4.8 : Composantes d’un état mémoire4.5. OPÉRATIONS SUR LES VALEURS 45
• un couple 〈e,m〉 où e est une expression et m un état mémoire. m est l’état mémoire
sous lequel l’évaluation sera réalisée. Par exemple 〈3, ([ ], [x �→ 3])〉 → 〈�3, ([ ], [x �→ 3])〉
L’évaluation des expressions est détaillée dans la section 4.10.
• un couple 〈i,m〉 où i est une instruction et m un état mémoire. La réduction des instructions
est traitée dans la section 4.11. Par exemple, 〈(x ← 3; y ← x),m〉 → 〈y ←
x,m[x �→ �3]〉 → 〈PASS,m[x �→ �3][y �→ �3]〉.
Dans le cas général, utiliser des instructions pour représenter l’état des calculs ne suffit
pas ; il faut utiliser une continuation. C’est ce qui est fait par exemple dans la sémantique
de CMinor [AB07]. Ici, le flot de contrôle est plus simple et on peut se contenter
de retenir une simple instruction, ce qui simplifie la présentation.
• un couple 〈l v,m〉 où l v est une valeur gauche et m un état mémoire. L’évaluation des
valeurs gauches est décrite en section 4.9.
• une erreur Ω. La propagation des erreurs est détaillée dans la section 4.12.
L’évaluation des expressions, valeurs gauches et instructions se fait à petits pas. C’est-à-
dire qu’on simplifie d’étape en étape leur forme, jusqu’à arriver à un cas de base :
• pour les expressions, une valeur v ;
• pour les instructions, l’instruction PASS ou RETURN(v) où v est une valeur ;
• pour les valeurs gauches, un chemin ϕ.
On considère en fait la clôture transitive de cette relation. Cela revient à ajouter une règle :
Ξ1 → Ξ2 Ξ2 → Ξ3
Ξ1 → Ξ3
(TRANS)
4.5 Opérations sur les valeurs
Un certain nombre d’opérations est possible sur les valeurs (figure 4.6) :
• les opérations arithmétiques +, −, ×, / et % sur les entiers. L’opérateur % correspond
au modulo (reste de la division euclidienne). En cas de division par zéro, l’erreur Ωd i v
est levée.
• les versions « pointées » +., −., ×. et /. sur les flottants.
• les opérations d’arithmétique de pointeur +p et −p qui à un chemin mémoire et un
entier associent un chemin mémoire.
• les opérations d’égalité = et �=. L’égalité entre entiers ou entre flottants est immédiate.
Deux valeurs composées (tableaux ou structures) sont égales si elles ont la même forme
(même taille pour les tableaux, ou mêmes champs pour les structures) et que toutes
leurs sous-valeurs sont égales deux à deux. Deux références mémoire sont égales
lorsque les chemins qu’elles décrivent sont syntaxiquement égaux.
• les opérations de comparaison ≤,≥,<,> sont définies avec leur sémantique habituelle
sur les entiers et les flottants. Sur les références mémoires, elles sont définies dans le
cas où les deux opérandes sont de la forme ϕ[·] par : ϕ[n] � ϕ[m] def
== n � m. Dans
les autres cas, l’erreur Ωp t r est renvoyée. Notamment, il n’est pas possible de comparer
deux fonctions, deux tableaux ou deux structures.
• les opérateurs bit à bit sont définis sur les entiers. &, | et ^ représentent respectivement
la conjonction, la disjonction et la disjonction exclusive (XOR).46 CHAPITRE 4. SYNTAXE ET SÉMANTIQUE D’ÉVALUATION
• des versions logiques de la conjonction (&&) et de la disjonction (||) sont également
présentes. Leur sémantique est donnée par le tableau suivant :
n m n && m n || m
0 0 0 0
0 �= 0 0 1
�= 0 0 0 1
�= 0 �= 0 1 1
• des opérateurs de décalage à gauche (�) et à droite (�) sont présents. Eux aussi ne
s’appliquent qu’aux entiers.
• les opérateurs arithmétiques unaires +, −, +. et −. sont équivalents par définition à
l’opération binaire correspondante. Par exemple −4 def
== 0−4.
• ∼ inverse tous les bits de son opérande. ! est une version logique, c’est-à-dire que !0 = 1
et, si n �= 0, !n = 0.
Si ces opérateurs sémantiques reçoivent des données incompatibles (par exemple si on
tente d’ajouter une fonction et un entier), l’erreur spéciale Ωt yp est renvoyée.
4.6 Opérations sur les états mémoire
Définition 4.4 (Recherche de variable). La recherche de variable permet d’associer à une variable
x une adresse a.
Chaque fonction peut accéder aux variables locales de la fonction en cours, ainsi qu’aux
variables globales.
Remarque : le cadre de variables locales le plus récent a toujours l’indice 1.
Lookup((s, g ),x) =
(|s|,x) si |s| > 0 et (x �→ v) ∈ s1
x si (x �→ v) ∈ g
Ωvar sinon
En entrant dans une fonction, on rajoutera un cadre de pile qui contient les paramètres
de la fonction ainsi que ses variables locales. En retournant à l’appelant, il faudra supprimer
ce cadre de pile.
Définition 4.5 (Manipulations de pile). On définit l’empilement d’un cadre de pile c = ((x1 �→
v1),..., (xn �→ vn)) sur un état mémoire m = (s, g ) (figure 4.9(a)) :
Push((s, g ),c) = (c :: s, g )
On définit aussi l’extension du dernier cadre de pile, qui sert aux déclarations de variables
locales (figure 4.9(b)) :
Extend((c :: s, g ),x �→ v) = (((x �→ v :: c) :: s), g )
L’opération inverse de Extend(·,· �→ ·) sera simplement notée « − » : m − x, par exemple.
De même on définit le dépilement (figure 4.9(c)) :
Pop((c :: s, g )) = (s, g )4.6. OPÉRATIONS SUR LES ÉTATS MÉMOIRE 47
x �→ 0
Push(·, (x �→ 0))
(a) Empilement
x �→ 0 x �→ 0, y �→ 3
Extend(·, y �→ 3)
(b) Extension de cadre
...
Pop
(c) Dépilement
FIGURE 4.9 : Opérations de pile
Définition 4.6 (Hauteur d’une valeur). Une valeur peut contenir une référence vers une variable
de la pile. La hauteur d’une valeur est l’indice du plus haut cadre qu’elle référence, ou −1
sinon.
H (c�) = −1
H (f
�) = −1
H (&� ϕ) = HΦ(ϕ)
H ({l1 : v�1;...;ln : vn}) = max
i∈[1;n]
H (vi)
H ([v�1,..., vn]) = max
i∈[1;n]
H (vi)
où :
HΦ((x)) = −1
HΦ((n,x)) = n
HΦ(ϕ�.l) = HΦ(ϕ)
HΦ(ϕ[
�n]) = HΦ(ϕ)
Les opérations Extend et Pop ne sont définies que pour une pile non vide. Néanmoins
cela ne pose pas de problème, puisque, lors de l’exécution, la pile n’est vide que lors de l’évaluation
d’expressions dans les phrases de programme. À cet endroit, seules des expressions
peuvent apparaître, et leur évaluation ne manipule jamais la pile avec ces opérations.
On définit aussi une opération de nettoyage de pile, qui sera utile pour les retours de
fonction.
En effet, si une référence au dernier cadre est toujours présente après le retour d’une
fonction, cela peut casser le typage.
Par exemple, dans la figure 4.10, l’exécution de h( ) donne à p la valeur (1,x). Puis en
arrivant dans g , le déréférencement de p va modifier x qui va avoir la valeur 1. x, variable
flottante, contient donc un entier. Dans la ligne marquée (*), on réalise donc l’addition d’un
entier (contenu dans x malgré le type de la variable) et d’un flottant. Cette opération est bien
typée dans le programme mais provoquera une erreur Ωt yp à l’exécution.
Pour empêcher cela, on instrumente donc le retour de la fonction f pour que p soit remplacé
par NULL. Alors dans h, le déréférencement provoquera une erreur et empêchera la
violation du typage.48 CHAPITRE 4. SYNTAXE ET SÉMANTIQUE D’ÉVALUATION
f = Fun () {
Decl x = 0 in
return (&x);
}
g = Fun (p) {
Decl x = 0.0 in
*p = 1;
x <- x + 2.0; // (*)
}
h = Fun () {
Decl p = f() in
g(p);
}
FIGURE 4.10 : Cassage du typage par un pointeur fou
Pour définir l’opération de nettoyage, on commence par définir une opération de nettoyage
selon un prédicat sur les chemins :
CleanVP(p,c�) = c�
CleanVP(p, f
�) = f
�
CleanVP(p,&� ϕ) =
�
NULL si p(ϕ)
&� ϕ sinon
CleanVP(p,{l1 : v�1,...,ln : vn}) = {l1 : CleanVP(p, v1
�),...,ln : CleanVP(p, vn)}
CleanVP(p,[v�1;...; vn]) = [CleanVP(p, v1
�);...;CleanVP(p, vn)]
On l’étend ensuite aux cadres de pile, puis aux états mémoire :
CleanLP(p, (x1 �→ v1,...,xn �→ vn)) = (x1 �→ CleanVP(p, v1),...,xn �→ CleanVP(p, vn))
CleanP(p, (s, g )) = (s�
, g �
)
où s� = (CleanLP(p,s1),...,CleanLP(p,s|s|))
g � = CleanLP(p, g )
À l’aide de ces fonctions, on définit quatre opérations permettant de nettoyer des états
mémoire ou des valeurs en enlevant tout un niveau de pile ou seulement une variable :
Cleanup(m) = CleanP(λϕ.HΦ(ϕ) > |m|,m) CleanVar(m,a) = CleanP(λϕ.ϕ = a,m)
CleanVm(v) = CleanVP(λϕ.HΦ(ϕ) > |m|, v) CleanVarV(v,a) = CleanVP(λϕ.ϕ = a, v)
Ces 4 fonctions seront utilisées dans plusieurs règles dans la suite de ce chapitre.4.7. ACCESSEURS 49
Remarques Ces opérations ne sont pas toujours bien définies. Par exemple, Extend(·,· �→ ·)
ne peut pas s’appliquer à une pile vide, et m − x n’est défini que si une variable x existe au
sommet de la pile de m. Ce caractère partiel ne pose pas de problème de par la structure
des règles qui vont utiliser ces constructions. Par exemple, à chaque empilement correspond
exactement un dépilement. De plus, les phrases d’un programme ne peuvent pas faire intervenir
de déclaration de variable (une instruction est forcément dans une fonction), donc
Extend(·,· �→ ·) réussit toujours.
Un autre problème se pose si deux variables ont le même nom dans un cadre. Elles ne
peuvent pas être distinguées. On interdit donc ce cas en demandant aux programmes d’être
bien formés : au sein d’une fonction, les paramètres ainsi que l’ensemble des locales déclarées
doivent être de noms différents. En pratique, une phase préalable d’α-conversion peut
renommer les variables problématiques.
De plus, le fait d’ajouter cette étape de nettoyage à chaque retour de fonction peut être
assez coûteux. C’est un compromis : si on considère que les programmes se comportent bien
et ne créent pas de pointeurs fous (pointant au-dessus de la pile), alors cette phase est inutile
et peut être remplacée par l’identité. Autrement dit, il s’agit seulement d’une technique pour
s’assurer de ne pas avoir d’erreurs dans la sémantique. L’ajout d’un ramasse-miette, ou une
vérification préalable par un système de régions [TJ92], peut garantir qu’il n’y a pas de telles
constructions dangereuses.
4.7 Accesseurs
Le but de cette section est de définir rigoureusement les accès à la mémoire. À partir d’un
état mémoire m et d’une valeur gauche ϕ, on veut pouvoir définir une lentille Φ, permettant
d’obtenir :
• la valeur accessible au chemin ϕ : m[ϕ]Φ
• l’état mémoire obtenu en remplaçant celle-ci par une nouvelle valeur v� : m[ϕ ← v�
]Φ
Pour définir cette lentille indexée Φ, on commence par définir des lentilles élémentaires,
et on les compose pour pouvoir définir des lentilles entre valeurs.
On commence par définir deux lentilles I et L pour accéder aux structures de listes. I
accède par indice et L par clef (dans une liste d’association, donc).
Cela permet ensuite de définir A, qui extrait une valeur à partir d’un nom de variable et
d’une éventuelle hauteur de pile. Pour cela, on compose les lentilles I et L.
Les autres travaillent sur des valeurs composées, c’est-à-dire sur les structures et tableaux.
La lentille F extrait une sous-valeur correspondant au champ d’une structure. Le fonctionnement
est similaire à la lentille L puisqu’on accède par nom à une sous-structure. La lentille
T , quant à elle, permet d’accéder au ne élement d’un tableau. De ce point de vue, elle est
similaire à I mais en travaillant sur les valeurs.
Enfin, on définit Φ pour accéder à n’importe quelle sous-valeur d’une variable dans la
mémoire. Cela utilise A, F et T précédemment définis.
La figure 4.11 résume ces dépendances. Les lignes pleines indiquent quelles sont les défi-
nitions utilisées, et les pointillés relient les lentilles similaires. À droite, on donne un exemple
des lentilles de base. La valeur entourée correspond au « curseur » de la lentille, c’est-à-dire
la valeur qui peut être renvoyée ou mise à jour.50 CHAPITRE 4. SYNTAXE ET SÉMANTIQUE D’ÉVALUATION
I
L
F
T
A
Φ
I(3) : (3, 14, 15 , 92, 65)
L(toto) : ((toto, 3 ), (t at a, 6), (t i t i, 2))
F(y) : {x : 0; y : -3 }
T (0) : [ 1 ; 2; 3; 5]
FIGURE 4.11 : Dépendances entre les lentilles
Accès à une liste par indice : I
On définit une lentille indexée I : N → LENSα∗,α permettant d’accéder aux éléments d’une
liste par leur indice. On rappelle que les listes sont des suites finies, définies page 36. En outre,
I n’est définie que pour n ∈ [1;|l|].
l[n]I = ln si n ∈ [1;|l|]
l[n ← x]I = l
�
où l
�
n = x
∀i �= n,l
�
i = li
Accès à une liste d’associations : L
Une liste d’association est une liste de paires (clef, valeur) avec l’invariant supplémentaire
que les clefs sont uniques. Il est donc possible de trouver au plus une valeur associée à une
clef donnée. L’écriture est également possible, en remplaçant un couple par un couple avec
une valeur différente.
l[x]L =
�
v si ∃!n ∈ [1;|l|],∃v,ln = (x �→ v)
Ωvar sinon
l[x ← v�
]L =
�
l[n ← (x �→ v�
)]I si ∃!n ∈ [1;|l|],∃v,ln = (x �→ v)
Ωvar sinon
Accès par adresse : A
Les états mémoire sont constitués des listes d’association (nom, valeur).
L’accesseur par adresse [·]A permet de généraliser l’accès à ces valeurs en utilisant comme
clef non pas un nom mais une adresse.
Selon cette adresse, on accède soit à la liste des variables globales, soit à une des listes de
la pile des variables locales.
On pose m = (s, g ).
Les accès aux variables globales se font de la manière suivante. Si la variable n’existe pas,
notons que L retourne Ωvar .4.7. ACCESSEURS 51
A((x)) = Snd≫L(x)
Snd désigne la lentille entre un couple et sa deuxième composante. Ainsi, par exemple
m[(x) ← v]A = (s, g [x ← v]L).
Les accès aux locales reviennent à accéder à la bonne variable du bon cadre de pile. Cela
revient naturellement à composer les lentilles L et I. On définit donc une lentille Ls,n,x =
I(|s|−n +1)≫L(x) qui accède à la variable x du ne cadre de pile.
m[(n,x)]A =
�
getLs,n,x (s) si n ∈ [1;|s|]
Ωvar sinon
m[(n,x) ← v]A =
�
(putLs,n,x (v,s), g ) si n ∈ [1;|s|]
Ωvar sinon
Les numéros de cadre qui permettent d’identifier les locales (le n dans (n,x)) croissent
avec la pile. D’autre part, l’empilement se fait en tête de liste (près de l’indice 1). Donc pour
accéder aux plus vieilles locales (numérotées 1), il faut accéder au dernier élément de la liste.
Ceci explique pourquoi un indice |s|−n +1 apparaît dans la définition précédente.
Accès par champ : F
Les valeurs qui sont des structures possèdent des sous-valeurs, associées à des noms de
champ.
L’accesseur [·]F permet de lire et de modifier un champ de ces valeurs.
L’erreur Ωf i eld est levée si on accède à un champ non existant.
{l1 : v1;...;ln : vn}[l]F = vi si ∃i ∈ [1;n],l = li
{l1 : v1;...;ln : vn}[l]F = Ωf i eld sinon
{l1 : v1;...;ln : vn}[l ← v]F = {l1 : v1
;...
;lp−1 : vp−1
;lp : v
;lp+1 : vp+1
;...
;ln : vn} si ∃p ∈ [1;n],l = lp
{l1 : v1;...;ln : vn}[l ← v]F = Ωf i eld sinon
Accès par indice de tableau : T
On définit de même un accesseur [·]T pour les accès par indice à des valeurs tableaux.
Néanmoins le paramètre indice est toujours un entier et pas une expression arbitraire. Notons
que les accès sont vérifiés dynamiquement : il ne peut pas y avoir de débordement de
tableau.52 CHAPITRE 4. SYNTAXE ET SÉMANTIQUE D’ÉVALUATION
[v1;...; vn][i]T = vi+1 si i ∈ [0;n −1]
[v1;...; vn][i]T = Ωar r ay sinon
[v1;...; vn][i ← v]T = [v�
1;...; v�
n] si i ∈ [0;n −1]
où �
v�
i = v
∀j �= i, v�
j = v j
[v1;...; vn][i ← v]T = Ωar r ay sinon
Accès par chemin : Φ
L’accès par chemin Φ permet de lire et de modifier la mémoire en profondeur.
On peut accéder directement à une variable, et les accès à des sous-valeurs se font en
composant les accesseurs (définition 4.3, page 39) :
Φ(a) = A(a)
Φ(ϕ.l) = Φ(ϕ)≫F(l)
Φ(ϕ[i]) = Φ(ϕ)≫T (i)
Remarque Dans toute la suite, lorsque ce n’est pas ambigü, on emploiera la notation m[ϕ]
pour désigner m[ϕ]Φ. Il est important de remarquer que m désigne un état particulier et ϕ
un chemin particulier, mais que Φ est la lentille indexée globale définie page 52.
4.8 Contextes d’évaluation
L’évaluation des expressions repose sur la notion de contextes d’évaluation. L’idée est
que, si on peut évaluer une expression, alors on peut évaluer une expression qui contient
celle-ci.
Par exemple, supposons que 〈f (3),m〉 → 〈2,m〉. Alors on peut ajouter la constante 1 à
gauche de chaque expression sans changer le résultat : 〈1+ f (3),m〉 → 〈1+2,m〉. On a utilisé
le même contexte C = 1+ •.
Pour pouvoir raisonner en termes de contextes, 3 points sont nécessaires :
• comment découper une expression selon un contexte ;
• comment appliquer une règle d’évaluation sous un contexte ;
• comment regrouper une expression et un contexte.
Le premier point consiste à définir les contextes eux-mêmes (figure 4.12).
Dans cette définition, chaque cas hormis le cas de base fait apparaître exactement un
«C ». Chaque contexte est donc constitué d’exactement une occurrence de • (une dérivation
de C est toujours linéaire). L’opération de substitution consiste à remplacer ce trou : C�X� est
l’objet syntaxique (instruction, expression ou valeur gauche) obtenu en remplaçant l’unique
• dans C par X. Par exemple, DECL x = 2+ • IN{PASS}�5� est DECL x = 2+5 IN{PASS}
À titre d’illustration, décomposons l’évaluation de e1 � e2 en v = v1 �� v2 depuis un état
mémoire m :4.8. CONTEXTES D’ÉVALUATION 53
Contextes C ::= •
| C � e
| v � C
| � C
| & C
| C ← e
| ϕ ←C
| {l1 : v1;...;li :C;...;ln : en}
| [v1;...;C;...;en]
| C(e1,...,en)
| f (v1,...,C,...,en)
| C.lS
| C[e]
| ϕ[C]
| ∗ C
| C;i
| IF(C){i1}ELSE{i2}
| RETURN(C)
| DECL x = C IN{i}
FIGURE 4.12 : Contextes d’évaluation
1. on commence par évaluer l’expression e1 en une valeur v1. Le nouvel état mémoire est
noté m�
. Soit donc 〈e1,m〉 → 〈v1,m�
〉.
2. En appliquant la règle CTX (définie ci-après) avec C = • � e2 (qui est une des formes
possibles pour un contexte d’évaluation), on déduit de 1. que 〈e1 � e2,m〉 → 〈v1 � e2,m�
〉
3. D’autre part, on évalue e2 depuis m�
. En supposant encore que l’évaluation converge,
notons v2 la valeur calculée et m�� l’état mémoire résultant : 〈e2,m�
〉 → 〈v2,m��〉.
4. Appliquons la règle CTX à 3. avec C = v1 � •. On obtient 〈v1 � e2,m〉 → 〈v1 � v2,m�
〉.
5. En combinant les résultats de 2. et 4. on en déduit que 〈e1 � e2,m〉 → 〈v1 � v2,m��〉.
6. D’après la règle EXP-BINOP (page 55), 〈v1 � v2,m��〉 → 〈v1 �� v2,m��〉
7. D’après 5. et 6., on a par combinaison 〈e1 � e2,m〉 → 〈v,m��〉 en posant v = v1 �� v2.
Le deuxième point sera résolu par la règle d’inférence suivante.
〈i,m〉 → 〈i
�
,m�
〉
〈C�i�,m〉 → 〈C�i
�
�,m�
〉
(CTX)
Enfin, le troisième revient à définir l’opérateur de substitution ·�·� présent dans la règle
précédente. Notons que puisque i ::= e et e ::= l v, on peut aussi l’appliquer aux expressions
et aux valeurs gauches : l’opération ·�·� est purement syntaxique.54 CHAPITRE 4. SYNTAXE ET SÉMANTIQUE D’ÉVALUATION
4.9 Valeurs gauches
Obtenir un chemin à partir d’un nom de variable revient à résoudre le nom de cette variable
: est-elle accessible ? Le nom désigne-t-il une variable locale ou une variable globale ?
a = Lookup(x,m)
〈x,m〉 → 〈a,m〉
(PHI-VAR)
Les règles portant sur le déréférencement et l’accès à un champ de structure sont similaires
: on commence par évaluer la valeur gauche sur laquelle porte ce modificateur, et on
place le même modificateur sur le chemin résultant. Dans le cas des champs de structure,
l’annotation de structure S n’est pas prise en compte pour l’évaluation : elle servira uniquement
au typage.
〈ϕ.lS,m〉 → 〈ϕ�.l,m〉
(PHI-STRUCT)
Enfin, pour évaluer un chemin dans un tableau, on commence par procéder comme pré-
cédemment, c’est-à-dire en évaluant la valeur gauche sur laquelle porte l’opération d’indexation.
Puis on évalue l’expression d’indice en une valeur qui permet de construire le chemin
résultant.
〈ϕ[n],m〉 → 〈ϕ[
�n],m〉
(PHI-ARRAY)
Notons qu’en procédant ainsi, on évalue les valeurs gauches en allant de gauche à droite :
dans l’expression x[e1][e2][e3], e1 est évalué en premier, puis e2, puis e3.
La règle portant sur le déréférencement est particulière. On peut penser que la bonne
définition de ϕ consiste à se calquer sur la définition de l v, en remplaçant les noms de variable
par leur adresse résolue et en évaluant les indices de tableau, et à ajouter une règle qui
transforme ∗ϕ en ∗�ϕ. Or, cela ne fonctionne pas, car alors les déréférencements sont évalués
trop tard : au moment de l’affectation dans la valeur gauche plutôt qu’à sa définition. La
figure 4.13 illustre ce problème.
Decl s0 = { .f : 0 } in
Decl s1 = { .f : 1 } in
Decl x = & s0 in
Decl p = & ((*x).f) in
/* (a) */
x <- & s1
/* (b) */
FIGURE 4.13 : Évaluation stricte ou paresseuse des valeurs gauches
On s’intéresse à l’évaluation de l’expression *p aux points (a) et (b). Avec une sémantique
paresseuse (en ajoutant un ∗�ϕ), la valeur de p est & (( � ∗(1,x)).f ), donc *p est évalué à 0
en (a) et 1 en (b). Au contraire, avec une sémantique stricte (correcte), p vaut & (((1, � s0).f )
et donc *p est évalué à 0 en (a) et en (b).
Dans le cas où la valeur référencée n’a pas la forme &�ϕ ou N
�ULL, aucune règle ne peut
s’appliquer (comme lorsqu’on cherche à réduire l’addition d’une fonction et d’un entier, par4.10. EXPRESSIONS 55
exemple). Cela est préférable à renvoyer Ωp t r car on montrera que ce cas est toujours évité
dans les programmes typés (théorème 5.1).
v = &� ϕ
〈∗ v,m〉 → 〈ϕ,m〉
(EXP-DEREF)
v = N
�ULL
〈∗ v,m〉 → Ωp t r
(EXP-DEREF-NULL)
Par exemple, l v = x.lS[2∗n].gT pourra s’évaluer en ϕ = (2,x).l[4].g .
4.10 Expressions
Évaluer une constante est le cas le plus simple, puisqu’en quelque sorte celle-ci est déjà
évaluée. À chaque constante syntaxique c, on peut associer une valeur sémantique c�. Par
exemple, au chiffre (symbole) 3, on associe le nombre (entier) �3.
〈c,m〉 → 〈c�,m〉
(EXP-CST)
De même, une fonction est déjà évaluée :
〈f ,m〉 → 〈f
�,m〉
(EXP-FUN)
Pour lire le contenu d’un emplacement mémoire (valeur gauche), il faut tout d’abord
l’évaluer en un chemin.
〈ϕ,m〉 → 〈m[ϕ]Φ,m〉
(EXP-LV )
Pour évaluer une expression constituée d’un opérateur, on évalue une sous-expression,
puis l’autre (l’ordre d’évaluation est encore imposé : de gauche à droite). À chaque opérateur
�, correspond un opérateur sémantique �� qui agit sur les valeurs. Par exemple, l’opérateur +�
est l’addition entre entiers machine (page 43). Comme précisé dans la section 4.5, la division
par zéro via /, % ou /. provoque l’erreur Ωd i v .
〈� v,m〉 → 〈�� v,m〉
(EXP-UNOP)
〈v1 � v2,m〉 → 〈v1 �� v2,m〉
(EXP-BINOP)
Il est nécessaire de dire un mot sur les opérations +�p et −�p définissant l’arithmétique
des pointeurs. Celles-ci sont uniquement définies pour les références mémoire à un tableau,
c’est-à-dire celles qui ont la forme &� ϕ[n]. On a alors :
&� ϕ[n] +�p i = &� ϕ[n +� i]
&� ϕ[n] ] −�p i = &� ϕ[n −� i]
Cela implique qu’on ne peut pas faire d’arithmétique de pointeurs au sein d’une même
structure. Autrement c’est une erreur de manipulation de pointeurs 3 et l’opérateur �� renvoie
Ωp t r .
3. Cela est cohérent avec la norme C99 : « If the pointer operand points to an element of an array object, and
the array is large enough, [. . . ] ; otherwise, the behavior is undefined. » [ISO99, 6.5.6 §8]56 CHAPITRE 4. SYNTAXE ET SÉMANTIQUE D’ÉVALUATION
Si l’indice calculé (n +� i ou n −� i) sort de l’espace alloué, alors l’erreur sera faite au moment
de l’accès : la lentille T renverra Ωar r ay (page 51).
Une left-value s’évalue en le chemin correspondant.
〈& ϕ,m〉 → 〈&� ϕ,m〉
(EXP-ADDR)
L’affectation se déroule en 3 étapes. D’abord, l’expression est évaluée en une valeur v.
Ensuite, la valeur gauche est évaluée en un chemin ϕ. Enfin, un nouvel état mémoire est
construit, où la valeur accessible par ϕ est remplacée par v. Comme dans le langage C, l’expression
d’affectation produit une valeur, qui est celle qui a été affectée.
〈ϕ ← v,m〉 → 〈v,m[ϕ ← v]Φ〉
(EXP-SET)
Expressions composées
Les littéraux de structures sont évalués en leurs constructions syntaxiques respectives.
Puisque les contextes d’évaluation sont de la forme [v1;...;C;...;en], l’évaluation se fait toujours
de gauche à droite.
〈{l1 : v1;...;ln : vn},m〉 → 〈{l1 : v�1;...;ln : vn},m〉
(EXP-STRUCT)
〈[v1;...; vn],m〉 → 〈[v�1;...; vn],m〉
(EXP-ARRAY)
L’appel de fonction est traité de la manière suivante. On ne peut pas facilement relier
un pas d’évaluation de i à un pas d’évaluation de fun(a){i}(v1,..., vn), et donc un contexte
C ::= fun(a){•}(v1,..., vn) n’est pas à considérer. En effet, l’empilement suivi du dépilement
modifie la mémoire.
On emploie donc une règle EXP-CALL-CTX qui relie un pas interne 〈i,m1〉 → 〈i�
,m2〉 à un
pas externe. Une fois l’instruction interne réduite d’un pas, on évalue les arguments en des
valeurs v�
i
. Ils correspondent aux nouvelles valeurs à passer à la fonction.
Les autres règles permettent de transférer le flot de contrôle : en retournant la même
instruction pour une instruction terminale, ou en propageant une erreur. Dans le cas où on
retourne de la fonction pari = RETURN(v), il faut alors supprimer les références aux variables
qui ont disparu grâce aux opérateurs Cleanup(·) et CleanV·(·).
On suppose deux choses sur chaque fonction : d’une part, les noms de ses arguments sont
deux à deux différents et, d’autre part, son corps se termine par une instruction RETURN(·).
Cela veut dire que la dernière instruction doit être soit de cette forme, soit par exemple une
alternative dans laquelle les deux branches se terminent par un RETURN(·). C’est une propriété
qui peut être détectée statiquement avant l’exécution. Néanmoins, dans la syntaxe
concrète, on peut supposer qu’un RETURN(( )) est inséré automatiquement en fin de fonction
lorsqu’aucun RETURN(·) n’est présent dans son corps.4.11. INSTRUCTIONS 57
m1 = Push(m0, ((a1 �→ v1),..., (an �→ vn)))
〈i,m1〉 → 〈i
�
,m2〉 ∀i ∈ [1;n], v�
i = m2[(|m2|,ai)]A m3 = Pop(m2)
〈fun(a1,...,an){i}(v1,..., vn),m0〉 → 〈fun(a1,...,an){i
�
}(v�
1,..., v�
n),m3〉
(EXP-CALL-CTX)
m� = Push(m, ((a1 �→ v1),..., (an �→ vn))) 〈i,m�
〉 → Ω
〈fun(a1,...,an){i}(v1,..., vn),m〉 → Ω
(EXP-CALL-ERR)
m� = Cleanup(m) v� = CleanV|m|(v)
〈fun(a1,...,an){RETURN(v)}(v1,..., vn),m〉 → 〈v�
,m�
〉
(EXP-CALL-RETURN)
4.11 Instructions
Les cas de la séquence et de l’évaluation d’une expression sont sans surprise.
〈(PASS;i),m〉 → 〈i,m〉
(SEQ)
〈v,m〉 → 〈PASS,m〉
(EXP)
L’évaluation de DECL x = v IN{i} sous m se fait de la manière suivante, similaire à l’appel
de fonction. La règle principale est DECL-CTX qui relie un pas d’évaluation sous une déclaration
à un pas d’évaluation externe : pour ce faire, on étend l’état mémoire en ajoutant x,
on effectue le pas, puis on enlève x. L’instruction résultante est la déclaration de x avec la
nouvelle valeur v� de x après le pas d’exécution 4.
On suppose qu’il n’y a pas de masquage au sein d’une fonction, c’est-à-dire que le nom
d’une variable déclarée n’est jamais dans l’environnement avant cette déclaration.
Si i est terminale (PASS ou RETURN(v)), alors on peut l’évaluer en i en nettoyant l’espace
mémoire des références à x qui peuvent subsister.
Enfin, si une erreur se produit elle est propagée.
m� = CleanVar(m − x, (|m|,x))
〈DECL x = v IN{PASS},m〉 → 〈PASS,m�
〉
(DECL-PASS)
m� = CleanVar(m − x, (|m|,x)) v�� = CleanVarV(v�
, (|m|,x))
〈DECL x = v IN{RETURN(v�
)},m〉 → 〈RETURN(v��),m�
〉
(DECL-RETURN)
m� = Extend(m,x �→ v)
〈i,m�
〉 → 〈i
�
,m��〉 v� = m��[(|m��|,x)]A m��� = m�� − x
〈DECL x = v IN{i},m〉 → 〈DECL x = v� IN{i
�
},m���〉
(DECL-CTX)
〈i,m〉 → Ω
〈DECL x = v IN{i},m〉 → Ω
(DECL-ERR)
Pour traiter l’alternative, on a besoin de 2 règles. Elles commencent de la même manière,
en évaluant la condition. Si le résultat est 0 (et seulement dans ce cas), c’est la règle IF-FALSE
4. On peut remarquer qu’il est impossible de définir un contexte d’évaluation C ::= DECL x = v IN{C}. En
effet, puisque celui-ci nécessiterait d’ajouter une variable, il ne préserve pas la mémoire.58 CHAPITRE 4. SYNTAXE ET SÉMANTIQUE D’ÉVALUATION
qui est appliquée et l’instruction revient à évaluer la branche « else ». Dans les autres cas, c’est
la règle IF-TRUE qui s’applique et la branche « then » qui est prise.
〈IF(0){it }ELSE{if },m〉 → 〈if ,m〉
(IF-FALSE)
v �= 0
〈IF(v){it }ELSE{if },m〉 → 〈it ,m〉
(IF-TRUE)
On exprime la sémantique de la boucle comme une simple règle de réécriture :
〈WHILE(e){i},m〉 → 〈IF(e){i;WHILE(e){i}}ELSE{PASS},m〉
(WHILE)
Enfin, si un RETURN(·) apparaît dans une séquence, on peut supprimer la suite :
〈RETURN(v);i,m〉 → 〈RETURN(v),m〉
(RETURN)
4.12 Erreurs
Les erreurs se propagent des données vers l’interprète ; c’est-à-dire que si une expression
ou instruction est réduite en une valeur d’erreur Ω, alors une transition est faite vers cet état
d’erreur.
Cela est aussi vrai d’une sous-expression ou sous-instruction : si l’évaluation de e1 provoque
une erreur, l’évaluation de e1 + e2 également. La notion de sous-expression ou sous
instruction est définie en fonction des contextes C. Notons que, dans EVAL-ERR, C�e� peut
être une expression ou une instruction.
〈Ω,m〉 → Ω
(EXP-ERR)
〈e,m〉 → Ω
〈C�e�,m〉 → Ω
(EVAL-ERR)
4.13 Phrases et exécution d’un programme
Un programme est constitué d’une suite de phrases qui sont soit des déclarations de variables
(dont les fonctions), soit des évaluations d’expressions.
Contrairement à C, il n’y a pas de déclaration de types au niveau des phrases (permettant
par example de définir les types structures et leurs champs). On suppose que, dans une
étape précédente, chaque accès à un champ de structure a été décoré du type complet correspondant.
Par exemple, il est possible de compiler vers SAFESPEAK un langage comportant
des accès non décorés, mais où les types de structures sont déclarés. Le compilateur est alors
capable de repérer à quel type appartiennent quels champs et d’émettre ces étiquettes. C’est
d’ailleurs une des étapes de la compilation d’un programme C.
L’évaluation d’une phrase p fait donc passer d’un état mémoire m à un autre m�
, ce que
l’on note m � p → m�
.
L’évaluation d’une expression est uniquement faite pour ses effets de bord. Par exemple,
après avoir défini les fonctions du programme, on pourra appeler main(). La déclaration
d’une variable globale, quant à elle, consiste à évaluer sa valeur initiale et à étendre l’état
mémoire avec ce couple (variable, valeur). On suppose que les variables globales ont toutes
des noms différents. Notons que ces évaluations se font à grands pas.4.14. EXEMPLE 59
Enfin, l’exécution d’un programme, notée � P →∗ m, permet de construire un état mé-
moire final. Cette relation →∗ est l’extension de → sur les suites de phrases, c’est-à-dire les
programmes.
〈e,m〉 → 〈v,m�
〉
m � e → m� (ET-EXP)
〈e,m〉 → 〈v,m�
〉 m� = (s, g ) m�� = (s, (x �→ v) :: g )
m � x = e → m�� (ET-VAR)
([ ], [ ]) � p1 → m1 m1 � p2 → m2 ... mn−1 � pn → mn
� p1,...,pn →∗ m
(PROG)
4.14 Exemple
Considérons le programme suivant :
(p1) s = { x: 0; y: 0}
(p2) f = fun(q) {
*q <- 1
}
(p3) f(&s.x)
Ce programme est constitué des phrases p1,p2 et p3. On rappelle que par rapport à la syntaxe
concrète, un RETURN(( )) est inséré automatiquement, donc p2 est en fait f = fun(q){∗q ←
1; RETURN(( ))}. De plus, un prétraitement va annoter l’accès à s.x en rajoutant le type structure
de s, noté S.
D’après PROG, l’évaluer va revenir à évaluer à la suite ces 3 phrases.
Déclaration de x D’après PROG, on part d’un état mémoire m0 = ([ ], [ ]). Pour trouver m1
tel que m0 � s = {x : 0; y : 0} → m1, il faut appliquer la règle ET-VAR. Celle-ci va étendre l’ensemble
(vide) des globales mais demande d’évaluer l’expression 0. D’après EXP-CST,〈0,m0〉 →
〈�0,m0〉.
Donc m0 � s = {x : 0; y : 0} → m1 en posant m1 = ([ ], [s �→ {x�: 0; y : 0}]).
Déclaration de f On se trouve encore dans le cas de la déclaration d’une variable globale.
Il faut comme auparavant évaluer l’expression. C’est la règle EXP-FUN qui s’applique :
〈fun(q){∗q ← 1; RETURN(( ))},m1〉 → 〈fun(q){∗q�← 1; RETURN(( ))},m1〉 (ce qui revient à dire
que le code de la fonction est directement placé en mémoire).
Ainsi m1 � f = fun(q){∗q ← 1; RETURN(( ))} → m2 où :
m2 = ([ ], [f �→ fun(q){∗q�← 1; RETURN(( ))};s �→ {x�: 0; y : 0}])
Appel de f Ici, on évalue une expression pour ses effets de bords. La règle à appliquer est
ET-EXP, qui a comme prémisse 〈f (&s.xS),m2〉 → 〈v,m3〉.
D’après la forme de l’expression, la règle à appliquer va être EXP-CALL-RETURN. Mais il
va falloir d’abord réécrire l’expression à l’aide de CTX (pour que l’expression appellée ait la60 CHAPITRE 4. SYNTAXE ET SÉMANTIQUE D’ÉVALUATION
forme f
�et l’argument soit évalué) et EXP-CALL-CTX (pour que le corps de la fonction ait pour
forme RETURN(( ))).
Tout d’abord on applique donc CTX avec C = •(&s.xS). Comme on a via PHI-VAR puis
EXP-LV :
〈f ,m2〉 → 〈fun(q){∗q�← 1; RETURN(( ))},m2〉
On en déduit que :
〈f (&s.xS),m2〉 → 〈fun(q){∗q�← 1; RETURN(( ))}(&s.xS),m2〉
On évalue ensuite &s.xS. Les règles à appliquer sont EXP-ADDR et PHI-STRUCT. On en
déduit que 〈&s.xS,m2〉 → 〈&( � s).x,m2〉. Remarquons que l’étiquette de type structure S a été
effacée. Une application supplémentaire de CTX permet d’en arriver à la ligne suivante :
〈f (&s.xS),m2〉 → 〈fun(q){∗q�← 1; RETURN(( ))}(&( � s).x),m2〉
La fonction et son argument sont évalués, donc on peut appliquer EXP-CALL-CTX. En
posant m�
2 = Push(m2, (q �→ &( � s).x)), le but est de trouver m��
2 et v tels que :
〈∗q ← 1; RETURN(( )),m�
2〉 → 〈RETURN(v),m��
2 〉
Puisque l’instruction est une séquence, on va appliquer SEQ. La première partie n’étant
pas PASS, il faut l’évaluer grâce à la règle CTX avec C = •; RETURN(( )).
Le nouveau but est de trouver un m��
2 tel que 〈∗q ← 1,m�
2〉 → 〈PASS,m��
2 〉.
En appliquant EXP-DEREF sous C = ∗• ← 1, on obtient 〈∗q ← 1,m�
2〉 → 〈(s).x ← 1,m�
2〉.
Puis on applique EXP-CST sous C = (s).x ← • et 〈∗q ← 1,m�
2〉 → 〈(s).x ← �1,m�
2〉.
Maintenant que les deux côtés de ← sont évalués, on peut appliquer EXP-SET, et 〈∗q ←
1,m�
2〉 → 〈PASS,m��
2 〉 où :
m��
2 = ([[q �→ &( � s).x]], [f �→ fun(q){∗q�← 1; RETURN(( ))};s �→ {x�: 0; y : 0}])
Alors, d’après SEQ, 〈∗q ← 1,m�
2〉 → 〈RETURN(()),m��
2 〉. Avec EXP-CST sous C = RETURN(•),
on a donc 〈∗q ← 1,m�
2〉 → 〈RETURN(()), � m��
2 〉.
On peut enfin appliquer EXP-CALL-CTX pour en déduire que :
〈f (&s.xS),m2〉 → 〈fun(q){RETURN(( ))}( � &( � s).x),m���
2 〉
Donc d’après EXP-CALL-RETURN (car on a m���
2 = Cleanup(m��
2 ) et ( )� = CleanV|m���
2 |(( ))) : �
〈f (&s.xS),m2〉 → 〈( ), � m���
2 〉
En posant m3 = m���
2 , on a m2 � f (&s.xS) → m3.
Donc pour conclure (grâce à PROG), on a � [p1,p2,p3] →∗ m3.
Conclusion
On vient de définir un langage impératif, SAFESPEAK. Le but est que celui-ci serve de support
à des analyses statiques, afin notamment de montrer une propriété de sécurité sur les
pointeurs. Pour le moment, on a seulement défini ce que sont les programmes (leur syntaxe)
et comment ils s’exécutent (leur sémantique). Sur ces deux points, on note que nous sommes4.14. EXEMPLE 61
restés suffisamment proches de C, tout en utilisant pour la mémoire un modèle plus structuré
qu’une simple suite d’octets. Les définitions de la syntaxe ainsi que de la sémantique
sont rappelées dans l’annexe B (sections B.1 à B.7).
Afin de manipuler les états mémoire dans la sémantique d’évaluation, nous avons utilisé
le concept des lentilles, qui permettent de chaîner des accesseurs entre eux et d’accéder simplement
à des valeurs profondes de la mémoire, en utilisant le même outil pour la lecture et
l’écriture.
Pour le moment, on ne peut rien présager de l’exécution d’un programme bien formé
syntaxiquement. Pour la grande majorité des programmes bien formés (à la syntaxe correcte),
l’évaluation s’arrêtera soit par une erreur, soit parce qu’aucune règle d’évaluation ne peut
s’appliquer. Dans les chapitres 5 et 6, nous allons donc définir un système de types qui permet
de rejeter ces programmes se comportant mal à l’exécution.C H A P I T R E
5
TYPAGE
Dans ce chapitre, nous enrichissons le langage défini dans le chapitre 4 d’un système
de types. Celui-ci permet de séparer les programmes bien formés, comme celui de la fi-
gure 5.1(a), des programmes mal formés, comme celui de la figure 5.1(b). Intuitivement, le
programme mal formé provoquera des erreurs à l’exécution car il manipule des données de
manière incohérente : la variable x reçoit 1, donc elle se comporte comme un entier, puis est
déférencée, se comportant comme un pointeur.
f = Fun() {
Decl x = 0 in
x <- 1
return x
}
(a) Programme bien formé
f = Fun() {
Decl x = 0 in
x <- 1
return (*x)
}
(b) Programme mal formé
FIGURE 5.1 : Programmes bien et mal formés
Le but d’un tel système de types est de rejeter les programmes pour lesquels on peut facilement
déterminer qu’ils sont faux, c’est-à-dire dont on peut prouver qu’ils provoqueraient
des erreurs à l’exécution dues à une incompatibilité entre valeurs. En ajoutant cette étape, on
restreint la classe d’erreurs qui pourraient bloquer la sémantique.
On emploie un système de types monomorphe : à chaque expression, on associe un
unique type. En plus des types de base INT, FLOAT et UNIT, on peut construire des types
composés : pointeurs, tableaux, structures et fonctions.
Pour typer les structures, on suppose que les accès aux champs sont décorés du type complet
de la structure. Cela permet de typer sans ambigüité ces accès. Dans l’implantation dé-
crite dans le chapitre 7, ces annotations ne sont pas présentes. On y utilise donc une variante
du polymorphisme de rangée [RV98] présent dans OCaml pour unifier deux types structures
partiellement connus.
Le principe du typage est d’associer à chaque construction syntaxique une étiquette représentant
le genre de valeurs qu’elle produira. Dans le programme de la figure 5.1(a), la
variable x est initialisée avec la valeur 0 ; c’est donc un entier. Cela signifie que, dans tout le
programme, toutes les instances de cette variable 1 porteront ce type. La première instruction
1. Deux variables peuvent avoir le même nom dans deux fonctions différentes, par exemple. Dans ce cas il n’y
a aucune contrainte particulière entre ces deux variables. L’analyse de typage se fait toujours dans un contexte
précis.
6364 CHAPITRE 5. TYPAGE
est l’affectation de la constante 1 (entière) à x dont on sait qu’elle porte des valeurs entières,
ce qui est donc correct. Le fait de rencontrer RETURN(x) permet de conclure que le type de la
fonction est ( ) → INT (c’est-à-dire qu’elle n’a pas d’arguments et qu’elle retourne un INT).
Dans la seconde fonction, au contraire, l’opérateur ∗ est appliqué à x (le début de l’analyse
est identique et permet de conclure que x porte des valeurs entières). Or cet opérateur
prend un argument d’un type pointeur de la forme t ∗ et renvoie alors une valeur de type t.
Ceci est valable pour tout t (INT, FLOAT ou même t� ∗ : le déréférencement d’un pointeur sur
pointeur donne un pointeur), mais le type de x, INT, n’est pas de cette forme. Ce programme
est donc mal typé.
Dans ce chapitre, on commence par poser les notations qui vont servir à définir la relation
de typage. Ensuite, on explique les différentes règles de typage sur les composantes de
SAFESPEAK : expressions, instructions et phrases. Enfin, dans le reste du chapitre on établit
des propriétés qui sont respectées par les programmes bien typés. On conclut par les théorèmes
de progrès et de préservation qui établissent la sûreté du typage.
5.1 Environnements et notations
Les types associés aux expressions sont décrits dans la figure 5.2. Tous sont des types
concrets : il n’y a pas de polymorphisme.
Type t ::= INT Entier
| FLOAT Flottant
| UNIT Unité
| t∗ Pointeur
| t [ ] Tableau
| S Structure
| (t1,...,tn) → t Fonction
Structure S ::= {l1 : t1;...;ln : tn}
FIGURE 5.2 : Types et environnements de typage
Pour maintenir les contextes de typage, un environnement Γ associe un type à un ensemble
de variables.
Plus précisément, un environnement Γ est composé de deux listes de couples (variable,
type) : une pour les variables locales, et une pour les variables globales. Cette distinction est
nécessaire pour les définitions de fonctions : on remplace la liste des variables locales, mais
on conserve le type des variables globales.
Si Γ = (ΓG ,ΓL) = ((γi)i∈[1;n], (ηi)i∈[1;m]), avec γi = (gi ,ti) et ηi = (li ,ui), on utilise les notations
suivantes :5.2. EXPRESSIONS 65
x : t ∈ Γ def
== ∃i ∈ [1;n],γi = (x,t)∨ ∃i ∈ [1;m],ηi = (x,t)
dom(ΓG ) def
== {gi /i ∈ [1;n]}
dom(ΓL) def
== {li /i ∈ [1;m]}
dom(Γ) def
== dom(ΓG )∪dom(ΓL)
Γ, global x : t def
== ((γ�
i)
i∈[1;n+1],ΓL) tel que�
∀i ∈ [1;n],γ�
i = γi
γn+1 = (x,t)
Γ,local x : t def
== (ΓG , (η�
i)
i∈[1;m+1]) tel que�
∀i ∈ [1;m],η�
i = ηi
ηn+1 = (x,t)
Le type des fonctions semble faire apparaître un n-uplet (t1,...,tn) mais ce n’est qu’une
notation : il n’y a pas de n-uplets de première classe ; ils sont toujours présents dans un type
fonctionnel.
Le typage correspond à la définition des trois jugements suivants. Les deux premiers sont
mutuellement récursifs car une instruction peut consister en l’évaluation d’une expression,
et la définition d’une fonction repose sur le typage de son corps.
Typage d’une expression : on note de la manière suivante le fait qu’une expression e (telle
que définie dans la figure 4.4) ait pour type t dans le contexte Γ.
Γ � e : t
Typage d’une instruction : les instructions n’ont en revanche pas de type. Mais il est tout
de même nécessaire de vérifier que toutes les sous-expressions apparaissant dans une instruction
sont cohérentes ensemble.
On note de la manière suivante le fait que sous l’environnement Γ l’instruction i est bien
typée :
Γ � i
Typage d’une phrase : De par leur nature séquentielle, les phrases qui composent un programme
altèrent l’environnement de typage. Par exemple, la déclaration d’une variable globale
ajoute une valeur dans l’environnement.
On note de la manière suivante le fait que le typage de la phrase p transforme l’environnement
Γ en Γ� :
Γ � p → Γ�
On étend cette notation aux suites de phrases, ce qui définit le typage d’un programme,
ce que l’on note � P.
5.2 Expressions
Littéraux
Le typage des littéraux numériques ne dépend pas de l’environnement de typage : ce sont
toujours des entiers ou des flottants.66 CHAPITRE 5. TYPAGE
Γ � n : INT
(CST-INT)
Γ � d : FLOAT
(CST-FLOAT)
Le pointeur nul, quant à lui, est compatible avec tous les types pointeur. Cependant, il
conserve bien un type monomorphe : le type t n’est pas généralisé.
Γ � NULL : t ∗ (CST-NULL)
Enfin, le littéral unité a le type UNIT.
Γ � ( ) : UNIT
(CST-UNIT)
Valeurs gauches
Rappelons que l’environnement de typage Γ contient le type des variables accessibles du
programme. Le cas où la valeur gauche à typer est une variable est donc direct : il suffit de
retrouver son type dans l’environnement.
x : t ∈ Γ
Γ � x : t
(LV-VAR)
Dans le cas d’un déréférencement, on commence par typer la valeur gauche déréférencée.
Si elle a un type pointeur, la valeur déréférencée est du type pointé.
Γ � e : t ∗
Γ � ∗e : t
(LV-DEREF)
Pour une valeur gauche indexée (l’accès à tableau), on s’assure que l’indice soit entier, et
que la valeur gauche a un type tableau : le type de l’élement est encore une fois le type de
base du type tableau.
Γ � e : INT Γ � l v : t[ ]
Γ � l v[e] : t
(LV-INDEX)
Le typage de l’accès à un champ est facilité par le fait que, dans le programme, le type
complet de la structure est accessible sur chaque accès.
Dans la définition de cette règle on utilise la notation :
(l,t) ∈ {l1 : t1;...;ln : tn} def
== ∃i ∈ [1;n],l = li ∧ t = ti
(l,t) ∈ S Γ � l v : S
Γ � l v.lS : t
(LV-FIELD)5.2. EXPRESSIONS 67
Opérateurs
Un certain nombre d’opérations est possible sur le type INT.
� ∈ {+,−,×,/,&,|,^,&&,||,�,�,≤,≥,<,>} Γ � e1 : INT Γ � e2 : INT
Γ � e1 � e2 : INT
(OP-INT)
De même sur FLOAT.
� ∈ {+.,−.,×.,/.,≤ .,≥ .,< .,> .} Γ � e1 : FLOAT Γ � e2 : FLOAT
Γ � e1 � e2 : FLOAT
(OP-FLOAT)
Les opérateurs de comparaison peuvent s’appliquer à deux opérandes qui sont d’un type
qui supporte l’égalité. Ceci est représenté par un jugement EQ(t) qui est vrai pour les types
INT, FLOAT et pointeurs, ainsi que les types composés si les types de leurs composantes le
supportent (figure 5.3). Les opérateurs = et �= renvoient alors un INT :
� ∈ {=,�=} Γ � e1 : t Γ � e2 : t EQ(t)
Γ � e1 � e2 : INT
(OP-EQ)
EQ(t)
t ∈ {INT, FLOAT}
EQ(t)
(EQ-NUM)
EQ(t ∗)
(EQ-PTR)
EQ(t)
EQ(t[ ])
(EQ-ARRAY)
∀i ∈ [1;n].EQ(ti)
EQ({l1 : t1;...ln : tn})
(EQ-STRUCT)
FIGURE 5.3 : Jugements d’égalité sur les types
Les opérateurs unaires « + » et « − » appliquent aux entiers, et leurs équivalents « +. » et
« −. » aux flottants.
Γ � e : INT
Γ � +e : INT
(UNOP-PLUS-INT)
Γ � e : FLOAT
Γ � +.e : FLOAT
(UNOP-PLUS-FLOAT)
Γ � e : INT
Γ � −e : INT
(UNOP-MINUS-INT)
Γ � e : FLOAT
Γ � −.e : FLOAT
(UNOP-MINUS-FLOAT)
Les opérateurs de négation unaires, en revanche, ne s’appliquent qu’aux entiers.
� ∈ {∼,!} Γ � e : INT
Γ � � e : INT
(UNOP-NOT)68 CHAPITRE 5. TYPAGE
L’arithmétique de pointeurs préserve le type des pointeurs.
� ∈ {+p,−p} Γ � e1 : t ∗ Γ � e2 : INT
Γ � e1 � e2 : t ∗ (PTR-ARITH)
Autres expressions
Prendre l’adresse d’une valeur gauche rend un type pointeur sur le type de celle-ci.
Γ � l v : t
Γ � &l v : t ∗ (ADDR)
Pour typer une affectation, on vérifie que la valeur gauche (à gauche) et l’expression (à
droite) ont le même type. C’est alors le type résultat de l’expression d’affectation.
Γ � l v : t Γ � e : t
Γ � l v ← e : t
(SET)
Un littéral tableau a pour type t[ ] où t est le type de chacun de ses éléments.
∀i ∈ [1;n],Γ � ei : t
Γ � [e1;...;en] : t[ ]
(ARRAY)
Un littéral de structure est bien typé si ses champs sont bien typés.
∀i ∈ [1;n],Γ � ei : ti
Γ � {l1 : e1;...;ln : en} : {l1 : t1;...;ln : tn}
(STRUCT)
Pour typer un appel de fonction, on s’assure que la fonction a bien un type fonctionnel.
On type alors chacun des arguments avec le type attendu. Le résultat est du type de retour de
la fonction.
Γ � e : (t1,...,tn) → t ∀i ∈ [1;n],Γ � ei : ti
Γ � e(e1,...,en) : t
(CALL)
5.3 Instructions
La séquence est simple à traiter : l’instruction vide est toujours bien typée, et la suite de
deux instructions est bien typée si celles-ci le sont également.
Γ � PASS
(PASS)
Γ � i1 Γ � i2
Γ � i1;i2
(SEQ)
Une instruction constituée d’une expression est bien typée si celle-ci peut être typée dans
ce même contexte.5.4. FONCTIONS 69
Γ � e : t
Γ � e
(EXP)
Une déclaration de variable est bien typée si son bloc interne est bien typé quand on
ajoute à l’environnement la variable avec le type de sa valeur initiale.
Γ � e : t Γ,local x : t � i
Γ � DECL x = e IN{i}
(DECL)
Les constructions de contrôle sont bien typées si leurs sous-instructions sont bien typées,
et si la condition est d’un type entier.
Γ � e : INT Γ � i1 Γ � i2
Γ � IF(e){i1}ELSE{i2}
(IF)
Γ � e : INT Γ � i
Γ � WHILE(e){i}
(WHILE)
5.4 Fonctions
Le typage des fonctions fait intervenir une variable virtuelle R. Cela revient à typer l’instruction
RETURN(e) comme R ← e. Cela rappelle le langage Pascal, où pour retourner une
valeur on l’affecte à une variable nommée comme la fonction courante 2.
R : t ∈ Γ Γ � e : t
Γ � RETURN(e)
(RETURN)
Pour typer une définition de fonction, on commence par créer un nouvel environnement
de typage Γ� obtenu par la suite d’opérations suivantes :
• on enlève l’ensemble des locales. Cela inclut le couple R : tf correspondant à la valeur
de retour de la fonction appelante.
• on ajoute les types des arguments ai : ti
• on ajoute le type de la valeur de retour de la fonction appelée, R : t
Si le corps de la fonction est bien typé sous Γ�
, alors la fonction est typable en (t1,...,tn) →
t sous Γ.
Γ = (ΓG ,ΓL) Γ� = (ΓG , [a1 : t1;...;an : tn;R : t]) Γ� � i
Γ � fun(a1,...,an){i} : (t1,...,tn) → t
(FUN)
5.5 Phrases
Le typage des phrases est détaillé dans la figure 5.4. Le typage d’une expression est le cas
le plus simple. En effet, il y a juste à vérifier que celle-ci est bien typable (avec ce type) dans
l’environnement de départ : l’environnement n’est pas modifié. En revanche, la déclaration
d’une variable globale commence de la même manière, mais on enrichit l’environnement de
typage des globales de cette nouvelle association.
2. Si on n’avait pas introduit la restriction que chaque fonction doit terminer par un RETURN(·) (page 56),
alors le type de R pourrait rester inconnu. En pratique cela veut dire que la valeur de retour d’une telle fonction
serait compatible avec n’importe quel type t, ce qui briserait la sûreté du typage.70 CHAPITRE 5. TYPAGE
Γ � p → Γ�
Γ � e : t
Γ � e → Γ
(T-EXP)
Γ � e : t Γ� = Γ, global x : t
Γ � x = e → Γ� (T-VAR)
Γ � P
[ ] � p1 → Γ1 Γ1 � p2 → Γ2 ... Γn−1 � pn → Γn
� p1,...,pn
(PROG)
FIGURE 5.4 : Typage des phrases et programmes
5.6 Sûreté du typage
Comme nous l’évoquions au début de ce chapitre, le but du typage est de rejeter certains
programmes afin de ne garder que ceux qui ne provoquent pas un certain type d’erreurs à
l’exécution.
Dans la suite, nous donnons des propriétés que respectent tous les programmes bien
typés. Il est traditionnel de rappeler l’adage de Robin Milner :
Well-typed programs don’t go wrong.
To go wrong reste bien sûr à définir ! Cette sûreté du typage repose sur deux théorèmes :
• progrès : si un terme est bien typé, il y a toujours une règle d’évaluation qui s’applique.
• préservation (ou subject reduction) : l’évaluation transforme un terme bien typé en un
terme du même type.
5.7 Typage des valeurs
Puisque nous allons manipuler les propriétés statiques et dynamiques des programmes,
nous allons avoir à traiter des environnements de typage Γ et des états mémoires m. La première
chose à faire est donc d’établir une correspondance entre ces deux mondes.
Étant donné un état mémoire m, on associe un type de valeur τ aux valeurs v. Cela est fait
sous la forme d’un jugement m � v : τ.
Ces types de valeurs ne sont pas exactement les mêmes que les types statiques. Pour les
calculer, on n’a pas accès au code du programme, seulement à ses données. Il est par exemple
possible de reconnaître le type des constantes, mais pas celui des fonctions. Celles-ci sont en
fait le seul cas qu’il est impossible de déterminer à l’exécution. On le remplace donc par un
cas plus simple où seul l’arité est conservée.
Remarque Le fait d’effacer les types à l’exécution est un choix permettant d’alléger les valeurs
en mémoire. Il serait aussi possible de conserver les types complets à l’exécution, afin
de permettre une introspection dynamique des valeurs, mais cela éloignerait le langage de C.
Le cas des références (règle S-PTR) utilise le typage des valeurs gauches, codéfini par :
m �Φ ϕ : τ
def
== m � m[ϕ]Φ : τ5.7. TYPAGE DES VALEURS 71
Les règles de définition du typage des valeurs sont données dans la figure 5.5. On rappelle
que Φ est la lentille indexée définie page 52.
Type
de valeur
τ ::= INT Entier
| FLOAT Flottant
| UNIT Unité
| τ ∗ Pointeur
| τ[ ] Tableau
| {l1 : τ1;...;ln : τn} Structure
| FUNn Fonction
FIGURE 5.5 : Types de valeurs
Les règles sont détaillées dans la figure 5.6 : les types des constantes sont simples à retrouver
car il y a assez d’information en mémoire. Pour les références, ce qui peut être déréférencé
en une valeur de type τ est un τ ∗. Le typage des valeurs composées se fait en profondeur. En-
fin, la seule information restant à l’exécution sur les fonctions est son arité.
m � v : τ
m � n : INT
(S-INT)
m � d : FLOAT
(S-FLOAT)
m � ( ) : UNIT
(S-UNIT)
m � NULL : τ ∗ (S-NULL)
m �Φ ϕ : τ
m � &� ϕ : τ ∗ (S-PTR)
∀i ∈ [1;n].m � vi : τ
m � [v�1;...; vn] : τ[ ]
(S-ARRAY)
∀i ∈ [1;n].m � vi : τi
m � {l1 : v�1;...;ln : vn} : {l1 : τ1;...;ln : τn}
(S-STRUCT)
m � fun(x1,...,xn){i} : FUNn
(S-FUN)
FIGURE 5.6 : Règles de typage des valeurs
La prochaine étape est de définir une relation de compatibilité entre les types de valeurs
τ et statiques t. Nous noterons ceci sous la forme d’un jugement τ�t. Les règles sont décrites
dans la figure 5.7, la règle importante étant COMP-FUN. Notons qu’on garde le même nom
pour les types de base, et que par exemple INT peut être vu soit comme un type statique,
soit comme un type de valeur. Il y a donc un abus de notation dans la règle COMP-GROUND :
quand on note INT�INT, le premier désigne le type des valeurs à l’exécution, et le second le
type statique.
On définit enfin la notion d’état mémoire bien typé. On dit qu’un état mémoire m est bien
typé sous un environnement Γ, ce que l’on note Γ � m, si le type des valeurs à l’exécution
présent dans m est « compatible » avec les types présents dans Γ.
Cela se fait par induction sur la forme de Γ et m. Fonctionnellement, cela implique que
les accès à la mémoire retournent des valeurs en accord avec le type statique (lemme 5.6). Les72 CHAPITRE 5. TYPAGE
τ�t
t ∈ {INT, FLOAT, UNIT}
t �t
(COMP-GROUND)
τ�t
τ ∗�t ∗ (COMP-PTR)
τ�t
τ[ ]�t[ ]
(COMP-ARRAY)
∀i ∈ [1;n].τi �ti
{l1 : τ1;...;ln : τn}�{l1 : t1;...;ln : tn}
(COMP-STRUCT)
FUNn �(t1,...,tn) → t
(COMP-FUN)
FIGURE 5.7 : Compatibilité entre types de valeurs et statiques
[ ] � ([ ], [ ])
(M-EMPTY)
Γ � (s, g ) (s, g ) � v : τ τ�t
Γ, global x : t � (s, ((x �→ v) :: g ))
(M-GLOBAL)
Γ � m Γ = (ΓG ,ΓL) Γ� = (ΓG , [x1 : t1,...,xn : tn,R : t])
m � v1 : τ1 τ1 �t1 ... m � vn : τn τn �tn
Γ� � Push(m, ((x1 �→ v1),..., (xn �→ vn)))
(M-PUSH)
Γ = (ΓG ,ΓL) Γ � m
m� = Push(m, ((x1 �→ v1),..., (xn �→ vn))) (ΓG , [x1 : t1,...,xn : tn,R : t]) � m�
Γ � Cleanup(Pop(m�
))
(M-POP)
Γ � m m � v : τ τ�t x ∉ Γ
Γ,local x : t � Extend(m,x �→ v)
(M-DECL)
Γ,local x : t � m x ∉ Γ
Γ � CleanVar(m − x,x)
(M-DECLCLEAN)
Γ � m Γ � ϕ : t m � v : τ τ�t m� = m[ϕ ← v]
Γ � m� (M-WRITE)
FIGURE 5.8 : Compatibilité entre états mémoire et environnements de typage
règles définissant cette relation sont données dans la figure 5.8.
5.8 Propriétés du typage
On commence par énoncer quelques lemmes utiles dans la démonstration de ces théorèmes.
Les démonstrations des lemmes 5.1 et 5.2 sont des analyses de cas laborieuses et sans
difficulté ; dans ce cas on n’en donne que des esquisses.
Lemme 5.1 (Inversion). À partir d’un jugement de typage, on peut en déduire des informations
sur les types de ses sous-expressions.
• Constantes
• si Γ � n : t, alors t = INT
• si Γ � d : t, alors t = FLOAT
• si Γ � NULL : t, alors ∃t�
,t = t�
∗5.8. PROPRIÉTÉS DU TYPAGE 73
• si Γ � ( ) : t, alors t = UNIT
• Références mémoire :
• si Γ � (x) : t, alors x : t ∈ ΓG
• si Γ � (n, x) : t, alors x : t ∈ ΓL
• si Γ � l v[e] : t, alors Γ � l v : t[ ] et Γ � e : INT
• si Γ � l v.lS : t, alors Γ � l v : S
• Opérations :
• si Γ � � e : t, alors on est dans un des cas suivants :
• � ∈ {+,−,∼,!}, t = INT, Γ � e : INT
• � ∈ {+.,−.}, t = FLOAT, Γ � e : FLOAT
• si Γ � e1 � e2 : t, un des cas suivants se présente :
• � ∈ {+,−,×,/,&,|,^,&&,||,�,�,≤,≥,<,>}, Γ � e1 : INT, Γ � e2 : INT, t = INT
• � ∈ {+.,−.,×.,/.,≤ .,≥ .,< .,> .}, Γ � e1 : FLOAT, Γ � e2 : FLOAT, t = FLOAT
• � ∈ {=,�=}, Γ � e1 : t�
, Γ � e2 : t�
, EQ(t�
), t = INT
• � ∈ {≤,≥,<,>}, t = INT, Γ � e1 : t�
, Γ � e2 : t�
, t� ∈ {INT, FLOAT}
• � ∈ {+p,−p}, ∃t�
,t = t�
∗, Γ � e1 : t�
∗, Γ � e2 : INT
• Appel de fonction : si Γ � e(e1,...,en) : t, il existe (t1,...,tn) tels que :
�
Γ � e : (t1,...,tn) → t
∀i ∈ [1;n],Γ � ei : ti
• Fonction : si (ΓG ,ΓL) � fun(a1,...,an){i} : t, alors il existe (t1,...,tn) et t� tels que :
�
t = (t1,...,tn) → t�
(ΓG , [a1 : t1,...,an : tn,R : t�
]) � i
• Si Γ � ∗e : t, alors Γ � e : t∗.
• Si Γ � l v ← e : t, alors Γ � l v : t et Γ � e : t.
• Si Γ � & l v : t, alors il existe t� tel que Γ � l v : t� et t = t� ∗.
• Instructions :
• Si Γ � i1;i2, alors Γ � i1 et Γ � i2.
• Si Γ � e, alors il existe t tel que Γ � e : t.
• Si Γ � DECL x = e IN{i}, alors il existe t tel que Γ � e : t et Γ,local x : t � i.
• Si Γ � IF(e){it }ELSE{if }, alors Γ � e : INT, Γ � it et Γ � if .
• Si Γ � WHILE(e){i}, alors Γ � e : INT et Γ � i.
• Si Γ � RETURN(e), alors il existe t tel que Γ � e : t et Γ � R : t.
Démonstration (esquisse). Pour chaque forme de jugement de typage, on liste les règles qui
peuvent amener à cette conclusion.
Il est aussi possible de réaliser l’opération inverse : à partir du type d’une valeur, on peut
déterminer sa forme syntaxique. C’est bien sûr uniquement possible pour les valeurs, pas
pour n’importe quelle expression (par exemple l’expression x (variable) peut avoir n’importe
quel type t dans le contexte Γ = x : t).74 CHAPITRE 5. TYPAGE
Lemme 5.2 (Formes canoniques). Il est possible de déterminer la forme syntaxique d’une valeur
étant donné son type, comme décrit dans le tableau suivant. Par exemple, d’après la première
ligne, si Γ � v : INT, alors v est de la forme n (cf. � figure 4.7, page 44 pour la définition des
valeurs).
Type de v Forme de v
INT n
FLOAT d
UNIT ( )
t∗ &� ϕ ou NULL
t[ ] [v1;...; vn]
{l1 : t1;...;ln : tn} {l1 : v1;...;ln : vn}
(t1,...,tn) → t fun(a1,...,an){i}
Démonstration (esquisse). On procède comme pour le lemme d’inversion : pour chaque forme
syntaxique, on fait l’inventaire des règles pouvant arriver à cette dérivation.
Lemme 5.3 (Représentabilité). On définit un opérateur de représentation d’un type statique à
l’exécution :
Repr(INT) = INT
Repr(FLOAT) = FLOAT
Repr(UNIT) = UNIT
Repr(t�
∗) = Repr(t�
)∗
Repr(t�
[ ]) = Repr(t�
)[ ]
Repr({l1 : t1;...;ln : tn}) = {l1 : Repr(t1);...;ln : Repr(tn)}
Repr((t1,...,tn) → t) = FUNn
Supposons que Γ � v : t et Γ � m. On pose τ = Repr(t). Alors m � v : τ et τ�t.
Démonstration. On procède par induction sur la forme de t.
• INT : D’après le lemme des formes canoniques, v = n. On conclut avec S-INT et COMPGROUND.
• FLOAT : Idem avec v = d et S-FLOAT.
• UNIT : Idem avec v = ( ) et S-UNIT.
• t = t�
∗ : Soient τ� = Repr(t�
) et τ = τ� ∗. D’après le lemme des formes canoniques, deux
cas sont possibles :
• v = &� ϕ :
Par inversion (lemme 5.1), Γ � ϕ : t�
.
Puisque Γ � m et Γ � ϕ : t�
, on obtient par le lemme 5.6 que m[ϕ] est une valeur
telle que m � m[ϕ] : τ� où τ� �t�
. D’après S-PTR, m � &� ϕ : τ.
De plus par COMP-PTR τ�t.
• v = NULL :
Par induction, τ� �t�
. Alors par COMP-PTR, τ ∗�t ∗.
En outre, grâce à S-NULL, on obtient m � NULL : τ ∗.5.8. PROPRIÉTÉS DU TYPAGE 75
• t = t�
[ ] : Par le lemme des formes canoniques, v = [v�1;...; vn]. Par inversion on obtient
que ∀i,Γ � vi : t�
.
Soient τ� = Repr(t�
) et τ = τ� [ ].
Alors par induction ∀i,m � vi : τ� et τ� � t�
. De la première propriété il vient (via SARRAY)
m � v : τ, et de la seconde (via COMP-ARRAY) τ�t.
• {l1 : t1;...;ln : tn} : Par le lemme des formes canoniques, v = {l1 : v�1;...;ln : vn}. Et par
inversion, ∀i,Γ � vi : ti .
Soient τi = Repr(ti) et τ = {l1 : τ1;...;ln : τn}.
Alors par induction, ∀i,m � vi : τi et τi �ti .
On déduit de S-STRUCT que m � v : τ, et de COMP-STRUCT que τ�t.
• t = (t1,...,tn) → t� : Par formes canoniques, on a v = fun(a
�1,...,an){i}.
Soit τ = FUNn : par S-FUN on obtient que m � v : τ. On conclut d’autre part que τ� t
grâce à COMP-FUN.
Lemme 5.4 (Hauteur des chemins typés). Une valeur typée ne peut jamais pointer au dessus
du niveau courant de pile. (H (·) provient de la définition 4.6, page 47).
Si m � v : τ, alors H (v) ≤ |m|.
Démonstration. On procède par induction sur la forme de v.
c�: Alors H (v) = −1. Comme |m| ≥ 0, ce cas est établi.
f
�: Idem.
&� a : On distingue selon la forme de a. Si a = (x), c’est immédiat. Si a = (n,x), alors d’après
la forme de v, la dernière règle appliquée dans la dérivation de m � v : τ est S-PTR, et donc
m[(n,x)] est une valeur. D’après la définition de a, n ≤ |m|.
&� ϕ.l : On procède par induction sur v� = &� ϕ. Comme H (&� ϕ) ≤ |m| et H (&� ϕ.l) = H (&� ϕ),
on en déduit que H (&� ϕ.l) ≤ |m|.
&� ϕ[n] : Idem.
{l1 : v�1;...;ln : vn} : Par induction, ∀i ∈ [1;n],H (vi) ≤ |m|. Donc il en est de même pour leur
maximum, et H (v) ≤ |m|.
[v�1,..., vn] : Idem.
Lemme 5.5 (Accès à des variables bien typées). Soit Adr(ϕ) l’adresse de la variable qui apparaît
dans ϕ :
Adr(a) = a
Adr(ϕ.l) = Adr(ϕ)
Adr(ϕ[n]) = Adr(ϕ)76 CHAPITRE 5. TYPAGE
Alors, si Γ � m et Γ � ϕ : t, alors Adr(ϕ) est soit une variable globale (x) avec x ∈ dom(ΓG ),
soit une variable locale (|m|,x) du plus haut cadre de pile avec x ∈ dom(ΓL).
Démonstration. On procède par induction sur la forme de ϕ.
• Si ϕ = ϕ�
.lS, alors Adr(ϕ) = Adr(ϕ�
), et par inversion Γ � ϕ� : S. On conclut en appliquant
l’hypothèse de récurrence à ϕ�
.
• Si ϕ = ϕ�
[n], le cas est similaire.
• Si ϕ = a, alors Adr(ϕ) = a. Si a = (x), on a par inversion x : t ∈ ΓG . Si a = (n,x), alors par
inversion x : t ∈ ΓL. Il reste à montrer que n = |m|, ce qui peut se prouver par induction
sur la dérivation de Γ � m, en notant que dom(ΓL) coincide toujours avec le dernier
niveau de pile. Cette étape est ici admise.
Lemme 5.6 (Accès à une mémoire bien typée). Si Γ � m et Γ � ϕ : t, alors m[ϕ] est une valeur
v et m � v : τ où τ�t.
Démonstration. À partir du lemme 5.5, on prouve celui-ci par induction sur une dérivation
de Γ � m.
M-EMPTY : ΓG = ΓL = [ ], la prémisse Γ � ϕ : t est donc impossible à satisfaire.
M-GLOBAL : Soient ϕ tel que Γ, global x : t� � ϕ : t et m� = (s, ((x �→ v) :: g )). Alors la variable
référencée par ϕ est soit (x), soit (y) avec y ∈ dom(ΓG ), soit (|m|, y) avec y ∈ dom(ΓL).
Dans le premier cas, m�
[ϕ] = v, ce qui permet de conclure.
Dans les autres cas, m�
[ϕ] = m[ϕ], ce qui nous permet de conclure grâce à l’hypothèse
d’induction.
M-DECL : On part de Γ � ϕ : t�
. Alors Adr(ϕ) est soit la locale x, soit une autre variable locale,
soit une globale. Dans le premier cas, m�
[ϕ] = v et les prémisses nous permettent de conclure.
Dans tous les autres cas, m�
[ϕ] = m[ϕ] et on applique l’hypothèse d’induction.
M-DECLCLEAN : On suppose que Γ � ϕ : t� et m� = CleanVar(m − x,x). Alors Γ,local x :
t � ϕ : t� par affaiblissement. On peut donc appliquer l’hypothèse d’induction : m[ϕ] = v où
m � v : τ� avec τ� �t�
. On distingue alors selon la forme de v. Si v = &� ϕ� où Adr(ϕ�
) = (|m|,x),
alors m�
[ϕ] = NULL par l’opération CleanVar(·,·). Le type τ� étant un type pointeur par le
lemme 5.2, on peut conclure. Dans les autres cas m[ϕ] = m�
[ϕ] ce qui termine ce cas.
M-PUSH : On procède d’une manière similaire. ϕ peut faire référence soit à un des xi , auquel
cas la valeur vi convient, soit à une variable globale, auquel cas on applique l’hypothèse
de récurrence.
M-POP : On part de Γ � m�� où m�� = Cleanup(Pop(m�
)). Deux cas se produisent selon la
forme de Adr(ϕ).
• Soit Adr(ϕ) = (x) avec x ∈ dom(ΓG ), alors Γ� � ϕ : t où Γ� = (ΓG , [x1 : t1,...,xn : tn,R : t]).
On applique alors l’hypothèse de récurrence en partant du jugement Γ � m� : il vient
que m�
[ϕ] = v où m � v : τ� avec τ� � t�
. Comme H (v) ≤ |m�
| (lemme 5.4), deux cas
peuvent se produire :5.9. PROGRÈS ET PRÉSERVATION 77
• Si H (v) = |m�
|, alors m��[ϕ] = NULL et on a bien la compatibilité mémoire (l’argument
est similaire au cas DECL-CLEAN).
• Sinon, m��[ϕ] = m�
[ϕ] et on conclut directement.
• Soit Adr(ϕ) = (|m��|,x). On procède alors de la mème manière sauf qu’on invoque alors
le cas d’induction sur Γ � m.
M-WRITE : On part de Γ � m� où m� = m[ϕ ← v], et on suppose que Γ � ϕ� : t�
.
Si ϕ = ϕ� : alors il suffit d’appliquer GETPUT à la lentille Φ : m[ϕ ← m[ϕ]] = m, ce qui
donne directement la conclusion.
Si ϕ �= ϕ� : Γ � ϕ� : t� donc Adr(ϕ�
) est soit une locale soit une globale de m�
. Donc m�
[ϕ�
] =
m[ϕ�
] et on conclut grâce à l’hypothèse d’induction.
5.9 Progrès et préservation
Ces lemmes étant établis, on énonce maintenant le théorème de progrès. Contrairement
aux langages où tout est expression, il faut traiter séparément les trois constructions principales
de SAFESPEAK : les expressions, les valeurs gauches et les instructions. Celles-ci sont
mutuellement dépendantes car :
• la définition d’une fonction par un bloc est une expression ;
• une expression est un cas particulier d’instruction ;
• une valeur gauche peut convenir une expression en indice de tableau ;
• une valeur gauche est un cas particulier d’expression.
Théorème 5.1 (Progrès). Supposons que Γ � i. Soit m un état mémoire tel que Γ � m.
Alors l’un des cas suivants est vrai :
• i = PASS
• ∃v,i = RETURN(v)
• ∃(i�
,m�
),〈i,m〉 → 〈i�
,m�
〉
• ∃Ω ∈ {Ωd i v ,Ωar r ay ,Ωp t r },〈i,m〉 → Ω
� � �
Supposons que Γ � e : t. Soit m un état mémoire tel que Γ � m. Alors l’un des cas suivants
est vrai :
• ∃v �= Ω,e = v
• ∃(e�
,m�
),〈e,m〉 → 〈e�
,m�
〉
• ∃Ω ∈ {Ωd i v ,Ωar r ay ,Ωp t r },〈e,m〉 → Ω
� � �
Supposons que Γ � l v : t. Soit m un état mémoire tel que Γ � m.
Alors l’un des cas suivants est vrai :
• ∃ϕ,l v = ϕ
• ∃(l v�
,m�
),〈l v,m〉 → 〈l v�
,m�
〉
• ∃Ω ∈ {Ωd i v ,Ωar r ay ,Ωp t r },〈l v,m〉 → Ω
C’est-à-dire, soit :
• l’entité (instruction, expression ou valeur gauche) est complètement évaluée.78 CHAPITRE 5. TYPAGE
• un pas d’évaluation est possible.
• une erreur de division, tableau ou pointeur se produit.
La preuve du théorème 5.1 se trouve en annexe D.2.
Théorème 5.2 (Préservation). Soit Γ un environnement de typage et m un état mémoire tels
que Γ � m.
Alors :
• Si Γ � l v : t et 〈l v,m〉 → 〈ϕ,m�
〉, alors Γ � Cleanup(m�
) et m� �Φ ϕ : τ où τ�t.
• Si Γ � l v : t et 〈l v,m〉 → 〈l v�
,m�
〉, alors Γ � Cleanup(m�
) et Γ � l v� : t.
• Si Γ � e : t et 〈e,m〉 → 〈v,m�
〉, alors Γ � Cleanup(m�
) et m� � v : τ où τ�t.
• Si Γ � e : t et 〈e,m〉 → 〈e�
,m�
〉, alors Γ � Cleanup(m�
) et Γ � e� : t.
• Si Γ � i et 〈i,m〉 → 〈i�
,m�
〉, alors Γ � Cleanup(m�
) et Γ � i�
.
Autrement dit, si une construction est typable, alors un pas d’évaluation ne modifie pas son
type et préserve le typage de la mémoire.
Remarque Dans la formulation classique de ce théorème, on indique que Γ � m implique
Γ � m�
. Ici, la conclusion est moins forte en indiquant seulement que Γ � Cleanup(m�
). Cela
indique que la compatibilité mémoire est établie mais peut localement introduire des pointeurs
fous. En fait, comme une étape de Cleanup(·) est faite après chaque appel de fonction et
chaque déclaration, la propriété classique est vraie mais uniquement sur un plus grand pas
d’exécution.
La preuve de ce théorème se trouve en annexe D.3.
Cela établit qu’aucun terme ne reste « bloqué » parce qu’aucune règle ne s’applique, et
que la sémantique respecte le typage. En quelque sorte, les types sont un contrat entre les
expressions et les fonctions : si leur évaluation converge, alors une valeur du type inféré sera
produite.
Enfin, on donne une version de ces propriétés pour les phrases de programme.
Théorème 5.3 (Progrès pour les phrases). Soit Γ un environnement de typage, m un état mé-
moire et p une phrase de programme. Supposons que Γ � p → Γ� et Γ � m.
On suppose en outre que l’évaluation de p termine.
Alors ∃m�
.m � p → m�
.
Démonstration. Ici il n’y a pas de difficulté puisque la contrainte (forte) de terminaison se lit
〈e,m〉 → 〈v�
,m�
〉 où e est l’expression apparaissant dans p.
Selon la forme de p, il suffit alors d’appliquer la règle ET-EXP ou ET-VAR.
Théorème 5.4 (Préservation pour les phrases). On suppose que les trois propriétés suivantes
sont vérifiées :
Γ � m
Γ � p → Γ�
m � p → m�
Alors Γ� � m�
.
Démonstration. On distingue selon la dernière règle appliquée dans la dérivation de m �
p → m�
.5.9. PROGRÈS ET PRÉSERVATION 79
ET-EXP : La dernière règle appliquée pour dériver Γ � p → Γ� est donc T-EXP. D’après les
prémisses de ces deux règles, on a donc Γ � e : t et 〈e,m〉 → 〈v,m�
〉. Alors, d’après le théorème
de préservation, Γ � m�
.
ET-VAR : Ici, la dérivation de Γ � p → Γ� termine par T-VAR. D’après leurs prémisses, on a
donc : Γ � e : t, Γ� = Γ, global x : t, et m�� = (s, (x �→ v) :: g ) où (s, g ) = m� (on cherche à prouver
que � � m��).
En appliquant le théorème de préservation, on obtient que Γ � v : t et Γ � m�
. D’après le
lemme 5.3, il existe τ tel que m� � v : τ où τ�t. On peut alors appliquer M-GLOBAL qui nous
donne que � � m��.
Conclusion
En ajoutant un système de types statiques à SAFESPEAK, on peut calculer à la compilation
la forme des valeurs produites par chaque expression. Pour ce faire, on a défini un ensemble
de règles de typage (regroupées dans l’annexe C) à appliquer selon la forme de celle-ci.
Si on considère des programmes qui sont seulement syntaxiquement corrects, on ne peut
rien prédire sur leur exécution. Par exemple, fun(x){PASS}+1 est une expression correcte mais
pour laquelle il n’y a pas de règle d’évaluation qui s’applique. En ajoutant un système de
types, les propriétés de sûreté établies dans ce chapitre assurent que les termes peuvent être
évalués, et que les valeurs produites sont en accord avec les types donnés aux différentes parties
du programme. Cela permet surtout de s’assurer que les programmes ne peuvent provoquer
une erreur d’exécution que dans certains cas particuliers, comme les divisions ou les
accès aux tableaux.
À l’issue de ce chapitre, on a donc un langage impératif sain pour bâtir des analyses de
typage, ce que nous allons faire dans le chapitre suivant.C H A P I T R E
6
EXTENSIONS DE TYPAGE
Nous venons de définir un système de types sûrs dans le chapitre 5. Cela permet de mettre
en relation les types des expressions avec les valeurs qui leur seront associées. Cela permet
une forme d’analyse de flot : si peu de constructions permettent de créer des valeurs d’un
type t, alors toutes les valeurs de type t proviennent de ces « sources ».
On se propose ici d’enrichir le système de types de plusieurs extensions permettant d’explorer
cette idée, en ajoutant de la « signification » dans les types de données des programmes.
Ces extensions permettront de détecter des erreurs de programmation communes, appuyées
sur des exemples réels.
Cela revient à introduire une séparation entre le type des données et sa représentation,
c’est-à-dire définir un type abstrait. Dans un système d’exploitation, les pointeurs utilisateur
sont en fait des pointeurs classiques déguisés, pour lesquels on interdit l’opérateur de déré-
férencement.
Cette technique est en fait générique : on peut également l’appliquer à certains types
d’entiers. En C, il est commun d’utiliser des int pour tout et n’importe quoi : pour des entiers
bien sûr (au sens de Z), mais aussi comme identificateurs pour lesquels les opérations
usuelles comme l’addition n’ont pas de sens. Par exemple, sous Linux, l’opération d’ouverture
de fichier renvoie un entier, dit descripteur de fichier, qui identifie ce fichier pour ce processus.
Le langage autorise donc par exemple de multiplier entre eux deux descripteurs de
fichiers, mais le résultat n’a pas de raison a priori d’être un descripteur de fichier valide.
En n’offrant pas cette distinction, le langage C permet d’écrire du code qui peut s’exé-
cuter mais dont la sémantique n’est, quelque part, pas bien fondée. En effet, le système de
types de C est trop primitif pour pouvoir garantir une véritable isolation entre deux types
de même représentation : il n’y a pas de types abstraits. Certes, typedef permet d’introduire
un nouveau nom pour un type, mais ce n’est qu’un raccourci syntaxique. Le compilateur ne
peut en effet pas considérer un programme sans avoir la définition quasi-complète des types
qui y apparaissent. La seule exception concerne les pointeurs sur structures : si on ne fait
que les affecter, il n’est pas nécessaire de connaître la taille ni la disposition de la structure ;
donc la définition peut ne pas être visible. Cette technique, connue sous le nom de pointeurs
opaques, n’est pas applicable aux autres types.
En ajoutant une couche de typage, on interdit ces opérations à la compilation. Cela permet
deux choses : pour le code déjà écrit, de détecter et corriger les manipulations dangereuses
; et, pour le nouveau code, de s’assurer qu’il est correct. Par exemple, si on écrit un
éditeur de texte, on peut éviter de nombreuses erreurs de programmation en définissant un
type « indice de ligne » et un type « indice de colonne » incompatibles entre eux.
Un premier exemple permet de distinguer plusieurs utilisations des entiers, selon s’ils
8182 CHAPITRE 6. EXTENSIONS DE TYPAGE
sont utilisés comme entiers arithmétiques ou ensemble de bits. Cela permet de détecter une
erreur courante qui consiste à mélanger les opérateurs logiques et bit à bit.
Ensuite, on étend de manière indépendante le système de types, cette fois au niveau des
pointeurs. Plus précisément, dans le contexte des systèmes d’exploitation, on introduit une
différence entre les pointeurs dont la valeur est contrôlée par l’utilisateur et ceux dont elle ne
l’est pas.
6.1 Exemple préliminaire : les entiers utilisés comme bitmasks
Dans le langage C, les types de données décrivent uniquement l’agencement en mé-
moire des valeurs. Ils n’ont pas de signification plus sémantique permettant d’exprimer ce
que les données représentent. Par exemple, dans un programme manipulant des dates, on
sera amené à manipuler des numéros de mois et d’années, représentés par des types entiers.
Le langage C permet de définir des nouveaux types :
typedef int month_t;
typedef int year_t;
Cependant, rien ne distingue le nouveau type de l’ancien. Il ne s’agit que d’une aide à la
documentation. Dans cet exemple, month_t et year_t sont tous les deux des nouveaux noms
pour le type int ; donc ils sont en fait compatibles. Le compilateur ne peut donc pas détecter
qu’on utilise un numéro de mois là où un numéro d’année était attendu (ou vice versa).
Cet idiome est commun en C. On manipule notamment certaines données abstraites par
des clés entières, et un typedef particulier permet de désigner celles-ci. Par exemple sous
Linux, les numéros de processus sont des indices dans la table de processus interne au noyau,
et on y accède par une valeur de type pid_t. De même, les utilisateurs sont représentés par
un nombre entier du type uid_t.
Un autre idiome est répandu : l’utilisation d’entiers comme représentation d’un ensemble
de booléens. En effet, un nombre a = �N−1
i=0 ai 2i peut s’interpréter comme la liste d’indices
de ses bits égaux à 1 : {i ∈ [0;N − 1]/ai = 1}. Un entier de 32 bits peut donc représenter une
combinaison de 32 options indépendantes.
C’est de cette manière que fonctionne l’interface qui permet d’ouvrir un fichier sous Unix
(figure 6.1). Le paramètre flags est un entier qui encode les options liées à l’ouverture du
fichier. On précise son mode (lecture, écriture ou les deux) par les bits 1 et 2 ; s’il faut créer
le fichier ou non s’il n’existe pas par le bit 7 ; si dans ce cas il doit être effacé par le bit 8,
etc. On obtient le paramètre complet en réalisant un « ou » bit à bit entre des constantes. Le
paramètre mode encode de la même manière les permissions que doit avoir le fichier créé, le
cas échéant (mode_t désigne en fait unsigned int).
int open(const char *pathname, int flags, mode_t mode);
int creat(const char *pathname, mode_t mode);
FIGURE 6.1 : Interface permettant d’ouvrir un fichier sous Unix
Ces fonctions retournent un entier, qui est un descripteur de fichier. Il correspond à un
indice numérique dans une table interne au processus. Par exemple, 0 désigne son entrée
standard, 1 sa sortie standard, et 2 son flux d’erreur standard.
On identifie donc au moins trois utilisations du type int :6.1. EXEMPLE PRÉLIMINAIRE : LES ENTIERS UTILISÉS COMME BITMASKS 83
• entier : c’est l’utilisation classique pour représenter des valeurs numériques. Toutes les
opérations sont possibles.
• bitmask : on utilise un entier comme ensemble de bits. Seules les opérations bit à bit
ont du sens.
• entier opaque : on utilise un entier de manière purement abstraite. C’est l’exemple des
descripteurs de fichier.
Ces utilisations du type n’ont rien à voir ; il faudrait donc empêcher d’utiliser un descripteur
de fichier comme un mode, et vice-versa. De même, aucun opérateur n’a de sens sur
les descripteurs de fichier, mais l’opérateur | du « ou » bit à bit doit rester possible pour les
modes.
On décrit ici une technique de typage pour détecter et interdire ces mauvaises utilisations
en proposant une version « bien typée » de la fonction open. Plus précisément, on donne à ses
deuxième et troisième arguments (respectivement flags et mode) le nouveau type BITS qui
correspond aux entiers utilisés comme bitmasks. Le type de retour n’est pas modifié (il reste
INT), mais on décrit comment il est possible de rendre ce type opaque.
6.1.1 Modifications
On commence par ajouter deux types : d’une part BITS bien sûr, mais également CHAR qui
apparaît dans les chaînes de caractères. On ne spécifie pas plus ce dernier mais on suppose
qu’il existe des littéraux de chaînes qui retournent un pointeur vers le premier élément d’un
tableaux de caractères. Pour rester compatible avec C, on suppose qu’un caractère nul ’\0’
est inséré à la fin de la chaîne. On ajoute ces chaînes uniquement dans le but de pouvoir
représenter les noms de fichiers.
Au niveau des valeurs, les entiers utilisés comme bitmasks sont représentés par des valeurs
entières classiques n�. En particulier, on n’ajoute pas de nouveau type sémantique, mais
on ajoute une règle de compatibilité entre le type de valeurs INT et le type statique BITS
(cela signifie qu’une valeur de type BITS est représentée par un INT en mémoire, figure 6.2).
Par ailleurs, on change le type des « constructeurs » (O_RDONLY, O_RDWR, O_APPEND, . . . ) et du
« consommateur » open (figure 6.3).
Type t ::= ...
| CHAR Caractère
| BITS Entier utilisé comme bitmask
INT�BITS
(COMP-BITS)
FIGURE 6.2 : Ajouts liés aux entiers utilisés comme bitmasks
Pour que les opérations bit à bit puissent s’appliquer aux bitmasks, on ajoute aux règles
s’appliquant à INT les règles suivantes. Cela revient à permettre plusieurs types pour l’opérateur
∼, mais la sémantique d’exécution est la même quel que soit le type, car BITS et INT sont
représentés de la même manière.
� ∈ { | , & , ^ } Γ � e1 : BITS Γ � e2 : BITS
Γ � e1 � e2 : BITS
(OP-BITS)
Γ � e : BITS
Γ �∼ e : BITS
(NOT-BITS)84 CHAPITRE 6. EXTENSIONS DE TYPAGE
[ ] � O_RDONLY : BITS
[ ] � O_RDWR : BITS
[ ] � O_APPEND : BITS
[ ] � open : (CHAR ∗, BITS) → INT
FIGURE 6.3 : Nouvelles valeurs liées aux bitmasks
Il reste à permettre d’utiliser les bitmasks dans les contextes où on attend un entier. Par
exemple, pour écrire IF(x & 0x80){...}ELSE{...} (test du bit numéro 7). On veut donc exprimer
que « un BITS est un INT ». Cette relation entre différents types d’entier correspond à un cas
particulier de sous-typage.
On ajoute la règle de subsomption suivante. Elle permet d’utiliser une expression de type
BITS là où une expression de type INT est attendue.
Γ � e : BITS
Γ � e : INT
(SUB-BITSINT)
Cela modifie légèrement l’implantation de l’inférence de types. Le type d’une expression
utilisée comme opérande de l’opérateur + n’est donc pas a priori de type INT, mais BITS ou
INT. Cela implique aussi qu’on peut additionner un BITS et un INT pour obtenir un INT. Les
expressions de la forme fun(x, y){RETURN(x|y)} peuvent donc accepter plusieurs types. Pour
l’inférence, cela correspondra à une inconnue de type. Si celle-ci n’est pas résolue à la fin de
l’inférence (par exemple si cette fonction n’est pas appelée), une erreur est levée. C’est une
limitation du monomorphisme.
Ainsi, si Γ � e : BITS, on a par exemple Γ � ! e : INT. On rappelle que la règle permettant de
typer ! est inchangée et reste la suivante :
� ∈ {∼,!} Γ � e : INT
Γ � � e : INT
(UNOP-NOT)
6.1.2 Exemple : ! x & y
Les nombreux opérateurs de C (repris en SAFESPEAK) posent plusieurs problèmes :
• il sont nombreux et il est facile de confondre && avec &, ou ! avec ∼ ;
• il y a un opérateur « ou exclusif » bit à bit (^) mais pas d’équivalent logique ;
• la priorité des opérateurs semble parfois arbitraire. Par exemple, les opérateurs de dé-
calage sont plus prioritaires que les additions, donc x � 2 + 1 est interprété comme
(x � 2)+1.
Le premier et le dernier point permettent d’expliquer une erreur courante : celle qui
consiste à écrire ! x & y au lieu de ! (x & y).
En effet, la première expression est équivalente à (! x) & y. Comme ! x vaut 0 ou 1, l’expression
résultante vaut y & 1 si x = 0, ou 0 sinon. Il s’agit probablement d’une erreur de
programmation. L’alternative ! (x & y) a plus de sens : elle vaut 0 si x et y ont un bit en commun,
1 sinon.6.2. ANALYSE DE PROVENANCE DE POINTEURS 85
On vérifie enfin que la première n’est pas bien typée alors que la seconde l’est. Dans les
deux cas suivants on se place dans un environnement Γ comportant deux variables globales
x et y de type BITS. Alors (! x)&y n’est pas bien typée. En effet, Γ � ! x : INT et la seule règle
qui s’applique à l’opérateur & ne peut pas s’appliquer. En revanche la seconde est bien typée
(figure 6.4).
Γ = ([x �→ BITS, y �→ BITS], [ ])
Γ � x : BITS Γ � y : BITS
Γ � x & y : BITS
(OP-BITS)
Γ � x & y : INT
(SUB-BITSINT)
Γ � ! (x & y) : INT
(UNOP-NOT)
FIGURE 6.4 : Dérivation montrant que ! (x & y) est bien typée
Cet exemple préliminaire permet de voir en quoi SAFESPEAK est adapté à des analyses
de typage légères. Puisque le typage est sûr, on en déduit que les valeurs d’un certain type
ne peuvent être créées que par un certain nombre de constructeurs. Par exemple ici les bitmasks
ne proviennent que de combinaisons de constantes. C’est précisément cette idée de
détection de source qui est au cœur de l’analyse suivante.
6.2 Analyse de provenance de pointeurs
Jusqu’ici SAFESPEAK est un langage impératif généraliste, ne prenant pas en compte les
spécificités de l’adressage utilisé dans les systèmes d’exploitation.
Dans cette section, on commence par l’étendre en ajoutant des constructions modélisant
les variables présentes dans l’espace utilisateur (cf. chapitre 2). Pour accéder à celles-ci, on
ajoute un opérateur de déréférencement sûr qui vérifie à l’exécution que l’invariant suivant
est respecté :
Les pointeurs dont la valeur est contrôlée par l’utilisateur pointent vers l’espace
utilisateur.
La terminologie mérite d’être détaillée :
Un pointeur contrôlé par l’utilisateur, ou pointeur utilisateur, est une référence mémoire
dont la valeur est modifiable par le code utilisateur (opposé au code noyau, que nous analysons
ici). Ceci correspond à des données provenant de l’extérieur du système vérifié. C’est
une propriété statique, qui peut être déterminée à la compilation à partir de considérations
syntaxiques. Par exemple, l’adresse d’une variable locale au sein de code noyau est toujours
considérée comme étant contrôlée par le noyau.
Un pointeur pointant vers l’espace utilisateur fait référence à une variable allouée en espace
utilisateur. Cela veut dire qu’y accéder ne risque pas de mettre en péril l’isolation du
noyau en faisant fuiter des informations confidentielles ou en déjouant son intégrité. Cette
propriété est dynamique : un pointeur utilisateur peut a priori pointer vers l’espace utilisateur,
ou non.
Pour prouver que l’invariant précédent est bien respecté, on procède en plusieurs étapes.
Tout d’abord, on définit une nouvelle erreur Ωsec (pour « sécurité »), déclenchée lorsqu’un
pointeur contrôlé par l’utilisateur et pointant vers le noyau est déréférencé (le cas que86 CHAPITRE 6. EXTENSIONS DE TYPAGE
l’on cherche à éviter). Il est important de noter que ce cas d’erreur est « virtuel », c’est-à-dire
qu’on l’ajoute à la sémantique pour pouvoir le détecter facilement comme un cas d’erreur,
mais, dans une sémantique de plus bas niveau, comme en C, l’erreur ne serait pas déclenchée.
D’un point de vue opérationnel, cela équivaut à ajouter un test dynamique à chaque
déréférencement, ce qui est sûr mais se paye en performances. Ajouter ce cas d’erreur virtuel
dans la sémantique d’évaluation permet de transformer un problème de sécurité (empêcher
les fuites d’information) en problème de sûreté (empêcher les erreurs à l’exécution).
Ensuite, on montre qu’avec cet ajout, si on étend naïvement le système de types en donnant
le même type aux pointeurs contrôlés par l’utilisateur et le noyau, le théorème de progrès
(5.1) n’est plus valable. Cela signifie que le système de types classique présenté dans le
chapitre 5 ne suffit pas à capturer les propriétés de sécurité que nous voulons interdire.
L’étape suivante est d’étendre, à son tour, le système de types de SAFESPEAK en distinguant
les types des pointeurs contrôlés par l’utilisateur des pointeurs contrôlés par le noyau.
Puisqu’on veut interdire le déréférencement des premiers par l’opérateur *, on introduit les
constructions copy_from_user et copy_to_user qui réaliseront le déréférencement sûr de ces
pointeurs.
Enfin, une fois ces modifications faites, on prouve que les propriétés de progrès et de
préservation sont rétablies.
6.2.1 Extensions noyau pour SAFESPEAK
On ajoute à SAFESPEAK la notion de valeur provenant de l’espace utilisateur. Pour marquer
la séparation entre les deux espaces d’adressage, on ajoute une construction ϕ ::= ♦� ϕ�
.
Le chemin interne ϕ� désigne une variable classique (un pointeur noyau) et l’opérateur ♦� ·
permet de l’interpréter comme un pointeur vers l’espace utilisateur. En quelque sorte, on ne
classifie pas les valeurs selon la variable pointée mais selon la construction du pointeur.
Remarquons qu’on n’introduit pas de sous-typage : les pointeurs noyau ne peuvent être
utilisés qu’en tant que pointeurs noyau, et les pointeurs utilisateur qu’en tant que pointeurs
utilisateur.
En plus du déréférencement par * (qui devra donc renvoyer Ωsec pour les valeurs de la
forme ♦� ϕ�
), il faut aussi ajouter des constructions de lecture et d’écriture à travers les pointeurs
utilisateur. Ceci sera fait sous forme de deux fonctions, copy_from_user et
copy_to_user. Celles-ci prennent deux pointeurs en paramètre et renvoient un booléen indiquant
si la copie a pu être faite (si le paramètre contrôlé par l’utilisateur pointe en espace
noyau, les fonctions ne font pas la copie et signalent l’erreur).
Illustrons ceci par un exemple. Imaginons un appel système fictif qui renvoie la version
du noyau, en remplissant par pointeur une structure contenant les champs entiers major,
minor et patch (un équivalent dans Linux est l’appel système uname()). Celui-ci peut être
alors écrit comme dans la figure 6.5. Une fois la structure noyau v remplie, il faut la copier
vers l’espace utilisateur. La fonction copy_to_user va réaliser cette copie (de la même manière
qu’avec un memcpy()), mais après avoir testé dynamiquement que p pointe en espace
utilisateur (dans le cas contraire, la copie n’est pas faite).
On peut remarquer que, contrairement aux fonctions présentes dans le noyau Linux, les
fonctions copy_from_user et copy_to_user n’ont pas de paramètre indiquant la taille à copier.
Cela est dû au fait que le modèle mémoire de SAFESPEAK est de plus haut niveau. L’information
de taille est déjà présente dans chaque valeur.
Une autre remarque à faire est qu’il n’y a pas de manière de copier des données de l’espace
utilisateur vers l’espace utilisateur. Il est nécessaire de passer par l’espace noyau. La
raison est que, puisqu’il faut réaliser deux tests dynamiques, les erreurs peuvent arriver à ces6.2. ANALYSE DE PROVENANCE DE POINTEURS 87
sys_getver = fun(p){
DECL v = { major : 3;minor : 14;patch : 15 } IN
copy_to_user(p,&v)
}
FIGURE 6.5 : Implantation d’un appel système qui remplit une structure par pointeur
Expressions e ::= ...
| ♦ l v Adresse utilisateur
| copy_from_user(ed ,es) Lecture depuis l’espace utilisateur
| copy_to_user(ed ,es) Écriture vers l’espace utilisateur
Contextes C ::= ...
| ♦ C
| copy_from_user(C,e)
| copy_from_user(v,C)
| copy_to_user(C,e)
| copy_to_user(v,C)
Chemins ϕ ::= ...
| ♦� ϕ Pointeur utilisateur
Erreurs Ω ::= ...
| Ωsec Erreur de sécurité
FIGURE 6.6 : Ajouts liés aux pointeurs utilisateur (par rapport à l’interprète du chapitre 4)
deux endroits. Plutôt que de proposer un opérateur qui réalise cette copie, on laisse le programmeur
faire les deux copies manuellement.
On commence donc par ajouter aux instructions des constructions copy_to_user(·,·) et
copy_from_user(·,·) de copie sûre. copy_from_user(pk ,pu) copie la valeur pointée par pu
(qui se trouve en espace utilisateur) à l’emplacement mémoire pointé par pk (en espace
noyau). copy_to_user(pu,pk ) réalise l’opération inverse, en copiant la valeur pointée par pk
(en espace noyau) à l’emplacement mémoire pointé par pu (en espace utilisateur).
Afin de leur donner une sémantique, il faut étendre l’ensemble des valeurs pointeur ϕ aux
constructions de la forme ♦� ϕ�
. Pour créer des termes s’évaluant en de telles valeurs, il faut
une construction syntaxique ♦ e telle que, si e s’évalue en &� ϕ, ♦ e s’évalue en &� ♦� ϕ. Cela
demande 2 autres ajouts : un nouveau contexte d’évaluation ♦ C et une règle d’évaluation.
Enfin, on ajoute une nouvelle erreur Ωsec à déclencher lorsqu’on déréférence directement un
pointeur utilisateur. Ces étapes sont résumées dans la figure 6.6.
En résumé, on a deux constructions pour créer des pointeurs à partir d’une valeur gauche :88 CHAPITRE 6. EXTENSIONS DE TYPAGE
& · crée un pointeur noyau, et ♦ · crée un pointeur utilisateur. Seule la première est faite pour
être utilisée dans le code à analyser. La seconde sert uniquement à modéliser les points d’entrée
du noyau. Par exemple, la fonction sys_getver de la figure 6.5 peut être appelée par un
utilisateur de la manière décrite dans la figure 6.7.
DECL v = { major : 0;minor : 0;patch : 0 } IN
sys_getver(♦ v)
FIGURE 6.7 : Appel de la fonction sys_getver de la figure 6.5
6.2.2 Extensions sémantiques
En ce qui concerne l’évaluation des expressions ♦ ·, on ajoute la règle suivante :
〈♦ ϕ,m〉 → 〈& ( � ♦� ϕ),m〉
(PHI-USER)
Dans & ( � ♦� ϕ), l’opérateur &� · indique que la valeur créée est une référence mémoire. Cette
référence mémoire, ♦� ϕ, est contrôlée par l’utilisateur. C’est ce qu’indique le constructeur ♦� ·
Cette règle semble asymétrique. C’est lié au fait qu’habituellement, les valeurs pointeurs
(de la forme &� Φ) sont crées en utilisant la règle CTX avec l’opérateur &. Ici une expression
crée une valeur pointeur, il faut donc y insérer un &. En effet, � ♦� · n’est qu’une transformation
entre chemins, pas une manière de construire une valeur à partir d’un chemin comme &. �
Ensuite, il est nécessaire d’adapter les règles d’accès à la mémoire pour déclencher une
erreur Ωsec en cas de déréférencement d’un pointeur utilisateur. Les accès mémoire en lecture
proviennent de la règle EXP-LV et ceux en lecture, de la règle EXP-SET, rappellées ici :
〈ϕ,m〉 → 〈m[ϕ]Φ,m〉
(EXP-LV )
〈ϕ ← v,m〉 → 〈v,m[ϕ ← v]Φ〉
(EXP-SET)
Les accès à la mémoire sont en effet faits par le biais de la lentille Φ. Il suffit donc d’adapter
sa définition (page 52) de celle-ci en rajoutant les cas suivant :
getΦ(♦� ϕ) = Ωsec
putΦ(♦� ϕ, v) = Ωsec
Enfin, il est nécessaire de donner une sémantique aux fonctions copy_from_user et
copy_to_user. L’idée est que celles-ci testent dynamiquement la valeur du paramètre
contrôlé par l’utilisateur afin de vérifier que celui-ci pointe vers l’espace utilisateur (c’est-
à-dire, qu’il est de la forme ♦� ϕ).
Deux cas peuvent se produire. Soit la partie à vérifier a la forme ♦� ϕ�
, soit non (et dans ce
cas �ϕ�
,ϕ = ♦� ϕ�
). Dans le premier cas (règles USER-*-OK), alors la copie est faite et l’opération
de copie retourne la valeur entière 0. Dans le second (règles USER-*-ERR), aucune copie
n’est faite et la valeur −1 est retournée. Ce comportement est calé sur celui des fonctions
copy_{from,to}_user du noyau Linux : en cas de succès elles renvoient 0, et en cas d’erreur
-EFAULT (= −14).6.2. ANALYSE DE PROVENANCE DE POINTEURS 89
v = m[ϕs]Φ m� = m[ϕd ← v]Φ
〈copy_from_user(&� ϕd ,& ( � ♦� ϕs)),m〉 → 〈0,m�
〉
(USER-GET-OK)
� ϕs.ϕ = ♦� ϕs
〈copy_from_user(&� ϕd ,&� ϕ),m〉 → 〈−14,m〉
(USER-GET-ERR)
v = m[ϕs]Φ m� = m[ϕd ← v]Φ
〈copy_to_user(& ( � ♦� ϕd ),&� ϕs),m〉 → 〈0,m�
〉
(USER-PUT-OK)
� ϕd .ϕ = ♦� ϕd
〈copy_to_user(&� ϕ,&� ϕs),m〉 → 〈−14,m〉
(USER-PUT-ERR)
Ces règles sont à appliquer en priorité de la règle d’appel de fonction classique, puisqu’il
s’agit d’élements de syntaxe différents. En effet ces « fonctions » ne sont pas implantables
directement en SAFESPEAK, puisqu’il n’y a pas par exemple d’opérateur permettant d’extraire
ϕ depuis une valeur ♦� ϕ. L’opération en « boîte noire » de ces deux fonctions permet d’assurer
que l’accès à l’espace utilisateur est toujours couplé à un test dynamique.
6.2.3 Insuffisance des types simples
Étant donné SAFESPEAK augmenté de cette extension sémantique, on peut étendre naï-
vement le système de types avec la règle suivante :
Γ � l v : t
Γ � ♦ l v : t ∗ (ADDR-USER-IGNORE)
Cette règle est compatible avec l’extension, sauf qu’elle introduit des termes qui sont bien
typables mais dont l’évaluation provoque une erreur Ωsec ∉ {Ωd i v ,Ωar r ay ,Ωp t r }, violant ainsi
le théorème 5.1. Posons :
e = ∗♦ x
Γ = x : INT
m = ([[x �→ 0]], [ ])
Les hypothèses du théorème de progrès sont bien vérifiées, mais cependant la conclusion
n’est pas vraie :
• On a bien Γ � m. En effet :
[ ] � ([ ], [ ])
(M-EMPTY)
[ ] � 0 : INT INT�INT
x : INT � ([[x �→ 0]], [ ])
(M-PUSH)
• e est bien typée sous Γ :90 CHAPITRE 6. EXTENSIONS DE TYPAGE
x : INT ∈ Γ
Γ � x : INT
(LV-VAR)
Γ � &x : INT∗ (LV-DEREF)
Γ � ♦ x : INT∗ (ADDR-USER-IGNORE)
Γ � ∗♦ x : INT
(LV-DEREF)
• L’évaluation de e sous m provoque une erreur différente de Ωd i v , Ωar r ay , ou Ωp t r :
m[♦� x] = Ωsec
〈∗♦ x,m〉 → 〈Ωsec ,m〉
(EXP-LV )
〈Ωsec ,m〉 → Ωsec
(EVAL-ERR)
〈e,m〉 → Ωsec
Cela montre que le typage n’apporte plus de garantie de sûreté sur l’exécution : le système
de types naïvement étendu par une règle comme ADDR-USER-IGNORE n’est pas en adéquation
avec les extensions présentées dans la section 6.2.1. Il faut donc raffiner les règles de
typage pour interdire ce cas.
6.2.4 Extensions du système de types
On présente ici un système de types plus expressif permettant de capturer les extensions
de sémantique. In fine, cela permettra de prouver le théorème 6.1 qui est l’équivalent du théorème
5.1 mais pour le nouveau jugement de typage.
Définir un nouveau système de types revient à étendre le jugement de typage · � · : ·,
en modifiant certaines règles et en en ajoutant d’autres. Naturellement, la plupart des diffé-
rences porteront sur le traitement des pointeurs.
Pointeurs utilisateur
Le changement clef est l’ajout de pointeurs utilisateur. En plus des types pointeurs habituels
t ∗, on ajoute des types pointeurs utilisateur t @. La différence entre les deux représente
qui contrôle leur valeur (section 2.4).
Les différences sont les suivantes (figure 6.8) :
• Les types « t ∗ » s’appliquent aux pointeurs contrôlés par le noyau. Par exemple, prendre
l’adresse d’un objet de la pile noyau donne un pointeur noyau.
Type t ::= ...
| t @ Pointeur utilisateur
Type
de valeur
τ ::= ...
| τ @ Pointeur utilisateur
FIGURE 6.8 : Ajouts liés aux pointeurs utilisateur (par rapport aux figures 5.2 et 5.5)6.2. ANALYSE DE PROVENANCE DE POINTEURS 91
• Les types « t @ », quant à eux, s’appliquent aux pointeurs qui proviennent de l’espace
utilisateur. Ces pointeurs proviennent toujours d’interfaces particulières, comme les
appels système ou les paramètres passés aux implantations de la fonction ioctl.
L’ensemble des notations est résumé dans le tableau suivant :
Noyau Utilisateur
Syntaxe & x ♦ x
Valeur & ( � x) &� ♦� (x)
Type t ∗ t @
Accès ∗ x copy_*_user
Puisqu’on s’intéresse à la provenance des pointeurs, détaillons les règles qui créent, manipulent
et utilisent des pointeurs.
Sources de pointeurs
La source principale de pointeurs est l’opérateur & qui prend l’adresse d’une variable.
Celle-ci est bien entendue contrôlée par le noyau (dans le sens où son déréférencement est
toujours sûr). Cette construction crée donc des pointeurs noyau, et on maintient la règle suivante
:
Γ � l v : t
Γ � &l v : t ∗ (ADDR)
Manipulations de pointeurs
L’avantage du typage est que celui-ci suit le flot de données : si à un endroit une valeur de
type t est affectée à une variable, que le contenu de cette variable est placé puis retiré d’une
structure de données, il conserve ce type t. En particulier un pointeur utilisateur reste un
pointeur utilisateur.
Une seule règle consomme un pointeur et en retourne un. Elle concerne l’arithmétique
des pointeurs. On ne l’étend pas aux pointeurs utilisateur, car pour effectuer de l’arithmé-
rique, il faut observer la forme du pointeur sous-jacent. Si on veut laisser ♦� · opaque, il faut
donc interdire l’arithmétique sur les pointeurs utilisateur.
Utilisations de pointeurs
La principale restriction est que seuls les pointeurs noyau peuvent être déréférencés de
manière sûre. La règle capitale est donc la suivante (déjà introduite dans le chapitre 5) :
Γ � e : t ∗
Γ � ∗e : t
(LV-DEREF)
Ainsi, on interdit le déréférencement des expressions de type t @ à la compilation.
L’opérateur ♦ · transforme un pointeur selon la règle suivante :
Γ � l v : t
Γ � ♦ l v : t @
(ADDR-USER)92 CHAPITRE 6. EXTENSIONS DE TYPAGE
Les « fonctions » copy_from_user et copy_to_user sont typées de la manière suivante. Il
est à remarquer que ce ne sont pas vraiment des fonctions et qu’elles n’ont pas un type en
(t1,t2) → t, car il faudrait un type polymorphe pour pouvoir les appliquer à n’importe quel
type de pointeurs. Leur typage est donc plus proche de celui d’un opérateur.
Γ � ed : t ∗ Γ � es : t @
Γ � copy_from_user(ed ,es) : INT
(USER-GET)
Γ � ed : t @ Γ � es : t ∗
Γ � copy_to_user(ed ,es) : INT
(USER-PUT)
6.2.5 Sûreté du typage
Typage sémantique
La définition du typage sémantique doit aussi être étendue au cas ϕ = ♦� ϕ�
. En essence,
S-USERPTR énonce que traverser un constructeur ♦� · transforme un pointeur en pointeur
utilisateur.
m � &� ϕ : τ ∗
m � &� ♦� ϕ : τ @
(S-USERPTR)
τ�t
τ @�t @
(COMP-PTR)
Propriétés du typage
Lemme 6.1 (Inversion du typage). En plus des cas présentés dans le lemme 5.1, les cas suivants
permettent de remonter un jugement de typage.
• Si Γ � ♦ e : t, alors il existe t� tel que t = t� @ et Γ � e : t�
.
• Si Γ � copy_from_user(ed ,es) : t, alors t = INT et il existe t� tel que Γ � ed : t ∗ et Γ � es :
t @.
• Si Γ � copy_to_user(ed ,es) : t, alors t = INT et il existe t� tel que Γ � ed : t @ et Γ � es : t ∗.
Démonstration. Pour chaque forme syntaxique, on liste les règles qui ont comme conclusion
un jugement de typage portant sur celle-ci. Comme aucune autre règle ne convient, on peut
en déduire que c’est l’une de celles-ci qui a été appliquée, et donc qu’une des prémisses est
vraie.
Progrès et préservation
La propriété que nous cherchons à prouver est que le déréférencement d’un pointeur
dont la valeur est contrôlée par l’utilisateur ne peut se faire qu’à travers une fonction qui
vérifie la sûreté de celui-ci.
En fait il s’agit des théorèmes de sûreté du chapitre précédent.
Théorème 6.1 (Progrès pour les extensions noyau). Le théorème 5.1 reste valable avec les extensions
de ce chapitre.
La preuve de ce théorème est en annexe D.4.
Théorème 6.2 (Préservation pour les extensions noyau). Le théorème 5.2 reste valable avec les
extensions de ce chapitre.6.2. ANALYSE DE PROVENANCE DE POINTEURS 93
La preuve de ce théorème est en annexe D.5.
Ces extensions ne modifient pas les théorème de progrès et préservation sur les phrases
(théorèmes 5.3 et 5.4).
La sûreté du typage étant à nouveau établie, on a montré que l’ajout de types pointeurs
utilisateur suffit pour avoir une adéquation entre les extensions de sémantique de la section
6.2.1 et les extensions du système de type de la section 6.2.4.
Conclusion
En partant de SAFESPEAK tel que décrit dans les chapitres 4 et 5, on décrit une extension
de sa syntaxe et de sa sémantique. Cela permet d’exprimer les pointeurs vers l’espace utilisateur,
qui sont utilisés pour l’implantation d’appels système (chapitre 2).
Une première idée pour le typage de ces nouveaux pointeurs est de leur donner le même
type que les pointeurs classiques. On a montré ensuite que ce typage naïf ne suffit pas : il
permet en effet de faire fuiter de l’information, ce qu’on note par un cas d’erreur Ωsec . En
termes de systèmes de types, cela signifie que le théorème de progrès (théorème 5.1, page 77)
n’est plus vérifié.
Le langage des types est donc enrichi pour séparer les pointeurs utilisateur des pointeurs
noyau : les premiers sont explicitement construits par un ensemble de sources bien déterminé,
et les autres sont créés par exemple en prenant l’adresse d’une variable. La règle de typage
LV-DEREF assure que seuls les pointeurs noyau peuvent être déréférencés. Pour accéder
aux pointeurs utilisateur, il faut appeler les constructions copy_to_user et copy_from_user,
qui sont typées adéquatement et vérifient dynamiquement que les pointeurs dont la valeur
est contrôlée par l’utilisateur pointent vers l’espace utilisateur.CONCLUSION DE LA PARTIE II
On vient de décrire en détail un langage impératif, SAFESPEAK, et tout d’abord sa syntaxe
et sa sémantique d’évaluation dans le chapitre 4. Une des spécificités de cette sémantique est
l’utilisation de lentilles pour modifier les valeurs composées en profondeur.
Il y a plusieurs alternatives à cette présentation. La première est la solution classique qui
consiste à décrire les modifications de la mémoire en extension. C’est en général long et laborieux
puisqu’il faut définir les accès en lecture et écriture à chaque étape (avec des lentilles
on décrit ces deux opérations uniquement sur les briques du calcul, et la composition fait le
reste). La seconde solution est d’employer une sémantique monadique. Les transitions sont
alors encodées comme des actions monadiques qui représentent les modifications de la mé-
moire. Un des avantages de cette solution est qu’elle est très extensible. Par exemple, la propagation
des erreurs ou l’ajout de continuations légères (c’est-à-dire le support des fonctions
setjmp et longjmp) peuvent facilement être exprimés dans un formalisme monadique. Nous
avons préféré une présentation plus directe qui reste plus accessible à une audience habituée
à C, et suffisante compte tenu de la simplicité des constructions à interpréter dans le langage.
Ensuite, dans le chapitre 5, nous avons ajouté un système de types à SAFESPEAK. Le but
est de restreindre le genre d’erreurs qui peuvent arriver lors de l’évaluation d’un programme.
Par le théorème de progrès (théorème 5.1 , page 77), on interdit les erreurs qui signalent une
manipulation de valeurs incompatibles, l’accès à un champ de structure inconnu, et l’accès
à une variable inexistante. Et le théorème de préservation (théorème 5.2, page 78) formalise
le résultat classique qu’une étape d’évaluation ne modifie pas le typage. Une particularité de
SAFESPEAK est que son état mémoire est structuré, avec une pile de variables locales explicite.
On retrouve donc cette distinction dans le typage : les variables globales et les variable locales
sont séparées dans les environnements de typage Γ (page 64).
Enfin, dans le chapitre 6, on a étendu le langage pour exprimer la notion de pointeurs
utilisateur. Cela permet d’écrire des fonctions qui implantent des appels système. On a commencé
par montrer qu’une extension naïve du système de types ne suffit pas, car le théorème
de progrès est alors invalidé. On ajoute donc un type dédié aux pointeurs utilisateur. Les valeurs
de ce type sont créées explicitement et passées aux appels système. La règle de typage
du déréférencement est restreinte aux pointeurs noyau, ce qui permet de ré-établir les théorèmes
de progrès et préservation.
Notre technique de typage permet donc d’exprimer correctement les problèmes liés à la
manipulation mémoire lors des appels système, ainsi que décrits dans le chapitre 2 : c’est
une méthode simple pour détecter et empêcher les problèmes de sécurité qui proviennent
des pointeurs utilisateur.
Comme nous l’avons fait remarquer dans le chapitre 3, utiliser une technique de typage
pour étudier des propriétés sur les données a déjà été explorée dans l’outil CQual [FFA99], en
particulier sur les problèmes de pointeurs utilisateur [JW04].
En effet, si on remplace « t ∗ » par « KERNEL t ∗ » et « t @ » par « USER t ∗ », on obtient un
début de système de types qualifiés.
En revanche, il y a une différence importante : CQual modifie fondamentalement l’ensemble
du système de types, pas SAFESPEAK. Le jugement de typage de CQual a pour forme
générale Γ � e : q t (où Γ est un environnement de typage, e une expression, q un qualificateur
et t un type), alors que le nôtre a la forme plus classique Γ � e : t.
9596 CHAPITRE 6. EXTENSIONS DE TYPAGE
En intégrant q à la relation de typage, on ajoute un qualificateur à chaque type, même les
expressions pour lesquelles il n’est pas directement pertinent de déterminer qui les contrôle
(comme par exemple, un entier). Dans CQual, ceci permet de traiter de manière correcte le
transtypage. Par exemple, si e a pour type qualifié USER INT, alors (FLOAT ∗) e aura pour
type qualifié USER FLOAT ∗, et déréférencer cette expression produira une erreur de typage.
SAFESPEAK, dans son état actuel, ne permet pas de traiter les conversions de type et ne permet
donc pas de traiter ce cas.
Nous prenons, au contraire, l’approche de ne modifier le système de types que là où cela
est nécessaire, c’est-à-dire sur les types pointeurs. Cela permet de ne pas avoir à modifier en
profondeur un système de types existant.
Le modèle d’exécution est aussi très différent. CQual s’appuie sur un langage proche de
ML : un noyau de lambda-calcul avec des références. Le système de types sous-jacent est
proche de celui d’OCaml : du polymorphisme de premier ordre (avec la restriction habituelle
de généralisation des références) et du sous-typage structurel. En outre, leur approche repose
sur une gestion automatique de la mémoire. De notre côté, nous nous appuyons sur un modèle
mémoire plus proche de C, reposant sur une pile de variables et des pointeurs manipulés
à la main.
Une autre différence fondamentale est que le système de types de CQual fait intervenir
une relation de sous-typage. Le cas particulier du problème de déréférencement des pointeurs
utilisateur peut être traité dans ce cadre en posant KERNEL � USER pour restreindre
certaines opérations aux pointeurs KERNEL.
Notre approche, au contraire, n’utilise pas de sous-typage, mais consiste à définir un type
abstrait t @ partageant certaines propriétés avec t ∗ (comme la taille et la représentation)
mais incompatible avec certaines opérations. C’est à rapprocher des types abstraits dans les
langages comme OCaml et Haskell.
Les perspectives de travaux futurs sont également très différentes. Dans le cas des pointeurs,
même si le noyau Linux (et la plupart des systèmes d’exploitation) ne comportent que
deux espaces d’adressage, il est commun dans les systèmes embarqués de manipuler des
pointeurs provenant d’espaces mémoire indépendants : par exemple, de la mémoire flash, de
la RAM, ou une EEPROM de configuration. Ces différentes mémoires possèdent des adresses,
et un pointeur est interprété comme faisant référence à une ou l’autre selon le code dont il est
tiré. Lorsqu’il y a plus de deux espaces mémoire, aucun n’est plus spécifique que les autres :
le sous-typage, et donc un système de qualificateurs, n’est donc plus adapté. Au contraire il
est possible de créer un type de pointeurs pour chaque zone mémoire.Troisième partie
Expérimentation
Après avoir décrit notre solution dans la partie II, on présente ici son implantation.
Le chapitre 7 décrit l’implantation en elle-même : un prototype d’analyseur
de types, distribué avec le langage NEWSPEAK sur [☞3]. Il s’agit d’un logiciel libre,
distribué sous la license LGPL. La compilation depuis C est réalisée par l’utilitaire
C2NEWSPEAK. Celui-ci, tout comme le langage NEWSPEAK, proviennent d’EADS et
sont antérieurs à ce projet, mais le support de plusieurs extensions GNU C a été
développé spécialement pour pouvoir analyser le code du noyau Linux.
L’analyse en elle-même est implantée de la manière classique avec une variation
de l’algorithme W de Damas et Milner. Pour des raisons de simplicité et d’efficacité,
l’unification est faite en utilisant le partage de références plutôt que des substitutions.
L’algorithme d’inférence ne pose pas de problèmes de performance.
Ensuite, dans le chapitre 8, on évalue cette implantation sur le noyau Linux. On
commence par décrire comment fonctionnennt les appels système sous ce noyau,
et comment le confused deputy problem évoqué dans le chapitre 2 peut arriver dans
ce contexte. Dans une deuxième partie, on décrit le cas de deux bugs dans le noyau
Linux. Le premier porte sur un pilote de carte graphique Radeon et le second sur
l’appel système ptrace sur l’architecture Blackfin. Ils manipulent de manière non
sécurisée des pointeurs provenant de l’espace utilisateur. On montre que, pour chacun,
les analyses précédentes permettent de distinguer statiquement le cas incorrect
du cas corrigé.
97C H A P I T R E
7
IMPLANTATION
Dans ce chapitre, nous décrivons la mise en œuvre des analyses statiques précédentes.
Celles-ci ont été décrites sur SAFESPEAK, qui permet de modéliser des programmes C bien
typables.
Notre but est d’utiliser la représentation intermédiaire NEWSPEAK, développée par EADS.
Cela permet de profiter des nombreux outils existant déjà autour de ce langage, notamment
un compilateur depuis C et un analyseur statique par interprétation abstraite.
Mais cette représentation utilise un modèle mémoire différent. En effet il colle finement
à celui de C, où des constructions comme les unions empêchent la sûreté du typage. Défi-
nir SAFESPEAK a précisement pour but de définir un langage inspiré de C mais sur lequel le
typage peut être sûr. Il faudra donc adapter les règles de typage des chapitres 5 et 6. On reviendra
sur cette distinction entre les deux niveaux de sémantique dans la conclusion de la
partie III, page 123.
On commence par décrire le langage NEWSPEAK. Ensuite, nous décrivons la phase de
compilation, de C à NEWSPEAK, auquel on rajoute ensuite des étiquettes de types. Cellesci
sont calculées par un algorithme d’inférence de types à la Hindley-Milner, reposant sur
l’unification et le partage de références. Toutes ces étapes sont implantées dans le langage
OCaml [LDG+10, CMP03].
Le prototype décrit ici est disponible sur [☞3] sous une license libre, la GNU Lesser General
Public License.
7.1 NEWSPEAK et chaîne de compilation
NEWSPEAK est un langage intermédiaire conçu pour être un bon support d’analyses statiques,
contrairement à des langages conçus pour les programmeurs comme C. Sa sémantique
d’exécution (ainsi qu’une partie des étapes de compilation) est décrite dans [HL08]. Sa
syntaxe est donnée dans la figure 7.1.
La traduction depuis C est faite en trois étapes : prétraitement du code source par un
outil externe, compilation séparée de C prétraité vers des objets NEWSPEAK, puis liaison de
ces différentes unités de compilation. Il est aussi possible de compiler directement du code
Ada vers un objet NEWSPEAK.
La première étape consiste à prétraiter les fichiers C source avec le logiciel cpp, comme
pour une compilation normale. Cette étape interprète les directives de prétraitement comme
#include, #ifdef. À cet étape, les commentaires sont aussi supprimés.
99100 CHAPITRE 7. IMPLANTATION
Instruction s ::= Set(l v,e,st) Affectation
| Copy(l v,l v,n) Copie
| Guard(e) Garde
| Decl(var,t,bl k) Déclaration
| Select(bl k,bl k) Branchement
| InfLoop(bl k) Boucle infinie
| DoWith(bl k,x) Nommage de bloc
| Goto(x) Saut
| Call([(ei ,ti)], f , [(l vi ,ti)]) Appel de fonction
Bloc bl k ::= [si] Liste d’instructions
Valeur gauche l v ::= Local(x) Locale
| Global(x) Globale
| Deref(e,n) Déréférencement
| Shift(l v,e) Décalage
Expression e ::= CInt(n) Entier
| CFloat(d) Flottant
| Nil Pointeur nul
| Lval(l v,t) Accès mémoire
| AddrOf(l v) Adresse de variable
| AddrOfFun(x, [ti], [ti]) Adresse de fonction
| UnOp(unop,e) Opérateur unaire
| BinOp(binop,e1,e2) Opérateur binaire
Fonction f ::= FunId(x) Appel par nom
| FunDeref(e) Appel par pointeur
Type t ::= Scalar(st) Type scalaire
| Array(t,n) Tableau
| Region([(ni ,ti)],n�
) Structure/union
Type scalaire st ::= Int(n) Entier
| Float(n) Flottant
| Ptr Pointeur sur données
| FunPtr Pointeur sur fonction
FIGURE 7.1 : Syntaxe simplifiée de NEWSPEAK7.1. NEWSPEAK ET CHAÎNE DE COMPILATION 101
Une fois cette passe effectuée, le résultat est un ensemble de fichiers C prétraités ; c’est-
à-dire des unités de compilation.
Sur cette représentation (du C prétraité), il est possible d’ajouter des annotations de la
forme /*!npk [...] */ qui pourront être accessibles dans l’arbre de syntaxe abstraite des
passes suivantes.
À ce niveau, les fichiers sont passés à l’outil C2NEWSPEAK qui les traduit vers NEWSPEAK.
Comme il sera décrit dans la section 8.1, la plupart des extensions GNU C sont acceptées
en plus du C ANSI. Dans cette étape, les types et les noms sont résolus, et le programme est
annoté de manière à rendre les prochaines étapes indépendantes du contexte. Par exemple,
chaque déclaration de variable est adjointe d’une description complète du type.
Lors de cette étape, le flot de contrôle est également simplifié (figure 7.2). De plus, les
constructions ambigües en C comme i = i++ sont transformées pour que leur évaluation
se fasse dans dans un ordre explicite. Un choix arbitraire est alors fait ; par exemple, les arguments
de fonctions sont évalués de droite à gauche (la raison étant sur Intel, les arguments
sont empilés dans ce sens).
Au contraire, NEWSPEAK propose un nombre réduit de constructions. Rappelons que le
but de ce langage est de faciliter l’analyse statique : des constructions orthogonales permettent
donc d’éviter la duplication de règles sémantiques, ou de code, lors de l’implantation
d’un analyseur.
Par exemple, plutôt que de fournir une boucle while, une boucle do/while et une boucle
for, NEWSPEAK fournit une unique boucle WHILE(1){·}. La sortie de boucle est compilée vers
un GOTO [EH94], qui est toujours un saut vers l’avant (similaire à un « break » généralisé).
NEWSPEAK est conçu pour l’analyse statique par interprétation abstraite. Il a donc une
vue de bas niveau sur les programmes. Par exemple, aucune distinction n’est faite entre l’accès
à un champ et l’accès à un élément d’un tableau (tous deux sont traduits par un décalage
numérique depuis le début de la zone mémoire). De plus, les unions et les structures sont regroupées
sous forme des types « régions » qui associent à un décalage un type de champ. Pour
supprimer ces ambiguïtés, il faut s’interfacer dans les structures internes de C2NEWSPEAK, où
les informations nécessaires sont encore présentes.
int x;
x = 0;
while (x < 10) {
x++;
}
int32 x;
x =(int32) 0;
do {
while (1) {
choose {
-->
guard((10 > x_int32));
-->
guard(! (10 > x_int32));
goto lbl1;
}
x =(int32) coerce[-2**31,2**31-1] (x_int32 + 1);
}
} with lbl1: {
}
FIGURE 7.2 : Compilation du flot de contrôle en NEWSPEAK. Le code source C, à gauche, est
compilé en NEWSPEAK, à droite.102 CHAPITRE 7. IMPLANTATION
Ensuite, les différents fichiers sont liés ensemble. Cette étape consiste principalement à
s’assurer que les hypothèses faites par les différentes unités de compilation sont cohérentes
entre elles. Les objets marqués static, invisibles à l’extérieur de leur unité de compilation,
sont renommés afin qu’ils aient un nom globalement unique. Cette étape se conclut par la
création d’un fichier NEWSPEAK.
7.2 L’outil ptrtype
La dernière étape est réalisée dans un autre outil nommé ptrtype, d’environ 1600 lignes
de code OCaml, et réalisé dans le cadre de cette thèse. Elle consiste en l’implantation d’un
algorithme d’inférence pour les systèmes de types décrits dans les chapitres 5 et 6. Puisqu’ils
sont suffisamment proches du lambda calcul simplement typé, on peut utiliser une variante
de l’algorithme W de Damas et Milner [DM82].
Cela repose sur l’unification : on dispose d’une fonction permettant de créer des inconnues
de type, et d’une fonction pour unifier deux types partiellement inconnus. En pratique,
on utilise l’optimisation classique qui consiste à se reposer sur le partage de références pour
réaliser l’unification, plutôt que de faire des substitutions explicites. Puisque ces systèmes de
types sont monomorphes, on présente une erreur si des variable de type libres sont présentes.
Architecture de ptrtype
Bâti autour de cette fonction, le programme ptrtype lit un programme NEWSPEAK et réalise
l’inférence de types. Si l’argument passé à ptrtype est un fichier C, il est tout d’abord
compilé vers NEWSPEAK grâce à l’utilitaire C2NEWSPEAK. En sortie, il affiche soit le programme
complètement annoté, soit une erreur. Ce comportement est implanté dans la fonction de la
figure 7.3.
• Grâce à la fonction convert_unit : Newspeak.t -> unit Tyspeak.t, on ajoute des
étiquettes « vides » (toutes égales à () : unit) 1.
• L’ensemble des fonctions du programme est trié topologiquement selon la relation �
définie par f � g
def
== « g apparaît dans la définition de f ». Cela est fait en construisant
une représentation de � sous forme de graphe, puis en faisant un parcours en largeur
de celui-ci. Pour le moment, les fonctions récursives et mutellement récursives ne sont
pas supportées.
• Les annotations extérieures sont alors lues (variable exttbl), ce qui permet de créer un
environnement initial. On peut y introduire les annotations suivantes :
Annotation Signification
/*!npk f : (Int) -> Int */ f est une fonction prenant comme argument
un entier et renvoyant un entier.
/*!npk userptr x */ x a pour type a @, où a est une nouvelle inconnue
de type.
/*!npk userptr_fieldp x f */ x a pour type {f : a @;...} ∗, où a est une
nouvelle inconnue de type.
• Les types de chaque fonction sont ensuite inférés, par le biais de la fonction suivante :
1. ’a Tyspeak.t est le type des programmes NEWSPEAK où on insère des étiquettes de type ’a à tous les
niveaux.7.2. L’OUTIL PTRTYPE 103
let process_npk npk =
let tpk = Npk2tpk.convert_unit npk in
let order = Topological.topological_sort (Topological.make_graph npk) in
let function_is_defined f =
Hashtbl.mem tpk.Tyspeak.fundecs f
in
let (internal_funcs, external_funcs) =
List.partition function_is_defined order
in
let exttbl = Printer.parse_external_type_annotations tpk in
let env =
env_add_external_fundecs exttbl external_funcs Env.empty
in
let s = Infer.infer internal_funcs env tpk in
begin
if !Options.do_checks then
Check.check env s
end;
Printer.dump s
FIGURE 7.3 : Fonction principale de ptrtype
val infer : Newspeak.fid list (* liste triée de fonctions à typer *)
-> Types.simple Env.t (* environnement initial *)
-> 'a Tyspeak.t (* programme à analyser *)
-> Types.simple Tyspeak.t
• S’il n’y a pas d’erreurs, le programme obtenu, de type Types.simple Tyspeak.t, est
affiché sur le terminal.
Unification
La fonction unify prend en entrée deux représentations de types pouvant contenir des
inconnues de la forme Var n, et retourne une liste de contraintes indiquant les substitutions
à faire.
Cet algorithme est décrit en pseudo-code ML en figure 7.4. Pour simplifier, on le présente
comme retournant une liste, mais il est implanté de manière destructive : Var n contient une
référence qui peut être modifiée, et grâce au partage c’est équivalent à substituer dans tous
les types qui contiennent Var n.
La fonction d’unification prend un chemin différent selon la forme des deux types d’entrée
:
• si les deux types sont inconnus (de la forme Var n), on substitue l’un par l’autre.
• si un type est inconnu et pas l’autre, il faut de la même manière faire une substitution.
Mais en faisant ça inconditionnellement, cela peut poser problème : par exemple, en104 CHAPITRE 7. IMPLANTATION
Contrainte c ::= n �→ t Substitution
| (l : t) ∈ X Variable de rangée
1: function UNIFY(ta,tb)
2: match (ta,tb) with
3: | VAR na, VAR nb ⇒
4: if na = nb then
5: return [ ]
6: else
7: return [na �→ tb]
8: end if
9: | VAR na,tb ⇒
10: if OCCURS(na,tb) then
11: erreur
12: end if
13: return [na �→ tb]
14: | ta, VAR nb ⇒ return UNIFY(tb,ta)
15: | INT, INT ⇒ return [ ]
16: | FLOAT, FLOAT ⇒ return [ ]
17: | a[ ],b[ ] ⇒ return UNIFY(a,b)
18: | a ∗,b ∗ ⇒ return UNIFY(a,b)
19: | a @,b @ ⇒ return UNIFY(a,b)
20: | (la) → ra, (lb) → rb ⇒
21: r ← UNIFY(ra, rb)
22: n ← LENGTH(la)
23: if LENGTH(lb) �= n then
24: erreur
25: end if
26: for i = 0 to n −1 do
27: r ← r ∪ UNIFY(la[i],lb[i])
28: end for
29: return r
30: | A = {a1 : t1;...;an : tn;...Xa},B = {b1 : s1;...;bm : um;...Xb} ⇒
31: r ← �
32: for {(t,u)/∃l.(l : t) ∈ A ∧(l : u) ∈ B} do
33: r ← r ∪ UNIFY(t,u)
34: end for
35: for {(l,t) ∈ A/∀(l� : u) ∈ B.l �= l�
} do
36: r ← r ∪[(l : t) ∈ XB ]
37: end for
38: for {(l,u) ∈ B/∀(l� : t) ∈ A.l �= l�
} do
39: r ← r ∪[(l : u) ∈ XA]
40: end for
41: return r
42: | _ ⇒ erreur
43: end function
FIGURE 7.4 : Algorithme d’unification7.2. L’OUTIL PTRTYPE 105
let unify a b =
if !Options.lazy_unification then
Queue.add (Unify (a, b)) unify_queue
else
unify_now a b
FIGURE 7.5 : Unification directe ou retardée
tentant d’unifier a avec KPtr(a), on pourrait créer une substitution cyclique. Pour éviter
cette situation, il suffit de s’assurer que le type inconnu n’est pas présent dans le
type à affecter. C’est le but de la fonction occurs(n, t) qui calcule si Var n apparaît
dans t.
• si les deux types sont des types de base (comme INT ou FLOAT) égaux, on ne fait rien.
• si les deux types sont des constructeurs de type, il faut que les constructeurs soient
égaux. On unifie en outre leurs arguments deux à deux.
• dans les autres cas, l’algorithme échoue.
Le traitement des types structures est géré dans l’implantation d’une manière différente
de la présentation du chapitre 4. Au lieu d’accéder directement au type complet S à chaque
accès x.lS, on n’obtient qu’un nom de champ à chaque accès. C’est-à-dire qu’on va par exemple
inférer le type {l : INT;...X} où ...X désigne l’ensemble des champs inconnus (on rappelle
que dans la sémantique qui nous intéresse, ceux-ci n’ont pas un ordre défini au sein d’une
structure).
Plus précisément, si on cherche à unifier les types structures A = {a1 : t1;...;an : tn;...Xa}
et B = {b1 : s1;...;bm : um;...Xb}, il faut partitionner l’ensemble des champs en 3 : ceux qui
apparaissent dans les deux structures, ceux qui apparaissent dans A mais pas dans B, et ceux
qui apparaissent dans B mais pas dans A.
• Pour tous les champs l tels que l : t ∈ A et l : u ∈ B, on unifie t et u.
• Pour les champs l qui sont dans A mais pas dans B : on ajoute l à Xb.
• Pour les champs l qui sont dans B mais pas dans A : on ajoute l à Xa.
Cela se rapproche du polymorphisme de rangée [RV98] présent dans les langages comme
OCaml. À la fin de l’inférence, on considère que la variable de rangée « ...X » est vide. Elle
n’apparaît donc pas dans les types.
La fonction unify, appelée dans toutes les fonctions d’inférence, peut retarder l’unification
(figure 7.5). Dans ce cas, la paire de types à unifier est mise dans une liste d’attente qui
sera unifiée après le parcours du programme. Le but est d’instrumenter l’inférence de types
afin de pouvoir en faire une exécution « pas à pas ».
Inférence de types
Il ne reste plus qu’à remplacer les étiquettes de type unit par des étiquettes de type
simple (autrement dit de vraies représentations de types), à l’aide de la fonction unify.
Cette étape se fait de manière impérative. Cela permet de ne pas avoir à réaliser de substitutions
explicites. À la place, on repose sur le partage et les références, qui représentent
les inconnues de type. Lorsque celles-ci sont résolues, il suffit de muter une seule fois la ré-
férence, et le partage fait que ce changement sera visible partout. Plus précisément, on peut
créer de nouveaux types avec la fonction new_unknown et unifier deux types avec la fonction
unify. Leurs types sont :106 CHAPITRE 7. IMPLANTATION
val new_unknown : unit -> Types.simple
val unify : Types.simple -> Types.simple -> unit
La fonction infer s’appuie sur un ensemble de fonctions récursivement définies portant
sur chaque type de fragment : infer_fdec pour les déclarations de fonction, infer_exp pour
les expressions, infer_stmtkind pour les instructions, etc. Grâce au lemme 5.1, on sait quelle
règle appliquer en fonction de l’expression ou instruction considérée. Notons que, même
si le programme NEWSPEAK est décoré d’informations de types (celles qui existent dans le
programme C), elles ne sont pas utilisées.
Les règles de typage sont implantées par new_unknown et unify. Par exemple, pour typer
une déclaration (qui n’a pas de valeur initiale en NEWSPEAK), on crée un nouveau type t0. On
étend l’environnement courant avec cette nouvelle association et, sous ce nouvel environnement,
on type le bloc de portée de la déclaration (figure 7.6).
let rec infer_stmtkind env sk =
match sk with
(* [...] *)
| T.Decl (n, nty, _ty, blk) ->
let var = T.Local n in
let t0 = new_unknown () in
let new_env = Env.add (VLocal n) (Some nty) t0 env in
let blk’ = infer_blk new_env blk in
let ty = lval_type new_env var in
T.Decl (n, nty, ty, blk’)
(* [...] *)
| T.Call (args, fexp, rets) ->
let infer_arg (e, nt) =
let et = infer_exp env e in
(et, nt)
in
let infer_ret (lv, nt) =
(infer_lv env lv, nt)
in
let args’ = List.map infer_arg args in
let rets’ = List.map infer_ret rets in
let t_args = List.map (fun ((_, t), _) -> t) args’ in
let t_rets = List.map (fun (lv, _) -> lval_type env lv) rets’ in
let (fexp’, tf) = infer_funexp env fexp in
let call_type = Fun (t_args, t_rets) in
unify tf call_type;
T.Call (args’, fexp’, rets’)
FIGURE 7.6 : Inférence des déclarations de variable et appels de fonction
De même, pour typer un appel de fonction, on infère le type de ses arguments et valeurs
gauches de retour. On obtient également le type de la fonction (à partir du type de la fonction7.3. EXEMPLE 107
présent dans l’environnement, ou du type du pointeur de fonction qui est déréférencé), et on
unifie ces deux informations.
Pour additionner deux flottants, par exemple, on unifie leurs types avec FLOAT. Le résultat
est également de type FLOAT. Cela correspond à la règle OP-FLOAT.
let infer_binop op (_, a) (_, b) =
match op with
(* [...] *)
| N.PlusF _ ->
unify a Float;
unify b Float;
Float
Pour prendre l’adresse d’une variable, la règle ADDR s’applique : on prend le type de la
valeur gauche et on construit un pointeur noyau à partir de lui.
| T.AddrOf lv ->
let lv' = infer_lv env lv in
let ty = lval_type env lv in
(T.AddrOf lv', Ptr (Kernel, ty))
Enfin, pour déréférencer une expression, on unifie tout d’abord son type avec le type d’un
pointeur noyau.
| T.Deref(e, _sz) ->
let (_, te) = infer_exp env e in
let t = new_unknown () in
unify (Ptr (Kernel, t)) te;
t
7.3 Exemple
Lançons l’analyse sur un petit exemple (stocké dans le fichier example.c) :
int f(int *x) { return (*x + 1); }
L’exécution de notre analyseur affiche un programme complètement annoté :
% ptrtype example.c
1 f : (KPtr (Int)) -> (Int)
2 Int (example.c:1#4)^f(KPtr (Int) x) {
3 (.c:3#4)^!return =(int32)
4 (coerce[-2147483648,2147483647]
5 ( ( ([(x_KPtr (Int) : KPtr (Int))]32_Int
6 : Int
7 )
8 + (1 : Int)
9 ) : Int
10 ) : Int
11 );
12 }108 CHAPITRE 7. IMPLANTATION
• Ligne 1 : le type inféré de la fonction f est affiché. Il est calculé entièrement en fonction
des opérations effectuées ; on n’utilise pas les étiquettes de type du programme.
• Ligne 2 : le code de la fonction est affiché. Les indications de la forme (F:L#C)ˆX correspondent
à la déclaration d’une variable X, dans le fichier F, ligne L et colonne C.
• Ligne 3 : en NEWSPEAK, la valeur de retour est une variable qui est affectée. On sépare
ainsi le flot de données (définir la valeur de retour) du flot de contrôle (sortir de la
fonction). C’est un équivalent de la variable R introduite pour le typage des fonctions
(page 69). L’affectation est notée =(int32) car en NEWSPEAK elle est décorée du type
des opérandes. Cette information n’est pas utilisée dans l’inférence de types.
• Ligne 4 : l’opérateur coerce[a,b] sert à détecter les débordements d’entiers lors d’une
analyse de valeurs par interprétation abstraite. Dans le cas de notre analyse, les valeurs
ne sont pas pertinentes et cet opérateur peut être vu que comme l’identité.
• Ligne 5 : le déréférencement d’une valeur gauche e est noté [e]_n. Il est annoté par la
taille de l’opérande (32 bits ici). De plus, l’accès à une valeur gauche (pour la transformer
en expression) est annoté par son type, ce qui explique la verbosité de cette ligne.
• les autres lignes sont des étiquettes de type inférées sur les expressions 1, ∗x, 1, ∗x +1
et la valeur de retour coerce[−231, 231 −1](∗x +1).
Un exemple de détection d’erreur sera décrit dans la section 8.6.
7.4 Performance
Même s’il est simple en apparence, le problème de l’inférence de types par l’algorithme W
est EXP-complet [Mai90], c’est-à-dire que les algorithmes efficaces ont une complexité exponentielle
en la taille du programme. Cependant, lorsqu’on borne la « taille » des types, celle-ci
devient quasi-linéaire [McA03], ce qui signifie qu’il n’y a pas de problème de performance à
attendre en pratique.
Dans notre cas, on utilise une variante de l’algorithme W pour un langage particulièrement
simple. En particulier il n’y a pas de polymorphisme, ni de fonctions imbriquées, et
les types des valeurs globales sont écrites par le programmeur. Cela permet de borner leur
taille. En pratique, sur les exemples testés (jusqu’à quelques centaines de lignes de code)
nous n’avons pas noté de délai d’exécution notable.
En revanche, la compilation de C vers NEWSPEAK peut être plus coûteuse, notamment
lorsque le fichier d’entrée est de taille importante. Le temps de traitement est plus long que
celui d’un compilateur comme gcc ou clang. C2NEWSPEAK a toutefois été utilisé pour compiler
des projets de l’ordre du million de lignes de code source prétraité, et son exécution ne
prenait pas plus de quelques minutes.
À titre d’illustration, nous avons mesuré les performances de C2NEWSPEAK et ptrtype sur
l’exemple « Blackfin » du chapitre suivant. Celui consiste en un fichier prétraité de 853 lignes
de code C. Exécuter 1000 fois C2NEWSPEAK sur ce fichier prend 36.3 secondes, alors qu’exé-
cuter 1000 fois ptrtype sur le fichier NEWSPEAK résultant ne dure que 8.1 secondes (par comparaison,
lancer 1000 fois /bin/true, commande qui ne fait rien, prend 1.6 seconde).
Les structures internes de C2NEWSPEAK ont déjà été améliorées, et d’autres optimisations
sont certainement possibles, mais la performance n’est pas bloquante pour le moment : une
fois que le code est compilé, on peut réutiliser le fichier objet NEWSPEAK pour d’autres analyses.
La compilation est donc relativement rare.7.4. PERFORMANCE 109
Conclusion
Les analyses de typage correspondant aux chapitres 5 et 6 ont été implantées sous forme
d’un prototype utilisant le langage NEWSPEAK développé par EADS. Cela permet de réutiliser
les phases de compilation déjà implantées, et d’exprimer les règles de typage sur un langage
suffisament simple.
On utilise un algorithme par unification, qui donne une forme simple au programme
d’inférence. Pour chaque expression ou instruction à typer, on détermine grâce au lemme 5.1
quelle règle il faut appliquer. Ensuite, on génère les inconnues de type nécessaires pour appliquer
cette règle et on indique les contraintes en appelant la fonction d’unification.
Ce prototype comporte environ 1600 lignes de code OCaml. Il est disponible sous license
libre sur [☞3]. Il a été pensé pour traiter un type de code particulier, à savoir le noyau Linux.
On montre dans le chapitre suivant que cet objectif est atteint, puisqu’il permet de détecter
plusieurs bugs.C H A P I T R E
8
ÉTUDE DE CAS : LE NOYAU LINUX
Le noyau Linux, abordé dans le chapitre 2, est un noyau de système d’exploitation développé
depuis le début des années 90 et « figure de proue » du mouvement open-source. Au
départ écrit par Linus Torvalds sur son ordinateur personnel, il a été porté au fil des années
sur de nombreuses architectures et s’est enrichi de nombreux pilotes de périphériques. Dans
la version 3.13.1 (2014), son code source comporte 12 millions de lignes de code (en grande
majorité du C) dont 58% de pilotes.
Même si le noyau est monolithique (la majeure partie des traitements s’effectue au sein
d’un même fichier objet), les sous-systèmes sont indépendants. C’est ce qui permet d’écrire
des pilotes de périphériques et des modules.
Ces pilotes manipulent des données provenant de l’utilisateur, notamment par pointeur.
Comme on l’a vu, cela peut poser des problèmes de sécurité si on déréférence ces pointeurs
sans vérification.
Dans ce chapitre, on met en œuvre sur le noyau Linux le système de types décrit dans le
chapitre 6, ou plus précisément l’outil ptrtype du chapitre 7.
Pour montrer que le système de types capture cette propriété et que l’implantation est
utilisable, on étudie les cas de deux bugs qui ont touché le noyau Linux. À chaque fois, dans
une routine correspondant à un appel système, un pointeur utilisateur est déréférencé directement,
pouvant provoquer une fuite d’informations confidentielles dans le noyau.
On commence par décrire les difficultés rencontrées pour analyser le code du noyau Linux.
On décrit ensuite l’implantation du mécanisme d’appels système dans ce noyau, et en
quoi cela peut poser des problèmes. On détaille enfin les bugs étudiés, et comment les adapter
pour traiter le code en question.
8.1 Spécificités du code noyau
Linux est écrit dans le langage C, mais pas dans la version qui correspond à la norme. Il
utilise le dialecte GNU C qui est celui que supporte GCC. Une première difficulté pour traiter
le code du noyau est donc de le compiler.
Pour traduire ce dialecte, il a été nécessaire d’adapter C2NEWSPEAK. La principale particularité
est la notation __attribute__((...)) qui peut décorer les déclarations de fonctions,
de variables ou de types.
Par exemple, il est possible de manipuler des étiquettes de première classe : si « lbl: » est
présent avant une instruction, on peut capturer l’adresse de celle-ci avec void *p = &&lbl
et y sauter indirectement avec goto *p.
111112 CHAPITRE 8. ÉTUDE DE CAS : LE NOYAU LINUX
Une autre fonctionnalité est le concept d’instruction-expression : ({bloc}) est une expression,
dont la valeur est celle de la dernière expression évaluée lors de bloc.
Les attributs, quant à eux, rentrent dans trois catégories :
• les annotations de compilation ; par exemple, used désactive l’avertissement « cette variable
n’est pas utilisée ».
• les optimisations ; par exemple, les objets marqués hot sont groupés de telle manière
qu’ils se retrouvent en cache ensemble.
• les annotations de bas niveau ; par exemple, aligned(n) spécifie qu’un objet doit être
aligné sur au moins n bits.
Dans notre cas, toutes ces annotations peuvent être ignorées, mais il faut tout de même
adapter l’analyse syntaxique pour les ignorer. En particulier, pour le traitement du noyau Linux,
il a fallu traiter certaines formes de la construction typeof qui n’étaient pas supportées.
De plus, pour que le code noyau soit compilable, il est nécessaire de définir certaines
macros. En particulier, le système de configuration de Linux utilise des macros nommées
CONFIG_* pour inclure ou non certaines fonctionnalités. Il a donc fallu faire un choix ; nous
avons choisi la configuration par défaut. Pour analyser des morceaux plus importants du
noyau, il faudrait définir un fichier de configuration plus important.
8.2 Appels système sous Linux
Dans cette section, nous allons voir comment ces mécanismes sont implantés dans le
noyau Linux. Une description plus détaillée pourra être trouvée dans [BC05] ou, pour le cas
de la mémoire virtuelle, dans [Gor04].
Deux rings sont utilisés : en ring 0, le code noyau et, en ring 3, le code utilisateur.
Une notion de tâche similaire à celle décrite dans la section 2.2 existe : les tâches s’exé-
cutent l’une après l’autre, le changement s’effectuant sur interruptions.
Pour faire appel aux services du noyau, le code utilisateur doit faire appel à des appels
système, qui sont des fonctions exécutées par le noyau. Chaque tâche doit donc avoir deux
piles : une pile « utilisateur », qui sert pour l’application elle-même, et une pile « noyau », qui
sert aux appels système.
Grâce à la mémoire virtuelle, chaque processus possède sa propre vue de la mémoire dans
son espace d’adressage (figure 8.1), et donc chacun gère un ensemble de tables de pages et
une valeur de CR3 associée (ce mécanisme a été abordé page 17). Au moment de changer le
processus en cours, l’ordonnanceur charge donc le CR3 du nouveau processus.
Les adresses basses (inférieures à PAGE_OFFSET = 3 Gio = 0xc0000000) sont réservées à
l’utilisateur. On y trouvera par exemple : le code du programme, les données du programme
(variables globales), la pile utilisateur, le tas (mémoire allouée par malloc et fonctions similaires),
ou encore les bibliothèques partagées.
Au dessus de PAGE_OFFSET, se trouve la mémoire réservée au noyau. Cette zone contient
le code du noyau, les piles noyau des processus, etc.
0 3 Go 4 Go
FIGURE 8.1 : L’espace d’adressage d’un processus. En gris clair, les zones accessibles à tous les
niveaux de privilèges : code du programme, bibliothèques, tas, pile. En gris foncé, la mémoire
du noyau, réservée au mode privilégié.8.3. RISQUES 113
Les programmes utilisateur s’exécutant en ring 3, ils ne peuvent pas contenir d’instructions
privilégiées, et donc ne peuvent pas accéder directement au matériel. Pour que ces programmes
puissent interagir avec le système (afficher une sortie, écrire sur le disque. . . ), le
mécanisme des appels système est nécessaire. Il s’agit d’une interface de haut niveau entre
les rings 3 et 0. Du point de vue du programmeur, il s’agit d’un ensemble de fonctions C « magiques
» qui font appel au système d’exploitation pour effectuer des opérations.
Par exemple, le programmeur peut appeller la fonction getpid pour connaître le numéro
du processus courant. Cela passe par une fonction getpid dans la bibliothèque C, en espace
utilisateur. Celle-ci va invoquer (via un mécanisme non pertinent ici) la fonction sys_getpid
du noyau (figure 8.2).
Comme les piles sont différentes entre les espaces, la convention d’appel est différente :
les arguments sont copiés directement par les registres.
SYSCALL_DEFINE0(getpid)
{
return task_tgid_vnr(current);
}
FIGURE 8.2 : Fonction de définition d’un appel système
La macro SYSCALL_DEFINE0 permet de nommer la fonction sys_getpid, et définit entre
autres des points d’entrée pour les fonctionnalités de débogage du noyau. Le corps de la fonction
fait directement référence aux structures de données internes du noyau pour retourner
le résultat voulu.
8.3 Risques
Ainsi que décrit dans la section 2.4, cela peut poser un problème de manipuler des pointeurs
contrôlés par l’utilisateur au sein d’une routine de traitement d’appel système.
Si le déréférencement est fait sans vérification, un utilisateur mal intentionné peut forger
un pointeur vers le noyau (en déterminant des adresses valides dans l’espace noyau entre
0xc0000000 et 0xffffffff). En provoquant une lecture sur ce pointeur, des informations
confidentielles peuvent fuiter ; et, en forçant une écriture, il est possible d’augmenter ses privilèges,
par exemple en devenant super-utilisateur (root). En pratique, il n’est pas toujours
possible d’accéder à la mémoire. La mémoire utilisateur peut par exemple avoir été placée
en zone d’échange sur le disque, ou swap. À ce moment là, l’erreur provoquera tout de même
un déni de service. Plus de détails sur ce mécanisme, et le fonctionnement de la mémoire
virtuelle dans Linux, peuvent être trouvés dans [Jon10].
8.4 Premier exemple de bug : pilote Radeon KMS
On décrit le cas d’un pilote vidéo qui contenait un bug de pointeur utilisateur. Il est ré-
pertorié sur http://freedesktop.org en tant que bug #29340.
Pour changer de mode graphique, les pilotes de GPU peuvent supporter le Kernel Mode
Setting (KMS).
Pour configurer un périphérique, l’utilisateur communique avec le pilote noyau avec le
mécanisme d’ioctls (pour Input/Output Control). Ils sont similaires à des appels système,
mais spécifiques à un périphérique particulier. Le transfert de contrôle est similaire à ce qui
a été décrit dans la section précédente : les applications utilisateurs appellent la fonction114 CHAPITRE 8. ÉTUDE DE CAS : LE NOYAU LINUX
ioctl() de la bibliothèque standard, qui provoque une interruption. Celle-ci est traitée par
la fonction sys_ioctl() qui appelle la routine de traitement dans le bon pilote de périphé-
rique.
Les fonctions du noyau implantant un ioctl sont donc vulnérables à la même classe d’attaques
que les appels système, et donc doivent être écrites avec une attention particulière.
Le code de la figure 8.3 est présent dans le pilote KMS pour les GPU AMD Radeon.
/* drivers/gpu/drm/radeon/radeon_kms.c */
int radeon_info_ioctl(struct drm_device *dev, void *data,
struct drm_file *filp) {
struct radeon_device *rdev = dev->dev_private;
struct drm_radeon_info *info;
struct radeon_mode_info *minfo = &rdev->mode_info;
uint32_t *value_ptr;
uint32_t value;
struct drm_crtc *crtc;
int i, found;
info = data;
value_ptr = (uint32_t *) ((unsigned long)info->value);
/*=>*/ value = *value_ptr;
/* ... */
}
FIGURE 8.3 : Code de la fonction radeon_info_ioctl
On peut voir que l’argument data est converti en un struct drm_radeon_info *. Un
pointeur value_ptr est extrait de son champ value, et finalement ce pointeur est déréferencé.
Cependant, l’argument data est un pointeur vers une structure (allouée en espace noyau)
du type donné dans la figure 8.4, dont les champs proviennent d’un appel utilisateur de
ioctl().
/* from include/drm/radeon_drm.h */
struct drm_radeon_info {
uint32_t request;
uint32_t pad;
uint64_t value;
};
FIGURE 8.4 : Définition de struct drm_radeon_info
Pour mettre ce problème en évidence, nous avons annoté la fonction radeon_info_ioctl
de telle manière que son second paramètre soit un pointeur noyau vers une structure contenant
un champ contrôlé par l’utilisateur, value.
L’intégralité de ce code peut être trouvée en annexe A.
La bonne manière de faire a été publiée avec le numéro de commit d8ab3557 (figure 8.5)
(DRM_COPY_FROM_USER étant une simple macro pour copy_from_user). Dans ce cas, on n’obtient
pas d’erreur de typage.8.5. SECOND EXEMPLE : PTRACE SUR ARCHITECTURE BLACKFIN 115
--- a/drivers/gpu/drm/radeon/radeon_kms.c
+++ b/drivers/gpu/drm/radeon/radeon_kms.c
@@ -112,7 +112,9 @@
info = data;
value_ptr = (uint32_t *)((unsigned long)info->value);
- value = *value_ptr;
+ if (DRM_COPY_FROM_USER(&value, value_ptr, sizeof(value)))
+ return -EFAULT;
+
switch (info->request) {
case RADEON_INFO_DEVICE_ID:
value = dev->pci_device;
FIGURE 8.5 : Patch résolvant le problème de pointeur utilisateur. La ligne précédée par un
signe - est supprimée et remplacée par les lignes précédées par un signe +.
8.5 Second exemple : ptrace sur architecture Blackfin
Le noyau Linux peut s’exécuter sur l’architecture Blackfin, qui est spécialisée dans le traitement
du signal. Le problème de manipulation des pointeurs utilisateur auquel nous nous
intéressons peut également s’y produire.
En particulier nous nous intéressons à l’appel système ptrace. Il permet à un processus
d’accéder à la mémoire et de contrôler l’exécution d’un autre processus, par exemple à
des fins de débogage. Ainsi, ptrace(PTRACE_PEEKDATA, p, addr) renvoie la valeur du mot
mémoire à l’adresse addr dans l’espace d’adressage du processus p.
Comme pour la plupart des appels système, la fonction ptrace est dépendante de l’architecture.
Le deuxième exemple que nous présentons concerne l’implantation de celle-ci pour
les processeurs Blackfin, figure 8.6.
Dans d’anciennes versions de Linux 1, cette fonction appelle memcpy au lieu de copy_
from_user pour lire dans la mémoire du processus. La ligne problématique est préfixée par
/*=>*/. En théorie, si un utilisateur passe un pointeur vers une adresse du noyau à la fonction
ptrace, il pourra lire des données du noyau. L’appel ptrace (PTRACE_PEEKDATA, p, addr)
permet ainsi non seulement de lire les variables du processus p si addr est une adresse dans
l’espace utilisateur (ce qui est le comportement attendu), mais aussi de lire dans l’espace
noyau si addr y pointe (ce qui est un bug de sécurité).
On peut repérer ce bug par simple relecture pour commencer. On commence par remarquer
que l’argument addr, malgré son type long, est en réalité un void * provenant directement
de l’espace utilisateur. C’est en effet le même argument addr de l’appel système ptrace.
Cet argument correspond à l’adresse à lire dans l’espace mémoire du processus. Comme il est
passé à memcpy, aucune vérification n’est faite avant la copie. La valeur pointée par addr sera
copiée, même si elle est en espace noyau.
En annotant correctement les types, on peut donc détecter ce bug : le type correct de
addr est INT @, et celui de memcpy est (INT ∗, INT ∗, INT) → INT ∗. Il est donc impossible de lui
passer cet argument. Remarquons que le type de memcpy en C utilise des pointeurs de type
1. Jusqu’à la version 2.6.28 — ce bug a été corrigé dans le commit 7786ce82 en remplaçant l’appel à memcpy
par un appel à copy_from_user_page.116 CHAPITRE 8. ÉTUDE DE CAS : LE NOYAU LINUX
/* kernel/ptrace.c */
SYSCALL_DEFINE4(ptrace, long, request, long, pid, unsigned long, addr,
unsigned long, data)
{
struct task_struct *child = ptrace_get_task_struct(pid);
/* ... */
long ret = arch_ptrace(child, request, addr, data);
/* ... */
return ret;
}
/* arch/blackfin/kernel/ptrace.c */
long arch_ptrace(struct task_struct *child, long request,
long addr, long data)
{
int ret;
unsigned long __user *datap = (unsigned long __user *)data;
switch (request) {
/* ... */
case PTRACE_PEEKTEXT: {
unsigned long tmp = 0;
int copied;
ret = -EIO;
/* ... */
if (addr >= FIXED_CODE_START
&& addr + sizeof(tmp) <= FIXED_CODE_END) {
/*=>*/ memcpy(&tmp, (const void *)(addr), sizeof(tmp));
copied = sizeof(tmp);
}
/* ... */
ret = put_user(tmp, datap);
break;
/* ... */
}
return ret;
}
FIGURE 8.6 : Implantation de ptrace sur architecture Blackfin8.6. PROCÉDURE EXPÉRIMENTALE 117
void *. Pour les traiter correctement on pourrait utiliser du polymorphisme, mais dans ce
cas précis utiliser le type INT * est suffisant.
Remarque En pratique, le problème de sécurité n’est pas si important. En effet, la copie se
fait sous un test forçant addr à être entre FIXED_CODE_START et FIXED_CODE_END. Cette zone
est incluse en espace utilisateur ; cela empêche donc le problème de fuite de données.
Mais cela reste un problème de sécurité : contrairement à copy_from_user, la fonction
memcpy ne vérifie pas que l’espace utilisateur est chargé en mémoire. Si ce n’est pas le cas, une
faute mémoire sera provoquée dans le noyau. Il s’agit alors d’un déni de service (section 8.3),
qui est tout de même un comportement à empêcher.
8.6 Procédure expérimentale
Pour utiliser notre système de types, plusieurs étapes sont nécessaires en plus de traduire
le noyau Linux en NEWSPEAK.
Afin de réaliser l’analyse, il faut annoter les sources pour créer un environnement initial
(les annotations possibles sont résumées dans un tableau page 102). Plus précisément, pour
chaque source de pointeurs utilisateur, on ajoute un commentaire !npk userptr_fieldp
x f, qui indique que x est un pointeur vers une structure contenant un pointeur utilisateur
dans le champ f. En fait, il unifie le type de x avec {f : t @;...} ∗ où t est une inconnue de
type. Cette annotation est nécessaire car c’est le moyen d’indiquer que la structure contient
un pointeur utilisateur.
Par rapport au code complet présent dans l’annexe A, l’expression calculant value_ptr
est également simplifiée. Dans le code d’origine, info->value est transtypé en unsigned
long puis en uint32_t *. En NEWSPEAK, cela correspond à des opérateurs PtrToInt
et IntToPtr mais, si on les autorise, on casse le typage puisqu’il est alors possible de transformer
n’importe quel type en un autre. De plus, on modifie la définition du type struct
drm_radeon_info pour que son champ value ait pour type uint32_t * plutôt que uint64_t.
En effet, dans ce cas d’étude, cet entier est uniquement utilisé en tant que pointeur au cours
de toute l’exécution.
En ce qui concerne les fonctions de manipulation de pointeurs fournies par le noyau
(get_user, put_user, copy_from_user, copy_to_user, etc.), on ajoute à l’environnement
global leur type correct.
Enfin, on peut lancer l’inférence de type. Ainsi, sur l’exemple de la figure 8.7 (page 118),
on obtient la sortie suivante :
05-drm.c:19#8 - Type clash between :
KPtr (_a15)
UPtr (_a8)
Cela indique qu’on a essayé d’unifier un type de la forme t ∗ avec un type de la forme
t @, en précisant l’emplacement où la dernière unification a échoué (les _aN correspondent
à des inconnues de type). En effet, l’annotation de la ligne 10 donne à data le type {value :
a @;...} ∗, où a est une nouvelle inconnue de type. La ligne 18 donne donc à value_ptr le
type a @. Il y a donc une incompatibilité ligne 19 puisque l’instruction cherche à unifier le
type de value_ptr avec b ∗ où b est une nouvelle inconnue de type. La variable value aurait
alors le type b.118 CHAPITRE 8. ÉTUDE DE CAS : LE NOYAU LINUX
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
typedef unsigned long uint32_t;
struct drm_radeon_info {
uint32_t *value;
};
int radeon_info_ioctl(struct drm_device *d, void *data,
struct drm_file *f)
{
/*!npk userptr_fieldp data value*/
struct drm_radeon_info *info;
uint32_t *value_ptr;
uint32_t value;
struct drm_crtc *crtc;
int i, found;
info = data;
value_ptr = info->value;
value = *value_ptr; /* erreur */
return 0;
}
FIGURE 8.7 : Cas d’étude « Radeon » minimisé et annoté
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
typedef unsigned long uint32_t;
struct drm_radeon_info {
uint32_t *value;
};
int radeon_info_ioctl(struct drm_device *d, void *data,
struct drm_file *f)
{
/*!npk userptr_fieldp data value*/
struct drm_radeon_info *info;
uint32_t *value_ptr;
uint32_t value;
struct drm_crtc *crtc;
int i, found;
info = data;
value_ptr = info->value;
if (copy_from_user(&value, value_ptr, sizeof(value)))
return -14;
return 0;
}
FIGURE 8.8 : Cas d’étude « Radeon » minimisé et annoté – version correcte8.6. PROCÉDURE EXPÉRIMENTALE 119
217
218
255
256
257
258
259
260
261
262
342
343
344
345
346
347
348
349
441
long arch_ptrace(struct task_struct *child, long request,
long addr, long data)
{
/* ... */
if (addr >= FIXED_CODE_START
&& addr + sizeof(tmp) <= FIXED_CODE_END) {
#if FIX
copy_from_user_page(0, 0, 0, &tmp,
(const void *)(addr), sizeof(tmp));
#else
memcpy(&tmp, (const void *)(addr), sizeof(tmp));
#endif
copied = sizeof(tmp);
/* ... */
if (addr >= FIXED_CODE_START
&& addr + sizeof(data) <= FIXED_CODE_END) {
#if FIX
copy_to_user_page(0, 0, 0,
(void *)(addr), &data, sizeof(data));
#else
memcpy((void *)(addr), &data, sizeof(data));
#endif
copied = sizeof(data);
/* ... */
}
FIGURE 8.9 : Cas d’étude « Blackfin »
La version correcte minimisée correspond à la figure 8.8. Pour celle-ci, l’inférence se fait
sans erreur. La partie pertinente est la suivante (une explication de la syntaxe est donnée dans
la section 7.3, page 107)) :
(06-drm-ok.c:19#8)^{
Int tmp_cir!0;
(06-drm-ok.c:19#8)^tmp_cir!0 <-
copy_from_user
( (focus32 (&(value) : KPtr (d)) : KPtr (d)): KPtr (d),
(value_ptr_UPtr (d) : UPtr (d)): UPtr (d),
(4 : Int): Int
);
}
En ce qui concerne l’exemple « Blackfin », on commence par isoler la fonction problématique.
Celle-ci utilise de nombreuses constructions propres au noyau. On écrit donc un pré-
ambule permettant de les traiter (définitions de type, etc). Ensuite, il est nécessaire de commenter
certains appels à memcpy pour lesquelles les adresses sont testées dynamiquement
(il n’est donc pas nécessaire d’utiliser les fonctions de copie sûres pour ces sites d’appel). La
figure 8.9 montre le reste de la fonction, c’est-à-dire les parties sensibles.
Dans le cas où FIX vaut 0, la sortie est la suivante :120 CHAPITRE 8. ÉTUDE DE CAS : LE NOYAU LINUX
bf.c:260#32 - Type clash between :
KPtr (Int)
UPtr (_a122)
Et quand FIX vaut 1, le programme annoté est affiché. Les parties correspondantes aux
appels sensibles sont données dans la figurs 8.10.
Conclusion
Après voir décrit l’implantation de notre solution, on a montré comment celle-ci peut
s’appliquer à détecter deux bugs dans le noyau Linux. La première difficulté est de traduire
en NEWSPEAK le code source écrit dans le dialecte GNU C.
Pour chaque bug, on montre que la version originale du code (incluant une erreur de
programmation) ne peut pas être typée, alors que sur la version corrigée on peut inférer des
types compatibles.
Le prototype décrit dans le chapitre 7 peut donc s’adapter à détecter des bugs dans le
noyau Linux. Pour le moment, il nécessite du code annoté, mais des travaux sont en cours
pour permettre de passer automatiquement des portions plus importantes du noyau Linux.
Le principal obstacle est de devoir réécrire certaines parties du code pour supprimer les
constructions non typables.8.6. PROCÉDURE EXPÉRIMENTALE 121
(bf.c:255#3)^guard((! (((coerce[0,4294967295]
(((coerce[0,4294967295] (addr_Int : Int) : Int)
+ (4 : Int)) : Int) : Int) > (1168 : Int)) : Int) : Int));
(bf.c:258#32)^{
Int tmp_cir!7;
(bf.c:258#32)^tmp_cir!7 <-
copy_from_user_page(
(0 : Int): Int,
(0 : Int): Int,
(0 : Int): Int,
(focus32 (&(tmp) : KPtr (Int)) : KPtr (Int)): KPtr (Int),
((ptr) (addr_Int : Int) : UPtr (Int)): UPtr (Int),
(4 : Int): Int);
}
(bf.c:262#4)^copied =(int32) (4 : Int);
...
(bf.c:342#28)^guard((! (((coerce[0,4294967295]
(((coerce[0,4294967295] (addr_Int : Int) : Int)
+ (4 : Int)) : Int) : Int) > (1168 : Int)) : Int) : Int));
(bf.c:345#32)^{
Int tmp_cir!5;
(bf.c:345#32)^tmp_cir!5 <-
copy_to_user_page(
(0 : Int): Int,
(0 : Int): Int,
(0 : Int): Int,
((ptr) (addr_Int : Int) : UPtr (Int)): UPtr (Int),
(focus32 (&(data) : KPtr (Int)) : KPtr (Int)): KPtr (Int),
(4 : Int): Int);
}
(bf.c:349#4)^copied =(int32) (4 : Int);
FIGURE 8.10 : Traduction en NEWSPEAK du cas d’étude « Blackfin »CONCLUSION DE LA PARTIE III
Après avoir décrit notre solution théorique dans la partie II, nous avons présenté ici notre
démarche expérimentale. Dans le chapitre 7, nous avons détaillé l’implantation de notre prototype.
Pour ce faire, nous avons ajouté des étiquettes de type au langage NEWSPEAK et implanté
un algorithme d’inférence de types. Ce prototype est distribué sur [☞3] sous le nom de
ptrtype.
Ensuite, le but du chapitre 8 est d’appliquer notre analyse (à l’aide de ce prototype) sur
le noyau Linux. Après avoir décrit le fonctionnement des appels système sur ce noyau, on
présente deux bugs qui ont touché respectivement un pilote de carte graphique et l’implantation
d’un appel système. Ils sont la manifestation d’un problème de pointeur utilisateur
mal déréférencé dans le noyau, ainsi que décrit dans le chapitre 2. En lançant notre analyse
sur le code présentant un problème, l’erreur est détectée. Au contraire, en la lançant sur le
code après application du correctif, aucune erreur n’est trouvée.
En s’appuyant sur le langage NEWSPEAK, on gagne beaucoup par rapport à d’autres représentations
intermédiaires. Le fait d’avoir un langage avec peu de constructions permet de
ne pas avoir à exprimer plusieurs fois la même règle (par exemple, une fois sur la boucle for
et une autre sur la boucle while).
Un des inconvénients de notre système est que le modèle mémoire utilisé par NEWSPEAK
est assez différent de celui de SAFESPEAK (ainsi que décrit dans le chapitre 4). NEWSPEAK est
en effet prévu pour implanter des analyses précises de valeur reposant sur l’interprétation
abstraite, et nécessite donc un modèle mémoire de plus bas niveau (où on peut créer des
valeurs à partir d’une suite d’octets, par exemple).
Le prototype d’implantation peut évoluer dans deux directions : d’une part, en continuant
à s’appuyer sur NEWSPEAK, on peut réaliser des pré-analyses de typage qui permettent
de guider une analyse de valeurs plus précise, par exemple en choisissant un domaine abstrait
différent en fonction des types de données rencontrés. D’autre part, il est possible de
faire une implantation plus fidèle à SAFESPEAK, qui permette d’ajouter de nouvelles fonctionnalités
plus éloignées de C. Par exemple, un système de régions comme [TJ92] permettrait
de simplifier l’environnement d’exécution en enlevant l’opération de nettoyage mémoire
Cleanup(·). Le système de types peut également être enrichi, pour ajouter par exemple du polymorphisme.
Cela rapprocherait le langage source de Rust. Le chapitre 9 présente quelques
unes de ces extensions possibles.
L’expérimentation, quant à elle, est pour le moment limitée, mais on peut l’étendre à des
domaines de plus en plus importants dans le noyau Linux. Tout d’abord, le module graphique
définit d’autres fonctions implantant des ioctls. Celles-ci reçoivent donc également des pointeurs
utilisateur et sont susceptibles d’être vulnérables à ce genre d’erreurs de programmation.
Ensuite, d’autres modules exposent une interface similaire, à commencer par les autres
pilotes de cartes graphiques. Ceux-ci sont également un terrain sur lequel appliquer cette
analyse.
De manière générale, toutes les interfaces du noyau manipulant des pointeurs utilisateur
gagnent à être analysées. Outre les implantations des ioctls dans chaque pilote et les appels
système, les systèmes de fichiers manipulent aussi de tels pointeurs via leurs opérations de
lecture et d’écriture.
123C H A P I T R E
9
CONCLUSION
On présente ici un résumé des travaux présentés, en commençant par un bilan des contributions
réalisées. On réalise ensuite un tour des aspects posant problème, ou traités de manière
incomplète, en évoquant les travaux possibles pour enrichir l’expressivité de ce système.
9.1 Contributions
Cette thèse comporte 4 contributions principales.
Un langage impératif bien typé Le système de types de C est trop rudimentaire pour permettre
d’obtenir des garanties sur l’exécution des programmes bien typés. En interdisant
certaines constructions dangereuses et en annotant certaines autres, nous avons isolé un
langage impératif bien typable, SAFESPEAK, pour lequel on peut définir un système de types
sûr.
Une sémantique basée sur les lentilles Une des particularités de SAFESPEAK est qu’il utilise
un état mémoire structuré, modélisant les cadres de piles présents dans le langage. Pour
décrire la sémantique des accès mémoire, nous utilisons le concept de lentilles issues de la
programmation fonctionnelle et des systèmes de bases de données. Cela permet de définir
de manière déclarative la modification en profondeur de valeurs dans la mémoire, sans avoir
à distinguer le cas de la lecture et celui de l’écriture.
Un système de types abstraits En partant de ce système de types, on a décrit une extension
permettant de créer des pointeurs pour lesquels l’opération de déréférencement est restreinte
à certaines fonctions. Dans le contexte d’un noyau de système d’exploitation, cette
restriction permet de vérifier statiquement qu’à aucun moment le noyau ne déréférence un
pointeur dont la valeur est contrôlée par l’espace utilisateur, évitant ainsi un problème de
sécurité. Cette approche peut s’étendre à d’autres classes de problèmes comme par exemple
éviter l’utilisation de certaines opérations sur les types entiers lorsqu’ils sont utilisés comme
identificateurs ou masque de bits.
Un prototype d’analyseur statique Les analyses de typage ici décrites ont été implantées
sous forme d’un prototype d’analyseur statique distribué avec le langage NEWSPEAK, développé
par EADS. Le choix de NEWSPEAK pour l’implantation demande d’adapter les règles de
125126 CHAPITRE 9. CONCLUSION
typage, mais il permet de réutiliser un traducteur existant et à l’entreprise de profiter des ré-
sultats. Ce prototype permet d’une part de vérifier la propriété d’isolation des appels système
sur du code C existant, et d’autre part fournit une base saine pour implanter d’autres analyses
de typage sur le langage NEWSPEAK. Ce prototype a été utilisé pour confirmer l’existence de
deux bugs dans le noyau Linux, ce qui permet de valider l’approche : il est possible de vérifier
du code de production à l’aide de techniques de typage. Des travaux d’expérimentation sont
en cours afin d’analyser de plus grandes parties du noyau.
9.2 Différences avec C
SAFESPEAK a été construit pour pouvoir ajouter un système de types à un langage proche
de C. Ces deux langages diffèrent donc sur certains points. On détaille ici ces différences et,
selon les cas, comment les combler ou pourquoi cela est impossible de manière inhérente.
Types numériques En C, on dispose de plusieurs types entiers, pouvant avoir plusieurs
tailles et être signés ou non signés, ainsi que des types flottants qui diffèrent par leur taille.
Au contraire, en SAFESPEAK on ne conserve qu’un seul type d’entier et un seul type de flottant.
La raison pour cela est que nous ne nous intéressons pas du tout aux problématiques de
sémantique arithmétique : les débordements, dénormalisations, etc, sont supposés ne pas
arriver.
Il est possible d’étendre le système de types de SAFESPEAK pour ajouter tous ces nouveaux
types. La traduction depuis NEWSPEAK insère déjà des opérateurs de transtypage pour
lesquels il est facile de donner une sémantique (pouvant lever une erreur en cas de débordement,
comme en Ada) et un typage. Les littéraux numériques peuvent poser problème, puisqu’ils
deviennent alors polymorphes. Une solution peut être de leur donner le plus grand type
entier et d’insérer un opérateur de transtypage à chaque littéral. Haskell utilise une solution
similaire : les littéraux entiers ont le type de précision arbitraire Integer et sont convertis
dans le bon type en appelant la fonction fromInteger du type synthétisé à partir de l’environnement.
Transtypage et unions Puisque l’approche retenue est basée sur le typage statique, il est
impossible de capturer de nombreuses constructions qui sont permises, ou même idiomatiques,
en C : les unions, les conversions de types (explicites ou implicites) et le type punning
(défini ci-dessous). Les deux premières sont équivalentes. Bien qu’on puisse remplacer
chaque conversion explicite d’un type t1 vers un type t2 par l’appel à une fonction castt1,t2 ,
on ajoute alors un « trou » dans le système de types. Cette fonction devrait en effet être typée
(t1) → t2, autrement dit le type « maudit » α → β de Obj.magic en OCaml ou unsafeCoerce
en Haskell.
Le type punning consiste à modifier directement la suite de bits de certaines données
pour la manipuler d’une manière efficace. Par exemple, il est commun de définir un ensemble
de macros pour accéder à la mantisse et à l’exposant de flottants IEEE754. Ceci peut être fait
avec des unions ou des masques de bits.
Dans de tels cas, le typage statique est bien sûr impossible. Pour traiter ces cas, il faudrait
encapsuler la manipulation dans une fonction et y ajouter une information de type explicite,
comme float_exponent : (FLOAT) → INT.
Pour ces conversions de types, on distingue en fait plusieurs cas : les conversions entre
types numériques, entre types pointeurs, ou entre un type entier et un type pointeur.9.2. DIFFÉRENCES AVEC C 127
Le premier ne pose pas de problème : il est toujours possible de donner une sémantique à
une conversion entre deux types numériques, quitte à détecter les cas où il faut signaler une
erreur à l’exécution (comme en cas de débordement).
Le deuxième non plus n’est pas un problème en soi : une conversion entre deux types
pointeurs revient à convertir entre les types pointés (il faut bien sûr interdire les conversions
entre pointeurs noyau et utilisateur).
Le vrai problème provient des conversions entre entiers et pointeurs, qui sont des données
fondamentalement différentes. Le même problème se pose d’ailleurs si on cherche à
convertir une fonction en entier ou en pointeur, même si les raisons valables pour faire cela
sont moins nombreuses. Si on s’en tient aux conversions entre entiers et pointeurs, une manière
naïve de typer ces opérations est :
Γ � e : t ∗
Γ � (INT) e : INT
(PTRINT-BAD)
Γ � e : INT
Γ � (PTR) e : t ∗ (INTPTR-BAD)
Tout d’abord, cela pose problème car il est alors possible de créer une fonction pouvant
convertir n’importe quel type pointeur en n’importe quel autre type pointeur :
� fun(p){RETURN((PTR) (INT) p)} : (ta ∗) → tb ∗
Si on crée une variable du type ta, prend son adresse, la convertit à l’aide de cette fonction,
puis déréférence le résultat, on obtient une valeur du type tb (remarquons que ce genre
d’opération est tout à fait possible en C).
Outre ce problème de typage, il faudrait pouvoir donner une sémantique à ces opérations.
Convertir un pointeur en entier revient à spécifier l’environnement d’exécution, c’est-à-dire
qu’il faut une fonction de placement en mémoire beaucoup plus précise que notre modèle
mémoire actuel. Celle-ci dépend de beaucoup de paramètres : dans quel sens croit la pile,
quelle est la taille des types, etc.
La conversion dans le sens inverse, d’entier vers pointeur, est encore plus complexe. Entre
autres, cela suppose qu’on puisse retrouver la taille des valeurs à partir de leur adresse. Dans
de nombreux langages, on résout ce problème en stockant la taille de chaque valeur avec elle.
Mais cela fait s’éloigner du modèle mémoire de C, où le déréférencement porte sur une
adresse mais également sur une taille (portée implicitement par le type du pointeur). Le langage
NEWSPEAK conserve d’ailleurs cette distinction, que nous avons éliminée dans SAFESPEAK.
Il y a une incompatibilité entre ces deux approches : dans le cas de C (et de NEWSPEAK),
on laisse le programmeur gérer l’organisation de la mémoire alors qu’avec SAFESPEAK ces
choix sont faits par le langage. En contrepartie, cela permet d’avoir d’assurer la sûreté du typage.
Environnement d’exécution La sémantique opérationnelle utilise un environnement
d’exécution pour certains cas. Contrairement à C, les débordements de tampon et les déréfé-
rencements de pointeurs sont vérifiés dynamiquement. Mais ce n’est pas une caractéristique
cruciale de cette approche : en effet, si on suppose que les programmes que l’on analyse ne
comportent pas de telles erreurs de programmation, on peut désactiver ces vérifications et le
reste des propriétés est toujours valable.
On repose sur l’environnement d’exécution à un endroit plus problématique. À la sortie
de chaque portée (au retour d’une fonction et après la portée d’une variable locale déclarée),
on parcourt la mémoire à la recherche des pointeurs référençant les variables qui ne sont plus128 CHAPITRE 9. CONCLUSION
valides. Supprimer ce test rend l’analyse incorrecte, car il est alors possible de faire référence
à une variable avec un type différent.
Si on peut avoir une garantie statique que les adresses des variables locales ne seront plus
accessibles au retour d’une fonction, alors on peut supprimer cette étape de nettoyage. Cette
garantie peut être obtenue avec une analyse statique préalable. Par exemple les régions [TJ92]
peuvent être utilisées à cet effet : en plus de donner un type à chaque expression, on calcule
statiquement la zone mémoire dans laquelle cette valeur sera allouée. Cela correspond à un
ramasse-miette réalisé statiquement.
Flot de contrôle Dans le langage C, en plus des boucles et de l’alternative, on peut sauter
d’une instruction à l’autre au sein d’une fonction à l’aide de la construction goto. Pour pouvoir
traiter ces cas, il est possible de transformer ces sauts d’un programme vers des simples
boucles. Cette réécriture peut être coûteuse puisqu’elle peut introduire des variables booléennes
et dupliquer du code. En pratique, c’est d’ailleurs ce qui est fait dans l’implantation
puisque cette transformation est réalisée par C2NEWSPEAK.
Dans le noyau Linux, il est courant d’utiliser les sauts pour factoriser la libération de ressources
à la fin d’une fonction. Il est d’ailleurs possible d’utiliser l’outil Coccinelle pour donner
cette forme à du code utilisant un autre style de structures de contrôle [SLM11]. On peut
imaginer qu’il est possible de l’utiliser pour faire la conversion inverse.
En plus de ces sauts locaux, le langage C contient une manière de sauvegarder un état
d’exécution et d’y sauter, même entre deux fonctions : ce sont respectivement les constructions
setjmp et longjmp. Elles sont très puissantes puisqu’elles permettent d’exprimer de
nouvelles structures de contrôle. Il s’agit de formes légères de continuations où la pile reste
commune. Cette fonctionnalité peut servir par exemple à implanter des exceptions ou des
coroutines.
Avec l’interprète du chapitre 4, il n’est pas possible de donner une sémantique à ces
constructions. Une des manières de faire est de modifier les états de l’interprète : au lieu de
retenir l’instruction à évaluer avec 〈i,m〉, on retient la continuation complète : 〈k,m〉. Pour
faciliter ce changement, on peut tout d’abord passer à une sémantique monadique (ainsi
qu’évoqué dans la conclusion de la partie II, page 95) puis ajouter les continuations à la monade
sous-jacente.
En pratique, il est rare de trouver ces constructions plus avancées dans du code noyau ou
embarqué, donc ce manque n’a pas beaucoup d’impact. De plus, cela permet une présentation
plus simple et accessible.
Allocation dynamique La plupart des programmes, et le noyau Linux en particulier, utilisent
la notion d’allocation dynamique de mémoire. C’est une manière de créer dynamiquement
une zone de mémoire qui restera accessible après l’exécution de la fonction courante.
Cette mémoire pourra être libérée à l’aide d’une fonction dédiée. Dans l’espace utilisateur,
les programmes peuvent utiliser les fonctions malloc(), calloc() et realloc() pour allouer
des zones de mémoire et free() pour les libérer. Dans le noyau Linux, ces fonctions existent
sous la forme de kmalloc(), kfree(), etc. Une explication détaillée de ces mécanismes peut
être trouvée dans [Gor04].
Ces fonctions manipulent les données en tant que zones mémoires opaques, en renvoyant
un pointeur vers une zone mémoire d’un nombre d’octets donnés. Cela présuppose
un modèle mémoire de plus bas niveau. Pour se rapprocher de la sémantique de SAFESPEAK,
une manière de faire est de définir un opérateur de plus haut niveau prenant une expression
et retournant l’adresse d’une cellule mémoire contenant cette valeur (la taille de chaque9.3. PERSPECTIVES 129
valeur fait partie de celle-ci), ou NULL si l’allocation échoue. Le typage est alors direct (on
suppose que FREE(e) est une instruction :
Γ � e : t
Γ � NEW(e) : t ∗ (NEW )
Γ � e : t ∗
Γ � FREE(e)
(FREE)
En ce qui concerne l’exécution, on peut ajouter une troisième composante aux états mé-
moire : m = (s, g ,h) où h est une liste d’association entre des identifiants uniques et des
valeurs. Chaque allocation dynamique crée une nouvelle clef entière et met à jour h. La libération
de mémoire est en revanche problématique parce qu’il faut faire confiance au programmeur
pour ne pas accéder aux zones mémoires libérées, ni libérer deux fois la même
zone mémoire. Il est aussi possible d’obtenir cette garantie avec une analyse préalable. Par
exemple, il est possible ici encore d’utiliser une analyse basée sur les régions pour vérifier
l’absence de pointeurs fous [DDMP10].
9.3 Perspectives
L’importance des logiciels grandit par deux effets : d’une part, ils sont présents dans de
plus en plus d’appareils et, d’autre part, leur taille est de plus en plus importante. En une
journée, entre les appareils dédiés au calcul, à la communication, au multimédia et au transport,
on est facilement exposé au fonctionnement de plus d’une dizaine de millions de lignes
de code. Il donc primordial de vérifier que ces logiciels ne peuvent pas être détournés de leur
utilisation prévue. Dans le cas de logiciels avioniques ou militaires, les conséquences peuvent
en effet être catastrophiques. C’est dans ce contexte industriel que ce travail a été motivé et
réalisé.
Au cœur de la plupart de ces systèmes informatiques se trouve un noyau qui abstrait les
détails du matériel pour fournir aux programmes des abstractions sûres, permettant de protéger
les données sensibles contenues dans ce système. Puisqu’une simple erreur de programmation
peut briser cette isolation, on voit pourquoi la vérification est si importante.
Dans ce but, les systèmes de types sont des outils bien connus de programmeurs. Même
dans les langages peu typés comme C, les compilateurs aident de plus en plus les programmeurs
à trouver des erreurs de programmation. De très nombreuses analyses peuvent être
faites rien qu’en classant les expressions selon le genre de valeurs qu’elles créent à l’exécution
— c’est la définition que donne Benjamin C. Pierce d’un système de types [Pie02].
L’utilisation d’un système de types comme analyseur statique léger est donc efficace. Pour
des propriétés qui ne dépendent pas de la valeur des expressions, mais uniquement de leur
forme, c’est d’ailleurs la solution à préférer. En effet, nous avons montré qu’elle est simple à
mettre en œuvre et rapide à exécuter.
On peut se poser la question suivante : pourquoi a-t-on besoin d’une analyse statique dé-
diée, plutôt que de passer par le langage C lui-même ? Le problème vient du fait que celui-ci
considère que les types définissent une représentation en mémoire sans guère plus d’information.
On peut définir de nouveaux noms pour un type, mais l’ancien et le nouveau sont
alors compatibles. En un mot il est impossible de distinguer le rôle d’un type (son intention)
de sa représentation (son extension).
Ici, nous avons proposé une solution au problème de pointeurs utilisateur en introduisant
un type ayant la même représentation que les pointeurs classiques, mais pour lequel
l’ensemble des opérations est différent : c’est un type opaque. Cela suffit déjà à détecter des
erreurs de programmation.130 CHAPITRE 9. CONCLUSION
Si on ajoutait cette construction au langage, on pourrait définir de nouveaux types partageant
la représentation d’un type C existant, mais qui ne soit pas compatible avec le type
d’origine. Avec cette fonctionnalité dans un langage, non seulement on peut détecter d’autres
classes de problèmes, mais surtout on laisse le programmeur définir de nouvelles analyses
lui-même en modélisant les problèmes concrets par des types.Annexes
131A N N E X E
A
MODULE RADEON KMS
On inclut ici le code analysé dans le chapitre 8. On inclut à la suite le contexte nécessaire
pour comprendre ce code.
/* from drivers/gpu/drm/radeon/radeon_kms.c */
int radeon_info_ioctl(struct drm_device *dev, void *data, struct drm_file *filp)
{
struct radeon_device *rdev = dev->dev_private;
struct drm_radeon_info *info;
struct radeon_mode_info *minfo = &rdev->mode_info;
uint32_t *value_ptr;
uint32_t value;
struct drm_crtc *crtc;
int i, found;
info = data;
value_ptr = (uint32_t *)((unsigned long)info->value);
value = *value_ptr;
switch (info->request) {
case RADEON_INFO_DEVICE_ID:
value = dev->pci_device;
break;
case RADEON_INFO_NUM_GB_PIPES:
value = rdev->num_gb_pipes;
break;
case RADEON_INFO_NUM_Z_PIPES:
value = rdev->num_z_pipes;
break;
case RADEON_INFO_ACCEL_WORKING:
/* xf86-video-ati 6.13.0 relies on this being false for evergreen */
if ((rdev->family >= CHIP_CEDAR) && (rdev->family <= CHIP_HEMLOCK))
value = false;
else
value = rdev->accel_working;
break;
case RADEON_INFO_CRTC_FROM_ID:
for (i = 0, found = 0; i < rdev->num_crtc; i++) {
crtc = (struct drm_crtc *)minfo->crtcs[i];
if (crtc && crtc->base.id == value) {
struct radeon_crtc *radeon_crtc = to_radeon_crtc(crtc);
value = radeon_crtc->crtc_id;
133134 ANNEXE A. MODULE RADEON KMS
found = 1;
break;
}
}
if (!found) {
DRM_DEBUG_KMS("unknown crtc id %d\n", value);
return -EINVAL;
}
break;
case RADEON_INFO_ACCEL_WORKING2:
value = rdev->accel_working;
break;
case RADEON_INFO_TILING_CONFIG:
if (rdev->family >= CHIP_CEDAR)
value = rdev->config.evergreen.tile_config;
else if (rdev->family >= CHIP_RV770)
value = rdev->config.rv770.tile_config;
else if (rdev->family >= CHIP_R600)
value = rdev->config.r600.tile_config;
else {
DRM_DEBUG_KMS("tiling config is r6xx+ only!\n");
return -EINVAL;
}
case RADEON_INFO_WANT_HYPERZ:
mutex_lock(&dev->struct_mutex);
if (rdev->hyperz_filp)
value = 0;
else {
rdev->hyperz_filp = filp;
value = 1;
}
mutex_unlock(&dev->struct_mutex);
break;
default:
DRM_DEBUG_KMS("Invalid request %d\n", info->request);
return -EINVAL;
}
if (DRM_COPY_TO_USER(value_ptr, &value, sizeof(uint32_t))) {
DRM_ERROR("copy_to_user\n");
return -EFAULT;
}
return 0;
}
/* from include/drm/radeon_drm.h */
struct drm_radeon_info {
uint32_t request;
uint32_t pad;
uint64_t value;
};
/* from drivers/gpu/drm/radeon/radeon_kms.c */
struct drm_ioctl_desc radeon_ioctls_kms[] = {
/* KMS */
DRM_IOCTL_DEF(DRM_RADEON_INFO, radeon_info_ioctl, DRM_AUTH|DRM_UNLOCKED)135
};
/* from drivers/gpu/drm/radeon/radeon_drv.c */
static struct drm_driver kms_driver = {
.driver_features =
DRIVER_USE_AGP | DRIVER_USE_MTRR | DRIVER_PCI_DMA | DRIVER_SG |
DRIVER_HAVE_IRQ | DRIVER_HAVE_DMA | DRIVER_IRQ_SHARED | DRIVER_GEM,
.dev_priv_size = 0,
.ioctls = radeon_ioctls_kms,
.name = "radeon",
.desc = "ATI Radeon",
.date = "20080528",
.major = 2,
.minor = 6,
.patchlevel = 0,
};
/* from drivers/gpu/drm/drm_drv.c */
int drm_init(struct drm_driver *driver)
{
DRM_DEBUG("\n");
INIT_LIST_HEAD(&driver->device_list);
if (driver->driver_features & DRIVER_USE_PLATFORM_DEVICE)
return drm_platform_init(driver);
else
return drm_pci_init(driver);
}A N N E X E
B
SYNTAXE ET RÈGLES D’ÉVALUATION
On rappelle ici pour référence la syntaxe de SAFESPEAK, ainsi que sa sémantique d’évaluation.
Les règles sont décrites dans les chapitres 4 et 6.
B.1 Syntaxe des expressions
Constantes c ::= n Entier
| d Flottant
| NULL Pointeur nul
| ( ) Valeur unité
Expressions e ::= c Constante
| � e Opération unaire
| e � e Opération binaire
| l v Accès mémoire
| l v ← e Affectation
| &l v Pointeur
| f Fonction
| e(e1,...,en) Appel de fonction
| {l1 : e1;...;ln : en} Structure
| [e1;...;en] Tableau
Valeurs
gauches
l v ::= x Variable
| l v.lS Accès à un champ
| l v[e] Accès à un élément
| ∗e Déréférencement
Fonctions f ::= fun(x1,...,xn){i} Arguments, corps
137138 ANNEXE B. SYNTAXE ET RÈGLES D’ÉVALUATION
B.2 Syntaxe des instructions
Instructions i ::= PASS Instruction vide
| i;i Séquence
| e Expression
| DECL x = e IN{i} Déclaration de variable
| IF(e){i}ELSE{i} Alternative
| WHILE(e){i} Boucle
| RETURN(e) Retour de fonction
Phrases p ::= x = e Variable globale
| e Évaluation d’expression
Programme P ::= (p1,...,pn) Phrases
B.3 Syntaxe des opérateurs
Opérateurs
binaires
� ::= +,−,×,/,% Arithmétique entière
| +.,−.,×.,/. Arithmétique flottante
| +p,−p Arithmétique de pointeurs
| ≤,≥,<,> Comparaison sur les entiers
| ≤ .,≥ .,< .,> . Comparaison sur les flottants
| =,�= Tests d’égalité
| &,|,^ Opérateurs bit à bit
| &&,|| Opérateurs logiques
| �,� Décalages
Opérateurs
unaires
� ::= +,− Arithmétique entière
| +.,−. Arithmétique flottante
| ∼ Négation bit à bit
| ! Négation logiqueB.4. CONTEXTES D’ÉVALUATION 139
B.4 Contextes d’évaluation
Contextes C ::= •
| C � e
| v � C
| � C
| & C
| C ← e
| ϕ ←C
| {l1 : v1;...;li :C;...;ln : en}
| [v1;...;C;...;en]
| C(e1,...,en)
| f (v1,...,C,...,en)
| C.lS
| C[e]
| ϕ[C]
| ∗ C
| C;i
| IF(C){i1}ELSE{i2}
| RETURN(C)
| DECL x = C IN{i}
B.5 Règles d’évaluation des erreurs
Ξ → Ω
〈Ω,m〉 → Ω
(EXP-ERR)
〈e,m〉 → Ω
〈C�e�,m〉 → Ω
(EVAL-ERR)
〈i,m〉 → Ω
〈DECL x = v IN{i},m〉 → Ω
(DECL-ERR)
m� = Push(m, ((a1 �→ v1),..., (an �→ vn))) 〈i,m�
〉 → Ω
〈fun(a1,...,an){i}(v1,..., vn),m〉 → Ω
(EXP-CALL-ERR)140 ANNEXE B. SYNTAXE ET RÈGLES D’ÉVALUATION
B.6 Règles d’évaluation des valeurs gauches et expressions
〈l v,m〉 → 〈ϕ,m〉
a = Lookup(x,m)
〈x,m〉 → 〈a,m〉
(PHI-VAR)
v = &� ϕ
〈∗ v,m〉 → 〈ϕ,m〉
(EXP-DEREF)
v = N
�ULL
〈∗ v,m〉 → Ωp t r
(EXP-DEREF-NULL)
〈ϕ.lS,m〉 → 〈ϕ�.l,m〉
(PHI-STRUCT)
〈ϕ[n],m〉 → 〈ϕ[
�n],m〉
(PHI-ARRAY)
〈e,m〉 → 〈v,m〉
〈c,m〉 → 〈c�,m〉
(EXP-CST)
〈f ,m〉 → 〈f
�,m〉
(EXP-FUN)
〈ϕ,m〉 → 〈m[ϕ]Φ,m〉
(EXP-LV )
〈� v,m〉 → 〈�� v,m〉
(EXP-UNOP)
〈v1 � v2,m〉 → 〈v1 �� v2,m〉
(EXP-BINOP)
〈& ϕ,m〉 → 〈&� ϕ,m〉
(EXP-ADDR)
〈ϕ ← v,m〉 → 〈v,m[ϕ ← v]Φ〉
(EXP-SET)
〈{l1 : v1;...;ln : vn},m〉 → 〈{l1 : v�1;...;ln : vn},m〉
(EXP-STRUCT)
〈[v1;...; vn],m〉 → 〈[v�1;...; vn],m〉
(EXP-ARRAY)
m� = Cleanup(m) v� = CleanV|m|(v)
〈fun(a1,...,an){RETURN(v)}(v1,..., vn),m〉 → 〈v�
,m�
〉
(EXP-CALL-RETURN)
〈e,m〉 → 〈e�
,m�
〉
〈i,m〉 → 〈i
�
,m�
〉
〈C�i�,m〉 → 〈C�i
�
�,m�
〉
(CTX)
m1 = Push(m0, ((a1 �→ v1),..., (an �→ vn)))
〈i,m1〉 → 〈i
�
,m2〉 ∀i ∈ [1;n], v�
i = m2[(|m2|,ai)]A m3 = Pop(m2)
〈fun(a1,...,an){i}(v1,..., vn),m0〉 → 〈fun(a1,...,an){i
�
}(v�
1,..., v�
n),m3〉
(EXP-CALL-CTX)B.7. RÈGLES D’ÉVALUATION DES INSTRUCTIONS, PHRASES ET PROGRAMMES 141
B.7 Règles d’évaluation des instructions, phrases et programmes
〈i,m〉 → 〈i�
,m〉
〈(PASS;i),m〉 → 〈i,m〉
(SEQ)
〈v,m〉 → 〈PASS,m〉
(EXP)
m� = CleanVar(m − x, (|m|,x))
〈DECL x = v IN{PASS},m〉 → 〈PASS,m�
〉
(DECL-PASS)
m� = CleanVar(m − x, (|m|,x)) v�� = CleanVarV(v�
, (|m|,x))
〈DECL x = v IN{RETURN(v�
)},m〉 → 〈RETURN(v��),m�
〉
(DECL-RETURN)
m� = Extend(m,x �→ v)
〈i,m�
〉 → 〈i
�
,m��〉 v� = m��[(|m��|,x)]A m��� = m�� − x
〈DECL x = v IN{i},m〉 → 〈DECL x = v� IN{i
�
},m���〉
(DECL-CTX)
〈IF(0){it }ELSE{if },m〉 → 〈if ,m〉
(IF-FALSE)
v �= 0
〈IF(v){it }ELSE{if },m〉 → 〈it ,m〉
(IF-TRUE)
〈WHILE(e){i},m〉 → 〈IF(e){i;WHILE(e){i}}ELSE{PASS},m〉
(WHILE)
〈RETURN(v);i,m〉 → 〈RETURN(v),m〉
(RETURN)
m � p → m�
〈e,m〉 → 〈v,m�
〉
m � e → m� (ET-EXP)
〈e,m〉 → 〈v,m�
〉 m� = (s, g ) m�� = (s, (x �→ v) :: g )
m � x = e → m�� (ET-VAR)
� P →∗ m
([ ], [ ]) � p1 → m1 m1 � p2 → m2 ... mn−1 � pn → mn
� p1,...,pn →∗ m
(PROG)142 ANNEXE B. SYNTAXE ET RÈGLES D’ÉVALUATION
B.8 Règles d’évaluation des extensions noyau
〈♦ ϕ,m〉 → 〈& ( � ♦� ϕ),m〉
(PHI-USER)
v = m[ϕs]Φ m� = m[ϕd ← v]Φ
〈copy_from_user(&� ϕd ,& ( � ♦� ϕs)),m〉 → 〈0,m�
〉
(USER-GET-OK)
� ϕs.ϕ = ♦� ϕs
〈copy_from_user(&� ϕd ,&� ϕ),m〉 → 〈−14,m〉
(USER-GET-ERR)
v = m[ϕs]Φ m� = m[ϕd ← v]Φ
〈copy_to_user(& ( � ♦� ϕd ),&� ϕs),m〉 → 〈0,m�
〉
(USER-PUT-OK)
� ϕd .ϕ = ♦� ϕd
〈copy_to_user(&� ϕ,&� ϕs),m〉 → 〈−14,m〉
(USER-PUT-ERR)A N N E X E
C
RÈGLES DE TYPAGE
On rappelle ici l’ensemble des règles de typage décrites dans les chapitres 5 et 6.
C.1 Règles de typage des constantes et valeurs gauches
Γ � c : t
Γ � n : INT
(CST-INT)
Γ � d : FLOAT
(CST-FLOAT)
Γ � NULL : t ∗ (CST-NULL)
Γ � ( ) : UNIT
(CST-UNIT)
Γ � l v : t
x : t ∈ Γ
Γ � x : t
(LV-VAR)
Γ � e : t ∗
Γ � ∗e : t
(LV-DEREF)
Γ � e : INT Γ � l v : t[ ]
Γ � l v[e] : t
(LV-INDEX)
(l,t) ∈ S Γ � l v : S
Γ � l v.lS : t
(LV-FIELD)
143144 ANNEXE C. RÈGLES DE TYPAGE
C.2 Règles de typage des opérateurs
Γ � � e : t
Γ � e : INT
Γ � +e : INT
(UNOP-PLUS-INT)
Γ � e : FLOAT
Γ � +.e : FLOAT
(UNOP-PLUS-FLOAT)
Γ � e : INT
Γ � −e : INT
(UNOP-MINUS-INT)
Γ � e : FLOAT
Γ � −.e : FLOAT
(UNOP-MINUS-FLOAT)
� ∈ {∼,!} Γ � e : INT
Γ � � e : INT
(UNOP-NOT)
Γ � e1 � e2 : t
� ∈ {+,−,×,/,&,|,^,&&,||,�,�,≤,≥,<,>} Γ � e1 : INT Γ � e2 : INT
Γ � e1 � e2 : INT
(OP-INT)
� ∈ {+.,−.,×.,/.,≤ .,≥ .,< .,> .} Γ � e1 : FLOAT Γ � e2 : FLOAT
Γ � e1 � e2 : FLOAT
(OP-FLOAT)
� ∈ {=,�=} Γ � e1 : t Γ � e2 : t EQ(t)
Γ � e1 � e2 : INT
(OP-EQ)
� ∈ {+p,−p} Γ � e1 : t ∗ Γ � e2 : INT
Γ � e1 � e2 : t ∗ (PTR-ARITH)
EQ(t)
t ∈ {INT, FLOAT}
EQ(t)
(EQ-NUM)
EQ(t ∗)
(EQ-PTR)
EQ(t)
EQ(t[ ])
(EQ-ARRAY)
∀i ∈ [1;n].EQ(ti)
EQ({l1 : t1;...ln : tn})
(EQ-STRUCT)C.3. RÈGLES DE TYPAGE DES EXPRESSIONS ET INSTRUCTIONS 145
C.3 Règles de typage des expressions et instructions
Γ � e : t
Γ � l v : t
Γ � &l v : t ∗ (ADDR)
∀i ∈ [1;n],Γ � ei : ti
Γ � {l1 : e1;...;ln : en} : {l1 : t1;...;ln : tn}
(STRUCT)
Γ � e : (t1,...,tn) → t ∀i ∈ [1;n],Γ � ei : ti
Γ � e(e1,...,en) : t
(CALL)
Γ � l v : t Γ � e : t
Γ � l v ← e : t
(SET)
∀i ∈ [1;n],Γ � ei : t
Γ � [e1;...;en] : t[ ]
(ARRAY)
Γ = (ΓG ,ΓL) Γ� = (ΓG , [a1 : t1;...;an : tn;R : t]) Γ� � i
Γ � fun(a1,...,an){i} : (t1,...,tn) → t
(FUN)
Γ � i
Γ � PASS
(PASS)
Γ � i1 Γ � i2
Γ � i1;i2
(SEQ)
Γ � e : t
Γ � e
(EXP)
Γ � e : t Γ,local x : t � i
Γ � DECL x = e IN{i}
(DECL)
Γ � e : INT Γ � i1 Γ � i2
Γ � IF(e){i1}ELSE{i2}
(IF)
Γ � e : INT Γ � i
Γ � WHILE(e){i}
(WHILE)
R : t ∈ Γ Γ � e : t
Γ � RETURN(e)
(RETURN)
Γ � p → Γ�
Γ � e : t
Γ � e → Γ
(T-EXP)
Γ � e : t Γ� = Γ, global x : t
Γ � x = e → Γ� (T-VAR)
Γ � P
[ ] � p1 → Γ1 Γ1 � p2 → Γ2 ... Γn−1 � pn → Γn
� p1,...,pn
(PROG)146 ANNEXE C. RÈGLES DE TYPAGE
C.4 Règles de typage des valeurs
m � v : τ
m � n : INT
(S-INT)
m � d : FLOAT
(S-FLOAT)
m � ( ) : UNIT
(S-UNIT)
m � NULL : τ ∗ (S-NULL)
m �Φ ϕ : τ
m � &� ϕ : τ ∗ (S-PTR)
∀i ∈ [1;n].m � vi : τ
m � [v�1;...; vn] : τ[ ]
(S-ARRAY)
∀i ∈ [1;n].m � vi : τi
m � {l1 : v�1;...;ln : vn} : {l1 : τ1;...;ln : τn}
(S-STRUCT)
m � fun(x1,...,xn){i} : FUNn
(S-FUN)
C.5 Règles de typage des extensions noyau
Γ � l v : t
Γ � ♦ l v : t @
(ADDR-USER)
Γ � ed : t ∗ Γ � es : t @
Γ � copy_from_user(ed ,es) : INT
(USER-GET)
Γ � ed : t @ Γ � es : t ∗
Γ � copy_to_user(ed ,es) : INT
(USER-PUT)A N N E X E
D
PREUVES
On présente ici les preuves de certains résultats établis dans le manuscrit : le caractère
bien fondé de la composition de deux lentilles, et les théorèmes de sûreté du typage.
D.1 Composition de lentilles
Démonstration. On cherche à prouver que, si L1 ∈ LENSA,B et L2 ∈ LENSB,C , alors L =
L1≫L2 ∈ LENSA,C (≫est la composition de lentilles, définie page 39).
Il suffit pour cela d’établir les trois propriétés caractéristiques qui définissent les lentilles :
PUTPUT, GETPUT et PUTGET. Cela est essentiellement calculatoire : on utilise la définition de
≫et les propriétés caractéristiques sur L1 et L2.
PutPut
putL (a�
,putL (a, r ))
= putL (a�
,putL1 (putL2 (a, getL1
(r )), r ))
{ définition de putL }
= putL1 (putL2 (a�
, getL1
(putL1 (putL2 (a, getL1
(r )), r ))),putL1 (putL2 (a, getL1
(r )), r ))
{ définition de putL }
= putL1 (putL2 (a�
,putL2 (a, getL1
(r ))),putL1 (putL2 (a, getL1
(r )), r ))
{ GETPUT sur L1 }
= putL1 (putL2 (a�
, getL1
(r )),putL1 (putL2 (a, getL1
(r )), r ))
{ PUTPUT sur L2 }
= putL1 (putL2 (a�
, getL1
(r )), r )
{ PUTPUT sur L1 }
= putL (a�
, r )
{ définition de≫}
147148 ANNEXE D. PREUVES
GetPut
putL (getL (r ), r ) = putL (getL2
(getL1
(r )), r ) { définition de getL }
= putL1 (putL2 (getL2
(getL1
(r )), getL1
(r )), r ) { définition de putL }
= putL1 (getL1
(r ), r ) { GETPUT sur L2 }
= r { GETPUT sur L1 }
PutGet
getL (putL (a, r )) = getL2
(getL1
(putL (a, r ))) { définition de getL }
= getL2
(getL1
(putL1 (putL2 (a, getL1
(r )), r ))) { définition de putL }
= getL2
(putL2 (a, getL1
(r ))) { PUTGET sur L1 }
= a { PUTGET sur L2 }
D.2 Progrès
On rappelle l’énoncé du théorème 5.1.
Théorème D.1 (Progrès). Supposons que Γ � i. Soit m un état mémoire tel que Γ � m.
Alors l’un des cas suivants est vrai :
• i = PASS
• ∃v,i = RETURN(v)
• ∃(i�
,m�
),〈i,m〉 → 〈i�
,m�
〉
• ∃Ω ∈ {Ωd i v ,Ωar r ay ,Ωp t r },〈i,m〉 → Ω
� � �
Supposons que Γ � e : t. Soit m un état mémoire tel que Γ � m. Alors l’un des cas suivant
est vrai :
• ∃v �= Ω,e = v
• ∃(e�
,m�
),〈e,m〉 → 〈e�
,m�
〉
• ∃Ω ∈ {Ωd i v ,Ωar r ay ,Ωp t r },〈e,m〉 → Ω
� � �
Supposons que Γ � l v : t. Soit m un état mémoire tel que Γ � m.
Alors l’un des cas suivants est vrai :
• ∃ϕ,l v = ϕ
• ∃(l v�
,m�
),〈l v,m〉 → 〈l v�
,m�
〉
• ∃Ω ∈ {Ωd i v ,Ωar r ay ,Ωp t r },〈l v,m〉 → Ω
C’est-à-dire, soit :
• l’entité (instruction, expression ou valeur gauche) est complètement évaluée.
• un pas d’évaluation est possible.
• une erreur de division, tableau ou pointeur se produit.D.2. PROGRÈS 149
Démonstration. On procède par induction sur la dérivation du jugement de typage. Puisque
les jugements Γ � i, Γ � e : t et Γ � l v : t sont interdépendants, on traite tous les cas par
récursion mutuelle.
Le squelette de cette preuve est une analyse de cas selon la dernière règle utilisée. La plupart
des cas ont la même forme : on utilise l’hypothèse de récurrence sur les sous-éléments
syntaxiques (en appliquant éventuellement le lemme 5.1 d’inversion pour établir qu’ils sont
bien typés). Dans le cas « valeur », on appelle une règle qui permet de transformer une opé-
ration syntaxique en opération sémantique (par exemple, on transforme le + unaire en un +�
sémantique). Dans le cas « évaluation », on applique la règle CTX avec un contexte particulier
qui permet de passer d’un jugement 〈a,m〉 → 〈a�
,m�
〉 à un jugement 〈b,m〉 → 〈b�
,m�
〉 (où a
apparaît dans b). Enfin, dans le cas « erreur », on utilise EVAL-ERR avec ce même contexte C.
Ceci est valable pour la majorité des cas. Il faut faire attention en particulier aux opé-
rations sémantiques qui peuvent produire des erreurs (comme la division, ou l’opérateur
Lookup(·,·)).
Instructions
PASS : Ce cas est immédiat.
RETURN : Partant de i = RETURN(e), on applique le lemme d’inversion. Il nous donne l’existence
de t tel que Γ � e : t. On applique alors l’hypothèse de récurrence à e.
• e = v. Alors i = RETURN(v), ce qui nous permet de conclure.
• 〈e,m〉 → 〈e�
,m�
〉. Alors en appliquant CTX avec C = RETURN(•) 1, on conclut que
〈RETURN(e),m〉 → 〈RETURN(e�
),m�
〉.
• 〈e,m〉 → Ω. On applique EVAL-ERR avec ce même C.
SEQ : Avec i = i1;i2, on applique l’hypothèse de récurrence à i1.
• i1 = PASS. On peut donc appliquer la règle SEQ et donc 〈i,m〉 → 〈i2,m〉.
• i1 = RETURN(v). Alors on peut appliquer la règle RETURN : 〈i,m〉 → 〈RETURN(v),m〉.
• 〈i1,m〉 → 〈i�
1,m�
〉. Soit C = •;i2. Par CTX il vient 〈i,m〉 → 〈i�
1;i2,m�
〉.
• 〈i1,m〉 → Ω. Avec ce même C dans EVAL-ERR on trouve 〈i,m〉 → Ω.
EXP : Ici i = e. On peut appliquer l’hypothèse de récurrence à e qui est « plus petit » que i
(i ::= e introduit un constructeur implicite).
• e = v. Alors on peut appliquer EXP : 〈e,m〉 → 〈PASS,m〉.
• 〈e,m〉 → 〈e�
,m�
〉. Alors 〈i,m〉 → 〈e�
,m�
〉 (cela revient à appliquer CTX au constructeur
implicite mentionné ci-dessus).
• 〈e,m〉 → Ω. C’est-à-dire 〈i,m〉 → Ω.
1. Les contextes sont des objets purement syntaxiques : on peut les appliquer entre instructions et expressions
indifféremment150 ANNEXE D. PREUVES
DECL : Ici i = DECL x = e IN{i�
}. On commence par appliquer l’hypothèse de récurrence à e.
• e = v. On applique alors l’hypothèse de récurrence à i� sous Γ� = Γ,local x : t et avec
m� = Extend(m,x �→ v).
• i� = PASS. Dans ce cas la règle DECL-PASS s’applique.
• i� = RETURN(v). Idem avec DECL-RETURN.
• 〈i�
,m�
〉 → 〈i��,m��〉. On peut alors appliquer la règle DECL-CTX.
• 〈i�
,m�
〉 → Ω. On applique DECL-ERR.
• 〈e,m〉 → 〈e�
,m�
〉. On pose C = DECL x = • IN{i�
} et on conclut avec la règle CTX.
• 〈e,m〉 → Ω. Idem avec EVAL-ERR.
IF : Ici i = IF(e){i1}ELSE{i2}. On applique l’hypothèse de récurrence à e.
• e = v.
Si v �= 0, on applique IF-TRUE. Dans le cas contraire, on applique IF-FALSE.
• 〈e,m〉 → 〈e�
,m�
〉. On pose C = IF(•){i1}ELSE{i2} et on conclut avec CTX.
• 〈e,m〉 → Ω. Avec ce même C et EVAL-ERR.
WHILE : Ce cas est direct : on applique la règle d’évaluation WHILE.
Expressions
CST-INT : e est alors de la forme n, qui est une valeur.
CST-FLOAT : e est alors de la forme d, qui est une valeur.
CST-NULL : e est alors égale à NULL, qui est une valeur.
CST-UNIT : e est alors égale à ( ), qui est une valeur.
FUN : Ce cas est direct : la règle EXP-FUN s’applique.
OP-INT : Cela implique que e = e1 � e2. Par le lemme 5.1, on en déduit que Γ � e1 : INT et
Γ � e2 : INT.
Appliquons l’hypothèse de récurrence sur e1. Trois cas peuvent se produire.
• e1 = v1. On a alors 〈e1,m〉 = 〈v1,m�
〉 avec m� = m.
On applique l’hypothèse de récurrence à e2.
• e2 = v2 : alors 〈e2,m�
〉 = 〈v2,m��〉 avec m�� = m. On peut alors appliquer EXPBINOP,
sauf dans le cas d’une division par zéro (� ∈ {/;%;/.} et v2 = 0) où alors
v1 �� v2 = Ωd i v . Dans ce cas, on a alors par EXP-ERR 〈e,m〉 → Ωd i v . Notons que
comme les opérandes sont bien typés, Ωt yp ne peut pas être levée.
• ∃(e�
2,m��),〈e2,m�
〉 → 〈e�
2,m��〉.
En appliquant CTX avec C = v1 � •, on en déduit 〈v1 � e2,m�
〉 → 〈v1 � e�
2,m��〉
soit 〈e,m〉 → 〈v1 � e�
2,m��〉.
• 〈e2,m�
〉 → Ω. De EVAL-ERR avec C = v1 � • vient alors 〈e,m〉 → Ω.D.2. PROGRÈS 151
• ∃(e�
1,m�
),〈e1,m〉 → 〈e�
1,m�
〉. En appliquant CTX avec C = • � e2, on obtient
〈e1 � e2,m〉 → 〈e�
1 � e2,m�
〉, ou 〈e,m〉 → 〈e�
1 � e2,m�
〉.
• 〈e1,m〉 → Ω. D’après EVAL-ERR avec C = • � e2, on a 〈e,m〉 → Ω.
OP-FLOAT : Ce cas est similaire à OP-INT.
OP-EQ : Ce cas est similaire à OP-INT.
UNOP-PLUS-INT : Alors e = + e1. En appliquant l’hypothèse d’induction sur e1 :
• soit e1 = v1. Alors en appliquant EXP-UNOP, 〈+ v1,m〉 → 〈+� v1,m〉, c’est-à-dire en posant
v = +� v1, 〈e,m〉 → 〈v,m〉.
• soit ∃e�
1,m�
,〈e1,m〉 → 〈e�
1,m�
〉. Alors en appliquant CTX avec C = + •, on obtient
〈e,m〉 → 〈e�
1,m�
〉.
• soit 〈e1,m〉 → Ω. De EVAL-ERR avec C = + • il vient〈e,m〉 → Ω.
UNOP-PLUS-FLOAT : Ce cas est similaire à UNOP-PLUS-INT.
UNOP-MINUS-INT : Ce cas est similaire à UNOP-PLUS-INT.
UNOP-MINUS-FLOAT : Ce cas est similaire à UNOP-PLUS-INT.
UNOP-NOT : Ce cas est similaire à UNOP-PLUS-INT.
ADDR : On applique l’hypothèse de récurrence à l v.
Les cas d’évaluation et d’erreur sont traités en appliquant respectivement CTX et EVALERR
avec C = &•. Dans le cas où l v = ϕ, on peut appliquer EXP-ADDR.
SET : On applique l’hypothèse de récurrence à l v.
• l v = ϕ. On applique l’hypothèse de récurrence à e.
• e = v. Alors on peut appliquer EXP-SET.
• 〈e,m〉 → 〈e�
,m�
〉. On conclut avec C = ϕ ← •.
• 〈e,m〉 → Ω. Idem.
• 〈l v,m〉 → 〈l v�
,m�
〉. On conclut avec C = • ← e.
• 〈l v,m〉 → Ω. Idem.
ARRAY : On va appliquer l’hypothèse de récurrence à e1, puis, si e1 = v1, on l’applique à e2,
etc. Alors on se retrouve dans un des cas suivants :
• ∃p ∈ [1;n],e�
p,m : e1 = v1,...,ep−1 = vp−1,〈ep,m〉 → 〈e�
p,m�
〉. Alors on peut appliquer
CTX avec C = [v1;...; vp−1;•;ep+1;...;en].
• ∃p ∈ [1;n],Ω : e1 = v1,...,ep−1 = vp−1,〈ep,m〉 → Ω. Dans ce cas EVAL-ERR est applicable
avec ce même C.
• e1 = v1,...,en = vn. Alors on peut appliquer EXP-ARRAY en construisant un tableau.152 ANNEXE D. PREUVES
STRUCT : Le schéma de preuve est similaire au cas ARRAY. En cas de pas d’évaluation ou
d’erreur, on utilise le contexte C = {l1 : v1;...;lp−1 : vp−1;lp : •;lp+1 : ep+1;...;ln : en} ; et dans
le cas où toutes les expressions sont évaluées, on applique EXP-STRUCT.
CALL : On commence par appliquer l’hypothèse de récurrence à e. Dans le cas d’un pas
d’évaluation ou d’erreur, on applique respectivement CTX ou EVAL-ERR avecC = •(e1,...,en).
Reste le cas où e est une valeur : d’après le lemme 5.2, e est de la forme f = fun(a1,...,an){i}.
Ensuite, appliquons le même schéma que pour ARRAY. En cas de pas d’évaluation ou d’erreur,
on utilise CTX ou EVAL-ERR avec C = f (v1,..., vp−1,•,ep+1,...,en). Le seul cas restant est
celui où l’expression considérée a pour forme f (v1,..., vn) avec f = fun(a1,...,an){i}.
Soit Γ� = (ΓG , [a1 : t1,...,an : tn,R : t]) et m1 = Push(m0, (a1 �→ v1,...an �→ vn)) où Γ =
(ΓG ,ΓL).
On applique alors l’hypothèse de récurrence à Γ�
, m1 et i (le lemme d’inversion garantit
que Γ� � i).
• i = RETURN(v). Alors on applique EXP-CALL-RETURN.
• i = PASS. Ce cas est impossible puisqu’on prend l’hypothèse que les fonctions se terminent
par une instruction RETURN(·) (page 56).
• 〈i,m1〉 → 〈i�
,m2〉. Alors on peut appliquer EXP-CALL-CTX.
• 〈i,m〉 → Ω. On peut alors appliquer EXP-CALL-ERR.
Valeurs gauches
LV-VAR : Le but est d’appliquer PHI-VAR. La seule condition pour que cela soit possible est
que Lookup(x,m) renvoie une adresse et non Ωvar .
Puisque Γ � x : t, on peut appliquer le lemme 5.5 : x est soit une variable locale, soit une
globale. Dans ces deux cas, Lookup(x,m) renvoie une adresse correcte.
LV-DEREF : Appliquons l’hypothèse de récurrence à e vue en tant qu’expression.
• e = v. Puisque Γ � v : t∗, on déduit du lemme 5.2 que v = NULL ou v = &� ϕ.
Dans le premier cas, puisque 〈∗NULL,m〉 → Ωp t r , on a 〈e,m〉 → Ωp t r .
Dans le second cas, EXP-DEREF s’applique.
• 〈e,m〉 → 〈e�
,m�
〉. De CTX avec C = ∗•, on obtient 〈e,m〉 → 〈∗e�
,m�
〉.
• 〈e,m〉 → Ω. En appliquant EVAL-ERR avec C = ∗•, on obtient 〈e,m〉 → Ω.
LV-INDEX : De même, on applique l’hypothèse de récurrence à l v.
• l v = v.
Comme Γ � v : t[ ], on déduit du lemme 5.2 que v = [v1;...; vp]. Appliquons l’hypothèse
de récurrence à e.
• e = v�
. Puisque Γ � e : INT, on réapplique le lemme 5.2 et v� = n. D’après PHIARRAY,〈l
v[e],m〉 → 〈[v1;...; vp][
�n],m〉. Deux cas sont à distinguer : si n ∈ [0;p−1],
la partie droite vaut vn+1 et donc 〈l v[e],m〉 → 〈vn+1,m〉. Sinon elle vaut Ωar r ay et
〈l v[e],m〉 → Ωar r ay par EXP-ERR.
• 〈e,m〉 → 〈e�
,m�
〉. En appliquant CTX avec C = v[•], on en déduit 〈l v[e],m〉 →
〈l v[e�
],m�
〉.
• 〈e,m〉 → Ω. Avec EVAL-ERR sous ce même contexte, 〈l v[e],m〉 → ΩD.3. PRÉSERVATION 153
• 〈l v,m〉 → 〈e�
,m�
〉. On applique alors CTX avec C = •[e], et 〈l v[e],m〉 → 〈e�
[e],m�
〉.
• 〈l v,m〉 → Ω. Toujours avec C = •[e], de EVAL-ERR il vient 〈l v[e],m〉 → Ω.
LV-FIELD : On applique l’hypothèse de récurrence à l v.
• l v = ϕ Alors PHI-STRUCT s’applique. Puisque (l,t) ∈ S, l’accès au champ l ne provoque
pas d’erreur Ωf i eld . Donc 〈e,m〉 → 〈ϕ[l],m〉.
• 〈l v,m〉 → 〈l v�
,m�
〉 En appliquant CTX avec C = •.lS, il vient 〈l v,m〉 → 〈l v�
,m�
〉.
• 〈l v,m〉 → Ω En appliquant EVAL-ERR avec C = •.lS, on a 〈l v,m〉 → Ω.
PTR-ARITH : Le schéma est similaire au cas OP-INT. Le seul cas intéressant arrive lorsque
e1 et e2 sont des valeurs. D’après le lemme 5.2 :
• e1 = NULL ou e1 = ϕ
• e2 = n
D’après EXP-BINOP, 〈e,m〉 → 〈e1 �� n,m〉.
On se réfère ensuite à la définition de �� (page 55) : si e1 est de la forme ϕ[m], alors e1 �� n =
ϕ[m +n]. Donc 〈e,m〉 → 〈ϕ[m +n],m〉.
Dans les autres cas (e1 = NULL ou e1 = ϕ avec ϕ pas de la forme ϕ�
[m]), on a e1 �� n = Ωp t r .
Donc d’après EXP-ERR, 〈e,m〉 → Ωp t r .
D.3 Préservation
On rappelle l’énoncé du théorème 5.2.
Théorème D.2 (Préservation). Soient Γ un environnement de typage, et m un état mémoire
tels que Γ � m.
Alors :
• Si Γ � l v : t et 〈l v,m〉 → 〈ϕ,m�
〉, alors Γ � Cleanup(m�
) et m� �Φ ϕ : τ où τ�t.
• Si Γ � l v : t et 〈l v,m〉 → 〈l v�
,m�
〉, alors Γ � Cleanup(m�
) et Γ � l v� : t.
• Si Γ � e : t et 〈e,m〉 → 〈v,m�
〉, alors Γ � Cleanup(m�
) et m� � v : τ où τ�t.
• Si Γ � e : t et 〈e,m〉 → 〈e�
,m�
〉, alors Γ � Cleanup(m�
) et Γ � e� : t.
• Si Γ � i et 〈i,m〉 → 〈i�
,m�
〉, alors Γ � Cleanup(m�
) et Γ � i�
.
Autrement dit, si une construction est typable, alors un pas d’évaluation ne modifie pas son
type et préserve le typage de la mémoire.
Démonstration. On procède par induction sur la dérivation de 〈·,m〉 → 〈·,m�
〉. Plusieurs remarques
sont à faire : d’abord, en ce qui concerne le typage de la mémoire, il suffit de montrer
que Γ � m� car cela implique que Γ � Cleanup(m�
). Ensuite, la règle CTX est traitée à part, car
elle peut être appliquée en contexte d’expression, d’instruction ou de valeur gauche. Enfin
la règle TRANS ne pose pas de problème, il suffit d’appliquer l’hypothèse de récurrence à ses
prémisses.
Cas Γ � l v : t et 〈l v,m〉 → 〈ϕ,m�
〉
EXP-DEREF : On sait que Γ � ∗ v : t où v = &� ϕ. Par inversion, Γ � v : t ∗. Alors d’après
le lemme 5.3, il existe τ� tel que m � v : τ� et τ� � t ∗. Par inversion de la relation de typage
sémantique, τ� = τ ∗ où τ�t. Alors par inversion de S-PTR, on obtient que m �Φ ϕ : τ.154 ANNEXE D. PREUVES
PHI-VAR, PHI-STRUCT et PHI-ARRAY : Il n’est pas nécessaire de montrer la compatibilité
de m� car la mémoire n’est pas modifiée. De plus, les prémisses de ces règles ont la forme ϕ ,
donc le lemme 5.6 s’applique avec la conclusion correcte.
Cas Γ � e : t et 〈e,m〉 → 〈v,m�
〉
EXP-CST : Toutes les constantes sont des valeurs, donc le lemme 5.3 peut s’appliquer : τ =
Repr(t) convient.
EXP-FUN : Idem : le lemme de représentabilité nous donne un candidat τ = Repr(t) qui
convient.
EXP-LV : Puisque Γ � ϕ : t et Γ � m, on a d’après le lemme 5.6 : m � v : τ où v = m[ϕ] avec
τ�t.
EXP-UNOP : Il vient des définitions des différents opérateurs �� que Γ � �� v : τ avec τ�t.
EXP-BINOP : Idem avec les définitions des opérateurs �� .
EXP-ADDR : On peut appliquer le lemme 5.3, qui nous donne un τ qui convient.
EXP-SET : Deux propriétés sont à prouver. D’une part, Γ � v : t, et d’autre part, Γ � m� où
m� = m[ϕ ← v]. Tout d’abord, le lemme d’inversion appliqué à Γ � ϕ ← v : t nous donne que
Γ � ϕ : t et Γ � v : t. Ensuite, comme Γ � ϕ : t et Γ � m, on peut appliquer le lemme 5.3 : il
existe τ tel que m � v : τ et τ� t. On peut donc appliquer le lemme 5.6, qui nous permet de
conclure que Γ � m�
.
EXP-STRUCT : Le lemme 5.3 s’applique à ce cas.
EXP-ARRAY : Idem, on conclut grâce au lemme de représentabilité.
EXP-CALL-RETURN : Par inversion, il vient que Γ � fun(a1,...,an){i} : (t1,...,tn) → t� et ∀i ∈
[1;n],Γ � vi : ti .
Posons Γ� = (ΓG , [a1 : t1,...,an : tn,R : t�
]) où Γ = (ΓG ,ΓL). Alors par inversions successives
on obtient que Γ� � RETURN(v) et Γ� � v : t�
.
Si on définit m�� = Push(m,a1 �→ v1,...,an �→ vn), alors par M-PUSH on obtient que Γ� �
m��. Donc, par le lemme 5.3, il existe τ tel que m�� � v : τ où τ�t�
.
Il reste à montrer que m� � v� : τ.
On distingue selon la forme de v. On applique un raisonnement similaire à celui de la
preuve du lemme 5.6 : soit v est une référence au cadre nettoyé, et dans ce cas v� = NULL et τ
est un type pointeur, soit v� = v. Dans tous les cas on conclut car m� � v� : τ.
Cas Γ � i et 〈i,m〉 → 〈i�
,m�
〉
SEQ : D’après le lemme d’inversion, Γ � i.
EXP : D’après PASS, Γ � PASS.D.3. PRÉSERVATION 155
DECL-PASS : Γ � PASS est immédiat, et Γ � m� est établi par M-DECL suivie de
M-DECLCLEAN. On a bien x ∉ Γ car les déclarations de variable ne peuvent pas masquer
de variables visibles existantes (page 57).
DECL-RETURN : La compatibilité mémoire se démontre de la même manière que pour
DECL-PASS. Il reste à montrer que Γ � RETURN(v��), ce qui fait de manière analogue au cas
EXP-CALL-RETURN.
DECL-CTX : On part de Γ � DECL x = v IN{i}. Par inversion, il existe t tel que Γ � v : t et
Γ� � i où Γ� = Γ,local x : t.
Comme Γ � m, le lemme 5.3 s’applique : il existe τ tel que m � v : τ où τ�t. De plus x ∉ Γ
car il n’y a pas de masquage (page 57).
En appliquant M-DECL, on obtient donc que Γ� � m�
.
On applique alors l’hypothèse d’induction à 〈i,m�
〉 → 〈i�
,m��〉. Il vient que Γ� � i� et Γ� �
m��.
On a donc Γ� � DECL x = v� IN{i�
} par DECL et à � Cleanup(m���) par M-DECLCLEAN.
IF-FALSE : D’après le lemme d’inversion, Γ � if .
IF-TRUE : D’après le lemme d’inversion, Γ � it .
WHILE : D’après le lemme d’inversion, Γ � e : t et Γ � i. Par SEQ, on a Γ � i;WHILE(e){i}.
Enfin par IF il vient Γ � IF(e){i;WHILE(e){i}}ELSE{PASS}.
RETURN : Par le lemme d’inversion, Γ � RETURN(v).
EXP-CALL-CTX : On sait que Γ � fun(a1,...,an){i}(v1,..., vn) et Γ � m0. D’après le lemme
d’inversion, il existe t1,...,tn tels que ∀i ∈ [1;n],Γ � vi : ti , Γ � fun(a1,...,an){i} : (t1,...,tn) →
t, donc qu’en posant Γ� = (ΓG , [a1 : t1,...,an : tn,R : t]) où Γ = (ΓG ,ΓL) on a Γ� � i.
D’un autre côté, il existe par le lemme 5.3 des types τi tels que ∀i ∈ [1;n],m0 � vi : τi avec
τi �ti . En appliquant M-PUSH, on a donc Γ� � m1.
On peut alors appliquer l’hypothèse d’induction à 〈i,m1〉 → 〈i�
,m2〉 : la conclusion est
que Γ� � i� et Γ� � m2. Comme Γ� � ai : ti , on a ∀i ∈ [1;n],Γ� � v�
i : ti . Donc on a bien Γ �
fun(a1,...,an){i�
}(v�
1,..., v�
n) : t.
D’autre part, en appliquant M-POP, on obtient que Γ � Cleanup(m3).
À propos de la règle CTX
L’application de la règle CTX nécessite une explication particulière. En effet, ce cas repose
sur un lemme d’inversion des constructions typées sous un contexte, qui est admis ici.
Par exemple, traitons le cas où le contexte C est tel que son « trou » soit une valeur gauche
l v et C�l v� est une instruction (les autres cas sont similaires). La règle appliquée est alors de
la forme :
〈l v,m〉 → 〈l v�
,m�
〉
〈C�l v�,m〉 → 〈C�l v�
�,m�
〉
(CTX)
Si Γ � C�l v�, on admet qu’il existe Γ� et t tels que :
• Γ� � l v : t ;156 ANNEXE D. PREUVES
• Quel que soit l v�
, si Γ� � l v� : t, alors Γ � C�l v�
�.
Par exemple, pour C = •[2] = 1, Γ� = Γ et t = INT[ ] conviennent. Pour C = DECL x =
0 IN{• = 3.0}, on prendra Γ� = Γ,local x : INT et t = FLOAT. Le fait de passer « sous » une dé-
claration ajoute une variable locale à Γ, et ainsi l’ensemble des variables de Γ� contient celui
de Γ.
Pour prouver la préservation dans ce cas, on commence par appliquer l’hypothèse de
récurrence à la prémisse de CTX, c’est-à-dire 〈l v,m〉 → 〈l v�
,m�
〉. Il vient que Γ� � l v� : t et
Γ� � Cleanup(m�
).
D’après le précédent lemme d’inversion on en déduit que Γ � C�l v�
�. De plus Γ� contient
plus de variables que Γ donc Γ � Cleanup(m�
).
D.4 Progrès pour les extensions noyau
(Théorème 6.1)
Démonstration. On procède de la même manière que pour le théorème 5.1 (prouvé en annexe
D.2). En fait, puisque le schéma de preuve porte sur les règles de typage, il suffit de traiter
les cas supplémentaires.
ADDR-USER : Alors e = ♦ l v. On applique l’hypothèse de récurrence à l v.
• l v = ϕ. Alors on peut appliquer PHI-USER.
• 〈l v,m〉 → 〈l v�
,m�
〉. On conclut en utilisant CTX avec C = ♦ •.
• 〈l v,m〉 → Ω. On applique EVAL-ERR avec ce même C.
USER-GET : On applique l’hypothèse de récurrence à ed .
• ed = vd . On applique l’hypothèse de récurrence à es.
• es = vs.
D’après le lemme 5.2 adapté aux extensions noyau, vs a pour forme ϕs.
On distingue la forme de ϕs :
• ϕs = ♦� ϕ. Alors on applique USER-GET-OK. Le lemme 5.6 adapté aux extensions
noyau assure que les prémisses sont correctes.
• � ϕ,ϕs = ♦� ϕ. Alors on applique USER-GET-ERR.
• 〈es,m〉 → 〈e�
s,m�
〉. Posons C = copy_from_user(vd ,•). On conclut avec CTX.
• 〈es,m〉 → Ω. Idem avec EVAL-ERR.
• 〈ed ,m〉 → 〈e�
d ,m�
〉. On applique CTX avec C = copy_from_user(•,es).
• 〈ed ,m〉 → Ω. On utilise EVAL-ERR avec ce même contexte.
USER-PUT : Ce cas est similaire au cas USER-GET, en appliquant les règles USER-PUT-OK
et USER-PUT-ERR.D.5. PRÉSERVATION POUR LES EXTENSIONS NOYAU 157
D.5 Préservation pour les extensions noyau
(Théorème 6.2)
De même, il suffit de prouver les cas correspondant aux nouvelles règles.
PHI-USER : On applique le lemme de représentation, qu’on étend avec le cas
Repr(t @) = Repr(t) @.
USER-GET-OK : Tout d’abord, d’après le lemme 6.1, t = INT, donc la préservation du type
est établie car m� � 0 : INT. La compatibilité mémoire est obtenue en appliquant M-WRITE.
USER-GET-ERR : La seule partie à prouver est la préservation, qui se fait de la même manière
que dans le cas précédent.
USER-PUT-OK : Idem que dans le cas USER-PUT-OK.
USER-PUT-ERR : Idem que pour USER-GET-ERR.LISTE DES FIGURES
1.1 Surapproximation. L’ensemble des états erronés est hachuré. L’ensemble des états
effectifs du programme, noté par des points, est approximé par l’ensemble en gris. 9
1.2 Utilisation de l’attribut non-standard packed . . . . . . . . . . . . . . . . . . . . . . 10
2.1 Mécanisme de mémoire virtuelle. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.2 Implantation de la mémoire virtuelle . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.3 Appel de gettimeofday . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
2.4 Implantation de l’appel système gettimeofday . . . . . . . . . . . . . . . . . . . . . 19
3.1 Domaine des signes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Quelques domaines abstraits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.3 Treillis de qualificateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
4.1 Fonctionnement d’une lentille . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.2 Fonctionnement d’une lentille indexée . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3 Composition de lentilles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.4 Syntaxe des expressions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.5 Syntaxe des instructions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.6 Syntaxe des opérateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.7 Valeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.8 Composantes d’un état mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.9 Opérations de pile . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.10 Cassage du typage par un pointeur fou . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.11 Dépendances entre les lentilles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.12 Contextes d’évaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.13 Évaluation stricte ou paresseuse des valeurs gauches . . . . . . . . . . . . . . . . . 54
5.1 Programmes bien et mal formés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.2 Types et environnements de typage . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
5.3 Jugements d’égalité sur les types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.4 Typage des phrases et programmes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.5 Types de valeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.6 Règles de typage des valeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
5.7 Compatibilité entre types de valeurs et statiques . . . . . . . . . . . . . . . . . . . . 72
5.8 Compatibilité entre états mémoire et environnements de typage . . . . . . . . . . 72
6.1 Interface permettant d’ouvrir un fichier sous Unix . . . . . . . . . . . . . . . . . . . 82
6.2 Ajouts liés aux entiers utilisés comme bitmasks . . . . . . . . . . . . . . . . . . . . . 83
6.3 Nouvelles valeurs liées aux bitmasks . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.4 Dérivation montrant que ! (x & y) est bien typée . . . . . . . . . . . . . . . . . . . . 85
6.5 Implantation d’un appel système qui remplit une structure par pointeur . . . . . . 87
6.6 Ajouts liés aux pointeurs utilisateur (par rapport à l’interprète du chapitre 4) . . . 87
6.7 Appel de la fonction sys_getver de la figure 6.5 . . . . . . . . . . . . . . . . . . . . . 88
6.8 Ajouts liés aux pointeurs utilisateur (par rapport aux figures 5.2 et 5.5) . . . . . . . 90
159160 Liste des figures
7.1 Syntaxe simplifiée de NEWSPEAK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
7.2 Compilation du flot de contrôle en NEWSPEAK . . . . . . . . . . . . . . . . . . . . . 101
7.3 Fonction principale de ptrtype . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
7.4 Algorithme d’unification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
7.5 Unification directe ou retardée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
7.6 Inférence des déclarations de variable et appels de fonction . . . . . . . . . . . . . 106
8.1 Espace d’adressage d’un processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
8.2 Fonction de définition d’un appel système . . . . . . . . . . . . . . . . . . . . . . . . 113
8.3 Code de la fonction radeon_info_ioctl . . . . . . . . . . . . . . . . . . . . . . . . . 114
8.4 Définition de struct drm_radeon_info . . . . . . . . . . . . . . . . . . . . . . . . . 114
8.5 Patch résolvant le problème de pointeur utilisateur. . . . . . . . . . . . . . . . . . . 115
8.6 Implantation de ptrace sur architecture Blackfin . . . . . . . . . . . . . . . . . . . 116
8.7 Cas d’étude « Radeon » minimisé et annoté . . . . . . . . . . . . . . . . . . . . . . . 118
8.8 Cas d’étude « Radeon » minimisé et annoté – version correcte . . . . . . . . . . . . 118
8.9 Cas d’étude « Blackfin » . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
8.10 Traduction en NEWSPEAK du cas d’étude « Blackfin » . . . . . . . . . . . . . . . . . . 121LISTE DES DÉFINITIONS
4.1 Définition (Lentille) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
4.2 Définition (Lentille indexée) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
4.3 Définition (Composition de lentilles) . . . . . . . . . . . . . . . . . . . . . . . . . 39
4.4 Définition (Recherche de variable) . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.5 Définition (Manipulations de pile) . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.6 Définition (Hauteur d’une valeur) . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
LISTE DES THÉORÈMES ET LEMMES
5.1 Lemme (Inversion) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.2 Lemme (Formes canoniques) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.3 Lemme (Représentabilité) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.4 Lemme (Hauteur des chemins typés) . . . . . . . . . . . . . . . . . . . . . . . . . 75
5.5 Lemme (Accès à des variables bien typées) . . . . . . . . . . . . . . . . . . . . . . 75
5.6 Lemme (Accès à une mémoire bien typée) . . . . . . . . . . . . . . . . . . . . . . 76
5.1 Théorème (Progrès) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.2 Théorème (Préservation) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.3 Théorème (Progrès pour les phrases) . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.4 Théorème (Préservation pour les phrases) . . . . . . . . . . . . . . . . . . . . . . 78
6.1 Lemme (Inversion du typage) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
6.1 Théorème (Progrès pour les extensions noyau) . . . . . . . . . . . . . . . . . . . 92
6.2 Théorème (Préservation pour les extensions noyau) . . . . . . . . . . . . . . . . 92
D.1 Théorème (Progrès) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
D.2 Théorème (Préservation) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
161RÉFÉRENCES WEB
[☞1] The C - - language
http://www.cminusminus.org/
[☞2] OCaml – Home
http://ocaml.org/
[☞3] Penjili project
https://bitbucket.org/iwseclabs/c2newspeak
[☞4] Python Programming Language – Official Website
http://www.python.org/
[☞5] The Rust Programming Language
http://www.rust-lang.org/
[☞6] Sparse - a Semantic Parser for C
https://sparse.wiki.kernel.org/index.php/Main_Page
163BIBLIOGRAPHIE
[AB07] Andrew W. Appel and Sandrine Blazy. Separation logic for small-step Cminor. In
Proceedings of the 20th International Conference on Theorem Proving in Higher
Order Logics, TPHOLs 2007, pages 5–21, 2007.
[ABD+07] Alex Aiken, Suhabe Bugrara, Isil Dillig, Thomas Dillig, Brian Hackett, and Peter
Hawkins. An overview of the saturn project. In Proceedings of the 7th ACM
SIGPLAN-SIGSOFT workshop on Program analysis for software tools and engineering,
PASTE ’07, pages 43–48. ACM, 2007.
[AH07] Xavier Allamigeon and Charles Hymans. Analyse statique par interprétation abstraite.
In Eric Filiol, editor, 5ème Symposium sur la Sécurité des Technologies de
l’Information et des Communications (SSTIC’07), 2007.
[BA08] S. Bugrara and A. Aiken. Verifying the Safety of User Pointer Dereferences. In
Security and Privacy, 2008. SP 2008. IEEE Symposium on, pages 325–338, 2008.
[BBC+10] Al Bessey, Ken Block, Ben Chelf, Andy Chou, Bryan Fulton, Seth Hallem, Charles
Henri-Gros, Asya Kamsky, Scott McPeak, and Dawson Engler. A few billion lines
of code later : using static analysis to find bugs in the real world. Commun. ACM,
53(2) :66–75, 2010.
[BC05] Daniel P. Bovet and Marco Cesati. Understanding the Linux Kernel, Third Edition.
O’Reilly Media, third edition edition, 2005.
[BCC+03] Armin Biere, Alessandro Cimatti, Edmund M. Clarke, Ofer Strichman, and Yunshan
Zhu. Bounded model checking. Advances in Computers, 58 :117–148, 2003.
[BDH+09] Julien Brunel, Damien Doligez, René Rydhof Hansen, Julia L. Lawall, and Gilles
Muller. A foundation for flow-based program matching using temporal logic and
model checking. In The 36th Annual ACM SIGPLAN - SIGACT Symposium on
Principles of Programming Languages, POPL, pages 114–126, 2009.
[BDL06] Sandrine Blazy, Zaynah Dargaye, and Xavier Leroy. Formal verification of a C
compiler front-end. In FM 2006 : Int. Symp. on Formal Methods, volume 4085 of
Lecture Notes in Computer Science, pages 460–475. Springer, 2006.
[BDN09] Ana Bove, Peter Dybjer, and Ulf Norell. A brief overview of Agda — a functional
language with dependent types. In Proceedings of the 22nd International
Conference on Theorem Proving in Higher Order Logics, TPHOLs ’09, pages 73–
78. Springer-Verlag, 2009.
[BGH10] Lennart Beringer, Robert Grabowski, and Martin Hofmann. Verifying pointer and
string analyses with region type systems. In Proceedings of the 16th International
Conference on Logic for Programming, Artificial Intelligence, and Reasoning,
LPAR’10, pages 82–102. Springer-Verlag, 2010.
[BLS05] Mike Barnett, K. Rustan M. Leino, and Wolfram Schulte. The Spec# programming
system : an overview. In Proceedings of the 2004 international conference
on Construction and Analysis of Safe, Secure, and Interoperable Smart Devices,
CASSIS’04, pages 49–69. Springer-Verlag, 2005.
165166 BIBLIOGRAPHIE
[CC77] Patrick Cousot and Radhia Cousot. Abstract interpretation : a unified lattice model
for static analysis of programs by construction or approximation of fixpoints.
In Proceedings of the 4th ACM SIGACT-SIGPLAN symposium on Principles of Programming
Languages, POPL ’77, pages 238–252. ACM, 1977.
[CC92] P. Cousot and R. Cousot. Abstract interpretation and application to logic programs.
Journal of Logic Programming, 13(2–3) :103–179, 1992. (The editor of Journal
of Logic Programming has mistakenly published the unreadable galley proof. For a correct version
of this paper, see http://www.di.ens.fr/~cousot.).
[CCF+05] Patrick Cousot, Radhia Cousot, Jérôme Feret, Laurent Mauborgne, Antoine Miné,
David Monniaux, and Xavier Rival. The ASTREÉ analyzer. In Proceedings of the
14th European Symposium on Programming, ESOP 2005, pages 21–30, 2005.
[CCF+09] Patrick Cousot, Radhia Cousot, Jérôme Feret, Laurent Mauborgne, Antoine Miné,
and Xavier Rival. Why does Astrée scale up ? Formal Methods in System Design,
35(3) :229–264, 2009.
[CE81] Edmund M. Clarke and E. Allen Emerson. Design and synthesis of synchronization
skeletons using branching-time temporal logic. In Dexter Kozen, editor,
Logic of Programs, volume 131 of Lecture Notes in Computer Science, pages 52–71.
Springer, 1981.
[CH78] P. Cousot and N. Halbwachs. Automatic discovery of linear restraints among
variables of a program. In Conference Record of the Fifth Annual ACM SIGPLANSIGACT
Symposium on Principles of Programming Languages, POPL ’78, pages
84–97. ACM Press, New York, NY, 1978.
[CMP03] Emmanuel Chailloux, Pascal Manoury, and Bruno Pagano. Développement d’applications
avec Objective CAML. O’Reilly, 2003.
[DDMP10] Javier De Dios, Manuel Montenegro, and Ricardo Peña. Certified absence of dangling
pointers in a language with explicit deallocation. In Proceedings of the 8th
international conference on Integrated formal methods, IFM’10, pages 305–319.
Springer-Verlag, 2010.
[DM82] Luis Damas and Robin Milner. Principal type-schemes for functional programs.
In Proceedings of the 9th ACM SIGPLAN-SIGACT symposium on Principles of programming
languages, POPL ’82, pages 207–212. ACM, 1982.
[DRS03] Nurit Dor, Michael Rodeh, and Mooly Sagiv. CSSV : Towards a realistic tool for
statically detecting all buffer overflows in C. In Proceedings of the ACM SIGPLAN
2003 conference on Programming language design and implementation, PLDI ’03,
pages 155–167. ACM, 2003.
[EH94] Ana Erosa and Laurie J. Hendren. Taming control flow : A structured approach to
eliminating goto statements. In In Proceedings of 1994 IEEE International Conference
on Computer Languages, pages 229–240. IEEE Computer Society Press,
1994.
[FFA99] Jeffrey S. Foster, Manuel Fähndrich, and Alexander Aiken. A theory of type quali-
fiers. In Proceedings of the 1999 ACM SIGPLAN conference on Programming language
design and implementation, PLDI ’99, pages 192–203, 1999.BIBLIOGRAPHIE 167
[FGM+07] J. Nathan Foster, Michael B. Greenwald, Jonathan T. Moore, Benjamin C. Pierce,
and Alan Schmitt. Combinators for bidirectional tree transformations : A linguistic
approach to the view-update problem. ACM Trans. Program. Lang. Syst.,
29(3), 2007.
[FJKA06] Jeffrey S. Foster, Robert Johnson, John Kodumal, and Alex Aiken. Flow-insensitive
type qualifiers. ACM Trans. Program. Lang. Syst., 28 :1035–1087, 2006.
[Flo67] Robert W. Floyd. Assigning Meanings to Programs. In J. T. Schwartz, editor, Proceedings
of a Symposium on Applied Mathematics, volume 19 of Mathematical
Aspects of Computer Science, pages 19–31. American Mathematical Society, 1967.
[FTA02] Jeffrey S. Foster, Tachio Terauchi, and Alex Aiken. Flow-sensitive type qualifiers.
In Proceedings of the 2002 ACM SIGPLAN Conference on Programming language
design and implementation, PLDI ’02, pages 1–12. ACM, 2002.
[GGTZ07] Stephane Gaubert, Eric Goubault, Ankur Taly, and Sarah Zennou. Static analysis
by policy iteration on relational domains. In Rocco Nicola, editor, Programming
Languages and Systems, volume 4421 of Lecture Notes in Computer Science, pages
237–252. Springer Berlin, 2007.
[GMJ+02] Dan Grossman, Greg Morrisett, Trevor Jim, Michael Hicks, Yanling Wang, and
James Cheney. Region-based memory management in Cyclone. SIGPLAN Not.,
37(5) :282–293, 2002.
[Gon07] Georges Gonthier. The four colour theorem : Engineering of a formal proof. In
8th Asian Symposium on Computer Mathematics, ASCM 2007, page 333, 2007.
[Gor04] Mel Gorman. Understanding the Linux Virtual Memory Manager. Prentice Hall
PTR, 2004.
[Gra92] Philippe Granger. Improving the results of static analyses programs by local
decreasing iteration. In Proceedings of the 12th Conference on Foundations of
Software Technology and Theoretical Computer Science, pages 68–79. SpringerVerlag,
1992.
[Har88] Norm Hardy. The confused deputy (or why capabilities might have been invented).
ACM Operating Systems Review, 22(4) :36–38, 1988.
[HL08] Charles Hymans and Olivier Levillain. Newspeak, Doubleplussimple Minilang
for Goodthinkful Static Analysis of C. Technical Note 2008-IW-SE-00010-1, EADS
IW/SE, 2008.
[Hoa69] C. A. R. Hoare. An axiomatic basis for computer programming. Commun. ACM,
12(10) :576–580, 1969.
[ISO99] ISO. The ANSI C standard (C99). Technical Report WG14 N1124, ISO/IEC, 1999.
[JMG+02] Trevor Jim, J. Greg Morrisett, Dan Grossman, Michael W. Hicks, James Cheney,
and Yanling Wang. Cyclone : A safe dialect of c. In Proceedings of the General
Track of the annual conference on USENIX Annual Technical Conference, ATEC
’02, pages 275–288. USENIX Association, 2002.
[Jon10] M. Tim Jones. User space memory access from the Linux kernel. http://www.
ibm.com/developerworks/library/l-kernel-memory-access/, 2010.
[JW04] Robert Johnson and David Wagner. Finding user/kernel pointer bugs with type
inference. In USENIX Security Symposium, pages 119–134, 2004.168 BIBLIOGRAPHIE
[KcS07] Oleg Kiselyov and Chung chieh Shan. Lightweight static capabilities. Electr. Notes
Theor. Comput. Sci., 174(7) :79–104, 2007.
[Ker81] Brian W. Kernighan. Why Pascal is not my favorite programming language. Technical
report, AT&T Bell Laboratories, 1981.
[KR88] Brian W. Kernighan and Dennis M. Ritchie. The C Programming Language Second
Edition. Prentice-Hall, Inc., 1988.
[LA04] Chris Lattner and Vikram Adve. LLVM : A Compilation Framework for Lifelong
Program Analysis & Transformation. In Proceedings of the 2004 International
Symposium on Code Generation and Optimization (CGO’04), 2004.
[Lan96] Gérard Le Lann. The ariane 5 flight 501 failure - a case study in system engineering
for computing systems, 1996.
[LBR06] Gary T. Leavens, Albert L. Baker, and Clyde Ruby. Preliminary design of jml : A
behavioral interface specification language for java. SIGSOFT Softw. Eng. Notes,
31(3) :1–38, 2006.
[LDG+10] Xavier Leroy, Damien Doligez, Jacques Garrigue, Didier Rémy, and Jérôme
Vouillon. The Objective Caml system, documentation and user’s manual – release
3.12. INRIA, 2010.
[LZ06] Peng Li and Steve Zdancewic. Encoding information flow in Haskell. In Proceedings
of the 19th IEEE Workshop on Computer Security Foundations (CSFW ’06).
IEEE Computer Society, 2006.
[Mai90] Harry G. Mairson. Deciding ML typability is complete for deterministic exponential
time. In Proceedings of the Seventeenth Annual ACM Symposium on Principles
of Programming Languages, POPL ’90, pages 382–401, 1990.
[Mau04] Laurent Mauborgne. ASTRÉE : Verification of absence of run-time error. In
René Jacquart, editor, Building the information Society (18th IFIP World Computer
Congress), pages 384–392. The International Federation for Information Processing,
Kluwer Academic Publishers, 2004.
[McA03] David A. McAllester. Joint RTA-TLCA invited talk : A logical algorithm for ML
type inference. In Proceedings of the 14th International Conference on Rewriting
Techniques and Applications, RTA, pages 436–451, 2003.
[Mer03] J. Merrill. GENERIC and GIMPLE : a new tree representation for entire functions.
In GCC developers summit 2003, pages 171–180, 2003.
[MG07] Magnus O. Myreen and Michael J.C. Gordon. A Hoare logic for realistically modelled
machine code. In Tools and Algorithms for the Construction and Analysis
of Systems (TACAS 2007), LNCS, pages 568–582. Springer-Verlag, 2007.
[Mil78] Robin Milner. A theory of type polymorphism in programming. Journal of Computer
and System Sciences, 17(3) :348–375, 1978.
[Min01a] A. Miné. A new numerical abstract domain based on difference-bound matrices.
In Proc. of the Second Symposium on Programs as Data Objects (PADO II), volume
2053 of Lecture Notes in Computer Science (LNCS), pages 155–172. Springer, 2001.
http://www.di.ens.fr/~mine/publi/article-mine-padoII.pdf.BIBLIOGRAPHIE 169
[Min01b] A. Miné. The octagon abstract domain. In Proc. of the Workshop on Analysis,
Slicing, and Transformation (AST’01), pages 310–319. IEEE CS Press, 2001. http:
//www.di.ens.fr/~mine/publi/article-mine-ast01.pdf.
[NCH+05] George C. Necula, Jeremy Condit, Matthew Harren, Scott McPeak, and Westley
Weimer. Ccured : type-safe retrofitting of legacy software. ACM Trans. Program.
Lang. Syst., 27(3) :477–526, 2005.
[New00] Tim Newsham. Format string attacks. Phrack, 2000.
[NMRW02] George C. Necula, Scott McPeak, Shree Prakash Rahul, and Westley Weimer. CIL :
Intermediate language and tools for analysis and transformation of C programs.
In Proceedings of the 11th International Conference on Compiler Construction,
CC ’02, pages 213–228. Springer-Verlag, 2002.
[NPW02] Tobias Nipkow, Lawrence C. Paulson, and Markus Wenzel. Isabelle/HOL — A
Proof Assistant for Higher-Order Logic, volume 2283 of LNCS. Springer, 2002.
[oEE08] Institute of Electrical and Electronics Engineers. IEEE Standard for FloatingPoint
Arithmetic. Technical report, Microprocessor Standards Committee of the
IEEE Computer Society, 2008.
[OGS08] Bryan O’Sullivan, John Goerzen, and Don Stewart. Real World Haskell. O’Reilly
Media, Inc., 1st edition, 2008.
[Oiw09] Yutaka Oiwa. Implementation of the memory-safe full ANSI-C compiler. In Proceedings
of the 2009 ACM SIGPLAN conference on Programming language design
and implementation, PLDI ’09, pages 259–269. ACM, 2009.
[Pel93] Doron Peled. All from one, one for all : On model checking using representatives.
In Proceedings of the 5th International Conference on Computer Aided Verification,
CAV ’93, pages 409–423. Springer-Verlag, 1993.
[Pie02] Benjamin C. Pierce. Types and Programming Languages. MIT Press, 2002.
[PJNO97] Simon L. Peyton Jones, Thomas Nordin, and Dino Oliva. C- - : A portable assembly
language. In Chris Clack, Kevin Hammond, and Antony J. T. Davie, editors,
Implementation of Functional Languages, volume 1467 of Lecture Notes in Computer
Science, pages 1–19. Springer, 1997.
[PTS+11] Nicolas Palix, Gaël Thomas, Suman Saha, Christophe Calvès, Julia Lawall, and
Gilles Muller. Faults in Linux : Ten years later. In Sixteenth International Conference
on Architectural Support for Programming Languages and Operating Systems
(ASPLOS 2011), 2011.
[Ric53] H. G. Rice. Classes of recursively enumerable sets and their decision problems.
Transactions of the American Mathematical Society, 74(2) :pp. 358–366, 1953.
[RV98] Didier Rémy and Jérôme Vouillon. Objective ML : An effective object-oriented
extension to ML. In Theory And Practice of Object Systems, pages 27–50, 1998.
[Sim03] Vincent Simonet. Flow Caml in a nutshell. In Graham Hutton, editor, Proceedings
of the first APPSEM-II workshop, pages 152–165, 2003.
[SLM11] Suman Saha, Julia Lawall, and Gilles Muller. An approach to improving the structure
of error-handling code in the linux kernel. In Proceedings of the 2011 SIGPLAN/SIGBED
conference on Languages, compilers and tools for embedded systems,
LCTES ’11, pages 41–50. ACM, 2011.170 BIBLIOGRAPHIE
[SM03] Andrei Sabelfeld and Andrew C. Myers. Language-based information-flow security.
IEEE Journal on Selected Areas in Communications, 21 :2003, 2003.
[Spe05] Brad Spengler. grsecurity 2.1.0 and kernel vulnerabilities. Linux Weekly News,
2005.
[SRH96] Mooly Sagiv, Thomas Reps, and Susan Horwitz. Precise interprocedural data-
flow analysis with applications to constant propagation. In Selected papers from
the 6th international joint conference on Theory and practice of software development,
TAPSOFT ’95, pages 131–170. Elsevier Science Publishers B. V., 1996.
[Sta11] Basile Starynkevitch. Melt - a translated domain specific language embedded
in the gcc compiler. In Olivier Danvy and Chung chieh Shan, editors, DSL, volume
66 of EPTCS, pages 118–142, 2011.
[STFW01] Umesh Shankar, Kunal Talwar, Jeffrey S. Foster, and David Wagner. Detecting
format string vulnerabilities with type qualifiers. In SSYM’01 : Proceedings of the
10th conference on USENIX Security Symposium, page 16. USENIX Association,
2001.
[SY86] R E Strom and S Yemini. Typestate : A programming language concept for enhancing
software reliability. IEEE Trans. Softw. Eng., 12(1) :157–171, 1986.
[Tan07] Andrew S. Tanenbaum. Modern Operating Systems. Prentice Hall Press, 3rd edition,
2007.
[The04] The Coq Development Team. The Coq Proof Assistant Reference Manual – Version
V8.0, 2004. http://coq.inria.fr.
[TJ92] Jean-Pierre Talpin and Pierre Jouvelot. Polymorphic type, region and effect inference.
Journal of Functional Programming, 2 :245–271, 1992.
[TT94] Mads Tofte and Jean-Pierre Talpin. Implementation of the typed call-by-value
λ-calculus using a stack of regions. In Proceedings of the 21st ACM SIGPLANSIGACT
symposium on Principles of programming languages, POPL ’94, pages
188–201. ACM, 1994.
[VB04] Arnaud Venet and Guillaume Brat. Precise and efficient static array bound checking
for large embedded c programs. In Proceedings of the 2004 ACM SIGPLAN
conference on Programming language design and implementation, PLDI
’04, pages 231–242. ACM, 2004.
[vL11] Twan van Laarhoven. Lenses : viewing and updating data structures in Haskell.
http://www.twanvl.nl/files/lenses-talk-2011-05-17.pdf, 2011.Résumé
Les noyaux de systèmes d’exploitation manipulent des données fournies par les programmes utilisateur
via les appels système. Si elles sont manipulées sans prendre une attention particulière, une faille de sécurité
connue sous le nom de Confused Deputy Problem peut amener à des fuites de données confidentielles ou
l’élévation de privilèges d’un attaquant.
Le but de cette thèse est d’utiliser des techniques de typage statique afin de détecter les manipulations
dangereuses de pointeurs contrôlés par l’espace utilisateur.
La plupart des systèmes d’exploitation sont écrits dans le langage C. On commence par en isoler un
sous-langage sûr nommé SAFESPEAK. Sa sémantique opérationnelle et un premier système de types sont
décrits, et les propriétés classiques de sûreté du typage sont établies. La manipulation des états mémoire est
formalisée sous la forme de lentilles bidirectionnelles, qui permettent d’encoder les mises à jour partielles
des états et variables. Un première analyse sur ce langage est décrite, permettant de distinguer les entiers
utilisés comme bitmasks, qui sont une source de bugs dans les programmes C.
On ajoute ensuite à SAFESPEAK la notion de valeur provenant de l’espace utilisateur. La sûreté du typage
est alors brisée, mais on peut la réétablir en donnant un type particulier aux pointeurs contrôlés par l’espace
utilisateur, ce qui force leur déférencement à se faire de manière contrôlée. Cette technique permet
de détecter deux bugs dans le noyau Linux : le premier concerne un pilote de carte graphique AMD, et le
second l’appel système ptrace sur l’architecture Blackfin.
Abstract
Operating system kernels need to manipulate data that comes from user programs through system calls.
If it is done in an incautious manner, a security vulnerability known as the Confused Deputy Problem can
lead to information disclosure or privilege escalation.
The goal of this thesis is to use static typing to detect the dangerous uses of pointers that are controlled
by userspace.
Most operating systems are written in the C language. We start by isolating SAFESPEAK, a safe subset of it.
Its operational semantics as well as a type system are described, and the classic properties of type safety are
established. Memory states are manipulated using bidirectional lenses, which can encode partial updates
to states and variables. A first analysis is described, that identifies integers used as bitmasks, which are a
common source of bugs in C programs.
Then, we add to SAFESPEAK the notion of pointers coming from userspace. This breaks type safety, but
it is possible to get it back by assigning a different type to the pointers that are controlled by userspace. This
distinction forces their dereferencing to be done in a controlled fashion. This technique makes it possible to
detect two bugs in the Linux kernel : the first one is in a video driver for an AMD video card, and the second
one in the ptrace system call for the Blackfin architecture.
Analyse de mod`eles g´eom´etriques d’assemblages pour les
structures et les enrichir avec des informations
fonctionnelles
Ahmad Shahwan
To cite this version:
Ahmad Shahwan. Analyse de mod`eles g´eom´etriques d’assemblages pour les structures et les
enrichir avec des informations fonctionnelles. Other. Universit´e de Grenoble, 2014. French.
.
HAL Id: tel-01071650
https://tel.archives-ouvertes.fr/tel-01071650
Submitted on 6 Oct 2014
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of scientific
research documents, whether they are published
or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est
destin´ee au d´epˆot et `a la diffusion de documents
scientifiques de niveau recherche, publi´es ou non,
´emanant des ´etablissements d’enseignement et de
recherche fran¸cais ou ´etrangers, des laboratoires
publics ou priv´es.THESE `
Pour obtenir le grade de
DOCTEUR DE L’UNIVERSITE DE GRENOBLE ´
Specialit ´ e : ´ Mathematiques et Informatique ´
Arretˆ e minist ´ eriel : 7 ao ´ ut 2006 ˆ
Present ´ ee par ´
Ahmad SHAHWAN
These dirig ` ee par ´ Jean-Claude LEON ´
et codirigee par ´ Gilles Foucault
prepar ´ ee au sein ´ G-SCOP, Grenoble-INP
et de MSTII
Processing Geometric Models
of Assemblies to Structure and
Enrich them with Functional
Information
These soutenue publiquement le ` 29 ao ˆut 2014,
devant le jury compose de : ´
M., John GERO
Professor, University of North Carolina, USA, Rapporteur
M., Marc DANIEL
Professeur, Universite Aix-Marseille, Rapporteur ´
Mme, Marie-Christine ROUSSET
Professeur, Universite Joseph Fourier, Examinateur ´
M., Jean-Philippe PERNOT
Professeur, Arts et Metiers ParisTech, Examinateur ´
M., Jean-Claude LEON
Professeur, Grenoble-INP, Directeur de these `
M., Gilles FOUCAULT
Maˆıtre de Conferences, Universit ´ e Joseph Fourier, Co-Directeur de th ´ ese `Processing Geometric Models of Assemblies
to Structure and Enrich them with
Functional Information
Traitement de mod`eles g´eom´etriques
d’assemblages afin de les structurer et de les
enrichir avec des informations fonctionnellesiii
abstract
The digital mock-up (DMU) of a product has taken a central position
in the product development process (PDP). It provides the geometric
reference of the product assembly, as it defines the shape of each individual
component, as well as the way components are put together.
However, observations show that this geometric model is no more than
a conventional representation of what the real product is. Additionally,
and because of its pivotal role, the DMU is more and more required
to provide information beyond mere geometry to be used in different
stages of the PDP. An increasingly urging demand is functional
information at different levels of the geometric representation of the
assembly. This information is shown to be essential in phases such as
geometric pre-processing for finite element analysis (FEA) purposes.
In this work, an automated method is put forward that enriches a
geometric model, which is the product DMU, with function information
needed for FEA preparations. To this end, the initial geometry
is restructured at different levels according to functional annotation
needs. Prevailing industrial practices and representation conventions
are taken into account in order to functionally interpret the pure geometric
model that provides a starting point to the proposed method.
r´esum´e
La maquette num´erique d’un produit occupe une position centrale
dans le processus de d´eveloppement de produits. Elle est utilis´ee comme
repr´esentations de r´ef´erence des produits, en d´efinissant la forme g´eom´etrique
de chaque composant, ainsi que les repr´esentations simplifi´ees
des liaisons entre composants. Toutefois, les observations montrent
que ce mod`ele g´eom´etrique n’est qu’une repr´esentation simplifi´ee
du produit r´eel. De plus, et grˆace `a son rˆole cl´e, la maquette num´erique
est de plus en plus utilis´ee pour structurer les informations non-g´eom´etriques
qui sont ensuite utilis´ees dans diverses ´etapes du processus
de d´eveloppement de produits. Une exigence importante est d’acc´eder
aux informations fonctionnelles `a diff´erents niveaux de la repr´esentations
g´eom´etrique d’un assemblage. Ces informations fonctionnelles
s’av`erent essentielles pour pr´eparer des analyses ´el´ements finis. Dans
ce travail, nous proposons une m´ethode automatis´ee afin d’enrichir
le mod`ele g´eom´etrique extrait d’une maquette num´erique avec les informations
fonctionnelles n´ecessaires pour la pr´eparation d’un mod`ele
de simulation par ´el´ements finis. Les pratiques industrielles et les repr´esentations
g´eom´etriques simplifi´ees sont prises en compte lors de
l’interpr´etation d’un mod`ele purement g´eom´etrique qui constitue le
point de d´epart de la m´ethode propos´ee.Scientific Communications
Accepted
• Shahwan, A., Leon, J.-C., Foucault, G., and Fine, L. ´ Functional
restructuring of CAD models for FEA purposes. Engineering
Computations (2014).
Articles
• Boussuge, F., Shahwan, A., Leon, J.-C., Hahmann, S., Fou- ´
cault, G., and Fine, L. Template-based geometric transformations
of a functionally enriched DMU into FE assembly models. ComputerAided
Design and Applications 11, 04 (2014), 436–449.
• Shahwan, A., Leon, J.-C., Foucault, G., Trlin, M., and Palombi, ´
O. Qualitative behavioral reasoning from components’ interfaces to
components’ functions for DMU adaption to fe analyses. ComputerAided
Design 45, 2 (2013), 383–394.
In proceedings
• Shahwan, A., Foucault, G., Leon, J.-C., and Fine, L. ´ Deriving
functional properties of components from the analysis of digital mockups.
In Tools and Methods of Competitive Engineering (Karlsruhe,
Germany, 2012).
• Li, K., Shahwan, A., Trlin, M., Foucault, G., and Leon, J.- ´
C. Automated contextual annotation of B-Rep CAD mechanical components
deriving technology and symmetry information to support
partial retrieval. In Eurographics Workshop on 3D Object Retrieval
(Cagliari, Italy, 2012), pp. 67–70.Contents
Acronyms xiii
Introduction xv
1 DMU and Polymorphic Representation 1
1.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Product model . . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.3 Product prototype . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Product digital mock-up . . . . . . . . . . . . . . . . . . . . . 7
1.4.1 Computerized product models . . . . . . . . . . . . . 7
1.4.2 DMUs as models and prototypes at a time . . . . . . 8
1.5 Geometric models and modeling methods . . . . . . . . . . . 9
1.5.1 Geometric validity and the quality of a DMU . . . . . 10
1.5.2 Discrete geometric models . . . . . . . . . . . . . . . . 13
1.5.3 Analytical geometric models . . . . . . . . . . . . . . . 16
1.6 DMU as an assembly . . . . . . . . . . . . . . . . . . . . . . . 18
1.6.1 DMU structure . . . . . . . . . . . . . . . . . . . . . . 19
1.6.2 Components’ positioning . . . . . . . . . . . . . . . . . 20
1.7 Other information associated to a DMU . . . . . . . . . . . . 25
1.8 Application of DMU . . . . . . . . . . . . . . . . . . . . . . . 27
1.9 Basic principles of finite element analyses . . . . . . . . . . . 28
1.9.1 Numerical approximations of physical phenomena . . 28
1.9.2 Generation of a FEM . . . . . . . . . . . . . . . . . . 30
1.10 DMU as polymorphic representation of a product . . . . . . . 30
1.11 Adapted definition of DMU . . . . . . . . . . . . . . . . . . . 31
1.12 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2 Literature Overview 35
2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.2 Function formalization . . . . . . . . . . . . . . . . . . . . . . 36
2.3 Connections between form, behavior, and function . . . . . . 38
2.3.1 Behavior to complete the design puzzle . . . . . . . . 38
2.3.2 Pairs of interacting interfaces . . . . . . . . . . . . . . 38viii Contents
2.3.3 Tools and guidelines to support the design process . . 39
2.4 Constructive approaches to deduce function . . . . . . . . . . 41
2.4.1 Form feature recognition . . . . . . . . . . . . . . . . . 42
2.4.2 Functionality as a result of geometric interactions . . . 44
2.5 Geometric analysis to detect interactions . . . . . . . . . . . . 46
2.5.1 Geometric interaction detection . . . . . . . . . . . . . 46
2.5.2 Importance of a unique geometric representation . . . 47
2.6 CAD and knowledge representation . . . . . . . . . . . . . . . 48
2.6.1 Domain knowledge and model knowledge . . . . . . . 49
2.6.2 Ontologies as an assembly knowledge storehouse . . . 49
2.6.3 Knowledge-based engineering approaches . . . . . . . 53
2.7 From CAD to FEA . . . . . . . . . . . . . . . . . . . . . . . . 55
2.7.1 Pre-processing at the core of the FEM . . . . . . . . . 55
2.7.2 Direct geometric approaches . . . . . . . . . . . . . . . 55
2.8 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3 Functional Semantics: Needs and Objectives 61
3.1 Taking 3D models beyond manufacturing purposes . . . . . . 61
3.2 Differences between digital and real shapes . . . . . . . . . . 63
3.3 Enabling semi-automatic pre-processing . . . . . . . . . . . . 65
3.3.1 Pre-processing tasks . . . . . . . . . . . . . . . . . . . 65
3.3.2 Pre-processing automation requirements . . . . . . . . 66
3.4 Bridging the gap with functional knowledge . . . . . . . . . . 67
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4 Functional Restructuring and Annotation 73
4.1 Qualitative bottom-up approach . . . . . . . . . . . . . . . . 74
4.2 Common concepts . . . . . . . . . . . . . . . . . . . . . . . . 74
4.2.1 Function as the semantics of design . . . . . . . . . . . 75
4.2.2 Functional Interface . . . . . . . . . . . . . . . . . . . 76
4.2.3 Functional Designation . . . . . . . . . . . . . . . . . 78
4.2.4 Functional Cluster . . . . . . . . . . . . . . . . . . . . 81
4.2.5 Conventional Interface . . . . . . . . . . . . . . . . . . 85
4.2.6 Taxonomies . . . . . . . . . . . . . . . . . . . . . . . . 87
4.3 Method walk-through . . . . . . . . . . . . . . . . . . . . . . 91
4.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
5 Functional Geometric Interaction 95
5.1 Functional surfaces . . . . . . . . . . . . . . . . . . . . . . . . 95
5.2 Geometric preparation and rapid detection of interactions . . 97
5.2.1 Geometric model as global input . . . . . . . . . . . . 97
5.2.2 Maximal edges and surfaces . . . . . . . . . . . . . . . 98
5.2.3 Geometric interaction detection . . . . . . . . . . . . . 99
5.2.4 Local coordinate systems . . . . . . . . . . . . . . . . 103Contents ix
5.2.5 Conventional interface graph . . . . . . . . . . . . . . 104
5.3 Precise detection of interaction zones . . . . . . . . . . . . . . 107
5.4 Form-functionality mapping . . . . . . . . . . . . . . . . . . . 108
5.4.1 Multiple functional interpretation . . . . . . . . . . . . 109
5.5 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
6 Qualitative Behavioral Analysis 111
6.1 Behavioral study to bind form to functionality . . . . . . . . 112
6.2 Reference states . . . . . . . . . . . . . . . . . . . . . . . . . . 112
6.3 Qualitative representation of physical properties . . . . . . . 114
6.3.1 Qualitative physical dimension . . . . . . . . . . . . . 115
6.3.2 Algebraic structure of qualitative values . . . . . . . . 121
6.3.3 Coordinate systems alignment . . . . . . . . . . . . . . 123
6.4 Reference state I: Static equilibrium . . . . . . . . . . . . . . 124
6.4.1 Static equilibrium equations . . . . . . . . . . . . . . . 124
6.4.2 Graph search to eliminate irrelevant FIs . . . . . . . . 125
6.4.3 Local failure of functional interpretation . . . . . . . . 129
6.4.4 Graph search example . . . . . . . . . . . . . . . . . . 129
6.5 Reference state II: Static determinacy . . . . . . . . . . . . . 130
6.5.1 Statically indeterminate configurations . . . . . . . . . 133
6.5.2 Force propagation and force propagation graphs . . . 137
6.6 Reference state III: Assembly joint with threaded link . . . . 138
6.6.1 Detection of force propagation cycles . . . . . . . . . . 139
6.7 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
7 Rule-based Reasoning 145
7.1 Knowledge at the functional unit level . . . . . . . . . . . . . 146
7.2 Inference rules as domain knowledge . . . . . . . . . . . . . . 146
7.3 Reasoning alternatives . . . . . . . . . . . . . . . . . . . . . . 148
7.3.1 Dynamic formalization of domain specific rules . . . . 148
7.3.2 Problem decidability . . . . . . . . . . . . . . . . . . . 149
7.4 DMU knowledge representation . . . . . . . . . . . . . . . . . 150
7.4.1 Ontology definition through its concepts and roles . . 151
7.4.2 Ontology population with model knowledge . . . . . . 152
7.5 Formal reasoning to complete functional knowledge . . . . . . 154
7.5.1 Inference rules in DL . . . . . . . . . . . . . . . . . . . 155
7.5.2 The unique name assumption . . . . . . . . . . . . . . 157
7.5.3 The open world assumption . . . . . . . . . . . . . . . 158
7.5.4 Integration of DL reasoners . . . . . . . . . . . . . . . 159
7.6 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163x Contents
8 Results and Comparative Study 165
8.1 Application architecture . . . . . . . . . . . . . . . . . . . . . 165
8.2 Application to industrial examples . . . . . . . . . . . . . . . 167
8.3 Integration with FEA pre-processors . . . . . . . . . . . . . . 173
8.4 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
9 Conclusions and Perspectives 177
9.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
9.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
A Fit Tolerancing and Dimensioning 183
B Dual Vectors 187
C Screw Theory 189
D Description Logic 193List of Definitions
1.1 Definition (Product model) . . . . . . . . . . . . . . . . . . . 2
1.2 Definition (Product prototype) . . . . . . . . . . . . . . . . . 4
1.3 Definition (Digital mock-up) . . . . . . . . . . . . . . . . . . . 32
4.1 Definition (Function) . . . . . . . . . . . . . . . . . . . . . . . 75
4.2 Definition (Functional Interface) . . . . . . . . . . . . . . . . 77
4.3 Definition (Functional Designation) . . . . . . . . . . . . . . . 78
4.4 Definition (Functional Cluster) . . . . . . . . . . . . . . . . . 81
4.5 Definition (Conventional Interface) . . . . . . . . . . . . . . . 87
4.6 Definition (Taxonomy) . . . . . . . . . . . . . . . . . . . . . . 88
5.1 Definition (Conventional interface graph) . . . . . . . . . . . 104
5.2 Definition (Functional interpretation) . . . . . . . . . . . . . 109
6.1 Definition (Reference state) . . . . . . . . . . . . . . . . . . . 112
6.2 Definition (Force Propagation Graph) . . . . . . . . . . . . . 137
B.1 Definition (General dual number ring) . . . . . . . . . . . . . 187
B.2 Definition (General dual number semi-ring) . . . . . . . . . . 188
C.1 Definition (Screw) . . . . . . . . . . . . . . . . . . . . . . . . 189
C.2 Definition (Reciprocal screws) . . . . . . . . . . . . . . . . . . 191List of Hypotheses
5.1 Hypothesis (Functional surfaces) . . . . . . . . . . . . . . . . 96
6.1 Hypothesis (Rigid bodies) . . . . . . . . . . . . . . . . . . . . 113
6.2 Hypothesis (Conservative systems) . . . . . . . . . . . . . . . 114
6.3 Hypothesis (Mechanical interactions) . . . . . . . . . . . . . . 114
6.4 Hypothesis (Static equilibrium) . . . . . . . . . . . . . . . . . 124
6.5 Hypothesis (Static determinacy) . . . . . . . . . . . . . . . . 134
6.6 Hypothesis (Force propagation) . . . . . . . . . . . . . . . . . 139Acronyms
AI Artificial Intelligence.
API Application Programming Interface.
ARM Assembly Relation Model.
B-Rep Boundary representation.
BOM Bill of materials.
C&CM Contact and Channel Model.
CAD Computer Aided Design.
CAM Computer Aided Manufacturing.
CAPP Computer Aided Process Planning.
CI Conventional interface.
CIG Conventional interface graph.
CIuG Conventional interface underling undirected
graph.
CNC Computer Numeric Control.
CPM Core Product Model.
CSG Constructive Solid Geometry.
CWA Closed World Assumption.
DIG DL Implementation Group.
DL Description Logic.
DMU Digital mock-up.
DoF Degree of freedom.
FBS Function-Behavior-Structure.
FC Functional cluster.
FD Functional designation.
FE Finite element.
FEA Finite element analysis.
FEM Finite Element Model.
FI Functional interface.
FOL First Order Logic.xvi Acronyms
FPG Force propagation graph.
FR Feature Recognition.
GARD Generic Assembly Relationship Diagram.
GCI General Concept Inclusion.
GD&T Geometric Dimensioning and Tolerancing.
GPU Graphics Processing Unit.
KBE Knowledge Based Engineering.
KRR Knowledge Representation and Reasoning.
MDB Model-Based Definition.
NURBS Non-Uniform Rational B-Spline.
OAM Open Assembly Model.
OIL Ontology Interchange Language.
OWA Open World Assumption.
OWL Web Ontology Language.
PDP Product development process.
PFM Part Function Model.
PLM Product Lifecycle Management.
RDF Resource Description Framework.
RDF-S Resource Description Framework Scheme.
RS Reference state.
SPARQL SPARQL Protocol and RDF Query Language.
SSWAP Simple Semantic Web Architecture and Protocol.
UNA Unique Name Assumption.
URI Uniform Resource Identifier.
VR Virtual Reality.
W3C World Wide Web Consortium.
XML Extensible Markup Language.Introduction
When designing an artifact that is identified by its functionality, it is a
common practice to decompose the artifact in question into components,
each satisfying a well-defined set of functions that, put together, lead to the
satisfaction of the desired functionality of the designed artifact.
In the industrial context, components happen to be physical objects, de-
fined by their shapes and materials that decide their physical properties and
behaviors. In order for an object to deliver a precise function, its shape has
to be carefully engineered. The 3D shape of the object dictates its interactions
with its environment, i.e., its neighboring components, its neighboring
products or a neighboring human being. These interactions define its behavior,
thus its functionality.
Because of this pivotal importance of components shapes to deliver their
functions, tools were provided and conventions established to enable the
production and communication of shape design models as part of the product
development process (PDP). This emphasis is a natural outcome of a shapeoriented
design process. Design intentions, however, are not clearly reflected
in design models, in spite of their clear presence in engineers’ minds during
the design process. In fact, no robust tools or agreed-upon conventions exist
to link a particular design with its rationale.
This observation used to be less pronounced at the time blueprints were
used to define design models. Blueprints are 2D drawings that aim at unambiguously
defining the shape of an object. They have been in use for
so long that conventions converged toward globally understood agreements,
and standards were put to govern such conventions [16, 183]. Nevertheless,
the advent of Computer Aided Design (CAD) systems in early 80s soon
provided designers with another geometric dimension that would remarkably
influence industrial standards and conventions. 3D solid modelers prevailed
as a natural choice for product design, engineers shifted to producing
3D models instead of traditional technical drawings, and mechanical components
became dominantly represented as 3D objects in today’s models.
This gave birth to the concept of digital mock-up (DMU), which gathered
the representation of components of a product assembly in one geometric
model.
Efforts were paid to centralize the product knowledge in one place, andxviii Introduction
the DMU was suggested as a natural candidate as it geometrically defines the
product. In spite of attempts to homogenize and standardize the representations
of non-geometric knowledge [12], defined standards are still poorly
implemented in industrial practices because commercial software products
are far from exploiting these standards. In fact, an industrial DMU, as currently
available, is no more than a conventional geometric representation of
a product assembly. A DMU can at best contain loose textual annotations,
which may be interpreted within an organization or a working group, if at
all interpretable. This is partially because a textual annotation does not
relate precisely to a geometric subset of a component or an assembly.
The need of design intentions, however, remained paramount, if the DMU
is to be fully exploited in the PDP, and utilized beyond Computer Aided
Manufacturing (CAM) applications. In fact, this knowledge is still being
mined from geometric models of a product to feed applications such as geometric
pre-processing of assembly models for simulation purposes. This is
particularly the case of mechanical simulations where the structural behavior
is a key issue that is commonly addressed using numerical methods such
as the Finite Element Model (FEM). However, and due to conventional
representations of functional and technological information in the DMU,
the model preparation task for FEM is still mainly manual and resource
intensive. This is particularly true for complex products like aircraft structures
[1].
The user-intensive functional annotation of a DMU introduces a bottleneck
into today’s highly automated PDP. In order to accelerate product
development, an automated method should be established that enables the
extraction of relevant functional information out of pure geometric representation
of product assembly. Function is a key concept for designers and
engineers that closely relates to the design activity and, hence, to the socalled
design intent [107]. Consequently, it is highly important to provide
engineers and designers with this functional information tightly connected
with 3D component models, so that they can efficiently process them during
the PDP. Furthermore, the desired approach should take into account
mainstream industrial practices and conventions when interpreting geometric
models.
In this work, the focus is placed on the application to structural behavior
of a product or, more precisely, of an assembly of components. The
proposed method is an enrichment process that mainly aims at a seamless
integration with geometric preprocessors for finite element (FE) simulation
purposes, even though other applications can also be envisaged. In order for
this method to provide an adequate input to finite element analysis (FEA)
applications functional annotations and component denominations should
be made in tight connection to precise geometric entities that they describe.
To this end, geometry processing and reasoning mechanisms applied to mechanical
behaviors are set up to adequately structure geometric models ofxix
assemblies.
In the rest of this document, Chapter 1 provides an introductory presentation
of industrial concepts that relate to our work. It particularly presents
what can be expected from an industrial DMU nowadays. Literature and
work related to the proposed method is reviewed and analyzed in Chapter 2.
Chapter 3 sheds more light on the motivation of our work, and the role that
the proposed method plays in an efficient PDP. Chapter 4 defines concepts
and terminology that are used across this document and upon which the
proposed method is founded. It also provides an overview of this method
before later chapters develop further on each stage.
Chapter 5 develops in more details the geometric analysis of the input
model, which is the pure geometric model of a DMU. This chapter shows
how interactions between components are reconstituted on a geometric basis
and how functional interpretations can be assigned to each of them. At this
stage, the shape – function relationship cannot be unambiguously recovered.
Chapter 6 then provides the means to functionally interpret those interactions
in an unambiguous way, through a qualitative behavioral analysis of
the model. This is algorithmic approach achieved through the tight dependencies
between shape, function and behavior that produce a unique relation
between shape and function for the interactions between components. The
concept of reference states is then used to synthesize some component behavior
through their interactions in order to reject irrelevant configurations,
thus removing ambiguities. Further qualitative behavioral information is
derived too.
Chapter 7 completes the functional picture of the assembly using domain
specific rules and taking the functional interpretation beyond the interaction
level, toward the functional unit level, using the effective relationship
between shape and function at the interface level and the newly derived behavioral
information at the component and component cluster levels. It is
an inference-based reasoning approach that can be adapted to the conventional
representations of assemblies and meet the current practices observed
in industry.
Once the input model is geometrically restructured, and functionally
annotated, it is made available as input for FEA preprocessors. Chapter 8
shows results of the application of the proposed method on examples varying
from illustrative models to industrial scale DMUs. The same chapter
also shows how the method successfully lends hand to a template-based geometric
preprocessor, generating simulation models that correspond to the
simulation objectives. Chapter 9 concludes this document, exploring potentials
of future work to extend the proposed method and its application.Chapter 1
Digital Mock-Up and the
Polymorphic Representation
of Assemblies
DMUs constitute a starting point to our research. Thus, it is indispensable
to present basic concepts and definitions that are central
to this work before detailing our approach. Those concepts are
presented from different viewpoints according to the literature and
to industrial practices, before an adaption of these concepts to our
context is underlined. An analysis of a DMU content also shows
how it can refer not only to a single representation of an assembly
but to a polymorphic one.
1.1 Introduction
In this chapter we provide a general understanding of a DMU, a concept
which is central to our research. Then, we formally define this concept as
it applies to the current work. To this end, we first present closely related
notions that pave the way to the conceptualization of a DMU. We also show
what kind of information it holds, and how this information is represented.
Sections 1.2 and 1.3 demonstrate and distinguish two concepts: the product
model and product prototypes. Though these terminologies are used interchangeably
across literature, we clearly make the distinction according to
our understanding, and to the context of this work. Then, the concept of
DMU is analyzed in the following sections to address its representation from
a geometric point of view as well as from a more technological point of view
through the concept of assembly. This leads to the analysis of the effective
content of an assembly and its relationship with a DMU. Subsequently, the
generation of Finite Element Analyses from a DMU is outlined to illustrate
into which extent a DMU can contribute to define a Finite Element Model.2 Chapter 1. DMU and Polymorphic Representation
This finally leads to the concept of polymorphism of an assembly.
1.2 Product model
In the context of product development, manufacturing processes of this product
must be precisely defined, so that the resulting product matches its initial
requirements, i.e., the product meets designers’ and users’ expectations.
To this end, models are used to define the product in enough details as the
outcome of an unambiguous and overall manufacturing process.
Models consist of documents and schemes that describe the product, often
visually. They often use common languages and annotations to refer
to resources (materials, quantities, etc.) and processes (parameters, dimensions,
units, etc.). Those annotations should be standardized, or at least
agreed upon among people involved in the production process. Otherwise a
model can be misinterpreted.
Definition 1.1 (Product model). A product model is a document, or a set
of documents, that uniquely define the manufacturing process of a product
in compliance with its specifications [43, 140].
In this sense, models can be viewed as cookbooks showing how to produce
instances of the product that conform to the same specifications. Models
are closely related the production process for the following reasons:
• To persistently capture the know-how of the production process. In the
absence of such documentations, the manufacturing knowledge is only
present in engineers’ minds, making this process highly dependent on
the availability of experts. Models capture this knowledge and reduce
the risk associated with such dependency;
• To formally define the manufacturing process, leaving no room for ambiguity
and multiple interpretations. This formality allows for the reproduction
of identical instances of the same ‘pattern’, avoiding undesirable
surprises due to miscommunication or improvisation of incomplete
specifications. Otherwise, divergence in the final product may
drift it away form initial requirements;
• To allow tracking of and easy adaption to requirements. A product
(or its prototype, as shown in Section 1.3) still may fail to fulfill the
desired requirement. In this case, the product should be re-engineered.
The existence of a model allows engineers to perform more easily modifications
that can be directly mapped to the product characteristics
to be amended. Another case when the product, thus its model, is to
be re-engineered is when the requirements evolve, which is likely to
happen in almost all industries.Product model 3
(a) (b)
Figure 1.1: Examples of partial product model: (a) architectural blueprints;
(b) software diagram.
Product models existed quite early in different engineering domains such
as architecture, mechanics, electrics, electronics, and computer software,
among others. These models were not digital until a couple of decades ago.
Depending on the discipline, some subsets of these models can be referred to
as technical drawings, blueprints, draftings, diagrams, etc. Figure 1.1 shows
examples of such models in different disciplines and applications.
As pointed out earlier, the current concept of product model focuses
essentially on manufacturing issues and does neither incorporate properties
that ensure the consistency between its set of documents and the product
obtained nor cover some parts of the product design process.
Product model in the field of mechanical engineering
When it comes to mechanical engineering, product models were traditionally
referred to as technical drawings or drafting. In fact, those are 2D drawings
that represents either a projection of the product onto a given plane according
to a given orientation (usually perpendicular to the plane and aligned
with a reference direction) and/or a cross section into the product components(s)
[70]. These drawings form a part of the product model.
As Figure 1.2 shows, precise annotations are used to augment those drawings
with complementary information such as Geometric Dimensioning and
Tolerancing (GD&T), some of which cannot be geometrically represented
on a sheet. Such information is mandatory to allow people manufacturing
the product [124]. This figure shows in red, shaft/housing tolerancing and
dimensioning symbols explained further in Appendix A. Projection, cross-4 Chapter 1. DMU and Polymorphic Representation
Table 1.1: Geometric tolerancing reference chart as per ASME Y14.5 – 1982.
straightness planarity cicularity
cylindricity line profile surface profile
perpendicularity angularity parallelism
symmetry position concentricity
sectioning and annotations follow agreed-upon conventions that make the
model as unambiguous as possible to a knowledgeable reader. Table 1.1
show standard dimensioning and tolerancing symbols as defined by ASME
Y14.5 – 1982 [183].
1.3 Product prototype
It is preferable that design defects be outlined as early as possible in the
product live cycle. More specifically, it is of high advantage that a shortcoming
be reported before a real instance of a product is manufactured and
machined. This is due to the high cost of machining and other manufacturing
processes. If compliance tests are to be run directly on the real product,
without any previous test on some sort of a “dummy” version of it, a considerable
risk is involved since the product is likely to be re-engineered. The
manufacturing and machining costs can be nearly doubled at each iteration.
To this end, a prototype, close enough in its behaviors to the real product
but with reduced production costs, is produced first. Then, different
tests are run against this prototype to assess its conformity to different requirements
and detect potential deficiencies. Whenever such shortcomings
are revealed, the product model is adapted accordingly, generating a new
prototype. Then, the process is repeated until the prototype is validated by
all tests. This can be seen as an iterative process of modeling, prototyping,
and evaluation. Subsequently, the product is progressively refined through
multiple iterations.
Definition 1.2 (Product prototype). A product prototype is a dummy representation
of a real product, that is meant to emulate it in one or more
aspects. It is used to assess or predict certain behaviors and/or interactions
[160, 184].
Prototypes can emulate the product functionally, aesthetically, physically,
ergonomically, etc. depending on the intended assessment planned on
the prototype. Prototypes are vital in an efficient production process for
the following reasons:
• To allow early recognition of deficiencies. The earlier the deficiencies
are detected, the lower the amendment cost is, since fewer stages are
wasted and redone;Product prototype 5
Ø50H7
Ø41H7
Ø15p6
Ø69H8f7
Ø13H7g6
Figure 1.2: Blueprint of a mechanical product, showing a cross-section (top)
and a projection (bottom). The projection also shows the cutting plane
of the cross-section. The drawing shows in red, shaft/housing tolerance
annotations.6 Chapter 1. DMU and Polymorphic Representation
• To allow testing on life-critical products. Some highly critical industries,
such as aeronautics, tolerate little or no failure once the product
is put to operation. Errors can be fatal at this stage. Thus, prototypes
allowing virtual tests on the product are necessary in such cases;
• To help decision making. Studies show that decisions taken at early
stages of a design process are highly expensive [47, 180]. However,
oftentimes product behavior and the impact that it may entail cannot
be precisely predicted at those stages. Prototypes enables engineers to
do a sort of what-if analyses, and benefit form their feedbacks before
taking a final decision about the product design.
More recently, product prototypes evolved toward digital or virtual ones,
which reduces further a product development process and can be achieved
using digital simulations.
It is worth noticing that tests run against prototypes do not replace
quality and compliance tests that should be run on the real product. Product
prototypes are just mock-ups, they emulate the products behavior to a
certain extent, but not exactly.
Prototypes are used in different engineering disciplines. In architecture
and interior design scaled-down prototypes are used to give a global perspective
of the structure before it is actually implemented (see Figure 1.3a).
Architecture prototypes are often used for aesthetic and ergonomic assessments.
In software engineering, incomplete versions of the software that fulfill
certain requirements are implemented first to satisfy unit tests. Unit testing
is in the core of software engineering best practices to avoid bulk debugging.
Usually, one module of the software is tested at a time, with the rest replaced
by mock modules.
Product prototype in the field of mechanical engineering
Approximate replicas of a mechanical product may be built to assess its
ease of use, functionality, structural behavior, and so on. Those replicas are
prototypes that are very similar to the designed product (see Figure 1.3a).
However, a product and its prototype differ in how and from what each
is made. Materials of the real product are usually costly, thus prototypes are
built out of cheaper materials that have similar physical properties according
to the intended tests. Moreover, the manufacturing and machining processes
of the real product are often expensive as well, partially due to the choice
for materials. Then, prototypes are crafted using different methods that
reduce costs, keeping the final shapes as close as possible to the original
design [160].
Figure 1.4 shows a prototype of a hand navigator [49]. The prototype is
made of thermoplastic powder shaped by means of selective heat sintering.Product digital mock-up 7
(a) (b)
Figure 1.3: Examples of product prototypes: (a) Architectural scale prototype
of the interior of a building; (b) Full-size car prototype.
Though the resulting object is perfectly fitted for concept proofing, machining
techniques and materials are not suitable for mass production, once the
product is approved.
Despite their minimized cost, prototypes are often wasteful and nonreusable
(apart in some discipline, like software engineering, where prototypes
can later be integrated in an operational product). This makes the
manufacturing process redundant: one manufacturing process at least for
prototyping, and then another one for real production. It would be highly
advantageous if some test could be directly run against the models themselves,
without the need to create a prototype.
1.4 Product digital mock-up
Sections 1.2 and 1.3 introduced product model and product prototype as
historically two separate concepts. However, technological advances in information
systems allowed engineers to merge those concepts into a single
one, introducing little by little what become known as DMU in the domain
of mechanical engineering.
1.4.1 Computerized product models
With the introduction of information technology and its applications, engineering
and production disciplines tended to make the most out of its
possibilities. One obvious application was modeling. Engineers and designers
soon got convinced to use computers instead of drafting tables to
materialize their designs. This gave way to CAD systems, who were based
on advances in computer-based geometric modelers. Geometric modelers
were first two-dimensional, and offered little advantage over classical draft-8 Chapter 1. DMU and Polymorphic Representation
Figure 1.4: Hand navigator prototype (Chardonnet & L´eon [49]).
ing, apart their ease of use. Soon, those modelers started to address 3D
solid modeling and integrated complementary facilities such as parametric
and feature-based modeling [121, 54]. Digital product models became easier
to produce and to interpret.
With the advent of Model-Based Definition (MDB) paradigm [140, 43],
these models were soon imported into the downstream manufacturing process,
to allow what is now called CAM. CAD models contained information
not only understandable by expert engineers, but also by machine tools to
automatically configure some of the product manufacturing processes.
An important revolution in the field of CAD was the introduction of
3D modelers, thanks to the fast-paced advancement of computer graphics.
This gave the designers a better perception of their work, even tough
incomplete. 3D models now allow engineers to perform basic prototyping,
at least from an aesthetic point of view, with categories of shapes
as prescribed by CAD systems. Indeed, each CAD software enables the
generation of component/product shape within a range prescribed by its
algorithms. As a result, CAD software can detect some geometric inconsistencies,
e.g., self-intersections, invalid topologies, interferences, etc. (see
Section 1.5.1 for a discussion on geometric validity of a DMU), when a component
shape/product falls outside the range of shapes it can describe.
Product models have become more than mere patterns that used to
dictate how the product should be manufactured. The line that separated
models from prototypes got thinner as more and more product assessments
can be readily conducted on the models themselves.
1.4.2 Digital mock-ups as models and prototypes at a time
Computerized product models that also played the role of prototypes are
commonly called digital mock-ups (DMUs). They mainly contain the 3DGeometric models and modeling methods 9
geometric model of a product, but are not restricted to that. As product
models they also incorporate supplementary information about material and
other technological parameters.
The goal of DMUs is not limited to manufacturing only. Now that they
provide detailed geometry alongside material physical properties, different
physical simulations can be set up, taking advantage of increasing computational
capabilities rather than generating physical prototypes.
DMUs can be seen as the result of advances in geometric modeling software
and CAx systems. They directly support manufacturing processes,
fulfilling the role of product referential models, as well as the basis of simulation
mock-ups, and serving as product digital prototypes [177]. By the
late 90s, a DMU was seen as a realistic computer simulation of a product,
with the capability of all required functions from design engineering, manufacturing,
product service, up to maintenance and product recycling [57].
From this perspective, the DMU stems from the merge of product model
and product prototype.
Product geometry is a key information around which the DMU is organized.
Figure 1.5 shows an example of a DMU of a centrifugal pump as
visualized by its 3D representation. Other types of information, essential
for manufacturing and prototyping purposes are also present in the DMU,
and will be discussed in more details in Section 1.7.
In this sense, the DMU works as a repository of the engineering knowledge
about a product that can be used throughout its life cycle [47]. Thus,
DMUs are seen as the backbone of the product development process in todays
industries [64].
Figure 1.6 shows how the generation of technical drawings can be partly
automated using the 3D geometry of CAD models out of the product DMU.
Then, GD&T can be carried out by engineers to add technological data.
1.5 Geometric models and modeling methods
Often CAD systems consider a DMU as a set of components, that may also
be called parts, assembled together to directly form the 3D representation of
a product, or to form modules (sub-assemblies) that in turn are assembled
into a product. Section 1.6 explains different methods and viewpoints about
component assembly. In this section we are more concerned about how a
component is represented geometrically in a CAD system.
Geometric modelers are as important to CAD systems as the product
geometric model is to DMUs. The geometric modeling process is highly
influenced by the category of geometric model attached to a CAD system.
Often, engineers choose to represent a component as a volume; a threedimensional
manifold [131] that divides the 3D-euclidean space into three
sets: its interior C, its boundary ∂C, and its exterior ∼C. Then, the ge-10 Chapter 1. DMU and Polymorphic Representation
Figure 1.5: A DMU geometry of a centrifugal pump, showing different parts
using colors. For a better understanding of the product shape, the DMU is
sectioned by a vertical plane.
ometric model commonly used in CAD systems is of type boundary representation
(B-Rep) [119, 120]. In this case, the material of a component is
described by the topological closure of its interior cl(C), which is the union
of its interior and its boundary cl(C) = C ∪ ∂C [120].
1.5.1 Geometric validity and the quality of a DMU
As digital geometric representations of a product, a DMU may contain unrealistic,
or unrealizable, configurations. An example configuration that is
frequently encountered in industrial models is the volumetric interference
between two solids. This configuration can lead to several interpretations:
a. It might be a by-product of an imprecise design and it is therefore
incorrect;
b. It might also be a deliberate artifact to reflect some conventional meaning
and, in this case, it has no impact on the correctness of the DMU.Geometric models and modeling methods 11
Figure 1.6: Automated generation of a technical drawing from a DMU that
contribute to the definition of a product model.12 Chapter 1. DMU and Polymorphic Representation
P
Δ
H
D
d
Figure 1.7: A cross section of a threaded link between a screw and a nut
represented as a simple interference in a 3D assembly geometric model. The
sub-figure at the right shows how the cross section may look like in a real
product, and the technological parameters it may have conveyed. H: height
of the thread; P: pitch; d: minor diameter of external thread; D: minor
diameter of internal thread; Δ: nominal diameter.
Figure 1.7 shows an example where a threaded link is represented as
such an interference, which falls into the interpretation of type b.
Furthermore, some geometric modelers let a user create non-manifold
configurations (see Figure 1.8). Some of these configurations are useful to
produce a simplified representation of the real object that is needed to perform
mechanical simulations using the finite element method (see Figure 1.8c
and Section 1.9). Those configurations, however, are not physically realizable
[131].
These unrealistic or unrealizable geometric arrangements put a question
about the quality of DMU. One may ask what geometry to consider as
valid, and what to reject or disallow, knowing that these configurations
cannot be filtered out by the algorithms of a geometric modeler. In fact, the
answer to this question highly depends on conventions being followed by the
users or engineers because there is no representation standard that is used
in geometric modelers to discard such arrangements. However, studying
industrial models showed that there exists a general consensus in the domain
of mechanical engineering that geometric degeneracies such as non-manifold
configurations (see Figure 1.8a, b) should be avoided in a DMU, as they
are often misleading as for how to be interpreted. Meanwhile, volumetric
intersections are largely accepted, as they convey a particular meaning.Geometric models and modeling methods 13
(a) (b) (c)
Figure 1.8: (a), (b), (c) Geometric models with highlighted non-manifold
configurations. (c) is an example of simplified representation that can be
used for a mechanical simulation.
Manifold or not, digital geometric models defining products in CAD
systems have their boundary represented either with faceted models, i.e.,
piecewise linear surfaces, or with piecewise smooth surfaces. Here, the first
category is named discrete geometric models and the second one analytic
geometric models.
1.5.2 Discrete geometric models
Discrete geometric models consist of a finite set of geometric elements topologically
connected to each other to define the boundary of a shape. These
elements are manifolds that can be either one, two, or three-dimensional.
The very basic geometric element is a vertex : a point lying in 1D, 2D or
3D-space, this is a zero-dimensional manifold.
Two vertices connect to each other defining a line segment or edge that is
a one-dimensional manifold. An aggregation of edges on the same plane can
form a piecewise 1D curve. If every vertex of this aggregation is topologically
connected with at most two edges per connection1 the curve is indeed a onedimensional
manifold.
A 1D closed2 manifold and planar curve with no self-intersection bounds
a discrete planar area or face, i.e., a two-dimensional geometric entity. An
aggregation of faces connected to each other forms a faceted 2D surface.
If every edge of this aggregation is topologically connected with at most
two faces, while the connection between faces happens uniquely at their
boundary, i.e., at the edge level, the surface is a two-dimensional manifold.
A 2D closed3 manifold surface with no self-intersections bounds a solid,
1Connection between edges happens at their boundary, i.e., either of their vertices.
2A closed curve is a curve in which a connection happens at every vertex of each of its
edges. 3A closed surface is a surface in which a connection happens at every edge of each of14 Chapter 1. DMU and Polymorphic Representation
(a) (b)
Figure 1.9: Geometric models of a teapot: (a) discrete model (triangular
surface mesh); (b) analytical model (composite free-form shape obtained
from a set of surface patches).
a three-dimensional geometric entity. Solids can be aggregated to form more
complex ones. If this aggregation is topologically connected in a way that
connection happens uniquely at face level the resulting solid is manifold.
Discretized models are also called meshes. Meshed objects used in a
product development process to describe a solid are represented in one of
two ways:
Surface meshes
Using a discrete closed surface to define the boundary between the interior
and the exterior of the object. Those surfaces are decomposed of
faces, as mention before. Faces can have an arbitrary number of edges
each, however, surfaces are usually built out of triangles and/or quadrangles.
These models are also called polygon meshes. Figures 1.9a
and 1.10b show examples of surface triangular meshes;
Volume meshes
Using a set of connected simple volumes, such as tetrahedrons and/or
hexahedrons. These models are also called polyhedron meshes. Figure
1.10c shows a cut in a tetrahedral volumetric mesh of a fan blade
foot.
Discrete geometric representations are simple. However, they are not
suitable for the up-stream design phases of a PDP for the following reasons:
• They are approximate representations that imprecisely capture the
designed concept, as they fail to accurately define smooth curves and
surfaces that are mandatory for manufacturing processes. Powerful
shape modeling algorithms are not available in CAD systems;
its faces.Geometric models and modeling methods 15
(a) (b)
(c) (d)
Figure 1.10: Geometric models of a mechanical part (foot of a fan blade):
(a) complete B-Rep analytical model; (b) complete discrete model; (c) a cut
into a volume mesh showing tetrahedrons internal to (b); (d) a section into
a surface mesh showing that the triangles lie on the surface of the solid.16 Chapter 1. DMU and Polymorphic Representation
• Meshes are scale dependent, their level of details, i.e., their roughness,
cannot be adjusted to obtain smoother shapes once the model is
generated;
• The roughness of these models hinder their utilization for machining
purposes in the down-stream process, where smooth realizable surfaces
are expected unless the roughness is lower than that of the manufactured
surface. This constraint however requires a too large amount of
storage to be used for complex products.
As a result, geometric modelers of CAD systems are rarely discrete,
although discrete models can be generated from analytical ones for applications
in finite element simulations (see Section 1.9) and prototyping.
1.5.3 Analytical geometric models
Analytical geometric models use the same concepts defined for discrete models
to describe the topology of their B-Rep model, i.e., vertices, edges, and
faces. However, this topological representation is associated with geometric
models such that edges need not be linear, and faces need not be planar anymore
in these models. This allows for a concise yet precise representation
of smooth piecewise curves and piecewise surfaces.
While vertices still represent points in the euclidean space, an edge is only
partially defined by its two endpoints, since it is also characterized by the
curve on which it lies. To this end, curves are represented mathematically,
either as canonical geometric shapes such as lines and conic sections, or as
parametric equations such as B-splines and B´ezier curves.
The same principle applies to faces which are characterized by the surface
they lie upon, beyond their boundary edges. Carrier surfaces are also represented
mathematically, either as canonical surfaces such as planes, spheres,
cylinders, cones, or tori, or as parametric equations such as B-spline or
B´ezier surfaces, or as implicit surfaces.
Just as in discrete models, two vertices connect to each other forming
and edge, a set of edges forms a composite curve, either manifold or not4.
A closed manifold composite curve defines the boundary of a face, faces
are aggregated to form composite surfaces, again they may or may not be
manifold5. A closed, orientable surface, without self-intersection, defines a
solid C while forming its boundary ∂C.
Analytical geometric models are faithful to the original geometry that
a designer had in mind since they are accurate representations of a real
object. They are scalable with no information loss. Those properties make
4Manifold composite curves connect at most two edges at each of their vertices.
5Manifold surfaces connect at most two faces at each of their edges, while edges are
free to be decomposed into smaller onesGeometric models and modeling methods 17
Figure 1.11: An example of CSG tree where leaves are geometric primitives,
∪ is a Boolean union, ∩ is a Boolean intersection, and − is a Boolean
difference.
it easier for geometric models to provide a reference for processes located
down-stream with respect to the design process.
CAD systems use analytical representations of objects because of these
favorable properties [120, 121]. Geometric modelers represent analytical
models in one of following ways:
Generative methods
Where the object is defined by the process of its generation. One such
method is the Constructive Solid Geometry (CSG) whereby an object
is represented as a tree whose root is the geometric object and its
leaves are elementary geometric entities, i.e., primitives or geometric
objects generated by other generative methods, and internal nodes
are geometric Boolean operations, i.e., union, intersection, differences.
Other generative methods are sweeping, rotation, extrusion, etc. that
generate 3D entities out of 2D sketches.
These models are useful to describe products because they keep track
of a history of their modeling process and because they allow easy
modifications. Geometry modifications are frequent during a product
development process, hence the long lasting interest of CAD systems
in history trees. Figure 1.11 shows an example of a CSG tree and
corresponding geometric shape at each step of its construction;
Descriptive methods
Such as B-Rep, where the object is defined by its boundary. This
object is represented by a set of closed, oriented, non-intersecting surfaces
that forms a multiply connected volume. These models keep no
track of the construction process, however their data size is smaller18 Chapter 1. DMU and Polymorphic Representation
than that of their CSG counterparts. Figure 1.9 shows an example of
a teapot analytically represented by its boundary.
However, B-Rep models are automatically generated from any CSG
description: each CSG boolean operation has a corresponding B-Rep
transformation that represent the results in the B-Rep description.
Actually, hybrid model are used in the DMU context where different BRep
representations are linked: the CAD B-Rep model is the “exact”
representation of the geometry, the visualization model is a 3D mesh
approximating surfaces of the CAD model for user interaction, while
FE mesh model is used for physical simulation using the finite element
method.
Parametric and feature based methods
Which add geometric parameters and shape feature semantics to the
primitives of CSG representation and its resulting B-Rep model. Featurebased
and parametric model represents the history of the geometry
construction process with a tree where leaves are parameterized shape
features having shape characteristics and often functionnal and/or
manufacturing significance: holes, chamfers, pads, pockets, blends,
fastners, etc. Features associate properties and parameters to a set of
topological and geometrical entities of the B-Rep model and a CSG
primitive shape:
• geometric properties (dimensions such as hole diameter, 2D sketches,
extrusion direction, revolution axis, sweeping curve, blending radii,
etc.);
• application-specific properties (machining tool parameters, toolpath,
weld beads, threading parameters, glued surfaces).
Many feature descriptions have a significance for several applications,
e.g. a revolution cut can have a functional meaning (location of a bolted
joint), a manufacturing meaning (drilling process), an assembly process
meaning (fastening process), or a simulation meaning (definition
of boundary conditions for FEA simulation). Unfortunately, manufacturing
and functionnal properties are often missing in feature-based
models due to various reasons: the time required to describe functions
with features is often too long, manufacturing and functional features
available in STEP ISO-10303 standard [7] and implemented in commercial
software cover a small part of configurations.
1.6 DMU as an assembly
Products functionalities are satisfied by mechanical components that are
assembled together to function consistently with respect to each others.DMU as an assembly 19
Vehicle
Structure Powertrain
Body Chassis Gearbox Engine Gearbox Engine
Chassis Powertrain
Frame Body
(a) (b)
Figure 1.12: Two possible simple structures of a car DMU: (a) Assembly
tree organized as per function; (b) Assembly tree organized as per order of
mounting.
The DMU reflects this grouping by representing the product as an assembly
of parts, each representing one mechanical components. This grouping can
occur at different levels to form a tree structure, as components are gathered
in sub-assemblies.
1.6.1 DMU structure
This multi-level organization gives the assembly a tree-like structure for
which the root is the product, nodes are sub-assemblies, and leaves are components.
We note that if generative methods are used to model components,
the latter are also represented in a tree-like structure in CAD systems, with
leaves being the geometric primitives and nodes geometric construction operations
(see Section 1.5.3).
The hierarchical organization of a DMU using an assembly tree structure
is not intrinsic to a product, rather it depends on the criterion used to set up
the tree structure, e.g., functional, organizational, or assemblability. This
criterion is user-defined and the tree structure is defined interactively by the
user.
Functional criteria Components may be grouped according to their functional
contribution to the product. In this case, sub-assemblies represent
functional modules. For example, a car assembly may consist in
a structure and a powertrain. While powertrain can be decomposed
into engine, gearbox, driveshaft, differential, and suspension (see Figure
1.12a). Each of these denominations represent a functional grouping,
a unit that satisfies a specific function of a car6. Functional modules
in their turn consist of components interacting to fulfill a function.
6The decomposition is simplified from what a real car assembly is.20 Chapter 1. DMU and Polymorphic Representation
Figure 1.13 shows a snapshot of a commercial CAD software (CATIA
V5) showing the tree structure of the DMU of a centrifugal
pump shown on Figure 1.5. Sub-assemblies are organized according to
their functional properties. The tree expands the casing sub-assembly
(Carter pompe centrifuge) having as function to contain the fluid,
inside which it expands the volute housing part (Volute pompe) having
as function to drive the centrifugal movement of the fluid.
Organizational criteria Sub-assemblies arrangement may also reflect criteria
based on manufacturing and organizational choices rather than
internal functional coherence. For instance, if different components of
the product are designed and/or manufactured in different companies,
those parts are likely to be separated in a sub-assembly, even though
they do not constitute a valid functional unit on their own. Figure 1.14
shows how the aircraft structure of an Airbus A380 is divided into subassemblies,
each being manufactured at a different facility, possibly in
a different country.
Assemblability criteria Another aspect that can be encoded in a digital
assembly structure is the mounting sequence of components alongside
the assembly line. In this case, a sub-assembly represents a set of
elements, i.e., components or other sub-assemblies, that are put up
together at once. The depth of hierarchy represents the order in which
installation occurs. For instance, while chassis and powertrain are
two different sub-assemblies of a car, powertrain itself is decomposed
into engine and gearbox whose components are mounted separately,
and at an earlier stage than the assembly of the powerengine (see
Figure 1.12b).
It is worth mentioning that no matter what criterion is used to organize
a DMU structure, this knowledge is still partial and unreliable. This is
not only the subsequence of lack of norms and standards, but also because
the strict tree-like structure is incapable of representing certain semantic
groupings such as functional clusters where overlapping sets may occur,
or kinematic chains where cyclic graphs are expected rather than a tree
structure.
1.6.2 Components’ positioning
In real configurations, components are positioned relatively to each others
through contacts and other assembly techniques, e.g., clamping and welding.
In a DMU, however, the product is represented as a geometric model, and its
components as digital solids (see Section 1.5). Contacts lose their physical
meaning, welding and gluing are rarely represented, and some other unreal-DMU as an assembly 21
Figure 1.13: A snapshot from a commercial CAD software (CATIA V5)
showing a DMU as its geometric representation (see Figure 1.5), alongside
its tree-structure.22 Chapter 1. DMU and Polymorphic Representation
1
2
3
4
5
6
1
7
1 Hambourg (Germany) 2 Broughton (UK)
3 St. Nazaire/Nantes (France) 4 Stade (Germany)
5 St. Nazaire/M´eaulte (France) 6 Getafe/Puerto Real (Spain)
7 Toulouse (France)
Figure 1.14: Airbus A380 airframe sub-assemblies, not organized according
to their functions (cockpit, cabin, wings, tail, etc.) but according to the
place were they are built (courtesy EADS).
istic geometric configurations, such as interferences, may also take part in a
DMU (see Section 1.5.1).
Therefore, relative positioning should be represented in different means
to convey this attachment. A set of welded or glued parts forming a single
component, for instance, are usually represented as separate components
since they are manufactured separately prior to the welding or gluing process.
In this case, a simple contact that would represent the welding or
gluing zone in a DMU is not enough to assert that components are fixed in
position with respect to each others.
This first observation shows that pure geometric information to assess
connection between components is ambiguous. Further, this ambiguity is
often not removed in a DMU because the complementary information needed
does not exist in the DMU. It is up to engineer to interpret the DMU and
derive to correct contact information.
Now, concentrating on the purely geometric information related to the
spatial position of components; let us carry on the analysis of a DMU content.
Figure 1.16 shows a model of an internal combustion engine, with a
section cut in the combustion chamber showing how the piston (the green
object) fits in the cylinder of the chamber. It also shows how the pistonDMU as an assembly 23
links to the crankshaft (the blue object) through multiple pivot links.
Different ways can be used to represent components’ positioning and
orientation, depending on what to expect from the DMU.
Kinematic links
For kinematic simulation purposes, where animations of the mechanism
are to be generated, kinematic connections define relative positions
between objects, leaving some degrees of freedom (DoF). Simple
connections, also referred to as lower pair connections are classified
into prismatic, cylindric, screw, planar, and spheric connections [83].
In the example of the internal combustion chamber, a sliding pivot
joint between the piston and the cylinder, which is a cylindric connection,
aligns both axes leaving two DoF: rotation around and translation
along the common axis7. The connection between the connecting rod
and the crankshaft is defined by a pivot link that allows only a rotation
around their common axis B. Figure 1.15 shows the kinematic
diagram of the mechanism of a slider-crank.
Geometric constraints
Manufacturing models give more importance to how components are
located with respect to each other, rather than what relative motions
they exhibit. Thus, relative positions of components can be defined
through geometric constraints such as coincidence, concentricity, coaxiality,
distance, etc. These constrains usually leave the object stationary,
i.e., with zero DoF. Constraints that are not defined by the
designer are assumed by the modeler, usually in terms of linear and
angular distances, leading to a static representation of the product.
In the example of the combustion chamber shown in Figure 1.16 a
coaxiality constraint is defined between the piston and the internal
cylinder of the chamber. The distance between the piston and the
back end of the chamber is either defined or assumed.
Absolute positioning
Another way to create the scene of an assembly is to directly position
and align objects according to a global coordinate system defined
assembly-wise. This is usually achieved using an affine transformation
matrix per object.
The latest approach is the simplest, though it has many disadvantages:
• Setting the parameters of transformation matrices during design is
cumbersome. Designers usually define their concepts by means of kinematic
or geometric constraints;
7Rotation is eliminated when considering other connections in the mechanism.24 Chapter 1. DMU and Polymorphic Representation
0
1
2
3
A
B
C
0
1
2
3
0
A B
C
Figure 1.15: A drawing of a slider-crank mechanism (left) and its corresponding
kinematic diagram (right): (0) Chamber; (1) Piston; (2) Connecting
rod; (3) Crankshaft. A, B and C are points locating the rotation axes
of the crankshaft, connecting rod, and piston, respectively.
• Editing of the assembly model is more complicated, since constraints
propagation should be considered manually now and the consistency
of the assembly model is harder to achieve;
• Kinematic links are indicators of relative motion properties between
components. This information is lost when fixing components in place
in an absolute manner.
Nevertheless, standardized formats describing components and assemblies
across CAD software, such as STEP [7], still use absolute positioning
of assembly components, as it is globally recognized by all geometric modelers.
Geometric modelers, in their turn, allow the exportation of models
in such formats, even though native models usually use one of the first two
methods, or a combination of them to position and align components.
While kinematic links explicitly characterize the relative motion between
components using rotations axes and sliding directions, geometric
constraints are meant to fix components in place, generating an instantaneous
representation of the product at a given moment in time. Another distinctive
difference between these two methods is that geometric constraints,
as per definition, must refer to explicit geometric entities of components, unlike
kinematic links, such as helical motion, where certain attributes, such
as pitch, can be provided as a parameter, independently from any geometric
support. Other kinematic links, e.g., pivot link, do not need to refer to geometric
entities of the components, e.g., the cylindrical surfaces of the pivotOther information associated to a DMU 25
link, which means that the existence of a pivot link does not mean that the
corresponding components are geometrically consistent, i.e. of same diameter.
Considering that a product is subjected to numerous modifications
during its design process, this shows that kinematic links alone are not a
reliable source of data to ensure that a DMU is consistent with respect to
the relative position of its components.
Moreover, geometric constraints are of minor significance to design intentions,
since designer may use misleading geometric alignments for the
sake of ease of use. An example would be the alignment of the piston with
the chamber in Figure 1.16. One may assume that the contact between
the surface Sp of the piston and the internal one Sc of the chamber could
be inferred thanks to a coaxiality constraint, plus an additional diameter
check. However, this conclusion is not always achievable as the user-defined
positioning can be obtained by aligning, say, the axis Ap of Sp to the axis
of any given external cylindric or conic surface, Scy or Sco respectively, of
the chamber, leading to the same exact geometric configuration. Kinematic
links in turn bear an inherent sense in the context of motion simulation and
analysis. They are, however, often disconnected from boundary geometric
elements. For instance, if kinematic links are used in the example of the
combustion engine, the piston can be linked to the chamber by means of a
sliding pivot link. To establish this link, cylinder axes Ap and Ac should be
used. Such a link makes no reference to concrete geometric entities such as
boundary surfaces Sp and Sc (thus no reference to contact zones) and leads
to no avail when geometric interactions detection is sought.
As a conclusion, this renders reasoning based on geometric constraints or
kinematic links an unreliable approach. Globally, none of the three methods
to position components in an assembly is, alone, sufficient to ensure the
geometric consistency of an assembly model.
1.7 Other information associated to a DMU
So far a DMU is regarded as a set of geometric objects (components) grouped
together in a hierarchical structure (sub-assemblies). This representation incorporates
geometric information about the product, plus some kinematic
properties as seen in Section 1.6.2. However, and in order to efficiently participate
to the PDP, the DMU has to integrate other information about the
product and its components rather than its geometry, kinematic links, and
assembly structure. This information adds up to the geometry of components,
but is not part of it.
One reason that this “extra” information is needed is the fact that the
geometry of the product is often simplified in a DMU (see Figure 1.17),
thus differing from the shape of physical components. Standards as well as
companies’ practices suggest to compensate this loss of information due to26 Chapter 1. DMU and Polymorphic Representation
Figure 1.16: A DMU of an internal combustion engine. A section cut in
its combustion chamber shows the piston (in green), and the crankshaft (in
blue).
geometric simplification by other means of auxiliary annotations. Figure 1.7
shows an example of information lost due to such a simplification. The
ISO standard SETP AP214 [12], for instance, provides annotations such as
thread, where geometric properties such as major diameter, minor diameter,
pitch, number of threads and hand can be expressed explicitly [69]. This
allows the threaded part of a screw or a nut to be geometrically simplified,
e.g., as cylindric surface.
Another kind of such necessary annotations in the context of a PDP is
important information that cannot be represented geometrically. An example
is component material and its physical properties. Though it relates in
more than a way to geometry, kinematic knowledge about the product also
falls into this category, since relative motion holds more information thanApplication of DMU 27
(a) (b)
Figure 1.17: Screw and nut (a) in real configuration, (b) as simplified geometric
model.
instantaneous shape snapshots.
Integrating materials and their properties in the DMU is necessary to
enable the generation of detailed bills of materials (BOM), which design
office communicates to other departments such as purchase department [74].
BOM contains detailed information about required parts and material to
enable the manufacturing of a product [165]. This information is used to
prepare orders and manage inventory.
A close look at industrial practices shows that this information is scattered
around the DMU in a non-standardized manner, making the task of
exploiting such knowledge a challenging one. Iyer et al. [90] show that modern
Product Lifecycle Management (PLM) systems provide the DMU with
a context that allows annotations such as keywords and part name, etc.
Authors, however, show that these annotations are not robust, and of little
use for information retrieval. They attribute this inadequacy to reasons
among which are the non-unified conventions among design personnel, and
the change of industrial context with time.
1.8 Application of DMU
DMUs are computerized models that engineers use to communicate their
designs to the manufacturing as well as other company departments. Their
obvious application then is to provide the pattern upon which the product
is to be built.
However, they contain enough information that allows engineers to use
them at other stages all along a PDP.
In the previous section we saw that a DMUs contains supplementary
annotations that allow the generation of reports, such as BOM, necessary
for inventory and purchase management.
Another important application of DMUs is the generation of simulation
models. Since they closely represent product geometry as well as other phys-28 Chapter 1. DMU and Polymorphic Representation
ical properties, DMUs are good candidate to extract simulation models out
of them. Extracted models differ according to the goal of the simulation, we
can recognize structural simulation models, thermal simulation models, fluid
simulation models, among many others. A prominent simulation method in
todays PDP is the finite element method, Section 1.9 sheds more light on
this method. Auxiliary annotations, particularly kinematic connections between
components, contribute to a special type of simulations that are based
on the content of a DMU, this is Virtual Reality (VR) simulations.
Some VR simulations have their applications in high risk environments
when testing and training is too dangerous to be performed in real environments.
In such cases, a DMU can be used to generate a simulation model
where the desired tasks can be conducted in a completely virtual setup.
As demonstrated in Section 1.6 DMUs also provide a structure that
group components into subassemblies that are then grouped themselves into
an assembly representing a functional product. In this context, DMUs play
also an important role in the assembly/disassembly planning process of PDP.
Considering its diverse applications, a DMU shows a prominent presence
at different stages of todays PDP.
1.9 Basic principles of finite element analyses
The finite element method has shown its merits in different simulation applications.
In this section we introduce, in a nutshell, the basic concepts of
finite element analysis (FEA).
1.9.1 Numerical approximations of physical phenomena
FEA is a numerical method in which certain physical behavioral phenomena
are studied and analyzed using numerical approximations of real objects
called FEMs. A FEM contains a discrete representation of objects’ materials
in space, achieved using one-, two-, or tree-dimensional meshes (see
Section 1.5.2). Information about material physical properties are assigned
to the mesh at the element level. An element can be an edge, a polygon or
a polyhedron.
Figure 1.18 shows an example of the results of a FEA on a pump casing
to study heat conduction.
FEA simulations are in the heart of modern PDPs and product validation
practices. The FEM is prominent in most of behavioral studies of a product
prototype.
The process of FEA consists in three general steps:
pre-processing In this phase, the FEM is generated. This can be done
from scratch, building the mesh model at first, then assigning it physical
attributes. Nevertheless, in today’s industries the CAD model,Basic principles of finite element analyses 29
Figure 1.18: A FEM of a pump casing showing the results of a heat conduction
analysis.
which is usually an analytical one (see Section 1.5.3), tends to be integrated
with a mesh to facilitate the propagation of modifications
between these models. Then, the mesh acquired is in turn enriched
with material properties, in order to obtain the FEM. This process
is not as straightforward as it may seem, since many factors affect
the quality of the generated model, thus results’ accuracy when an
FE model can be effectively obtained. Such factors are how close the
approximate model, i.e., the meshed shape, is to the original objects;
how many elements does the model have; what are the distribution
and the quality of those elements over the original domains, etc.
analysis Now that the FEM is produced, the simulation problem is solved
by dividing it into simpler ones at the FE level, using differential equations
with boundary conditions. The type of equation used depends
on the desired simulated phenomenon. For instance, while EulerBernoulli
beam equations are used for structural simulations [82], heat
diffusion formulas are applied for thermal behavioral studies [45], and
Navier-Stokes equations for fluid simulations [18]. The solution boils
down to an error function minimization problem, respecting boundary
conditions.30 Chapter 1. DMU and Polymorphic Representation
post-processing The analysis phase comes out with observed variables values
over the meshed domain, i.e. solution fields. Those fields represent
studied changes in physical properties such as displacements, temperatures,
etc. To provide a global overview of the underling simulation,
those fields can be visualized using color codes, that allow enginners
to better estimate zones of interest.
In this work we are only concerned about the first step; the pre-processing.
1.9.2 Generation of a FEM
Pre-processing has a crucial impact on the efficiency, performance, and accuracy
of later steps of FEA. Many choices are made at this stage such
as shape simplifications, mesh element dimension (linear, surface, or volume)
and mesh element shape, e.g., triangular, quadrangular, tetrahedral,
hexahedral, etc.
The resulting FEM highly depends on the observed phenomenon and the
ultimate goals of the FEA. To this end, simulation objectives should be outlined
first, such objectives can be either structural study, with deformable
bodies, or thermal behavioral analysis, etc. Once objectives are defined,
assumptions about the relevance of geometric areas can be made, leading to
simplification hypotheses characterizing some areas as details with respect
to the simulation objectives. This enables the reduction of models’ complexity
through shape transformations [41]. Entire shapes of objects or a
small subset of them can either be simplified (case of dimension-preserving
transformations, e.g., hole removal from a volume that transforms a volume
into a new one), or idealized (case of dimension-reducing transformations,
e.g., replacing a thin and elongated volume with a beam that transforms a
volume into a line).
The shape transformation process generates what we refer to as simulation
model, also called mechanical model in the literature [168, 21, 80].
Alike the DMU, the simulation model contains a geometric representation
of the assembly that is dedicated to simulation purposes rather than manufacturing
ones. Such differences refer to the concept of product view where
the simulation view is distinguished from the design one (see Figure 1.19).
Along with the simplification hypotheses and simulation objectives, the simulation
model provides essential knowledge to generate the required FEM.
Figure 1.19 depicts how, for a given simulation context, geometric transformations
generates a simulation model out of an assembly DMU, whose mesh
is then generated to produce the FEM [41].DMU as polymorphic representation of a product 31
Simulation
Model DMU FEM
Simplifications
&
Idealizations
Product
Design
FE Mesh
Generation
Simulation Objectives & Hypotheses
Upstream Product View Simulation Product View
Figure 1.19: A flowchart showing processes and models involved in the
preparation of a DMU for FEA. It locates the simulation model as a result
of the simplification and idealization processes, and as an input of the
FE mesh generation process.
1.10 DMU as polymorphic representation of a product
Different applications of a DMU require different types of information, and
different levels of details, particularly when geometric representations are
included in these applications [71].
For instance, while purely volumetric models are recommended for manufacturing
and machining applications since they most accurately represent
the real shape of components, reduced-dimension configurations are tolerated,
even recommended, for simulation-oriented applications where geometric
details become a burden and shape simplicity is prioritized over its
accuracy to promote the accuracy of the simulations results.
In the same context, GD&T information is vital for manufacturing department,
while relative motion properties are usually irrelevant at this
stage. However, such kinematic knowledge is essential for rigid body simulations
where geometric details such as manufacturing tolerances are meaningless.
This diversity of applications requires the DMU to show different forms,
or views, according to the level of details that the application implies. In
this sense, the DMU acts as a polymorphic representation of the product,
where the shapes of components as well as their associated annotations are
dependent on the nature of the application.32 Chapter 1. DMU and Polymorphic Representation
1.11 Adapted definition of DMU
The concept of DMU has been developed across the literature, and many
works have tried to establish a definition. Those definitions all agree that a
DMU is a digital representation of a product that contains at least its 3D
geometry down to a certain level of details. They also assent that it plays
a major role in the PDP. However, they differ in defining to which extent a
DMU participates to certain stages such as simulation and validation.
Some definitions extend the concept of DMU to the point where it corporates
all virtual prototyping, referring to simulation models as part of the
DMU since they are indeed a digital representation of the product [57, 177].
Other works restrict DMUs to models that fit directly the purpose of
design and manufacturing. While simulation models can be generated based
on DMUs, these simulation models are not effectively part of them.
In our work we adopt the following definition.
Definition 1.3 (Digital mock-up). A DMU is a computerized representation
of a product as an assembly of sub-assemblies and components in a
hierarchical structure. It represents product geometry, possibly at different
levels of details. DMUs also contain supplementary information about the
product and its components that is casted in compliance with the intended
application.
This definition puts forward the polymorphic nature of a DMU since
geometry and other associated information are adaptable to the application
in which a model fits.
It is worth mentioning that although the concept of DMU covers a wide
variety of functional, kinematic and technological informations [69], only few
efforts are made to standardize non-geometric data. Therefore, in the scope
of the present work, we are only considering the geometric information that
a DMU holds, where components are positioned absolutely according to a
global (product-wide) coordinate system as it is the case for standardized
formats such as STEP. Other information such as kinematic links, technological
annotations, etc. are not considered because they are ambiguous and
unreliable.
1.12 Conclusions
DMUs accompany PDP and are now much more than manufacturing issues
as analyzed in Sections 1.8 and 1.9, and particularly in Section 1.9.2. Indeed,
DMUs have become focal to modern PDPs as they represent a central data
repository of a product incorporating models as generated by the engineering
design office.Conclusions 33
Further than a product model, DMUs contribute nowadays to the generation
of virtual prototypes that feed numerical simulations to assess product
functionalities (see Section 1.9).
This data repository is organized around a geometric model that forms
the kernel of a DMU (see Sections 1.5 and 1.6.1). However, considering the
geometric interactions between components of a product, as they are represented
in a DMU, Sections 1.5.1 and 1.6.2 have shown that the digital shape
of components may significantly differ from that of physical ones and component
positioning techniques do not ensure the consistency of an assembly.
Engineers’ know-how refers to various conventions and standards to interpret
component shapes as well as their relative positions. These conventions
and standards are not part of the CAD systems used to produce and modify
the geometry of DMUs. In addition, the diversity of processes, e.g. FEA,
assembly simulations, requiring a pre-processed DMU as input leads to the
concept of polymorphism (see Section 1.10).
Complementary information can be attached to components and/or subassemblies
(see Section 1.7) or derived from assembly models (see Section
1.6.2) but it appears that the robustness and reliability of these informations
do not strengthen a DMU and, in addition, are not easily accessible.
Among all these informations, it is important to mention that functional information
is not explicit in a DMU and consequently, there is no effective
link between any description of a function and some corresponding geometric
entities in a DMU.
In the present work, the focus is placed on the generation of explicit
functional information attached to components and sub-assemblies. The
attachment of such information to geometric entities is of strong interest
since the polymorphism of DMUs is a key requirement to pre-process them
and generate virtual prototypes. Among the virtual prototypes that can
take part to a PDP, the structural behavior of a product is of increasing
importance. Therefore, the shape transformations taking place during the
pre-processing for FEA is of strong interest, especially in the case of assembly
behavior. Relating shapes, i.e., the geometry of assemblies, to component
functions in order to ease the assembly pre-processing for behavioral simulations
is a consistent objective addressed here. To this end, further analyses
of prior work that relate shape, function and behavior of a product or, otherwise,
address either of these concepts separately is the purpose of the next
chapter.Chapter 2
Literature Overview
This chapter analyzes existing literature that relates to this work.
Work that founded the conceptual or methodological basis of our
approach is presented in Section 2.2 that studies product function
and Section 2.3 that relates function to shape. Later sections study
prior work that addressed problems of interest to our research. Section
2.4 visits works that aimed at the extraction of functional information
out of geometric data, showing the important role that
components interactions play whenever functionality is sought at
the assembly scale. Section 2.5 then studies efforts to define components
interactions geometrically. The problem of knowledge representation
and its importance to the DMU is addressed in Section
2.6, and works that tackled this problem from different angles
are reviewed. Finally, Section 2.7 examines works dedicated to the
transformation of CAD models to FEA-friendly simulation models,
emphasizing the importance of functional knowledge at this stage.
In the aforementioned sections, we also show why already established
work failed to provide satisfactory answers to some of the
difficulties observed in the previous chapter and hence, why they
motivate our work.
2.1 Introduction
As mentioned in the introduction of this document, the upcoming chapters
will concentrate on formulating the problematic that motivates this work
(see Chapter 3), before relevant concepts are defined (see Chapter 4) and the
proposed method is detailed (see Chapters 5, 6 and 7). However, and before
proceeding likewise, a review of what state of the art offers is imperative.
The objectives of such a literature review are twofold:
• The major objective of the proposed approach focuses on enriching assembly
models with functionally related information, as Chapter 1 has36 Chapter 2. Literature Overview
shown that the content of a DMU ends up as a simple geometric model
without functional information. It is therefore mandatory to review
concepts such as product and/or component functionality and how
these concepts can be related to geometry, i.e., product and/or component
shape. To this end, design process studies and corresponding
design methods that advocate the function–behavior–form relationships,
a central paradigm to this research, need to be analyzed to
evaluate how a geometric model of an assembly can be related to its
functional information. One of the outcome of this analysis shows the
prominence of geometric interfaces between components;
• Works that associate component geometry with functionally related
information such as feature-based approaches, detection of geometric
interfaces between components and knowledge-based approaches are
also studied since they are part of prior approaches that proposed
concepts related to function. Because a particular focus is placed on
the use of functional information in the context of FEA, some key
approaches that relate to FEA of assemblies and geometric interactions
between components are also reviewed to better highlight the
challenges in this area. Not only the common denominators with such
works are put forward, but also differences that distinguished the approach
proposed in this document and made it worthwhile. To the
author’s knowledge, none of the existing works addressed and effi-
ciently solved the tackled problem of functional enrichment of DMUs
for FEA purposes.
Such a literature survey prepares the ground for the discussion to come
in the successive chapters, and situates them with respect to existing works.
Section 2.2 starts this review by showing how functionality is seen from
different angles in the domain of mechanical engineering.
2.2 Function formalization
Although the concept of function may initially seem self-explanatory, literature
has different points of view regarding its definition. Deng et al. provide
an overview of different perspectives [62].
Three distinguished standpoints can be identified, from which a function
is seen:
as a raison d’ˆetre. A function is defined by many scholars from a teleological
point of view as the ultimate purpose of a product [60, 29, 46,
84, 136, 163, 172, 178].
An interesting definition to our approach is that of Gero [72] as he
defines function to be the semantics of design.Function formalization 37
as a black box. Others considered function as the relationship between
the input and the output of a system [105, 129].
as a verbal phrase. Function has also been regarded form a performance
perspective as it defines the behavior of a product [174, 172, 77, 85,
167, 162].
Literature suggests modeling functions as verb-object pairs [129, 86],
such as ‘reduce speed’ or ‘transfer torque’.
Many scholars, however, saw functionality from a midpoint perspective
between two or more of the above-mentioned ones. Pahl & Beitz [129]
formalized functionality as a verb-object pair, in which the verb expresses
the function, while the object represents the flow of material, energy, or
signal between the input and the output of a system. Likewise, Qian &
Gero [136] describe a function as the purpose of design, while emphasizing
its strong ties with behavior.
The above-mentioned works viewed functionality independently from
any product state. Without going into the details of the meaning of a
product state, it can be observed that a state can be related to the input
and output of a product. Indeed, a state can be characterized by a set I of
physical input parameters and another set O of physical output parameters
by the product. I and O are subsets of the whole set of input and output
parameters, respectively, that are used to describe all the possible configurations
the product can reach during its conventional usage. As pointed
out above, input and output parameters of a product are means to define
functions through the couples of input, output parameters that a function
binds. It is clearly the case when authors consider a function as a ‘black
box’, which is a casual standpoint, but also when authors concentrate on a
behavior since its purpose is to take parameters as input and modify them
to produce output parameters, which clearly underlines the concept of state.
When modeling functions through verb-object pairs, the verb expresses also
an action, which refers also to the concept of behavior. Therefore, a state
can be seen as a collection of functions that pertain to the sets I and O of
physical parameters attached to a product.
Therefore, the two concepts are closely related to each other, as the
products deliver different functions at different states. For instance an operational
bike delivers the functionality of transportation, while a dismantled
one has a better mobility which makes it easier for shipment. A broken bike,
however, delivers no particular function at all.
If states and functions are related to each other, it can be observed also
that the proposed definitions of a function do not refer explicitly to the
shapes of the product or some of its components.
In this work function is considered to be the major motivation behind
product design, with strong connection to the product state as part of its38 Chapter 2. Literature Overview
design. Now that the concept of functionality is well-situated with respect
to different literature viewpoints, the next section will develop on how to
link this concept to product and component forms. To this end, as the
upcoming section will reveal, it is essential to address the behavior of a
functional entity.
2.3 Connections between form, behavior, and function
The link between form, behavior, and function appeared early, and has
been discussed exhaustively, in the literature of engineering. De Kleer [60]
intuitively defined function as what a device is for, behavior as what a device
does, and structure as what a device is. When applied to mechanical
engineering, and from a design point of view, structure, under this understanding,
maps to form.
In an effort to formalize the relationship between function, behavior and
structure, Umeda et al. [174] established the Function-Behavior-Structure
(FBS) diagram, with a strong emphasis on a behavioral understanding of
functionality. Structure from the authors’ perspective denotes physical attributes
of an object. This can be seen as a generalization of object form.
2.3.1 Behavior to complete the design puzzle
Design is seen by scholars as a goal-oriented activity that aims at satisfying
certain requirement expressing a desired functionality. To this end, the link
between function and form, particularly in the domain of mechanical engineering,
is to be established. However, no direct mechanism allows for that
matching. Gero [72] shows how function can be formulated into an expected
behavior, and how form can be analyzed to produce its structural behavior.
This reduces the design activity to the process of matching expected and
structural behaviors, either through the evaluation of existing forms or the
synthesis of new ones.
Qian et al. [136] outline the casual relationship between structure and
behavior and between behavior and function that allows a product to meet
its expectations. This relationship is shown to be bidirectional, as function
can be analyzed to infer potentially-multiples behaviors that lead to its
satisfaction, then potentially-multiple structures can also be inferred in what
is referred to as goal achievement paths.
2.3.2 Pairs of interacting interfaces
In Albers et al. [23], the authors do not only emphasize the connection between
product geometry and functional attributes, they also demonstrateConnections between form, behavior, and function 39
Hollow wheel
Planet gear(s)
Sun gear
Planet carrier
C&CM Conceptual geometry Physical geometry
Figure 2.1: An example of a planetary gear modeled using C&CM [23],
showing interfaces between components of the corresponding assembly.
with concrete examples the correlation between pairs of interfacing geometrical
entities, i.e., pairs of surfaces belonging to different components, and
the expected purpose of a product. The corresponding design methodology
shows, through industrial case studies, how a function is tightly coupled
with the geometric properties of interfaces between neighboring components
that provide the desired, or even undesired, behavior. Figure 2.1 shows an
assembly model using Contact and Channel Model (C&CM) introduced by
Albers & Matthiesen in [24]. The example puts forward the important role
interfaces between components play in a product assembly to achieve the
desired function.
2.3.3 Tools and guidelines to support the design process
The aforementioned approaches have been applied to or are part of design
methodologies to provide engineers with tools to facilitate the creative activity
of design.
As an example, the work of [22] builds upon the C&CM to develop a
modeling approach as a tool to assist the design process.
Authors in [147] present a theoretical framework that builds upon formfunction
mapping to provide guidance to engineers along the design process,
in an effort to automate, or semi-automate, the transition from user requirements
into a functional artifact. In the latter work, authors address the
relationships between function, behavior and geometry from a top-down1
1By top-down, we refer to the path from functional specification, to design attributes,
particularly, components shapes.40 Chapter 2. Literature Overview
Input
(i)
Function
(F)
Output
(o)
Energy
Motion
Support
etc.
Energy
Motion
Support
etc.
Input
(i)
Function
(F)
Output
(o)
Energy
Motion
Support
etc.
Energy
Motion
Support
etc.
Behaviour
(Functional Relationships)
Geometry Physical Laws
(a) Traditional model (b) Part Function Model
Figure 2.2: A comparison between a traditional conceptual model of part
function (a), and PFM introduced by Roy & Bharadwaj [146] (b).
perspective, as a goal achievement guide to obtain parts geometry from
functional specifications.
Roy & Bharadwaj [146] set up a design approach to connect functions to
3D geometry using a Part Function Model (PFM) illustrated and compared
with traditional models in Figure 2.2. To acquire the proposed model, a
designer should provide a behavioral description of parts using a predefined
vocabulary. Along with geometrical properties of parts contacts, this description
is used to infer functional interactions between components. The
PFM obtained involves functional information down to the level of boundary
faces since the behavior model builds upon interfaces between parts, i.e.,
contact surfaces. This work emphasizes the discontinuity between spacial
properties of parts in an assembly model and their function, and advocates
the importance of a behavioral description to connect function and shape
concepts. It, however, requires the user to manually provide such a description
before making any judgment about a part functionality.
At the level of complex assemblies with hundreds to thousands of parts,
the amount of complementary data defining a behavioral model becomes too
tedious to add. Kim et al. [103] provide a formalism that augments a DMU
with the design intent of an assembly, particularly the semantics of contacts
between assembly components. This is achieved through the Assembly Relation
Model (ARM) and an XML-based meta-model that refers to geometric
entities in the DMU. Using this formalism, assembly models are annotated
by collaborating designers, based on spacial relationship analysis undertook
by a geometric kernel. Interactions between components are referred to as
joints in the context of assembly design. The nature of interacting form
features between components, then called mating feature, is captured in the
Generic Assembly Relationship Diagram (GARD) as part of the ARM, in
a graph-like manner. Joints in GARD are reduced to global parameters of
welded, glued, bolted and riveted connections that define components position
with respect to each other. This work is meant to facilitate collaborativeConnections between form, behavior, and function 41
assembly design and enriches a DMU with information relative to this task.
However, simulation objectives may require a detailed representation of
interfaces functional interactions beyond mere assembly joints. Especially
when the purpose is to assess the stress field distribution in a bolted connection
with tens or hundreds of bolts. Additionally, one can observe that
the relationship between shape and function strongly relates to interfaces
between components and, more precisely to contact surfaces, i.e., the real
component relative position. Somehow, this relationship is not robustly expressed
in a DMU, due to the designer’s choices made about component
shapes (see Section 1.5.1 and Section 1.7). Indeed, component shapes are
often simplified in a DMU, which can alter the representation of physical
contacts between components. As a result of the analysis of prior work, none
of them has taken into account this discrepancy, which can be regarded as a
fact creating inconsistencies between functional prescriptions of a designer
and the content of a DMU.
Works examined so far share a common denominator where assemblies
are described as geometric models enriched with technological annotations
that may qualify as functional information reflecting design rationale [107].
They participate to the enrichment of a DMU as a central repository of PDP
activities (see Section 1.7). While each of the unfolded efforts has seen the
DMU from a particular standpoint, none of them satisfactorily considered
the requirements of a seamless generation of simulation models. Observations
showed that the closer the enrichment is to any functional significance,
the higher the lack of information external to CAD environments and the
greater the need of user interactive input during a design process.
As a common observation of all prior works reviewed in this section, they
are all heavily dependent upon designer’s input data, i.e., the consistency
of functional information. Its relationship with 3D geometric models of
components or assemblies are left under the designer control. This is not
tractable for large assemblies and hard to set up even for simple products
with dozens of components.
Although proved bidirectional [136], the function-form relationship is
studied from a purpose-oriented viewpoint by the so-far analyzed works,
i.e., along the path from intended function to a designed form, oftentimes
through physical behavior as a connector. This understanding of the relationship
remains dominant in the literature. The following section, however,
shows work that made use of the bilateral nature of this relationship, exploiting
the causal direction, from form to function, to develop some confidence
about product functional properties.42 Chapter 2. Literature Overview
2.4 Constructive approaches to deduce function
In this section we walk through some of the existing work that aims at the
association of functional properties to different elements of a DMU. The
previous section has already highlighted that shape simplifications of components
restrict the applicability of approaches strictly based on geometric
contacts between components, which is the common feature of prior work.
2.4.1 Form feature recognition
Efforts have been paid in the field of Feature Recognition (FR) in solid
models as early as 1988 [94]. Zhu & Menq define features, also referred to
as form features or machining features, to be ‘the representations of shape
aspects of a physical product that can be mapped to generic shapes in a given
context and are functionally significant’ [185]. This definition establishes
links between form features and functionality, and makes it of a particular
interest to our research to shed some light on FR-related studies.
Examples of manufacturing features include holes, slots, pockets, and
other shapes that can be obtained by material removal operations using
Computer Numeric Control (CNC) machining systems [81].
In many occasions, literature shed the light on the gap between the
low-level geometric information usually present in CAD models, and the
higher level functional semantics needed by CAM systems. Authors in [121]
promote features as the link between pure geometry and design semantics,
allowing a smooth transaction from CAD to CAM activities. Literature also
surveyed a wide range of techniques that participate to the Computer Aided
Process Planning (CAPP) automation as a link between CAD and CAM,
where FR plays a major role as a communication agent [153, 152, 166].
Authors in [25] address the problem of functional features extraction out
of digital models. They classify existing solutions into human assisted approaches,
feature-based modeling, and automatic feature recognition and extraction.
Han et al. [81] in their turn regroup automated FR algorithms into
graph-based techniques, space decomposition approaches, and rule-based geometric
reasoning.
Falcidieno & Giannini [66] suggest a three-stage solution: recognition,
extraction, and organization of features. The proposed system builds a
hierarchical structure of a part shape in accordance with level of details.
The recognition phase builds on the work of Kyprianou [106] that paved the
road of graph-based FR.
A graph representation of the geometric model of an object is generated
in [94], before graph matching techniques are applied to extract form
features, also represented as graphs.
Ames in [26] advocates an expert system approach to recognize application-specific
features given the product solid model as an input.Constructive approaches to deduce function 43
In Date et al. [58], FR is integrated into the process of simplification as
a preliminary step to prepare a meshed model for FE analysis.
A technique to detect and remove blending features is presented in [185].
Even though fillet and round are secondary features as they are of little functional
significance (they don’t actually conform to Zhu & Menq’s definition)
their presence may interfere with the detection process of their parent features.
Authors, thus, present their work as a preliminary treatment of the
geometric model to enhance the recognition of more significant functional
features. Another approach, capable of handling more interacting shape features
through an iterative method is presented in [175]. In this work form
feature recognition techniques are used to detect features face-sets, and then
a feature is removed before passing to the next iteration, where previously
interfering features can be detected.
In Sunil et al. [164], authors again tackle the problem of features interaction
through a hybrid approach for FR that is both graph- and rule-based.
A more exhaustive categorization of efforts paid in the area of FR is given
by Shah et al. [154]. However, fruitful studied categories did not diverge
much from earlier classifications [66, 25, 81]. As a complement, Shah et
al. in [154], address recent work that considered the otherwise overlooked
free-form features [158, 182, 159].
Sridharan & Shah [159] provide a feature classification method to aid the
detection of complex CNC milling features. Figure 2.3 shows an overview of
the proposed taxonomy. The preliminary recognition of features uses a rulebased
approach independently of any geometric restriction, thus, allowing
for the identification of features involving free-form surfaces. At this stage,
features are categorized according to the first level of the taxonomy presented
in Figure 2.3. A finer classification of recognized features then takes
place, to predict feature type more precisely, this time taking into account
geometric properties such as surfaces types (cylindric, ruled, free-form, etc.).
This corresponds to the categorization of features in the second level of the
taxonomy presented in Figure 2.3.
Automatic FR techniques aim at the extraction of functional information
as design intentions given the pure geometric model, thus contributing to
the enrichment of a DMU. They are, however, still limited to a very small
set of simple geometric configurations like holes, pockets, slots, rounds and
fillets. Most of prior work fits into a bottom-up2 approach where features
are extracted from low level geometric entities and a detached volume model
is processed as a standalone entity. Whenever product models are referred,
they are generally regarded as a collection of components processed with
loose or no connections at all between them.
2In contrast to top-down scheme, bottom-up is used to refer to the path from existing
design information, such as objects shapes, to a more elaborate knowledge, such as
functionality.44 Chapter 2. Literature Overview
Figure 2.3: CNC machining feature taxonomy according to [159].
Another common observation regarding features is their sensitivity to
interactions with other features. It means that FR processes can be easily
perturbed when a feature is not precisely matching its definition or, alternatively,
a feature definition is often simplified to avoid referring to the very
wide diversity of geometric configurations that occur when a given feature
interact with many others. It has also to be observed that feature definitions
are not available in DMUs (see Section 1.7) partly because of the previous
observation and partly due to the fact that features follow definitions targeting
very specific applications, which justifies their absence in a DMU since
it is regarded as a common repository to feed a large range of product development
tasks. As a complement, FR approaches as well as feature modeling
ones process strictly standalone components whereas Section 2.3.1 has shown
that functional information requires the geometric interaction between components
to be precisely characterized. Therefore, functional features must
be addressed at the assembly level, which is the purpose works visited in
the following section.
2.4.2 Functionality as a result of geometric interactions
The strong ties between geometry and functional semantics are again brought
forward by [125] where authors analyze causal kinematic chains of a product
based on component-to-component kinematic links deduced from their
geometric interfaces.
Authors made simple assumptions about the assembly to semi-automatically
infer motion functions:
• Parts having rotational and translational (partial) symmetry properties
enable rotational and translational motion respectively, along theirConstructive approaches to deduce function 45
(a) Analyzed assembly parts (b) Interaction graph
Figure 2.4: Mitra et al. [125]. Parts of an assembly with automatically
detected axes of rotation or symmetry (a), and the corresponding interaction
graph (b). Graph edges encode the types of joints.
symmetry axis and direction respectively;
• Levers, belts, and chains have few geometric characteristics that enables
to identify them automatically: their 1D structure can be analyzed
with principal components analysis to infer curvilinear and periodic
motion properties;
• Kinematic functions as gears are set manually by the user.
An interaction graph illustrated in Figure 2.4, and representing contacts
between product components and their contact characteristic is used to draw
conclusions. Alongside the reasoning process, reduced user input is solicited
interactively.
Although the work acknowledges exploring components interactions as a
great indicator to functional and technical properties of the product, the proposed
semi-automatic approach builds on an already meshed model rather
than a CAD model, limiting its use to demonstrative kinematic simulations
as authors suggest. It should also be noted that the purpose in the abovementioned
work is component animation rather than an effective enrichment
of an assembly with functional information.
Dixon & Shah [63] provide an expert system for FR that is both graphand
rule-based. Unlike work presented in Section 2.4.1, emphasis here is
put on assembly feature recognition, as opposed to part feature recognition.
Authors define an assembly feature as ‘an association between two part features
that are on different parts’. The proposed system involves a learningby-example
phase in which a user defines assembly features from existing
assembly models. The user interactively provides rules that tie together geometric
and algebraic parameters of the defined feature. The user-defined46 Chapter 2. Literature Overview
patterns are then used to extract features from an unseen assembly model
where assembly features are to be found. The suggested work uses twist
and wrench matrices [181] to define structural and kinematic properties of
assembly features.
The work is devoted for application such as reverse engineering and reengineering
of legacy spare parts. Although some of the techniques used
inspired our simulation-aware approach, no particular attention has been
paid to FE application in authors’ work.
The developed system accepts assemblies as B-Rep models. However, it
does not account for shape simplifications encountered in industrial DMUs
(see Section 1.5.1 and Section 1.7). This is a direct implication of the fact
that the system only considers contact interaction between parts to generate
assembly features. Nonetheless, observation shows that functional interfacing
can also be represented, in a simplified manner, as volume intersection,
or interference. Finally, this learning-based approach does not refer to
the behavior concept of an assembly or sub-assembly, which could improve
the robustness of this feature-recognition approach and would conform to
the well-established dependency between form-behavior-function (see Section
2.3).
Literature studied in this section proved that if any functional information
is to be learned, this inquiry should start at the components interaction
level. To establish the link between shape and function in the light of the
above-mentioned observations, the input geometric model should first be
analyzed for candidate geometric interactions. The following section looks
at what existing work offers in this regard.
2.5 Geometric analysis to detect interactions
Section 2.3 showed the tight link between shape and function. Function,
however, is an interactive phenomenon, satisfied by the inevitable interaction
of components in a mechanical system [24, 103]. This means that only
shapes in interaction produce functionality. If any functional significance is
to be deduced from shapes, geometric interactions are to be addressed first
to locate their areas, which can influence their function. In this section,
we provide an overview of efforts paid in an attempt to analyze assembly
models to look for geometric information that is relevant to our research.
2.5.1 Geometric interaction detection
Geometric interaction detection often drew the attention of researches from
different domains, particularly robotics and computer graphics because of
its application to collision detection [101, 39, 44, 139].
Lin & Canny [113] provided an efficient technique to determine closest
points between two given 3D objects. The algorithm can make use of anGeometric analysis to detect interactions 47
approximate initialization, when available, to converge faster to an accurate
solution. This gives it an advantage when considering dynamic environments
such as motion planning and robotics, where closest points between pair of
objects can be computed adaptively with respect to time [44]. The local
convergence nature of this algorithm, however, makes it limited to convex
object shapes.
To account for non-convex objects, Quinlan [138] suggested the division
of the object into sub-components, which in turn are convex themselves. The
problem of finding the closest points, thus the minimal distance, between
two non-convex objects reduces to finding closest points between their subcomponents,
then considering the pair with minimum distance. To reduce
the quadratic complexity inherent to this approach, the author suggests
using cheap bounding spheres checks to reduce the number of compared
components.
Works from Agrawala et al. [20] and Mitra et al. [125] have built on
minimal distance detection to efficiently determine geometric interactions
in an assembly, such as contacts and clearances. However, all of the abovementioned
works considered a discrete geometric model of type polyhedral,
a representation that is not commonly used in industrial DMUs (see Section
1.5) and not robust enough to correctly detect unambiguous interactions
between components in complex assemblies. This is exemplified in commercial
CAD software like CATIA V5, where interaction detection is simply
displayed and left to user’s interpretation but cannot be used for further
assembly geometry processing.
This inconvenience was addressed, and tackled in the work of Iacob et
al. [89], where a contact detection algorithm is provided based on analytical
Non-Uniform Rational B-Spline (NURBS) surfaces. Detected contacts between
components in a DMU are then used for assembly/disassembly planing,
and in VR application. Due to its particular application, this method
paid no effort to detect interaction zones. Such a geometric knowledge,
however, is a key element for processing DMU for FEA purposes.
The recent work of Jourdes et al. [95], in the framework of ROMMA
project [1], solves the problem of the detection of precise contact zones in
a highly efficient manner, making use of discretized techniques that exploit
the Graphics Processing Unit (GPU) computational power. Despite its use
of internal discrete models to communicate with the GPU, the proposed
algorithm still inputs, and efficiently produces, analytical NURBS surfaces.
This work, however, did not address interference zones detection.
2.5.2 Importance of a unique geometric representation
In the domain of shape recognition, certain criteria have been identified to
ensure relevant comparisons between shape descriptions. One property of
shape synthesis methods has been outlined that allow shape search and 3D48 Chapter 2. Literature Overview
pattern detection. This is representation uniqueness [122, 126, 90].
Uniqueness implies a one-to-one relationship between a shape and its
descriptor using a given representation [90]. This means that using an appropriate
representation, an object can be geometrically described in only
one way. Two different descriptions mean that the underling objects are geometrically
distinct. Uniqueness in this sense also implies invariance [126],
that is if two object have the same shape, they must have the same geometric
description under their descriptor.
Uniqueness is a mandatory property to enable the judgment of whether
or not two descriptors represent the same shape. Work as early as [122]
shed light on this requirement when retrieval of relevant information out of
a geometric model is considered.
Commercial CAD systems, however, do not account for shape uniqueness.
In fact, a given object, such as a simple cylinder, may be represented
through different ways and different number of faces and edges even when
using the same geometric modeler, as Section 5.2.2 shows. In order to enable
a robust geometric interaction analysis, this inconvenience is to be addressed
first, which is the topic of Section 5.2.2.
Today’s industries regard the DMU as the product knowledge repository.
They expect it to tie the product geometric model with related information,
such as functionality, in a formally structured manner. Works in this direction
join our endeavor to enrich the dmu. with functional knowledge. Similar
efforts are thus summarized in the upcoming section.
2.6 CAD and knowledge representation
CAD systems are meant to provide a PDP with tools that spare the designers
the burden of repetitive tasks, allowing them to concentrate on creativity
and core expertise. They are the evolution of drafting tools, that use evergrowing
computing capacities and interactive techniques.
Design activities are becoming more and more knowledge-greedy. The
availability of relevant information is taking a major part in an efficient PDP.
Designers reportedly spend up to 60% of their production time searching
for the right information [108]. Ullman [171] argues that knowledge reuse is
involved in more than 75% of design activities.
CAD systems are, thus, more and more required to equip designers with
needed engineering knowledge. However, observations show that this knowledge
is still scattered around the DMU in a non-structured manner. Most of
this knowledge comes in a free text format (see Section 1.7), which is neither
reliable nor robust.
Section 2.6.2 studies research that tackled this problem by means of
general knowledge management tools applying paradigms of the Semantic
Web. Section 2.6.3 looks through prior work that utilized an approachCAD and knowledge representation 49
more specific to engineering knowledge. We first make a distinction between
knowledge at the domain of discourse level, and knowledge at the current
instance level in Section 2.6.1.
2.6.1 Domain knowledge and model knowledge
In fact, shortly after CAD systems were introduced and commercialized
they were suggested to provide active feedback to the designer, to enhance
the engineering process with decision support systems, embedded in their
working environment. Those systems made use of engineering knowledge
about both the domain and the particular product under development.
In the context of a PDP, we identify knowledge about the underlying domain,
such as aerospace and automotive industries, or software development,
which we refer to as domain knowledge. Another type of knowledge that can
be distinguished is the knowledge about a particular product or instance of
this product, e.g., car engine, aircraft, or piece of software. We refer to such
knowledge as model knowledge. This distinction is purely pragmatic since it
allows domain knowledge to represent global expertise independently from
any information about a particular case. Model knowledge, however, only
makes sense in the context of domain knowledge.
2.6.2 Ontologies as an assembly knowledge storehouse
The concept of ontologies as it applies to computer science is closely related
to the Semantic Web [35]. The Semantic Web is seen by World Wide
Web Consortium (W3C) as the Web of data, as compared to the Web of
documents that we know. It enable machines to interact and connect to
each other in the same way human beings do through the Web. To this
end, a common machine interpretable language, or vocabulary, should exist.
Ontologies are the Semantic Web vocabulary [5]. At their simplest understanding,
they define concepts and relationships between them in a machine
understandable language.
Because of their established formalism and their ability to intuitively
model the facts we know about a given domain of discourse, ontologies are
widely used as knowledge repositories. For a particular domain, knowledge
is represented as a set of objects, referred to as individuals, that are grouped
in classes that are called concepts. Classes are organized in a hierarchical
manner to reflect the generalization relationships between sets of objects.
Individuals are connected with relationships that are called roles in the context
of ontologies. Individuals, concepts and roles are identified by means of
agreed-upon human readable vocabularies. Gruber [76] describes an ontolgy
as a commitment to these vocabularies between participants to an Artificial
Intelligence (AI) system.
Knowledge captured by an ontology is classified in two categories:50 Chapter 2. Literature Overview
1. The terminological box, or TBox, where general concepts and rules
are expressed. This typically maps to the domain knowledge;
2. The assertional box, or ABox, where information about instances and
their relationships are maintained. The ABox typically maps to the
model knowledge.
It is important to note that while ontologies formally define the common
language necessary for knowledge sharing, they leave the choice open for how
this language is represented and communicated. Gruber [76] distinguishes
three needs to allow knowledge sharing:
• A common representation language format;
• A common agent communication protocol;
• And a common specification of the content of shared knowledge.
An ontology fulfills the last requirement, while the first two items are
considered to be implementation details rather than conceptualization problems.
The use of an ontology in the Semantic Web compares to the use of a
given language, e.g., English, French, or Arabic, in the Web where vocabulary
and their semantics are well defined and understood by people speaking
the language.
A variety of solutions already exist to represent ontologies in a common
format. Names include Resource Description Framework Scheme (RDF-S),
Ontology Interchange Language (OIL) and Web Ontology Language (OWL)
family [14] including variants like OWL Lite, OWL DL and OWL Full. This
compares to the use of HTML in the Web to represent documents. Protocols
do also exist to allow exchange of facts and queries using ontologies,
examples are SPARQL Protocol and RDF Query Language (SPARQL), DL
Implementation Group (DIG) [15] and Simple Semantic Web Architecture
and Protocol (SSWAP). This compares to the use of HTTP to communicate
requests and responses on the Web.
Ontologies are often used in different engineering disciplines to capture
knowledge. Liang & Paredis [112] provide a port ontology as an unambiguous
semantic structure that combines form, function and behavior as design
information characterizing subsystems interactions in a given mechatronic
product. This ontology, however, makes no connection between these three
design aspects. In Rahmani & Thompson [142], the authors build upon
the previous work and show how to represent functional interfaces between
product subsystems in machine-interpretable manner using a three-layered
ontology (two layers for domain knowledge and one layer of model knowledge).
They also provide necessary means to verify functional compatibility
between system components through their functional interfaces, therebyCAD and knowledge representation 51
called ports. In fact, this work is general and applies to different disciplines
beside mechanical engineering.
These two works join and extend a heritage of literature in an effort
to aid the design process in providing relevant information in a globally
understood basis.
Kitamura & Mizoguchi [104] suggest a semantic framework to enable
conceptual engineering knowledge sharing about functionality. This framework
is implemented in terms of layered ontologies where concepts of each
layer builds upon those of the layer above. To guarantee the generality and
wide coverage of their approach, the authors emphasize the distinction between
what a function is and the way it is achieved. This is reflected in a
distinctive conceptualization in two separate layers; functional concept ontology
and functional way knowledge, respectively. For example, ‘welding’ is
more than a function, under the proposed framework, as it implies ‘fusion’
as a way of satisfying the function ‘unification’. This function, however, can
be satisfied by other means such as ‘fastening’. Authors promote their ontological
framework as an agreement about a common vocabulary to allow
designers and engineers to share knowledge.
In the continuity of their work [103] presented in Section 2.3.3, Kim
et al. [102] developed the AsD ontology to capture design intentions in a
heterogeneous collaborative assembly design environment. Authors do not
only use advances in the domain of knowledge representation to formally
represent ARM presented in [103] using ontologies, they also use inferences
to obtain new facts that are not implicitly available in the initial model.
Inferred facts, however, dwelt in the domain of consistency checks, joins
types, and relative DoF. Figure 2.5 shows an overall structure of the proposed
system and its connections to other modules to deliver assistance to
engineers during the assembly design process. This figure shows how an
inference engine is used to extract implicit knowledge, then assistance is
provided mainly through querying, using a semantic search engine.
All the previously cited approaches share a common perspective since
they address the design assistance in a top-down manner where functional
information has to be related to 3D component models or to their interfaces
by an engineer. Consequently, this information may be incomplete if an
engineer fails to perform some connections during the design process. Few
authors have taken advantage of inference mechanisms to automate the connections
or check the consistency of the overall design data. Indeed, setting
up connections between component geometry and functional informations
raises the question of the meaning of this connection. It is essentially a logical
connection between data, e.g., functional ones, and an instance of 3D
component and it is not clear whether this connection should target a subset
of the component and what should be the appropriate geometric entities. If
a designer had to query this functional model to highlight a geometric area
over the boundaries of components, these approaches cannot process such52 Chapter 2. Literature Overview
Figure 2.5: Assembly design information sharing framework as proposed by
Kim et al. [102].
query, showing that the proposed connections are not adequate to process 3D
components for FEA preparation. Combining this observation with the topdown
feature of these approaches we infer that processing a DMU containing
essentially geometric models of components (see Section 1.6 and Section 1.7)
in a bottom-up manner, cannot be automated with these approaches because
the connections between geometric and functional informations are missing.
Barbau et al. [32] cover a large spectrum of product description with
an ontology, referred to as OntoSTEP, incorporating both geometry and
structure of a DMU as available through STEP APs [8, 12], the Core
Product Model (CPM) introduced in [67] and the Open Assembly Model
(OAM) introduced in [34]. A tool was developed to translate an EXPRESS
scheme [13], the scheme that governs STEP files syntax, into an OWL DL
ontology, defining its TBox. A STEP file can then be imported into the
same ontology, using the same tool, to define an ABox. The tool was implemented
in terms of a plug-in to the ontology editor Prot´eg´e [3]. Authors
thus define a mapping between EXPRESS primitives (entities, instances and
attributes) and those of OWL (classes, individuals and properties, respectively)
to enable the import of a TBox. They also implement a syntacticCAD and knowledge representation 53
analyzer that parses the STEP file to create the corresponding ABox of a
given model. The work aims at establishing a semantic layer on top of an
EXPRESS description. Aligning these semantics with functions and design
intents expressed in models such as CPM and OAM allows reasoning and
extraction of implicit knowledge. The authors use Description Logic (DL)
reasoner Pellet [156]. In spite of a relative success, authors showed that not
all EXPRESS language constructs can be expressed using OWL DL. Examples
are functions, entity constraints and attribute calculations that may
require complex algorithms beyond the expressiveness of DL, the logic upon
which OWL DL is built. Authors conclude that not all aspects of STEP
can be rigorously reflected through ontologies alone, leading to limitations
on reasoning power.
These approaches are meant to accompany the design process, and to
lend it the necessary tools for modeling and verification, including means to
represent knowledge about system components interactions as major actors
to such a process. Some of the work analyzed provided means to extract
technical or functional implied intention from an existing model through inferences.
This information, however, did not go further than interface-wise
descriptions of assembly links and kinematic connections. Inferences are
also used to align geometric models to functional ones. However, the latter
were explicitly provided and reasoners were rarely used to merge knowledge
stemming from different models. Even as knowledge capturers, proposed
ontologies fail short to encapsulate functional knowledge thoroughly enough
to the point that satisfies FEA requirements (see Section 1.9) with precise
geometric information about interfaces between components as well as functional
information about these areas.
2.6.3 Knowledge-based engineering approaches
Engineering knowledge is spread out in different places and forms along
a PDP. This includes experts’ minds, worksheets, CAD models, company
codes, databases, flowcharts, implicit and explicit conventions and rules of
thumb, etc. Knowledge Based Engineering (KBE) aims at gathering all such
knowledge in one place, and make it accessible to actors of the PDP at any
stage.
KBE can be seen as a specific type of experts system as applied to
engineering field. They combine geometric modeling, configuration management,
and knowledge management into one rule-based system [115].
Domain knowledge is collected and stored into a knowledge management
module, then rules derived from this knowledge are applied to CAD models
in a parametric-modeling-like manner. This knowledge also governs other
engineering and manufacturing aspects rather than geometry through the
configuration management module.
In this sense, KBE extends traditional CAD systems. DMUs are enriched54 Chapter 2. Literature Overview
with information that is persistent, relevant, meaningful, and reusable. This
knowledge is then analyzed and used to provide the designer with decision
making tools and advisory modules. This is meant to save development time,
and allow a designer to focus on innovative aspects rather than mundane
tasks.
The way knowledge is organized in a KBE system enables also the reusability
of pre-existing components or sub-systems, remarkably reducing
the cost of products modifications or upgrade. This is particularly useful
in industries where the design activity is of an adaptive nature; that is
products are rarely redesigned from scratch, but models are often adapted
to emerging needs. In this case, KBE aims at capturing the design intent
in the model itself, allowing for easier modification and avoiding reverse
engineering efforts to guess what engineers had in mind when the model
was first created [37].
KBE has its roots back in the late 80s [37, 176]. Many successful applications
reaped its fruits in the beginning of the century. Chapman &
Pinfold [48] show one application in the domain of automotive industry, applying
a standard KBE system in a highly dynamic design environment. In
the aerospace industry, La Rocca & van Tooren [145] tell a success story
fitting KBE to multi-disciplinary design to enable automatic generation of
FE analysis models. Emberey et al. show another application of KBE in
the domain of aeronautics [65].
Considering KBE early high potentials, it seems that this approach
didn’t yet meet its expectations, despite numerous success stories. This
led people to rethink the utility of such investment. Others tried to criticize
KBE, studying both failure and success case-studies, and drawing conclusions
about where did the applications of KBE go wrong [176].
One argument about the shortcomings of KBE is the lack of explicit
methodologies. Although such frameworks exist (MOKA [161], KOMPRESSA
[115], KNOMAD [56] and DEE [144]), applications usually don’t commit
themselves to any, and tend to be case-based. Verhagen et al. [176] note that
more than 80% of KBE applications do not fit in a particular framework, nor
do they follow any well-defined methodology. This poor modeling contradicts
with KBE basic assumptions and leads to significant loss of knowledge.
Another problem is the lack of a semantic link between identified formulae,
rules and models on one side, and real-life engineering expertise and
understandings on another. This reduces collected knowledge to mere data
that still miss the context of application. This contextual gap appears at the
level of knowledge collection, as well as knowledge representation. Knowledge
representation models are still unable to capture the link between one
engineering element and its scope of validity. This shortcoming strongly hinder
re-usability, one of major advantages of KBE, making initial overhead
of KBE systems unnecessarily costly.
The lack of quantitative means to assess the ‘success’ of a KBE systemFrom CAD to FEA 55
is another major inconvenience. A KBE implementation should be compared
to its traditional counterpart to truly justify the use of such initially
costly approach. Although some work shows serious comparative studies to
advocate KBE use [65, 55], this doesn’t apply for the majority of related
work [176].
Quantitative measures are also strongly needed to assess the suitability
of KBE to a particular project or application. A primary reason that made
people drift away from investing in KBE is the failure of inadequate applications
that were motivated by early success of such technology. In such
situations, extra-cost was often not justified by the little gain, because of
the nature of the application in hand [37].
Looking more precisely at the reasons that restrict the extensive use
of KBE systems, the connections between technological parameters and
geometric entities is similar to the connections observed in Section 2.6.2.
Consequently, the connections set up are applicable to a fairly small set of
configurations, i.e., when shape modifications are performed the new con-
figurations are no longer compatible with the technological parameters they
are connected to. This happens because these connections address geometric
areas of 3D components that are not precisely reflecting the meaning of
their associated technological parameters.
The need of robust connections between geometric elements, down to the
level of geometric interaction zones, and functional knowledge in terms of
agreed-upon semantics is emphasized when considering application such as
FEA. The following section walks through recent approaches in this domain.
2.7 From CAD to FEA
Section 1.9 introduced the finite element method, and how it contributes
to the whole PDP. In this section we analyze efforts paid to automate or
semi-automate the generation of the FEM.
2.7.1 Pre-processing at the core of the FEM
Haghighi & Kang [79] describe pre-processing as the most time-consuming
and expertise-intensive task in the behavioral simulation process. They also
argue that expertise and knowledge invested at this stage have a direct implication
on the accuracy of analysis results. The error-prone and resourceintensive
nature of this task often makes it the bottle-neck in the PDP. Jones
et al. [92] attribute the high cost of preprocessing to the many non-trivial
subtasks it involves, such as geometry processing, mesh quality control, and
the assignment of physical properties to mesh elements.56 Chapter 2. Literature Overview
2.7.2 Direct geometric approaches
As pointed out by Thakur et al. [166], most of prior work related to the
geometric transformations applied to components to generate a FE model
from a B-Rep CAD model, are purely geometric transformations, i.e., the
component shape is modified using criteria of morphological type. In Makem
et al. [117], a component is subjected to a segmentation process into manifold
models to enable the generation of a semi-structured mesh is proposed.
The hybrid mesh of structured and unstructured zones allows for efficient
anisotropic structural simulations. Few contributions take into account FE
sizes to modulate the geometric transformations applied [109]. Quadros et
al. [137] use de-featuring techniques to reduce model complexity. They therefore
generate an intermediate discrete model, keeping backward links to the
original CAD model to allow information flow such as boundary condition
attributes.
In the present context, the focus is placed on assemblies as a representation
of a DMU. There, few research works have addressed the FEA
preparation of assemblies. Specific operators have been provided to compute
contact zones between components. These operators fall into two categories
depending on whether the geometric model used to describe the components
is an analytical B-Rep model or a discretized mesh.
In case of B-Rep CAD models, Clark et al. [52] have developed a specific
operator to compute the imprint of a component onto another one and use
the corresponding imprint to subdivide the boundary of each component
so that they share a common geometric area that reflects the contact area
between the components. As a result, this common area can be used to
generate conformal FE meshes in this area, which greatly improves the FE
mesh generation process of an assembly model. In case of meshed or faceted
CAD models, several approaches have been proposed [50, 114] to compute
the common areas between components representing their contact areas and
to process FE meshes generated on a component basis so that their common
area can be identified and their FE meshes in that region can be modified to
produce a conformal mesh. Obviously, these approaches are of great interest
to process assembly models for FEA. However, those referring to a faceted
model are not robust since the operators are rather sensitive to discretized
representation they use as input. More precisely, it becomes difficult to make
a distinction between a discretized representation of two cylinders in contact
with each other along a cylindrical surface and a discretized representation
of two interfering cylinders as it can happen in a DMU with screws and nuts.
For this reason, this approach is not suited in the present context. Regarding
Clark’s approach, it has been addressed using Boolean type operators inside
a specific CAD software and it is restricted to contact configurations. As
a result, it is not generic compared to Jourdes’s [95] approach that uses a
STEP file as input and projection-type operators that can adapt to accuracyConclusions 57
of relative position of each component.
All these approaches, however, did not show any connection to the functional
attributes of a geometric interaction between components, leaving an
open question of how adequate those adaptations are with respect to a given
simulation process under prescribed simulation objectives. In the context of
the ROMMA [1] project, work has focused on assembly processing for FEA
and has highlighted the need to specifically process the interfaces between
components since they are directly related to the simulation objectives.
Work studied in the context of CAD-to-FEA transformations showed
that assembly models are rarely considered as a whole, instead, components
models are processed and transferred between the two domains individually.
Methods that accounted for interaction between components are also
uncommon in the literature, and those who did, only considered geometric
contacts as functional interaction indicators, leaving prevailing industrial
conventions, such as volumetric interferences, uninterpreted. This is a natural
consequence of the shortage we pointed out in Section 2.4. This shortage
reflects the need for a concrete approach that translates product geometry
to simulation-relevant functional properties, while taking into account
mainstream industrial practices, and the integrity of an assembly model.
2.8 Conclusions
In this chapter, concepts such as functionality and the relationship between
function, behavior and form are considered from literature standpoint.
These three concepts are inter-related, which means that adding functional
information to a purely geometric model of a system should refer, somehow,
to the behavior of this system. In addition to these three concepts, the
concept of state, though not mentioned in the relationships between function,
behavior and form, can be related to function. In later chapters, these
concepts will be revisited, extended, or narrowed down to a more specific
context or definition.
Examining work that compares to ours, in terms of problem tackled,
showed that though it is possible to recognize some basic manufacturing
features by merely considering local geometric properties of components,
the detection of more complicated functional properties, such as these required
for simulation preprocessing, requires that the geometric model be
regarded from a wider angle, that also covers the interaction between different
components. In addition, the feature recognition approaches essentially
concentrate on standalone components which prevent them from addressing
functional issues since their interfaces with other components are not taken
into account.
Knowledge repositories and reasoning methods used in the context of
a DMU are also examined, to determine that, although ontologies showed58 Chapter 2. Literature Overview
Non-conformal mesh
(a)
Contact imprint mesh
(b)
Conformal mesh
(c)
Figure 2.6: A demonstration of the work of Clark et al. [52]. (a) A nonconformal
mesh of an assembly of two components. (b) Components imprint
onto the each other represents the contact zone, a shared mesh is generated
at this region. (c) A conformal mesh of the same assembly, where the mesh
of the rest of each volume is generated after the mesh of the shared surface
(the imprint).Conclusions 59
promising abilities to faithfully represent engineering knowledge, and to reason
upon it to a certain extent, they are still inadequate for the type of
reasoning that requires heavy calculations or complex algorithms, as it is
the case in 3D geometry processing. This is a strong requirement to be able
to process complex industrial assemblies.
In spite of its potentials, little efforts have been paid to exploit the
Semantic Web reasoning capabilities to extract new functional knowledge
from merely geometric one to the level where the former can be used in
the preparation of a model for FEA purposes. Alternatively, the use of
engineering-specific approaches such as KBE enables flexible adaption to
reasoning needs. However, such approaches still miss the semantic connection
to design rationale, and come at a yet unjustified high cost with a
very limited capability to adapt to product variants and even more to an
acceptable range of products. At the origin of this limitation stands the
structure of the geometric model supporting the KBE application and how
it is connected to knowledge representation.
Attempts to automate the preprocessing of a FEA showed that only few
works made the necessary connection to the functional properties of components
and their interfaces. These approaches are still needed for automated
function enrichment of DMUs and must produce an accurate geometric representation
of the interface areas between components to be useful for FEA
preparation.Chapter 3
From Geometry to
Functional Semantics: Needs
and Objectives
This chapter sets the objectives of our work, shedding the light on
the prominence of functional knowledge, and on the importance of
its inference at different levels of the DMU structure, while minimizing
user’s interactions. We also show the applications and implications
such an inference have on the acceleration and enhancement
of a PDP, particularly in the context of FEA preparation.
This chapter is organized as follows: Section 3.1 presents the
need for automatic and intelligent preparation tools to adapt DMU
data to FE simulations, Section 3.2 shows that geometric assumptions
are made about the DMU, reflecting a variety of industrial
conventions. These conventions are to be taken into account if the
shape of a DMU is to be interpreted for FE simulation applications.
In Section 3.3, efficient methods for timely preparations of simulation
models are shown to require an enrichment of the DMU content
to incorporate critical functional knowledge, while preserving
connections between functional and geometric entities. Section 3.4
enumerate three different levels at which this functional enrichment
of a DMU content must take place, namely, the component interface
level, the component level, and the group of components level.
3.1 Taking 3D models beyond manufacturing purposes
With the development of 3D modeling techniques, industrial blueprints,
their 2D counterparts, have become less prevalent across the production62 Chapter 3. Functional Semantics: Needs and Objectives
process. This technical leap enabled the utilization of a reference model,
now referred to as a DMU, at different stages of a PDP, especially as an
entry point to simulation processes (see Section 1.4.2). However, this advent
also came at a cost: technological and functional information are scattered
around the DMU in a disorganized manner (see Section 1.7), the abstraction
of assembly geometry stopped being standardized (see Section 1.5.1)
and thus, became unreliable, unlike the way it used to be with 2D technical
drawings.
This technological and functional knowledge remains a core requirement
for the use of a DMU in product development tasks such as finite element
analyses and simulations [42]. Huge manual efforts are being paid by engineers
on daily basis to reconstitute such information [108].
Geometric modelers, as part of CAD software products, provide tools for
intuitive authoring and manipulation of DMUs. These substantial advantages
over two-dimensional drawings provoked a tremendous change in the
field of geometric modeling. As a result, traditional blueprints gave way to
3D models in today’s design offices. In this section, we outline the potential
that a DMU has to actively participate to the leverage of the PDP.
As a central component to a PDP, its DMUs allows engineers to design
components shapes and position them before the product is actually
manufactured and put to operation. Section 1.4 explains the focal role the
DMU plays in a PDP with the increasing tendency in today’s industries to
relate different tasks to the DMU content, all along the PDP. Reciprocally,
there is also a tendency to adapt the DMU content to the PDP requirements.
A DMU shows its capacity to contain further information rather
than pure geometry. Examples are component materials and their properties,
kinematic connections between components, geometric constraints and
functional zones to name only few (see Section 1.7).
Considering this viewpoint, a DMU can do better than barely providing
references for manufacturing, since it is, indeed, communicated all across a
PDP. One can expect DMUs to serve as entry points for simulation purposes,
e.g., allowing the generation of digital product prototypes. It would
be convenient if the same model, i.e. the DMU, could be enriched with necessary
knowledge for subsequent stages of the PDP, that would definitely
accelerate preparation processes, e.g. FEA ones and others [64].
Nonetheless, DMUs, the way they are designed, are subjected to manufacturing
requirements. This is mainly because designers oftentimes have
this consideration in mind while they’re also bounded by the solid modeler
capabilities when creating 3D models [102]. For this reason, the DMU is
not promptly ready to play its polymorphic role in the PDP, in a reference
to this concept set at Section 1.10. In fact, to process a DMU for FEA,
geometric transformations are still required to adapt it to simulation requirements.
Section 2.7.1 pointed out that this high skill demanding task
still poses a problem to the efficiency of a PDP, and that automating it asDifferences between digital and real shapes 63
much as possible gets in the way of timely simulations.
Most of today’s vendors ship their industrial CAD systems with modules
such as kinematics simulation, FE simulation for structural, thermal,
and flow analyses. These modules provide tools for additional tasks of a
PDP rather than mere geometric modeling during the design process. However,
the lack of automated and intelligent adaptation methods hinders the
utilization of these FE analysis modules.
Some sort of intelligence is thus required in order to adapt a DMU for
development phases other than manufacturing along a PDP. Section 2.7
however, showed the shortage in the state of the art of an robust approach
that functionally interprets the geometry of a DMU as an assembly of interacting
components, down to the level of interacting surfaces, while taking
into account dominant industrial conventional representation of such interactions
(see Sections 1.5.1 and 1.7). Such an approach would faithfully
bridge the gap between CAD offerings and FEA needs.
A major objective of the proposed approach stands in exploiting the
DMU content for simulation purposes. This content must be processed in a
bottom-up manner since a DMU content reduces to robust information only
for mere geometric models of components. Section 2.6 has shown that topdown
approaches don’t bring a tight connection between 3D models and the
technological, functional data associated to components and assemblies, and
they have not emerged in commercial CAD systems. More precisely, this
objective addresses the generation of a simulation model (as introduced in
Section 1.9.2) that is suitable for timely and accurate FEA under prescribed
simulation objectives.
3.2 Differences between digital and real shapes
The geometric model of each component in a DMU is meant to provide a
precise product model to enable its manufacture, as mentioned earlier in
Section 1.4. Inaccurate digital models are therefore little tolerated, as such
inaccuracy puts the manufacturing process at stake. However, particular
geometric configurations, e.g. helical threads and involute gear profile, are
not used as input of manufacturing processes. Also, modeling such surfaces
and volumes as carbon copies of real shapes is a tedious and inefficient task
that is of little or no interest to the PDP. In fact, the geometric accuracy of
such features has no impact on the manufacturing process of the components
due to at least one of the following reasons:
• Components such as threaded bolts, nuts, and profiled gears are often
imported as third-party components [4] that comply to specific
standards1;
1Naturally, precise detailed geometry of complex surfaces such as threads and gear teeth
on molded plastic components may be however important when manufactured in-house.64 Chapter 3. Functional Semantics: Needs and Objectives
(a) (b)
Figure 3.1: Two engaged spur gears: (a) representation of real surfaces,
showing involute profiles, and a simple contact between two gears; (b) simplified
representation as simple cylinders, leading to an unrealistic interference.
• The machining of profiled gears, threads, spline profile, etc. can be a
generative process that is prescribed by tooling parameters set later in
a PDP than the design stage. Consequently, at design and simulation
stages in a PDP, these shapes need not be accurate.
Other examples can be easily observed in industrial DMUs since these differences
between digital and real shapes is current practice.
Consequently, and for the sake of efficiency, complicated surfaces that are
part of imported components, or that comply to predefined implicit or explicit
standards are often simplified. For instance, threads and gear profiles
are modeled as simple cylindric surfaces as shows Figure 3.1. This simpli-
fies the geometric modeling task, while preserving technical informations for
manufacturing.
Those simplifications, however, imply an interpretation from the engineers.
For instance, both a brake disc and a gear may be represented as a
simple cylinder after geometric simplification. Hence, the mechanical component
has to be studied in its environment to clarify its nature, i.e., the
component must be analyzed along with its interaction with neighboring
components (see Figure 3.1). It is also worth observing that, as a consequence
of these simplifications, the geometric interactions between neighboring
digital components is not limited to contacts or clearances, as it is
the case between real components. Indeed, digital models of components
may exhibit volume interference (see Figure 3.1) while still conventionally
representing a consistent configuration of their real counterpart.
In addition to geometric simplifications, another inconvenience about
geometric models of a DMU is the way geometric interactions are handled.
We have seen in Section 1.6.2 that geometric constraints such as contact and
coaxiality may be deliberately dropped and replaced by absolute positioning,Enabling semi-automatic pre-processing 65
for the sake of conciseness or re-usability. Even when positioning constraints
are kept, they are still incomplete to infer geometric interactions between
components, as previously established in Section 1.6.2. For instance, the
simple fact that two cylindric surfaces are coaxial does not necessarily mean
that corresponding faces are in contact, at play, or having an interference.
These shape differences and representation shortcomings render the judgment
about functional intentions of elements of a DMU a non-trivial task,
even to a knowledgeable eye. This implies the incorporation of different
industrial conventions into the knowledge base of an expert system, if any
meaningful functional information is to be extracted. It is a second objective
of the proposed approach to structure the knowledge related to component
and assembly representation so that it can be processed reliably and effectively
connected with 3D shapes of components and assemblies.
3.3 Enabling semi-automatic pre-processing
To speed up a PDP, aeronautical, automotive and other industries face
increasing needs in setting up timely FE simulations of large sub-structures
of their products. The challenge is not only to study standalone components
but also to simulate the structural behavior of large assemblies containing up
to thousands of components [1, 41]. DMUs are widely used during a PDP as
the virtual geometric product model (see Section 1.4.2). This model contains
a detailed 3D representation of the whole product structure available for
simulation purposes. To prepare large sub-structure models for simulation
(such as wings or aircraft fuselage structures); the DMU offers a complete
geometric model as an input (even though not necessarily a faithful one, as
seen in Section 3.2). However, speeding up the simulation model generation
(see Figure 1.19) strongly relies on reducing the time required to perform the
geometric transformations needed to adapt the DMU to FE requirements in
the context of the pre-processing step discussed in Section 1.9.2.
3.3.1 Pre-processing tasks
Currently, due to the need of geometric transformations required to adapt
the shape of a DMU to simulation objectives (see Section 1.9), the corresponding
adaption of CAD models to generate FE models still requires time
and specific skills because there is a lack of automation of these transformations.
The time required to generate FE models often prevents engineers
from using structural analyses during early stages of a PDP. Several authors
proposed approaches to automate shape transformations required for
a standalone component (see Section 2.7). However, very few research work
addresses assembly models where similar configurations are duplicated many
times, e.g., contact areas, bolted assembly joint FE models. Consequently,66 Chapter 3. Functional Semantics: Needs and Objectives
Figure 3.2: Examples of aeronautical DMUs with a variety of bolted junctions
[42].
DMU of aeronautical structures are particularly complex to transform due
to their large number of joints incorporating bolts or rivets (see Figure 3.2).
Domain decomposition and shape transformations mentioned in Section
1.9.2 are examples of interactive and error-prone processes that an
engineer must perform tediously to enable efficient FE simulations. Within
the available resources and time frames planned in an industrial PDP, engineers
are bounded to simulate small models rather than complete assembly
structures. It is an objective of the proposed approach to contribute to
speed up and automate the shape transformations of assembly models for
FE simulations.
3.3.2 Pre-processing automation requirements
It can be observed that repetitive tasks originate from similar configurations
like bolted junctions and, more generally, interfaces between components.
Similar tasks relate to shape similarities as well as behavioral similarities
since the shape transformations performed fit into the same simulations objectives
for a given FE simulation model. As pointed out in Section 2.3,
shape, behavior and function are independent concepts and shape and behavior
similarities can refer to function similarity, i.e., similar shapes behaving
similarly and contribute to similar functions. Indeed, it is the case when
referring to bolted junctions where the underlying function is the ‘assembly
of components using bolts’. This analysis shows that functions are good candidates
to complement shapes when they have associated interfaces, whereas
feature recognition, purely based on component geometry, do not enable a
direct connection to component function (see Section 2.4).
Here, the targeted FEA preparation aims at producing a quantitative
behavioral analysis of an assembly, e.g., the computation of stress, strain,
and displacement fields. Therefore, there is no such behavioral informationBridging the gap with functional knowledge 67
available to combine with shape information that can help derive functional
information about components in addition to their shape. However, if there
is no quantitative behavioral information available for components, it is possible
to refer to the design rationale where design solutions emerge from a
qualitative assessment of components at the early design stages. Similarly,
qualitative behavior assessment is common engineers’ practice when analyzing
a mechanism from either blueprints or DMUs.
To this end, the above-mentioned principle is a path to another major
objective of the proposed approach to automate FEA preparation processes.
Indications about components functions, functional groups, and functional
interactions can be gained from assembly geometry processing and behavioral
information. These indications must be coupled with the product geometry,
not only at the component and group of components level, but also
at the joints interface level, particularly in connection with functional interactions.
This may imply a functional restructuring of components geometry
to highlight interaction zones. The following section sheds more light on this
issue.
3.4 Bridging the gap with functional knowledge
Despite attempts of geometric modelers vendors, as well as efforts paid by
data exchange standardization committees, industrial practices in the field
of knowledge representation and communication are still far from being standardized,
as shown in Sections 1.7 and 2.6.
3D modelers still fall short of providing a unified method to maintain
technical and functional properties alongside geometric models of components
and assemblies. Figure 1.2 shows precise technical annotations of
dimensioning and tolerancing which are standardized for a shaft-housing
connection (see Appendix A). Nevertheless, in a platform-independent 3D
representation of a product, such as a STEP file [7], this knowledge is lost as
both shaft and housing are represented with their nominal diameter, with
no further information about dimensional tolerances. Figure 3.3 depicts an
example of a 3D model showing a piston fit in a cylinder sleeve. This fit
should be loose in order for the crank-piston mechanism to work properly.
However, both parts of the fit are represented with the same nominal diameter,
leaving the fit nature ambiguous.
Even when standards provide auxiliary annotations that may actually
hold functional information (as Section 1.7 showed), observations reveal that
current CAD modelers do not make use of these facilities, stripping their
native models of all information but mere geometry when exporting them
in a standardized format [69].
From this perspective, it seems that the evolution from blueprints to 3D
digital models and the facilities that 3D modelers offer have come at the cost68 Chapter 3. Functional Semantics: Needs and Objectives
Figure 3.3: A 3D geometric model of a crank/piston mechanism. The piston
and its cylindric sleeve are represented with the same nominal diameter of
60mm.
of the loss of reliability of any other information rather than approximate
geometry. The bound between form, behavior and function that was seen
in Section 2.3, is not available in modern DMUs.
Another observation to be outlined in this context is the lack of the
thoroughness of these functional and technological annotations in 3D models,
even when they do exist as Sections 1.6.2 and 2.6.2 showed. Many
applications, in particular structural simulations, require the association of
functional information down to the level of geometric interaction zones, e.g.,
contact surfaces between components. Those information are still not available
in a DMU in a satisfactory manner that allows their involvement in
the FEA preparation process, or any other application that would fit into a
PDP and use assembly models.
Although DMU representations leave room for unconstrained textual
annotations, that designer may utilize at different geometric levels, i.e., surfaces,
solids, etc., to augment the model with functional and technological
information, these annotations are too loose to provide any viable knowledge,
as shown in Section 1.7. In fact, the best that we can expect from these
annotations is to be coherent enterprise-wise. Reaching this cohesion however,
requires engineers time and energy that compare to those needed for
the manual pre-processing tasks outlined in Section 3.3.1. Method dependent
on such a cohesion [32, 148] have therefore failed to provide a reliable
connection to functional properties down to the level of component boundaries.
In the proposed approach, its purpose is to minimize the human inter-Bridging the gap with functional knowledge 69
vention during the FEA pre-processing stage, integrating domain knowledge
in an inference system that enriches a pure geometric model with technological
and functional information necessary for its adaption under the
user-specified simulation objectives. This work contributes to a collaborative
effort in the framework of the ROMMA project [1] to reduce the FEM
preparation time to adapt CAD assembly models derived from DMUs into
FE models.
In order to enable the semantic enrichment of a DMU that is required by
state of the art FEA preparation approaches, the broken function-behaviorshape
link should be mended. This recovery happens at three levels, as
follows.
The functional interface level
Function is a result of interactions between components at their interface
level. FEA applications need to know what functions are fulfilled
by a component with regard to its neighboring components, in order
to represent these functional interactions geometrically in a simpli-
fied manner, and decide what hypotheses can be made in the light of
simulation objectives.
A mature approach to functionally supplement the DMU for FEA
applications should thus consider the labeling of functional interfaces
between components in an assembly. This leverage also requires the
isolation of these interfaces as geometrically independent entities, to
allow clearly interpretable labeling. Such labeling will be preformed
on the basis of reference configurations between components referred
to as ‘conventional interfaces’. Conventional interfaces and functional
interfaces are introduced in more details in Chapter 4 to produce a
taxonomy of functional interfaces as an explicit basis from which reasoning
mechanisms will take place. To efficiently support the FEA
preparation process, these interfaces need to located accurately over
the boundary of DMU components. This objective is addressed in
Chapter 5.
The functional unit level
Each component in an assembly plays one major well-defined functional
role within its functional group or groups. Before enabling geometric
simplifications, this role should be outlined as it orients the
content of suggested transformations.
To this end, a fruitful method must classify components into functional
classes that deterministically define their functional role. Such
classes, referred to as functional designations are introduced in more
details in Section 4.2.3 and are based on particular spatial setup of
functional interfaces. Indeed, functional designations are the major70 Chapter 3. Functional Semantics: Needs and Objectives
result of the proposed approach. Enriching a component with functional
designations from functional interfaces needs a reference to the
behavior of this component (see Section 3.3.2). Indeed, this objective
is addressed using a qualitative reasoning process as described in
Chapter 6 that is followed by a rule-based reasoning (see Chapter 7)
to infer the functional designation of this component. The purpose of
these qualitative analyses and rule-based reasoning is to resolve the
multiple interpretations that derive from the DMU input as pure geometric
model. Through this approach, the objective is to set up a
more generic approach than KBE ones (see Section 2.6.3) that takes
advantage of the functional interface level to tightly link 3D geometry
information to functional one.
The functional group level
In an assembly, a function is satisfied through physical interactions
between a set of its components. Consequently, we can refer to these
functions as internal functions. On a complementary basis, this assembly
is characterized by functions with respect to its environment,
i.e., these functions are often referred to as primary, secondary and
constraint functions. Here, the functions referring to the environment
of the assembly fall out of the scope of the present approach.
Efficient methods of geometric preparation for simulation purposes use
such groups of components as patterns that indicate an entry point
to relate geometry to functionality. As an example, Section 3.3.1 has
referred to bolted junctions that designate a group of components that
contain a screw, a nut and some tightened components, at least (see
Figure 3.2). Processing such subsets of an assembly in an efficient
manner connects with functional information when a selection process
matters. Indeed, the first step to prepare a bolted junction for FEA
is the selection of the corresponding components.
Accordingly, a beneficial enrichment of a DMU can organize components
into functional groups that perform a given function. Those
groups can then be labeled by the type of function they deliver. Labeled
functional groups, referred to as functional clusters are an outcome
of the proposed approach and can efficiently contribute to the
desired component selection process as needed for FEA preparation.
This objective is addressed in Chapter 8 and illustrated through a
template-based selection process.
Figure 3.4 shows how functional annotations apply at the three aforementioned
levels on the DMU of a centrifugal pump.Bridging the gap with functional knowledge 71
Geometry
Functionality
Components'
Groups
Components
Components'
Interfaces
Assembly
DMU
Coupling
Internal Forces
generation
propagation
Nut
Stud
Planar Support
Threaded Link
Figure 3.4: A synthetic, bottom-up approach to collect functional informations
of a product at different levels, based on its geometric representation
provided by its DMU.72 Chapter 3. Functional Semantics: Needs and Objectives
3.5 Conclusion
In this chapter we showed that, in spite of its potentials, the DMU content
as it is represented in today’s industrial examples is not yet ready to enable
its active participation to the preparation process of FEA. On one side, this
is because of the shape differences between the real product and its digital
representation, shown in Section 3.2. On the other side, another obstacle
to the DMU utilization in simulation purposes is the semantic gap, shown
in Sections 3.3 and 3.4, that prevents 3D component geometry from being
connected to functional an technological annotations required for any robust
and efficient geometric transformation.
Section 3.4 showed that those gaps should be bridged at three levels,
namely the functional group, the functional unit, and the functional interface
levels to allow the DMU to play its polymorphic role in the PDP as discussed
in Section 1.10. The same section also showed that this task is currently
being done manually, in a tedious and time-consuming manner. Therefore,
this has introduced the major objective of the proposed approach toward
the automation of tasks during DMU preparation for FEA.
Section 2.7 showed that current efforts in the field are still unable to
feed the functional enrichment required by geometric transformation methods
while taking into account today’s industrial practices and conventions.
Providing a method to automatically fill this need is one of the more precise
objectives set throughout this chapter.
While this chapter has outlined the problems and set the objectives
of the proposed approach, the following one presents starts presenting the
proposed contribution and conceptualize our approach.Chapter 4
Functional Restructuring
and Annotation of
Components Geometry
The proposed approach builds upon the relationship between function,
behavior and shape shown in Section 2.3 in order to extract
functional information from pure geometry of components for FEM
preparation purposes as shown in Section 3.4. Reference states and
design rules are introduced to express the behavior of components
through a qualitative reasoning process and to complement the assembly
geometric model used as input (see Section 3.3.2). These
facts and rules reflect the domain knowledge, and enable to check
the validity of certain hypotheses that must hold true at a specific
state of the product, such as operational, stand-by or relaxed
states.
Shortly, this bottom-up process starts with the generation of
a graph of interfaces between components. Interfaces are initially
defined geometrically. They are then populated with physical behavioral
properties suggested by the geometry, producing a number
of possible interpretations. The validation against reference states,
reduces this number to ideally one interpretation per interface.
Once components interfaces are identified functionally, domain
knowledge rules are applied to group the semantics of those interfaces
into one functional denomination per component, and to
cluster components into functional groups.
As a first step inside this overall process, the purpose of this
chapter is to define some initial concepts related to component
interfaces, their functional designation and the corresponding taxonomy.
From these concepts, the above outline of the bottom-up
approach to the functional enrichment of DMUs will be detailed74 Chapter 4. Functional Restructuring and Annotation
into an overall schematic description as a guide to the major steps
that will be detailed in Chapters 5, 6, and 7.
4.1 Qualitative bottom-up approach
Section 2.3 has shown that the link between shape, behavior and function has
been well established in the literature [73, 23, 173]. Design methodologies
have been built upon this link to boost assembly design and collaborative
product development [147, 142], while in another application of this relationship,
top-down approaches are suggested to augment DMUs with functional
attributes [146, 103]. These approaches, however, failed to functionally interpret
commonplace geometric conventions with respect to FEA needs (see
Section 2.4.2).
The present work proposes a bottom-up approach that takes the pure geometric
representation of an assembly as an input. Elementary facts about
geometric interactions are first collected. Those facts are then used to induce
higher level knowledge about components and components groups in a
synthetic manner, as Figure 3.4 shows.
Our approach is purely qualitative in a sense that no numerical values
are used across the analysis process apart from the geometric parameters
of the components, which are the input data. Geometric quantities such as
distances are compared to each others, while no assumption about referential
values or thresholds are made. This also applies to physical quantities which
are described only symbolically with no precise values. This makes our
reasoning universal, and independent of the availability of such quantities.
These characteristics clearly distinguish the proposed approach compared
to KBE (see Section 2.6.3) where quantitative parameter bounds are part
of the KBE to perform dimensioning processes.
This inductive method allows for the inference of technological knowledge
about the product at different levels, starting from components functional
interactions, up to their functional groups. As a prerequisite to simulation
preparation tasks, the proposed process is performed after the design
activity, independently of design choices, and as an automated procedure.
In the rest of this chapter, Section 4.2 defines the terminology that is used
in the proposed approach. The goal is to bring precise conceptual frames
that are applied to notions encountered across the rest of this document.
Next, Section 4.3 gives a synthetic description of our method, preparing the
ground for in-depth development in chapters to come.
4.2 Common concepts
Throughout this manuscript we describe the proposed method using a terminology
referring to concepts that are central to this research. Here, weCommon concepts 75
identify reference concepts contributing to all stages of the functional enrichment
process, and define each as it applies to this approach.
4.2.1 Function as the semantics of design
Functionality is an example of non-geometric knowledge that a DMU still
lacks, i.e., functions are essentially stated with natural language expressions.
In fact, this knowledge becomes paramount when considering the preparation
of a DMU for simulation purposes, as seen in Section 3.3. Section 2.2
examined different perspectives from which a function is seen in the literature.
In the context of our work, we join scholars that make clear distinction
between function and behavior, while admittedly demonstrating the strong
relationship that ties them [136, 73]. This perspective stands at a cross-road
between teleological and behavioral viewpoints, as discussed in Section 2.2.
Indeed, distinction between behavior and function is an important point in
our approach since qualitative models of behaviors are set up and attached
to components to infer component function. Consequently, this process
relies on an effective distinction between behavior and function—otherwise
the inference mechanism set up would be pointless—and a tight connection
between them so that the qualitative behaviors can be effectively related to
functions with meaningful inferences.
A function applies at different levels of the product structure. An interaction
between two components delivers precise functionality that adds up
to each component functional contribution. A particular function may be
attributed to a subset of components that forms a group. As an example,
the hydraulic pump illustrated on Figure 3.4 can be assigned a function to
its whole set of components: (1) move of a volume of fluid from the pump
inlet to the pump outlet1. This function is also designated as the primary
function of the product. Considering the group of components featured in
Figure 1.5 that contains the hydraulic casing (orange), the two ball bearings
(dark brown), the two elastic rings (black), this group can be assigned a
function: (2) guide the rotational movement of the shaft (gray). Now, considering
a standalone component (see Figure 3.4 top), the stud (yellow) has
as function: (3) assemble together the hydraulic casing (orange), the pump
housing (gray), the hydraulic flange (brown), and the nut (green).
The function of the product is then satisfied as a result of functional
groups collaboration. A component can be assigned more than one function
and can contribute to several functions through different groups of components,
e.g., the hydraulic casing (orange) is part of two groups of components
defining functions (1) and (2).
1The hydraulic pump is of type centrifugal for incompressible fluid. Therefore, its
function reduces to displacement of a volume of fluid76 Chapter 4. Functional Restructuring and Annotation
Figure 4.1: An example of a spline shaft-housing configuration that satisfies
two functionalities that are axial positioning and power transmistion. A cut
in the housing component is made to show the coupling.
Definition 4.1 (Function). A function is a desired effect that a certain
intentional configuration produces in a determinant manner.
In this sense, the underling configuration is sufficient to produce the effect,
hence, fulfill the function. However, it may or may not be unique, as
some functions can be satisfied by several different means. For example, a
screw-and-nut configuration satisfies the function of tightening a set of components.
However, the same function can also be satisfied by other means,
such as riveting, or even welding [104]. A screw-and-nut configuration is
thus not necessary to tighten components, although it is sufficient.
In the same context, one configuration may fulfill more that one function,
as it may produce more than one desired effect. An example is a spline
shaft-housing configuration that satisfies both axial positioning and power
transmission as functions (see Figure 4.1).
4.2.2 Functional Interface
Today’s products tend to be modular [30]. Modularity has been established
as an important paradigm in almost all design disciplines. Modular systems
can be easily analyzed, tested, repaired2 and upgraded. They also offer
higher customizability as modules can be replaced to adapt to more specific
requirements.
2In the context of mechanical products, repairing refers to the interchangeability of
components.Common concepts 77
An important aspect of modularity is loose coupling [128]. This means
that each module of the product has only minimal knowledge about the other
modules. System parts know about each others as much as necessary to get
the system operational. In order to reach a loose coupling, a single module
provides a minimal interface that interacts (couples) with other modules to
fulfill the product global functionality, while the actual implementation of
each module functionality is kept internal.
The same concept of interfacing appears in different engineering disciplines.
In software engineering modularity consists in logically partitioning
the software into different units at different levels, such as software packages
and classes. Those units provide public interfaces describing what kind of
stimuli they respond to. Communication between units is achieved through
stimuli exchange, while internal implementation of each unit is kept private.
In electronics, coupling coefficient refers to the amount of energy transferred
between integrated circuits, and it is recommended to be the lowest possible
in modular designs.
In mechanical engineering, modularity applies at different levels as well.
Its first clear manifestation occurs at the component level, where a single
component is meant to satisfy a very precise functional description. Another
sign of modularity appears at the functional group level, where components
are grouped to fulfill a higher level functional requirement, even though only
partially with respect to the whole product functionality.
To allow the decomposition of high level functions into simpler ones, as
suggested by modularity, mechanical components interact with each other
through interfaces as well. Interactions can either be internal to a product
or in connection with its environment. In this work we address the
first category of interactions only, and we refer to interfaces that allow this
interaction as functional interfaces (FIs).
A very basic example of a functionality that is fulfilled by FIs —and
is usually kept implicit due to its triviality— is the relative positioning of
components with respect to each others. Component shapes are designed
so that they offer interfaces standing as obstacles to remove some of the
degrees of freedom of some of their neighboring components.
In a real product, FIs are satisfied by functional contacts and plays
(see Figure 4.2 for an example). Functions are defined by the geometric
nature of the interaction between two components, and by their physical
properties [118] (see examples in Section 4.2.5).
Definition 4.2 (Functional Interface). A functional interface (FI) is an
interaction between two neighboring mechanical components that fulfills, or
contributes to the fulfillment of a function.
An FI is characterized by its ability to propagate internal forces, with
respect to the product as a physical system, between components involved78 Chapter 4. Functional Restructuring and Annotation
Operating pitch circles
Functional play
Figure 4.2: A gear train connection as functional interface, showing the
functional play between gear teeth.
in the interface. A property that enables the FIs to meet its expected
functionality from a dynamic standpoint.
When functionality is viewed from a kinematic standpoint, FIs are characterized
by their abilities to restrict relative motion of components involved
in the interface with respect to each others, reducing their respective DoF.
Examples of FIs are: threaded link, spline link, planar support, adherent
conic support, etc.
4.2.3 Functional Designation
Besides loose coupling at the product level, modularity requires tight cohesion
at the module level. That is, individual modules should fulfill one or
more well-defined function each. Loose coupling and tight cohesion happen
in parallel in a highly modular system.
When it applies to mechanical engineering, mechanical components are
considered as modules, and tight cohesion reduces to assigning a number
of precise functions to each component. There is a finite set of functions
that a mechanical component can fulfill, considering an upper bound on the
number of functions per individual component, the number of combinations
is bound as well. However, not all combinations are common, and some,
such as tightening and guidance, are not even possible.
We refer to the comprehensive set of functions that one mechanical component
may satisfy as the functional designation (FD) of this component.
Definition 4.3 (Functional Designation). A functional designation (FD)
is an equivalence class defined by the binary relation ‘has the same set of
functions as’ that is defined on the set of all mechanical components.
Given C the set of all mechanical components, and FC = {f1, f2, . . . fn}
the set of all functions that any given component may satisfy. Let c1 ∈ CCommon concepts 79
and c2 ∈ C be components and FC
1 ∈ FC and FC
2 ∈ FC the sets of functions
that they satisfy, in respective order. We state that c1 has the same set of
functions as c2 if and only if FC
1 is equal to FC
2 :
c1 ≡C
f c2 ⇐⇒ FC
1 = FC
2 . (4.1)
We note that ≡C
f is indeed an equivalence relation, as it is reflexive,
symmetric, and transitive. We call ≡C
f the functional equivalence relation
on C; the set of all mechanical components.
We note that if FC
1 �= FC
2 , it logically follows from Equation 4.1 that
c1 �≡C
f c2. We thus infer that c1 �= c2, since ≡C
f is reflexive.
Since an equivalence relation partitions a set into mutually exclusive
equivalence classes [40], FDs, as equivalence classes of ≡C
f according to Definition
4.3, are indeed mutually exclusive sets.
This means that components having a functional designation FC
1 are
functionally different from components having a functional designation FC
2 .
Indeed, FC
c ⊂ FC is unique for a component c ∈ C and it is the identifier of
its equivalence class. This identifier is expressed as a character string that
uniquely characterizes FC
c and can be one of the following3:
1 An expression that relates to one function among the set of functions
covered by FC
c , e.g., a stop screw. Often, this expression relates to one
major function of the component, its primary function;
2 An expression that uniquely designates FC
c in the common language,
e.g., a stud, and implicitly matches FC
c .
Figure 4.3 shows examples of selected mechanical components and their
respective FDs.
FDs relate to FIs in a way that each set of functions at the component
level (thus an FD) requires a set of functions at the interaction level (thus
at least one FI), i.e. let FC
c be the FD of c, FI
c is the set of FIs belonging
to c and |FI
c| ≥ 1. We refer to this one-to-many relation as the functional
breakdown.
Unlike unreliable textual annotations (see Section 2.6), the concept of
FD allows the qualitative reasoning and inference processes to give a component
a functional identifier that unambiguously define the functionality
of each labeled element. As shown in Section 4.2.6, FDs are organized into
super-classes that contain each others, building a hierarchical functional
classification. However, FDs are mutually exclusive classes at the leaf level,
i.e., a given component can only belong to one FD. This labeling provides assembly
components with a brief, yet precise functional description that can
be, once assigned, exploited though out later stages of a functional analysis.
3The two categories highlighted may behave differently according to the language used,
e.g. a ‘shoulder screw’ fall into category 1 in English whereas it is a ‘axe ´epaul´e’ in French.80 Chapter 4. Functional Restructuring and Annotation
cap-screw set screw stud
shoulder screw nut cap nut
pressure screw flat washer lock washer
ball bearing spur gear conic gear
Figure 4.3: Functional designations exemplified by instance components of
each (courtesy TraceParts [4]). The label under each instance(s) indicates
the identifier used as functional designation for each equivalence class.Common concepts 81
Geometrically speaking, this mapping restructures the geometry of a
component that belongs to a given FD into interaction zones, each defining
a FI, according to the functional breakdown of this component. Figure 4.4
shows an example of the restructuring of a cap-screw. This means that the
functional breakdown is not a mere logical relation between a FD and FIs,
there is also a strong connection with the geometric representation of the
component c, i.e., the B-Rep of the 3D solid model of c must be decomposed
into areas that match each FI of FI
c. This connection efficiently sets up a
consistency between the shape of c, its FIs, and its function with its FD.
This consistency will be further enforced through the qualitative analysis
and inference processes that will refer to the behavior of c, for the first one,
and to the connection between shape, behavior and function, for the second
one (see Chapters 6 and 7).
Also, it should be observed that the concept of FD is generic and not
bounded to any quantitative parameter that may hinder its use for a component
as it can happen for KBE approaches (see Section 2.6.3).
4.2.4 Functional Cluster
As mentioned earlier in Section 4.2.2; modularity can also apply at a higher
level than individual components. A set of components may tie up together
to deliver a coherent function or set of functions, while loosely interfacing
with other components/groups of components through minimal interfaces.
Those groups also form a module each. In the context of our research we
refer to each such group of components as a functional group.
We refer to the set of functional groups that satisfies one or more particular
functions as a functional cluster (FC).
Compared to the concept of FD where this concept can be stated for
a standalone component c without referring precisely to geometric entities,
it is critical to refer to the geometric interfaces between components when
addressing FCs. Effectively, each function is not only characterized symbolically
by its designation, e.g. set screw, but it is also instanciated through
the geometric interfaces it involves between components. Therefore, from
the set FC that symbolically represents all the functions any component can
satisfy, we can derive Fc = {fc
i , fc
j , . . .} the set of functions c performs where
Fc is an instance of FC and fc
i designates the symbolic representation of a
function fi ∈ FC associated with the geometric interfaces needed to describe
fi on c. fc
i is an instance of fi attached to c, an instance of a component
class characterized by its geometric representation and its geometric
interfaces with other components.
Definition 4.4 (Functional Cluster). A functional cluster (FC) is an equivalence
class defined by the binary relation ‘has the same set of functions as’
that is defined on the set of all functional groups, G. A particular instance82 Chapter 4. Functional Restructuring and Annotation
Initial component
FIs involved in an FD
Structured component after matching FIs with an FD
Figure 4.4: A geometrically restructured cap-screw according to its functional
breakdown.Common concepts 83
of this equivalence class is g, a set of components. The set of functions of
FC, Fg, is achieved by more than one component and it is an instance of
functions performed through some interfaces of components of g. At the
difference of a FD that relates to a single component of a DMU, an FC
addresses more than one component and not necessarily all the interfaces of
each component of this FC, which means that a component of this FC can
be involved into other FCs.
Let Cd be the set of components contained in a DMU d, and g ⊆ Cd
be a minimal non-empty set of components that together satisfy a set of
functions Fg. Each function of Fg is associated with one or more interfaces
between components of g. Based on that observation, we refer to g as a
functional group. We observe that:
|g| > 1; (4.2)
g ⊆ Cd ⊂ C. (4.3)
Given G the set of all functional groups and FG = {f1, f2, . . . , fn} the
set of functions that any given functional group may satisfy, FG ⊂ F, where
F designates the set of functions all assemblies can satisfy. Similarly to the
observations mentioned previously about the set of functions associated with
a component through its FD, Fg is the instance of FG for the set g, which
is an instance of a FC. Let ci be any component of g and Fg
ci the set of
functions associated to ci, i.e., Fg
ci ⊆ Fg. It has to be observed that Fg
ci does
not necessarily contains all the functions attached to all the interfaces of ci.
Now, let g1 ∈ G and g2 ∈ G be functional groups and Fg1 and Fg2 the
sets of functions that they satisfy, in respective order. Fg1 is associated with
FG1 ⊆ FG, its symbolic counterpart. Likewise, Fg2 is associated with FG2 .
We state that g1 ‘has the same set of functions as’ g2 if and only if FG
1 equals
FG
2 :
g1 ≡G
f g2 ⇐⇒ Fg1 = Fg2 (4.4)
We note that ≡G
f is indeed an equivalence relation, as it is reflexive,
symmetric, and transitive. We call ≡G
f the functional equivalence relation
on G; the set of all functional groups.
It is worth noticing that while FCs are equivalence classes, thus mutually
exclusive, functional groups are not. Functional groups being reduced to a
set of components ci, cj , . . ., the functions performed by these components
would contain functions attached to several FCs because the set of functions
attached to either of its components may contain functions related to more
than one FC. In fact, functional groups of a given DMU are not equivalence
classes because a component c can belong to two different functional groups,84 Chapter 4. Functional Restructuring and Annotation
(a) (b) (c)
Figure 4.5: Examples of three functional groups belonging to the same FC:
disassemblable joint obtained with obstacles and threaded links: (a) Bolted
joint, (b) Stud joint (c) Screw joint.
g1 and g2. Indeed, if Fg
ci ⊂ Fci , it means that (Fci − Fg
ci ) �= ∅ and this nonempty
set of functions attached to ci can be part of some other FC. This
justifies an FC being identified by a set of functions rather than a set of
components.
The identifier of a FC is expressed as a character string that uniquely
characterizes fg = f�
(g) and is usually an expression that uniquely designates
fg in the common language and may relate one function of fg, e.g.,
a disassemblable joint obtained with obstacles and threaded links, and implicitly
matches fg. Here also, this identifier can be related to the primary
function of the cluster.
To illustrate more precisely this concept, Figure 1.5 shows a set of components:
hydraulic casing (orange), the two ball bearings (dark brown), the
two elastic rings (dark blue), this group is assigned a FC whose identifier
can be stated as: guide the rotational movement of a shaft, which refers
to its primary function. Other illustrations of FCs are found in Figure 4.5
where each group refers to the same category of cluster that can be stated as
disassemblable joint obtained with obstacles and threaded links. Indeed, each
cluster is a variant of a technological solution that can be used to tighten
components together using different categories of connectors, namely a bolt
(Figure 4.5a), a stud (Figure 4.5b), or a screw (Figure 4.5c). In this example
variants originate from the different connectors that belong to different FDs,
respectively (capscrew and nut, stud and nut, capscrew) where each variant
contains a different set of FIs.
Likewise FDs, FCs also relate closely to FIs. For instance, a functionalCommon concepts 85
Figure 4.6: Examples of CIs as in a bolted joint.
group forming a bolted joint (an FC) can be recognized as the set of components
that are involved in an internal load propagation cycle generated
by a threaded link and propagated through FIs of types planar or conical
supports.
FDs in their turn relate to FCs in what we refers to as functional aggregation
where the union of functionalities offered by FDs produces a more
general functionality characterized by the FC.
4.2.5 Conventional Interface
The functionality of an interface is decidedly determined by the geometric
configuration of the interaction, and the physical properties of components
materials, as briefly mentioned in Section 4.2.2. For instance a threaded
part of a screw fulfills its function of tightening thanks to the helical shape
of its groove and the friction along the thread that produces irreversitibility.
The inner tube of a tire does it jobs properly as a result of its toroidal shape
and relatively low material stiffness.
Subsequently, geometric interactions between adjacent components reveal
essential information that guides the identification of functional properties.
Objects interactions in the digital model, however, do not accurately
reflect reality, as previously demonstrated in Section 3.2. In fact, the way
interactions are represented is no more than a convention made by designers,
or prescribed by a company, or a common practice since there is no standard
referring to the 3D representation of components.
We refer to interactions between neighboring components in a DMU as
conventional interfaces (CIs). Physical, and functional properties can be
attached to this concept. However, a CI is initially identified by a geometric
interaction between two components in a DMU. This interaction encapsulates
an interaction zone which can be either a contact, an interference, or
a clearance (see Figure 4.6).
Contact A contact between two components C1 and C2 defines one or more86 Chapter 4. Functional Restructuring and Annotation
shared surfaces or shared curves, without any shared volume (see Figure
4.6). The interaction zone of a contact is defined by this set of
shared surfaces and/or curves, leading to potential non-manifold con-
figurations, i.e. a contact along a surface area connected to a contact
along a line4.
A contact representation is usually realistic in the sense that a contact
in a digital model may reflect the same configuration in the corresponding
real product, where C1 and C2 are, indeed, touching each
other. However, when a clearance between C1 and C2 becomes small
enough in reality, it may conventionally be reduced to a geometric contact
as well. Consequently, a cylindrical contact can be functionally
interpreted either as a loose or a tight fit (see Figure 3.3 for an example).
In some conventions a contact may represent an idealization
of more complex settings, like threaded links or gears and sprocket
connections.
Contacts provide very valuable information to our reasoning, as they
usually help defining locations where resulting interaction forces can be
transmitted. At the same time they work as motion barriers reducing
components DoF.
Interference An interference defines a shared volume between two components
C1 and C3 . Obviously, an interference is a non-realistic representation
in the sense that the two digital shapes of C1 and C3 interfering
in a DMU do not represent overlapping volumes of C1 and C3 in a real
product, as this leads to non-physical configurations. Therefore, interferences
are often the result of local shape simplifications combined
with rather complex settings of component locations. For instance, engaged
spur gears frequently result in cylindrical interference volumes
(see Figure 3.1).
Also, when interferences become small enough, e.g., a shaft diameter
that is slightly greater than its housing diameter to produce a tight fit
between them, it is not represented in the DMU where the two corresponding
components have the same diameter and produce a contact.
Due to their idealized nature, interferences are harder to interpret
than contacts; however, they also provide valuable information about
functional attributes of a CI.
Clearance A clearance occurs when a distance between surfaces of two
components C1 and C2 is less than a defined threshold while staying
greater than zero, i.e. C1 does not touch C2 in the area of the corre-
4Though this configuration is not mechanically meaningful, it can be a geometric con-
figuration appearing in a DMU.Common concepts 87
sponding surfaces. The distance value acting as a threshold between
the two components is a matter of design decision.
The interaction zone of a clearance is the set of surfaces of C1 and C2
for which the minimal distance is less than the threshold while staying
strictly positive.
When this minimal distance conveys a functional intention, the clearance
is said to be a functional play (see Figure 4.2). As a convention,
when a functional play becomes small enough, it can be represented
as a contact in a DMU.
Definition 4.5 (Conventional Interface). A conventional interface (CI) is a
conceptual entity that represents an interaction between two components in
an assembly. It is identified by the geometric interaction of corresponding
components in a DMU, and augmented with other semantics such as physical
and functional properties.
Given I the set of all CIs in a DMU. We define the binary relation
‘forms’ as (∀ c1 ∈ C, i ∈ I) c1�f i if and only if the component c1 forms
the conventional interface i with another component c2 ∈ C. As stated in
the definition of a CI, this interface is defined from two components. If �f
relates one component c1 to a CI, i, this means that another instance of �f
relates c2 to the same CI, i.
We also define the binary relation ‘links’ as �l = �−1
f .
We note that each CI ‘links’ exactly two components. This can be noted:
(∀(i, c) ∈ I × C; ∃(x, y) ∈ C2) x �= y
∧ x�f i ∧ y�f i
∧ c�f i =⇒ (c = x ∨ c = y).
Since FIs are the result of interactions between components, a CI can
be seen as a potential FI, when the interaction it incorporates conveys a
functional meaning. There exists no direct one-to-one mapping between CI
and FI though. For example a cylindric interference can equally represent
a threaded link as well as a spline link. This is due to the simplified nature
of CIs. In both cases, either helical threads or meshed teeth and grooves
configurations are represented as a simple interference. These ambiguities
will be processed with the qualitative behavior to filter out some of them
(see Chapter 6).
Section 5.4.1 shows how to interpret CIs into their functional counterparts,
i.e., their corresponding FIs.
4.2.6 Taxonomies
The concepts previously defined in this chapter define equivalence binary
relations, that is they divide the global sets of functions, components in-88 Chapter 4. Functional Restructuring and Annotation
teractions, components, functional groups, and geometric interactions into
mutually exclusive subsets called classes. Examples are:
• Function defines reversible tightening as a class of the global set of all
functions F.
• FI defines threaded link as a class of the global set of all components
interactions If .
• FD defines cap-screw as a class of the global set of all components C.
• FC defines bolted joint as a class of the global set of all functional
groups G.
• CI defines complete cylindric interference as a class of the global set
of all geometric interactions Ig.
Those classes, however, can be grouped in their turn into more general
ones, i.e., larger mutually exclusive subsets. This grouping is the result of
sharing some less discriminant semantic properties, e.g., functional or geometrical
ones, across multiple primitive equivalent classes. We note that, for
example, reversible tightening is no more that a tightening function which
has a more specific property of being reversible. Thus, reversible tightening
and irreversible tightening can be grouped in a more general function class
called tightening. As a complement, disassemblable joint obtained with obstacles
and threaded links is a more specific class that is indirectly related
to the reversible tightening class. In the same spirit, complete cylindric interference
and partial cylindric interference are grouped in a more general
geometric interaction class called cylindric interference.
This leads to the structuring of each concept in a hierarchical structure
that reflects this generalization relation. We call each of these hierarchies a
taxonomy.
Definition 4.6 (Taxonomy). A taxonomy is a tree-like structure for which
the root is the concept domain of discourse, and the leaves are equivalence
classes that the concept defines. At each node, the children of the node are
mutually exclusive sets.
A concept domain of discourse is the global set that the concept covers.
That is F for function, If for FI, C for FD, 2C for FC, and Ig for CI.
Organizing FD in a hierarchical structure allows the proposed approach
to gradually identify components. For instance, a given component can be
first identified as a fastener at an early stage of the reasoning process, as
it complies to certain rules, this can be refined further by identifying the
component in hand as a screw in later stages. Finally, the component can
be precisely assigned the FD of a cap-screw if certain conditions are met.Common concepts 89
Power
Transmitter Seal Fastener Bearing
Contact
Bearing
Roller
Bearing Screw Nut
Set Nut Cap Nut
Screw
Capscrew
Spur
Gear
Conic
Gear
Component
Gear Sprocket Pinion GasketValve
Pressure Stud
Screw
Shoulder
Screw
Figure 4.7: A subtree of the taxonomy of FDs.
Figure 4.7 shows a portion of the taxonomy of FDs, showing the path to
cap-screw. It is now important to note that the taxonomy of FDs uniquely
defines the components of a DMU where these FDs are located in the leaves
of the taxonomy. It is effectively the place where the taxonomy associates
a single component to one FD.
The same applies to CIs, where geometric properties of an interface can
be narrowed down in an adaptive manner using the taxonomy of CIs, starting
with detecting whether it is a contact, interference, or clearance5 down to
the precise geometric configuration identification of the CI.
Figure 4.8 shows portions of FI taxonomy (left) and CI taxonomy (right),
and the relation between each class expressed at the leaf levels. This relationship
links each CI to all FIs that it may conventionally represent according
to observations in industrial DMUs. As the figure depicts, and as shown in
Section 4.2.5, this connection is inherently ambiguous as it relates one CI to
possibly more than one FI. It however defines at the outset how CIs must be
functionally interpreted knowing only their geometric properties (see Section
5.4). This ambiguity is reduced on a case-by-case basis, as shown in
Chapter 6.
5We show later in Chapter 5 that we are only interested in contacts and interferences
in the scope of our research.90 Chapter 4. Functional Restructuring and Annotation
Spline Link
Threaded Link
Snug Fit
Adhesive Link
Loose Fit
Conic Support
Planar Support
Linear Support
Radial Circular Contact
Axial Circular Contact
Cylindric Interference
Cylindric Contact
Conic Contact
Planar Contact
Linear Contact
Circular Contact
Clamp Link
Support
Kinematic Link
FI CI
Interference
Contact
Surface Contact
Curve Contact
Manifold Interference
Figure 4.8: Taxonomies of FIs (left) and CIs (right). Dotted lines show how
they relate to each other at the leave level (the figure only shows a partial
view of each taxonomy).Method walk-through 91
Extraction of
Component´s Interfaces
Assignment of
Functional Interpretations
Qualitative Assessment
against Reference States
Assignment of
Functional Designations
Digital Mockup
Set of B-Rep models
Restructure and Annotated Geometry
Geometric representation of
components interactions
Deriving elemetary functionalities
from components interfaces
Symoblic expression of
component´s behavior
Matching function patterns
to structured components
Figure 4.9: Data and process flow diagram of the proposed approach.
4.3 Method walk-through
In this section we define the outlines of our method using the reference
concepts introduced in the previous sections. The method takes as only
input the geometry of product components as represented in a DMU. The
proposed approach treats this model through different stages, as shown in
Figure 4.9, and concludes to deliver a restructuring of the initial geometric
models of components, with coherent technical and functional annotations
at different level of details where the first level is the FD of components.
Next, we briefly present each of these stages to synthesize the overall
process before details are elaborated in a dedicated chapter per stage in the
rest of this document. As depicted on Figure 4.9 the overall scheme is of
type linear and its main stages are as follows.
Extraction of component interfaces
The first step of the process is purely geometric. In this phase geometric interactions
between components are detected. A CI is created for each valid
interaction, and it is identified by the geometric nature of the interaction
zone. CIs are also loaded with information about their location and orientation
with respect to the whole assembly. Based on the nature of each CI,
the taxonomy of CIs (see Figure 4.8) is populated and a logical connection
is set up between the geometric data structure of this CI and its associated
instance in the taxonomy.
Also, the binary relations between components and CIs are expressed
in a graph structure, which is passed to the next stage together with the92 Chapter 4. Functional Restructuring and Annotation
taxonomy of CIs, as a result of the geometric analysis.
Assignment of functional interpretations
In this stage, a first attempt to functionally interpret CIs is made. This is
performed strictly using the intrinsic geometric properties of each interface.
Generally speaking, more than one functional interpretation is possible per
geometric configuration, hence, more than one possible FI is assigned to each
CI. This process populates the taxonomy of FIs and set up the connections
between this taxonomy and the taxonomy of CIs that has been populated
at the previous step. The connection between the taxonomies conforms to
Figure 4.8. At this stage, all the functional interpretations of the interfaces
between components are expressed and structured to characterize the ambiguities
living in a DMU that originate from the conventional representations
applied to each of its components.
Generating the instances of the taxonomy of FIs sets a link between
shape and function at the interface level between components. Because the
interfaces are the most elementary areas where components interact, their
functions are elementary and the corresponding set of functions is rather
small and can be enumerated easily. The behavioral phenomenon used to
assign function to each CI is based on the kinematic behavior of the interface,
i.e., the relative movements between the components defining this interface.
Chapter 5 details the detection and initial interpretations of geometric
interactions.
Qualitative behavioral assessment
In order to reduce the number of function interpretations to one per interface
between components, a physical dimension is given to each CI.
Since physical properties of interfaces are not yet available, we generate
assumptions for each possible interpretation, then the goal shifts to refute
some of those assumptions, thus their relative function interpretation. These
physical properties are related to a behavior of the DMU that express a
transition between reference states assigned to the DMU (see Section 2.2
and Section 2.3).
This refutation is made by validating each possible interpretation and
checking its physical plausibility and mechanical meaningfulness against a
set of established reference states. The corresponding process is based on
a qualitative behavior simulation to be independent of physical quantities
that are not available with the DMU and/or not available at the stage of a
product development process where the DMU is used as input.
The output of this stage is a precise functional interpretations of CIs in
terms of their respective FIs.Conclusions 93
Chapter 6 describe the details about the qualitative analysis algorithm
as well as the concept of state.
Assignment of functional denominations
Once functional properties of each interface is identified, i.e., the previous
step has discarded all unnecessary interpretations to keep only one of them
per interface, the functionality of components is investigated based on this
knowledge.
This is done using rules that describe relations between FDs, FCs, and
FIs, in a pattern-matching-like manner. This is the stage where relationships
between shape, behavior and function is used (see Section 2.3). The spatial
layout of interfaces combined with their functional behavior obtained
from the previous stage is used to infer the appropriate function of some
components, hence their corresponding FD (see Section 4.2.3).
The result of this stage is components classification into their corresponding
FDs, and components clustering into FCs. The component clustering
derives from the taxonomy generated from FCs.
Chapter 7 provides a detailed description of this rule-based reasoning.
Semantically-augmented geometric model
The previously collected knowledge is finally integrated into a semanticallyenriched
and restructured geometric model of the DMU components.
The restructuring is the result of the breakdown of model components
into geometric entities that reflect the functional interactions between components
by means of its CIs (according to the functional breakdown), and
the classification of components belonging to the same functional cluster
into groups (according to the functional aggregation). Additionally, the geometric
decomposition of components can be used to describe precisely the
FDs of components, i.e., the FIs of components involved in the FD of a
component are also connected to each other and related to the FD of this
component.
The semantic enrichment is achieved by the functional annotation of interfaces,
components, and groups of components. Based on this enrichment,
advantages can be gained to select components in a DMU in accordance with
their FD and their function and process their neighborhood (see Chapter 8).
This is particularly relevant for the pre-processing of DMUs for FEA.
4.4 Conclusions
This chapter has introduced some reference concepts of the proposed approach.
These concepts outline the knowledge modeling process used throughout
the proposed approach. There, the dependencies between shape, behav-94 Chapter 4. Functional Restructuring and Annotation
ior and function is precisely analyzed to produce efficient mechanisms that
can be used to enrich a purely geometric model of a DMU up to functional
information.
It has to be observed that the proposed approach is not depending upon
a particular morphology of the components that could restrict the range of
DMUs that could be processed. Therefore, the proposed enrichment process
is more generic than KBE approaches (see Section 2.6). Also, the boundary
decomposition of components resulting from the identification of CIs and
their enrichment with functional information to obtain FIs show how this
process can contribute to the definition of functional features and how these
features differ from features encountered in prior work (see Section 2.4).
Here, the dependency between shape, behavior and function brings consistency
to the functional information obtained from the enrichment process.
The proposed constructive bottom-up method has been presented synthetically
to emphasize its key steps. It has outlined central concepts (see
Section 4.2) and how they contribute to the context of the proposed enrichment
process, before we enumerated the major stages of the proposed
method in Section 4.3, shedding lights on how these concepts interact and
fit into the paradigm of shape - behavior - function dependencies. Introduced
concepts are revisited in the upcoming chapters, where we develop
our approach in more details.Chapter 5
Functional Geometric
Interaction between
Components in a DMU
Product modules interact through precise interfaces, this applies to
all engineering domains as we have shown in Section 4.2.2. When
it comes to mechanical engineering those interfaces are the direct
result of components geometric interaction, where components play
the role of modules in this context. This joins what is referred to
in the literature as form-function relationship and shown in Section
2.3.
The first indicator to components functions thus is their geometric
interactions. In this chapter we show how to efficiently, yet
precisely detect those interactions of interest as basis of a thorough
functional analysis.
5.1 Functional surfaces
As demonstrated in Section 4.2.2, FIs occur at the geometric interactions
between components in a DMU such as contacts and interferences. This
can theoretically happen between any kind of surfaces at both sides of the
interface, resulting in different possible types of interaction zones.
Observation shows, however, that geometric interaction of interest to our
analysis, that is those who convey a functional meaning, are restricted to a
subset of all possible configurations.
In fact, studying industrial DMUs showed that functional interaction
happens at parts of the components that fall in one of the following two
categories.
• Simple geometric configuration in the real product such as planar con-96 Chapter 5. Functional Geometric Interaction
Figure 5.1: Approximate relative rotational position of components in a
spline link; detailed view on the left, global one on the right (courtesy ANTECIM).
tacts and cylindric fits. In this case the real geometry is not simplified
in the digital model, and surfaces are represented as they should be
manufactured.
This configuration is quite common. It is preferable as planes, spheres,
and ruled surfaces are relatively easy to machine rather than free form
surfaces.
• Complex repetitive geometric features, like helices and involute teeth.
Such profiles are necessary to insure specific physical behavioral properties,
allowing the fulfillment of particular functions.
A detailed representation of such surfaces potentially leads to inaccurate
relative positioning of components when they are assembled
together (refer to Figure 5.1 for an example). Moreover, the machining
of such profiles are done independently of the digital model, since
whole components are often out-sourced, or features are machined using
particular tools. For these reasons, such detailed configurations are
simplified in the DMU, and reduced to simple contacts or interferences,
as shown in Section 3.2. Figure 1.7 shows how a threaded connection
between a bolt and a nut is represented as a simple interference.
In the lights of the aforementioned observation, we note that only interactions
that occur between canonic surfaces in the digital model may hold
functional interpretations, hence, only these interactions are of interest to
our research. This leads to the following hypothesis.
Hypothesis 5.1 (Functional surfaces). In a DMU, FIs are represented using
canonical surfaces that can be either planes, spheres, cones, tori, or cylinders.
We refer to such surfaces as functional surfaces.Geometric preparation and rapid detection of interactions 97
Free form surfaces, such as B´ezier patches [151] and NURBS [130], are
still used in product modeling for different reasons, not the least of which
are their precise mathematical representation, intuitive modeling, and their
agronomic and aerodynamic qualities.
Since free form surfaces do exist in a DMU, interaction between them
may indeed occur in an assembly. However, they usually do not connect
components functionally. They may though represent function interactions
with the product environment, such as aerodynamic drag. Nonetheless, such
interaction are out of the scope of our study as external elements such as
gases and fluids are usually not present in a DMU.
5.2 Geometric preparation and rapid detection of
interactions
In this section we describe the very first stage of our method which consist of
the geometric analysis to detect components interfaces and their geometric
properties. First, the nature of the method input as the geometric model of
the product is explained. Before going into details of the optimized detection
algorithm.
5.2.1 Geometric model as global input
As mentioned in Section 4.3, our analysis and reasoning to reveal functional
properties about the product are based solely on the geometric model of this
product, as represented in its DMU.
In the context of our research we opt to use a standardized portable representation,
that is widely used in industry to communicate product models
between different CAD systems. This is STEP format as standardized by
ISO 10303 [7].
STEP aims to provide a neutral format that represents product data
all along its lifecycle, across different platforms. However, and as shown
in Section 3.4 industrial practices make little use of STEP support of nongeometric
annotations. We are, thus, only concerned about part of the standard
that deals with geometric representation and referred to as AP 203 [8].
STEP is implemented using one of the following methods.
STEP-File Where product data are represented in and ASCII structured
file. This method is defined by ISO 10303-21 [10].
STEP-XML An alternative to the previous method that uses an XML
structured file. Both methods have the advantage of being highly
portable across different platforms. This method is defined by ISO
10303-28 [9].98 Chapter 5. Functional Geometric Interaction
(a) (b)
Figure 5.2: Effect of maximal faces and edges generation. Patch boundaries
are marked with black edges. Initial boundary decomposition (a), boundary
decomposition with maximal faces and edges (b) (courtesy ANTECIM).
SDAI An Application Programming Interface (API) that deals with products
data, and is defined by ISO 10303-22 [11].
Our methods takes a product DMU represented as a STEP-File formatted
file, and passes it to the first stage of our approach: the geometric
analysis.
5.2.2 Maximal edges and surfaces
STEP describes components geometric models using a B-Rep format. Unfortunately,
B-Rep encoding of a geometric object is not unique. That is;
two STEP files may represent the same shape differently. This is due to
the fact that an edge (then called a wire) can be represented as a set of
topologically-connected smaller edges laying on the same curve. The same
applies to faces, where a face can be divided into smaller ones that share
the same surface and are topologically-connected. This phenomenon originates
from component modeling process where functional surfaces are often
broken down into smaller pieces because of the constructive nature of the
process inherent to industrial CAD modelers.
Additionally, geometric modelers are subjected to topological and parametric
constraints [111]. This prevent the boundary decomposition from
matching the real boundaries of a component. For example, a cylindrical
surface can be represented either with two half cylinders or a single cylindrical
patch whose boundary contains a functionally meaningless generatrix,
since it is not a boundary of any surface on the real component (refer to
Figure 5.2).
The removal of such unnecessary geometric elements is mandatory to
obtain a unique geometric representation of a shape. As shown in Sec-Geometric preparation and rapid detection of interactions 99
tion 2.5.2, representation uniqueness is a must when useful information is
to be extracted from a geometric model. As a desirable side effect, the decrease
of the number of geometric elements boosts the performance of all
subsequent geometric treatments.
To obtain this representation of components boundaries, adjacent faces
(i.e. topologically-connected ones) that belong to the same analytical surface
are merged into one entity; a maximal face. A maximal face is represented
by its underlying oriented and topologically-connected faces. Edges are also
grouped into maximal edges using the same criterion, where adjacent edges
laying on the same analytical curve are merged. A maximal edge is represented
by its underlying oriented and topologically-connected edges. As a
result, a cylindrical face can end up with a boundary described by two closed
edges without vertices. The corresponding data-structure uses hyper-graphs
and was introduced by Foucault et al. [68].
The resulting normalized geometric model with maximal edges and surfaces
has a minimal number of topological elements (vertices, edges, and
faces).
5.2.3 Geometric interaction detection
Once the geometric model is normalized, it makes way for the detection of
geometrical interaction zones of interest that define CIs. This means the
detection of contacts and interferences that potentially convey a functional
meaning.
Clearances as functional plays
Clearances may imply functional intention as shown in Section 4.2.5, this is,
however, more intricate to detect than contacts and interferences. This is
basically because clearance detection, unlike that of contacts and interferences,
is dependent on a parameter which is the play threshold. The play ρ
is the minimal distance that two component preserve between their surfaces,
and can be defined as
ρ = min
p1∈∂C1
min
p2∈∂C2
�−−→p1p2�
as shown in Figure 5.3. If the play between two components is less than or
equal to a predefined threshold ρ ≤ P, components C1 and C2 are said to
have a clearance.
This dependence on an input parameter is contradictory to our assumption
of a purely qualitative reasoning (motivations are explained in Section
4.1). Moreover, and in spite of the potential functional implication
of plays, they are of less use to later stages of our analysis, as this potential
functional contribution is not easy to verify. Finally, functional plays
are usually not simplified in any way when preparing a CAD model for100 Chapter 5. Functional Geometric Interaction
Figure 5.3: Calculation of the play ρ between two solids C1 and C2, where d
is the distance between two given points on the surfaces of C1 and C2, and
δ is the minimal distance between a given point on C1 and the surface of
C2.
simulation, that makes their identification irrelevant to the geometric transformation
process.
For all these reasons, clearance detection is kept out of the scope of our
implementation, while focus was given to efficient detection of contacts and
interferences.
Early elimination of negatives
A naive approach to the geometric interaction detection is to use boolean
operators—explained hereafter—between pairs of solids of the model at
hand. This can however be enhanced using the early elimination of negatives.
Early elimination of negatives filters out candidate pairs that obviously
have no interaction zones, this is done using bounding boxes technique. A
bounding box of an object C is a minimal box with edges parallel to the
global coordinate system, which inclusively contains the object C. Each
bounding box is then defined by six values (in 3D): xmin, xmax, ymin, ymax,
zmin, and zmax. Bounding boxes interaction check reduces to 6 floatingpoint
comparisons at most. If the bounding boxes of two components do
not interact geometrically, the two components do not either.Geometric preparation and rapid detection of interactions 101
Boolean operators drawbacks
Boolean operators provide an accurate tool to detect contact and interference
zones. The intersection between two solids1 C1 and C2 is computed,
generating a set of geometrically connected shapes S, where
∀S1, S2 ∈ S, int(S1) ∩ int(S2) = ∅
∧ �
S∈S
S = C1 ∩ C2 .
where int(S) = S − ∂S is the interior of the solid S.
If S is an empty set, the two solids are said to have no geometric interaction.
Otherwise, and for each resulting shape S, if the shape is a volume
(possibly with non-manifold configurations) the two solids are said to be
interfering at S. If the shape is of a lesser dimension (a surface, curve, or
point) the two solids are said to be in contact at S.
Nevertheless, this tool is costly in time and resources. This cost quickly
becomes prohibitive, even for modestly large DMUs. Additionally, even
though the precise interaction zone is obtained as a result of the boolean
operation, geometric parameters are still to be looked for into those resulting
shapes. That means that the cylindric interference between two object, for
instance, is returned as a B-Rep shape, and still needs to be studied to obtain
the axis and diameters of the interaction, the axis being notably required
for further stages of our approach.
Canonical face comparison
To avoid the burden of boolean operators when not needed, a simpler, yet
more efficient, detection technique is utilized, based on the mere comparison
of geometric entity of two neighboring objects. We consider two objects to
be neighbors if they pass the bounding boxes test (i.e. their bounding boxes
interact with one another).
In this sens, bounding boxes are used first to filter out non-adjacent
solids. The remaining ones are then checked pairwise for geometric interactions.
For each pair of solids, maximal faces of one solid that lie on canonic
surfaces are compared against those of the other. We adopt a simple, yet
extensible approach to extract geometric interactions, based on the comparison
of the geometric characteristics of canonic surfaces. This comparison
is no more than a secondary filtering of irrelevant interaction candidates
surviving the bounding boxes check. The final detection of interaction zone
is discussed in Section 5.3.
Take two solids C1 and C2 whose bounding boxes are in interaction.
Therefore, canonic faces of C1 is to be compared to these of C2. Let us
1Solids here are represented by their closure C = int(C) ∪ ∂C.102 Chapter 5. Functional Geometric Interaction
consider a maximal faces F1 ⊂ ∂C1 and F2 ⊂ ∂C2. We need to compare F1
to F2.
If both F1 and F2 are planar, we check whether normals of the two
faces are opposite to each others, and if the difference between the position
vectors of the two faces is orthogonal to the normals. Given n�1 and n�2 the
normals of F1 and F2, and p�1 and p�2 their respective position vectors, the
above-mentioned check can be stated as follows;
n�1 . n�2 = −1
(p�1 − p�2) . n�2 = 0.
In this case the two faces are reported as a potential planar contact.
If F1 is cylindric while F2 is planar, we check whether the axis of the
cylindric face is parallel to the planar surface, and that the distance between
the axis and the plan is equal to the radius of the cylinder. Given a�1 the unit
vector in the direction of the axis of the cylindric face F1, r1 its radius, n�2
the normal of the planar face F2, p�1 and p�2 the respective position vectors
of F1 and F2, the above-mentioned check can be stated as follows;
a�1 . n�2 = 0
(p�1 − p�2) . n�2 = r1.
In this case the two faces are reported as a potential linear contact.
If both F1 and F2 are cylindric, we check whether the two axes coincide.
Given a�1 and a�2 the unit vectors in the directions of axes of F1 and F2
respectively, and p�1 and p�2 their respective position vectors, the abovementioned
check can be stated as follows;
|a�1 . a�2| = 1
|(p�1 − p�2) . a�2| = 1.
In this case, and if the radii are equal r1 = r2 the two faces are reported
as potential cylindric contact. If the radii are not equal, a further test of
surface orientation is done. In this case, if the cylinder with smaller diameter
is oriented inwards, while the other one is oriented outwards, the solids of
the two faces are reported as potentially in cylindric interference2.
It is worth noticing that the above-mentioned criterion only allows for the
detection of cylindric interferences for which the axes of the cylindric faces
at both sides of the interaction coincide. Although, other configurations can
be envisaged where the condition of axes coincidence is relaxed to simple
parallelism. In the latter case, an additional condition on the perpendicular
distance d between the two axes with respect to cylinder radii should be
introduced. More precisely, the distance between axes should be less than
2The inverse case, when the cylinder with smaller diameter is oriented outwards and
the other one is oriented inwards would denote a potential clearance. However, clearances
are not considered in the scope of this work.Geometric preparation and rapid detection of interactions 103
the sum of radii if partial, as well as complete, interferences are considered
d < r1 + r2, and less than the difference of radii if only complete cylindric
interferences are considered d < |r1 − r2|. The distance d can be calculated
as follows;
d = �(p�1 − p�2) − ((p�1 − p�2) · a�1) a�1�.
Such a configuration does not reflect an interpretable functional intention.
Nonetheless, it may be encountered in industrial models as a result
of imprecise geometric representation to what otherwise would be a coaxial
configuration. Even if the detection of such configuration is technically
possible with a minimal cost, it poses, however, a problem of interpretation.
Such a configuration is thus not considered in the actual work, and is left
for future extensions.
Combinations of other canonic faces such as spheres, cones and tori are
also considered and studies, reporting candidates to circular and conic contacts.
Up to this stage, geometric interaction filtering is implemented in the
class BoundingBoxesGID (for Bounding Boxes Geometric Interaction Detector)
in our code. Note however that this class signal all potential candidates,
as discussed above, leaving the final decision to boolean operators, as discussed
in Section 5.3.
A major advantage of this technique is the order of magnitude drop in
execution time it exhibits compared to mere boolean operators, as costly
solid intersection calculation is avoided when not needed.
Furthermore, results obtained by this method readily contain geometric
characteristics of the interaction, such as axes and normals, that are used
to define a local Cartesian coordinate system, as shown in Section 6.3.1.
A drawback of this method is that it only detects interaction between
surfaces that have a simple set of geometric characteristics; i.e. canonic
surfaces. Contacts and interferences that involve free-form surfaces are not
detected using this method, even if the opposite surface is canonic. However,
in the context of this research, this is tolerated, and even favorable, given
that we are only interested in functional surfaces, as shown in Section 5.1.
5.2.4 Local coordinate systems
CIs are shipped with local coordinate systems that are particularly important
when assigning physical properties to these interfaces. As Chapter 6
will unfold, dynamic and kinematic behaviours of a CI are expressed with
respect to these local coordinate systems.
The choice of a local coordinate system is thus not arbitrary. They are,
in fact, orthogonal right-handed coordinate systems, conventionally defined3
in as much aligment as possible to geometric characteristics of the interface.104 Chapter 5. Functional Geometric Interaction
To this end, coordinate axes are defined based on normals and axes
of symmetry whenever available. As an example, for a rectilinear contact
(such as the one between a cylinder and a plane shown in Figure 5.4b), the
z-axis is defined along the surface normal, while the x-axis is defined by
the contact line, the y-axis is then deduced using the right-hand rule, as
the vector product of the x- and the z-axes. For planar contacts (shown in
Figure 5.4a), only the z-axis is deterministically defined, while the x- and
y-axes are left to lie on the contact plane. The choice of the coordinate
system origin is also of important significance. In our work, this point is
chosen to be the barycenter of the interaction zone, whether it is a curve,
a surface or a volume. Figure 5.4 shows more examples of CIs geometries
associated with their conventional coordinate systems.
It is important to note that the choice of coordinate system is a matter
of convention. What does really matter here is the coherence between conventions
made at this stage, and those considered when assigning physical
properties to the interface. For example, a simple planar contact delimits
object translational motion along its normal, while leaving it free to translate
parallel to its surface. By making a coherent choice of the local coordinate
system, say the one shown on Figure 5.4, one can say that a planar contact
eliminates object translational mobility along the positive direction of the
z-axis of such a contact.
5.2.5 Conventional interface graph
The outcome of this phase is represented as a graph referred to as conventional
interface graph (CIG). This is a mathematical model upon which we
build our reasoning in phases to come.
Definition 5.1 (Conventional interface graph). The CIG is a directed graph
G(C,I) that has the set of all components in an assembly C as its nodes,
and the set of their CIs I as its edges.
Initially, edges of the graph (i.e. CIs) contain information only about
the geometric interaction between two nodes (i.e. two components), such as
normals, axes, directions and radii, along with the interface local coordinate
system transformation matrix with respect to the global coordinate system.
Even though some CIs are geometrically and functionally symmetric,
such as those resulting from a simple planar contact, the concept of CI is
still asymmetric in general.
A cylindric contact for instance generates a CI, we can clearly recognize
the outer component from the inner one. This recognition can be made
for many types of geometric configuration. CI asymmetry makes the CIG
3Conventions are made in the scope of this work.Geometric preparation and rapid detection of interactions 105
y x
z
y x
z
(a) Planar Contact (b) Rectilinear Contact
y x
z
y x
z
(c) Circular Contact (d) Punctual Contact
y x
z
y x
z
(e) Conic Contact (f) Cylindric Interference
Figure 5.4: A set of conventional interfaces with their associated coordinate
systems.106 Chapter 5. Functional Geometric Interaction
C
CI1: Cylindric Interference
CI2: Planar
Contact
A
B
D
CI3: Planar
Contact
CI4: Conic Contact
Figure 5.5: A cross-section in a partial geometric model model of a capscrew
and a nut tightening up two plates, showing detected CIs.
a directed graph. Even when the geometric nature of the interface makes
no distinction between the two components at each side, one of the two
orientations is assumed to define the edge orientation in the CIG.
We refer to the graph produced by ignoring edge orientations in CIG as
the conventional interface underling undirected graph (CIuG).
Figure 5.5 shows a cross-section in a model of two plates; A and B,
tightened up together by means of a capscrew D and a nut C. It also shows
CIs between components as represented in the DMU: a cylindric interference
CI1between C and D, two planar contacts CI2 and CI3, between B and C
and A and B, respectivly, and a conic contact CI4 between A and D. This
information is initially unavailable in the input model; which is the DMU.
Figure 5.6 shows the corresponding CIG, where components A, B, C, and
D form the nodes, and interfaces CI1, CI2, CI3 and CI4 form the edges,
after being detected.
While classes Component and ConventionalInterface represent components
and CIs respectivley, the CIG is represented by the class Conventional-Precise detection of interaction zones 107
C A
CI1: Cylindric Interference
Threaded Link
Spline Link
CI4: Conic Contact
Conic Support
Self-locking Fit
D
B
CI2: Planar Contact
Planar Support
CI3: Planar Contact
Planar Support
Figure 5.6: The CIG of the model represented in Figure 5.5, enriched with
functional interpretations, as a set of FIs assigned to each CI. Only relevant
edge orientations (those reflecting asymetric geometric interface) are shown
on the figure.
InterfaceGraph in our implementation.
5.3 Precise detection of interaction zones
The technique discussed in Section 5.2.3 is still approximate, it only filters
out non-interacting canonic faces based on the comparison of the geometric
parameters of their carrying surfaces. Faces that the previous phase reports
are likely to interact, nonetheless, another measure is still needed to ensure
real interaction. For example, two coaxial cylindric faces that share the
same radius are reported as potential cylindric contact, though they may be
afar along the axis and no actual contact takes place.
Moreover, the simple approach developed above fails short to deliver
accurate interaction zones. Even though this shortage can be easily overlooked
for the inference process, precise contact and interference zones are108 Chapter 5. Functional Geometric Interaction
still required for FEA purposes, as seen in Section 3.3.2.
A confirmation stage is hence necessary to validate candidates reported
by earlier stages, and to produce precise interaction zones for those that are
indeed valid.
To this end we use boolean operator applied to pairs of maximal surfaces
in case of candidate contacts, and to solids in case of candidate interferences.
In spite of their high cost, as mentioned in Section 5.2.3, boolean operators
are used to obtain precise geometric zone necessary for further FEA
treatment, hence, their cost are justified for positive candidates. Since this
is a final verification phase, only small number of false positives survive the
previous filters compared to the total number of candidates, minimizing the
wasted time computing intersection between non-interacting solids.
Candidates resulting from the canonical face comparison are thus validated
using intersection operators, if the resulting shape is not empty, the
interaction is considered valid, and a CI is created to represent it, adding
an edge to the CIG. The newly created CI is associated to a local Cartesian
coordinate system as shown in Section 6.3.1.
To enable the referencing of precise interaction zones and their annotation
with functional semantics, before the model is passed to applications
such as FEA, the geometric model of a component is restructured according
to those interaction zone. This makes the functional breakdown mentioned
in Section 4.2.3 possible as soon as the semantic annotations are available.
The OpenCascade software library [149] is used in our implementation
to conduct boolean operators whenever needed. The class BooleanBBGID, a
subclass of BoundingBoxesGID, implements the final precise detection of interaction
zone in our code, overriding the method verifyInteractions(int,
int) that constantly returns true in its superclass.
5.4 Form-functionality mapping
Section 4.2.5 showed how functionality is satisfied as a direct result of geometric
shape and physical material properties of components and their
interfaces [118]. Given exact shape and material properties at both sides of
an CI we can then deterministically deduce the functional role it plays in
an assembly. However, this deduction is not readily possible in the DMU,
because of the following reasons.
Imperfect geometric representation Section 3.2 showed that the DMU
geometrically represents the product through its constituent sub-assemblies
and components at different levels of details. That means
that many form simplifications may take place, leading to loss of geometric
information. Those simplifications are influenced by some sort
of conventions, either internal to one company, or agreed upon for a
specific 3D models provider or library as mentioned in Section 4.2.5.Form-functionality mapping 109
Some simplification conventions may become a de facto standard, but
there has never been a well-defined globally-recognized standardization
of such conventions and notions, in contrary with many traditional 2D
blueprints notions, as seen in .
Incomplete material information A DMU may or may not have a BOM
attached to it (see Section 1.7). When a BOM is available, it provides
an indication of physical properties that contributes to the functionality
of a component or an interface. Once again, this information not
reliable, neither in terms of existence (a DMU is not guaranteed to
have a BOM), nor in terms of meaningfulness (there is no standards
governing what information a BOM should contain, and in which format).
Because of this incomplete knowledge about shape and material properties
in a DMU, the immediate deduction of functionality is not possible.
However, assumptions can be made despite this incompleteness. Those assumption
can then be reduced when the missing knowledge is reconstructed
form existing one.
In this work we only consider pure geometry. We thus assume that
the the BOM is unavailable, or uninterpretable, which is the worse case.
Assumptions about materials physical properties such as stiffness and adherence
are discussed is Section 6.2 when reference states are introduced.
5.4.1 Multiple functional interpretation
Considering geometric simplifications conventions observed in the industry,
a limited number of assumptions can be made about the real shape when a
specific geometric configuration is encountered in a DMU.
Section 4.2.5 showed that different FIs, such as threaded links and spline
links can be represented as simple cylindric interference in a DMU. Another
example of the use of the same geometric interface for different functional
meanings is a simple cylindric contact that can refer either to a snug or to
a loose fit (see Figure 3.3).
This allows us to link a given geometric interface, represented by a CI,
to a set of functional interpretations, for each, an assumption is made about
the real shape and physical properties of materials.
Definition 5.2 (Functional interpretation). A function interpretation is the
assignment of one FI to a CI.
The assumption made for each interpretation provides the interface with
a physical dimension, as developed in Section 6.3.1. More than one interpretation
can be made per CI (see Figure 4.8), thus more than one independent
physical and behavioral assumption.110 Chapter 5. Functional Geometric Interaction
5.5 Conclusions
Our methods takes a pure geometric representation of a product as a set
of solids representing components. In this work we adopt an ISO standard
that represents the geometric model as a STEP-File [10].
The geometric analysis consists of detecting the geometric interaction
between solids, those are contacts and interferences defined in Section 4.2.5.
A preliminary approach would be to use geometric boolean operators,
preceded by early elimination of negatives by means of bounding boxes
checks.
We are particularly interested in those interaction occurring between
faces that are likely to connect components with a functional bound. Observation
shows that those faces happen to lie on canonic surfaces. This observation
allows us to optimize our detection algorithm, adding a secondary,
relatively fast, elimination filter right after the bounding boxes check.
Final validation and generation of interaction zones is still done by means
of boolean operators, calculating intersection between potentially interacting
elements.
This method is able to efficiently detect geometric interactions between
canonic surfaces. The intermediate filtering between bounding boxes check
and boolean operators validation reduces the detection time by orders of
magnitude.
Geometric interactions of interest define CIs that link components together
generating a directed graph called the CIG.
Once CIs are geometrically recognized, they are provided a physical dimension
through functional interpretations. Functional interpretations are
assumptions about the functional intent of the interface, made in the light
of its geometric properties in the DMU. As a result, each CI is interpreted
into one or more FI. This imprecision is due to the lack of reliable information
about exact geometry and materials physical properties. Checking
the validity of those assumptions allows for the elimination of irrelevant interpretations.
The elimination process is to be discussed in the following
chapter.Chapter 6
Qualitative Behavioral
Analysis of Components
Functional Interactions
The previous chapter has shown that component FI assignment
can lead to multiple solutions due to shape simplifications between
their real and digital shapes. The corresponding assumptions have
used shape – function dependencies. To reduce the number of FI
per CI to one, which is the real configuration, the purpose is now
to refer to behaviors to filter out FIs. Because the input data is
a purely geometric representation of a DMU, it is proposed to set
up a qualitative approach to describe behaviors where it is possible
to take advantage of the somewhat precise representation of
components while reasoning qualitatively with physical parameters.
Because this approach is qualitative, it is applicable to a wide range
of stages in a PDP, up to early design stages where the physical
parameters related to FIs and, more generally, to components, are
no yet available.
In this chapter, we demonstrate such an approach, defining referential
behavioral states against which the validity of functional
assumptions is checked to narrow down the number of possibilities
to one functional interpretation per CI.
This chapter is organized as follows: the concept of reference
state and energy preserving hypotheses in assembly joints are presented
in Section 6.2, then the qualitative representation of joint
forces and velocity properties is introduced in Section 6.3 through
the concepts of qualitative wrench and twist screws. Finally, the
reasoning scheme to select appropriate functions for each CI, which
is based on static equilibrium and statically indeterminate reference
states, is presented in Section 6.4 and Section 6.5.112 Chapter 6. Qualitative Behavioral Analysis
6.1 Behavioral study to bind form to functionality
The previous chapter showed how to build the CIG that reflects our initial
knowledge about the assembly through a graph structure. Even when enriched
with functional interpretations, this knowledge still shows functional
uncertainty.
Uncertainty in the knowledge base stems from the fact that some CIs
hold more than one functional interpretation, thus, they cannot yet be
mapped to a single FI. To reduce such uncertainty, additional rules and/or
facts are to be taken into consideration, before being able to speculate about
FDs and FCs of components and component groups.
Since the geometric analysis is not sufficient by itself to lead to a decisive
functional resolution, as shown in Section 5.4, the concept of mechanical
behavior, as discussed in Section 2.3.1, is borrowed here to take advantage
of the form–function–behavior dependencies to strengthen the relationship
between geometry and functionality so that efficient decisions can be taken
over FIs to reduce them to one per CI, wherever needed is the assembly
input.
Behavior can cover a wide spectrum of physical phenomena. In the scope
of FE simulations, mechanical properties of components and their interactions,
such as reciprocal forces between components taking place at each CI
and force cycles tightening groups of components together are key elements
that can be exploited to define behavioral models. Even though these mechanical
properties are directly related to boundary conditions required by
FE models, they are also of general interest. For example, reciprocal forces
express whether a component can or cannot move with respect to its neighbors,
which is also of interest in configurations of assembly or disassembly
processes. Therefore, the concept of behavior and its qualitative approach
can be seen as a generic tool that can be used to probe a DMU.
6.2 Reference states
Reference states (RSs) reflect rules that apply to the domain of discourse.
In this sense, RSs are domain knowledge, as introduced in Section 2.6.1.
This knowledge may clarify ambiguity by reducing uncertainty in the
knowledge base, e.g., reducing the number of functional interpretations per
CI to ideally one. It also may produce certain new facts, such as the existence
of a functional group that ties some subset of components. A RS is formally
defined as follows.
Definition 6.1 (Reference state). A reference state (RS) is characterized
by a set of input and a set of output physical parameters applied to a
subset of components of a DMU. This subset may cover the whole DMU and
the DMU is processed as given in its input geometric setting. A physicalReference states 113
behavior, consistent with the input and output parameters set up and a
set of hypotheses is associated with the DMU to express the corresponding
physical phenomenon. This behavior is characterized by a set of equations
that takes as input the set of input parameters characterizing the state and
the geometric configuration of the DMU and produces as output the set of
physical parameters characterizing this state. A reference state can match
any specific state) of the product lifecycle, e.g., assembly process, working
condition.
This definition straightforwardly relates to the notion of function (see
Section 2.2) that can be related to sets of input and output parameters of
a product or sub-system. Here, the purpose is to characterize a RS with
its input parameters, behavior equations, hypotheses and study the output
parameters that will characterize functions at some CIs of some components.
From the characterized functions, it will be possible then to confront them
to the assigned FIs and discard some of them when inconsistencies appear,
i.e., the function expressed by a FI differs from the function derived from
the output of the state behavior.
Indeed, the hypotheses and behavior equations are formed in terms of
rules against which our knowledge about the DMU is checked, reducing
uncertainty by refutation and producing facts by deduction. It has to be
noticed that the principle of qualitative reasoning will explicitly, or implicitly,
refer to relative physical values between components or products.
Different RSs have been recognized, both static and kinematic. Only
static RSs, namely static equilibrium (see Section 6.4), and static determinacy
(see Section 6.5), have been implemented in the scope of this work,
at a first step, even though others are discussed such as kinematic chains.
Initially, all studied RSs consider components as rigid bodies, unless rigidness
proves to be impossible, that is, no possible functional interpretation
satisfies this hypothesis.
Hypothesis 6.1 (Rigid bodies). Unless otherwise stated, components materials
are assumed to be of high stiffness such that components are considered
as rigid bodies, i.e., the loading conditions of a component do not alter
its geometry. It is a common hypothesis for manufactured products where
steel and other materials often lead to this hypothesis. It is also a common
hypothesis used to define the boundary conditions of FE models prior to the
use the deformation models expressed through the FE method.
This allows us to safely apply rigid body statics and kinematics throughout
our analysis. This means also that the geometry of the DMU can be
used straightforwardly.
Another common assumption that we make in default of any other clue
is that connections between components of the assembly are ideal, thus
frictionless. This can be generally formalized as follows.114 Chapter 6. Qualitative Behavioral Analysis
Hypothesis 6.2 (Conservative systems). Unless otherwise stated, the set
of components of the assembly forms an energy-conservative system. This
hypothesis imply that contacts are frictionless, i.e., there is no tangential
force between contact surfaces between any two components. We assume
the state of contacts is not changing, i.e., a pair of solids having a planar
support remain in contact. If not so, this means that the current RS is no
valid and a switch to a new one must be operated.
This allows us to safely alternate between kinematic and static properties
of interfaces, knowing that no work is done when two components move
as per DoF allowed by an FI, or when internal loads propagate from one
component to another through an FI. Again, this is the default configuration
often used during design processes. Friction, however, can be of function
importance and, it this particular case, lead to specific models as it will
appear later on.
In the scope of this work, we only consider mechanical interactions between
components in a product. This is because the recognition of other
types of interactions, such as electromagnetic ones, require information beyond
product geometry. Such information is not available in a DMU the
way we consider it as an input to our analysis (see Section 1.11). Indeed,
the objective of the proposed approach is to set up a process as automated
as possible, in a first place. We state the aforementioned assumption as
follows.
Hypothesis 6.3 (Mechanical interactions). In the scope of this study, we
consider forces internal to a product to be purely mechanical and generated
by solid components.
This allows us to ignore forces generated by electromagnetic fields, fluids,
. . . and to be consistent with the assembly model effectively input, i.e.,
the geometry of each component is known but there is no explicit representation
of fluid and gaz domains in a DMU.
6.3 Qualitative representation of physical properties
In order to relate geometry to behavior, as a prerequisite to relate geometry
to function, we need first to dress geometry in a DMU with physical properties.
Properties of interest can either originate from statics, such as forces
and torques1 or kinematics, such as linear and angular velocities.
As long as functionality is concerned, this dressing should happen at the
component interface level, i.e., the CI level, as it is the place from which
1A torque being the moment of a force vector about a given axis.Qualitative representation of physical properties 115
functionality actually emerges. Section 5.4.1 showed how a functional interpretation
of a CI connects it to a geometrically possible FI, in the light of
industrial common practices. In fact, physical behavior, such as static and
kinematic properties of an interface, directly relates to function [72, 136],
as shown in Section 2.3.1. Making a functional assumption about a CI,
the way a functional interpretation does, allows us to cast a behavioral –
thus physical– dimension on the interface, as will be shown in more details
hereafter.
Section 4.1 showed the motivation behind a purely qualitative approach.
All studied physical attributes should thus support this requirement. In this
section, we explain how static and kinematic properties can be expressed as
qualitative values, before they are used to reason upon functional properties
of components. We therefore provide our method with adequate data
structures and their corresponding operations, arithmetics, and inference
algorithms. Here, we promote an algorithmic approach since the concept
of RS, the static and kinematic behaviors, are independent of a domain
knowledge.
6.3.1 Qualitative physical dimension
An FI is given a physical dimension by associating it with a characteristic
wrench screw2 W = { �f|�t} representing force and torque applied through
the corresponding FI from one component onto the other one where FI is
defined. This assumption is possible in light of Hypothesis 6.1 and Poinsot’s
theory [132] that states that any system of external force exerted on a rigid
body can be resolved by one force, and a torque on a plane perpendicular
to the force direction.
The abstract class Screw represents a general screw as two vectors (objects
of the class ScrewVector) in our data structure scheme.
Values of force and torque vectors, however, are not scalars, as expected
in a general dual vector, but qualitative symbols. These values decide in
which direction, for a given vector component, a force or a torque may, or
should, propagate. The following is a comprehensive list of nominal values
that is used to this end.
Not Null: indicates that the underling FI propagates internal force/torque
in either orientation along the corresponding axis.
Null: indicates that the underling FI does not propagate any internal force/torque
along the corresponding axis.
Strictly Positive: indicates that the underling FI propagates internal force/torque,
in the positive direction only, along the corresponding axis.
2Refer to Appendix C for details on screws and their representation as dual vectors.116 Chapter 6. Qualitative Behavioral Analysis
Table 6.1: Qualitative vector values
Value Symbol Real interval
Not Null � ] − ∞, 0[ ∪ ]0, +∞[
Null � [0, 0]
Strictly Positive � ]0, +∞[
Strictly Negative � ] − ∞, 0[
Arbitrary � ] − ∞, +∞[
Strictly Negative: indicates that the underling FI propagates internal
force/torque, in the negative direction only, along the corresponding
axis.
Arbitrary: indicates that the underling FI may or may not propagate internal
force/torque, in either direction, along the corresponding axis.
Each FI is associated to a specific geometric configuration. For instance:
• spline and threaded links, and snug and loose fits, are associated geometrically
with a couple of cylinders;
• planar and circular supports can be associated with a couple of planes
and a plane and a torus, respectively;
• a linear support can be associated with a cylinder lying on a plane.
This enables an FI to acquire a local coordinate system, the same way
a CI does (see Figure 5.4). A wrench screw, defined as a dual qualitative
vector of values of Table 6.1, is then expressed in this local coordinate system
and attached to the FI.
As a subclass of Screw, the class RelativeScrew represents qualitative
dual vectors expressed in a local coordinate system in our application.
When a FI is processed, its local coordinate system is aligned with the
local coordinate system of its underlying CI, which is in turn defined under
the global coordinate system of the assembly. This allows the behavior
model to locate the qualitative wrench screw globally with respect to the
DMU.
Wrench and twist screws assigned to a planar support
When a planar support, an FI, is associated with a planar contact, a CI,
through a functional interpretation, the corresponding interface refers to
two components C1 and C2. Let us consider that C1 is chosen as reference
component and CI is characterized by its imprint on its surface. Then, aQualitative representation of physical properties 117
local coordinate system is assumed to have its z-axis coinciding with the
contact plane normal, and its origin O� at the barycenter of CI, as shown in
Figure 5.4a. C1 being chosen as reference, we then observe that for an ideal,
frictionless, planar support, as suggested by Hypothesis 6.2, all infinitesimal
external forces that may be exerted by C2 on C1 through CI are normal
to the plane, thus parallel to the z-axis of the interface local coordinate
system. A force can then be expressed in the local coordinate system as
d �f = (0, 0, dfz) where dfz < 0 is the force per infinitesimal area of CI.
Hence, the vector representing the sum of these infinitesimal forces is of the
form:
�f = (0, 0, fz) where fz < 0. (6.1)
To compute the moment vector of �f about the origin O� = (0, 0, 0), we
note that d �f produces a moment of the form: d�t = (P� − O� ) × d �f, where
P� = (x, y, 0) is the position vector where d �f applies in CI, and × is the
vector cross product operator.
d�t = (P� − O� ) × d �f,
= (x, y, 0) × (0, 0, dfz),
= (y dfz, −x dfz, 0) ,
= (dtx, dty, 0)
We observe then that the sum of these infinitesimal torques about O is
of the form:
�t(x0,y0,z0) = (tx, ty, 0). (6.2)
In fact, Equations 6.1 and 6.2 can be expressed by means of a wrench
screw W1 using nominal values of Table 6.1.
W1 =
� �
� �
� �
(6.3)
This physical understanding of a functional interface leads to the same
result if the phenomenon is studied from a pure kinematic perspective. In
the case of planar support, we define FI by its twist screw T1 that represents
the relative velocity (vx, vy, vz) and relative rotational speed (wx, wy, wz)
vectors between C1 and C2 as:
T1 = {w�|�v} =
0 vx
0 vy
wz 0
. (6.4)
This kinematic standpoint can be also regarded from a functional perspective
since T1 expresses the relative movements between C1 and C2 when
their contact is preserved.118 Chapter 6. Qualitative Behavioral Analysis
Definition C.2 states that a pair of wrench screw and twist screw is
reciprocal when the virtual work of the wrench on the twist equals zero.
This can be stated as follows:
dW = 0
(W � T)dt = 0
W � T = 0
{ �f|m� } � {�ω|�v} = 0
�f · �v + m� · �ω = 0.
(6.5)
In the context of this thesis, the component interfaces conform to Hypothesis
6.2 by default. Hence, contacts are frictionless and are neither
power generators nor consumers, meaning that the wrench and twist screws
are reciprocal [133]3.
We thus obtain the following wrench screw of a planar support, that,
along with twist screw T1, satisfies Equation 6.5:
W1 =
0 tx
0 ty
fz 0
(6.6)
Now considering the unilateral geometric configurations of FI, it is necessary
to add the condition fz < 0 to Equation 6.6. We then can express
W1 using qualitative values as shown in Equation 6.3.
Screws applied to cylindric contacts
Another example is a loose fit between C1 and C2, which is associated to a
cylindric contact through a functional interpretation. In this case, we define
the local coordinate system to lay its z-axis on the cylinder axis, while the
origin of coordinates O� coincides with the same axis at barycentric position
of the CI.
Then, we observe that all infinitesimal external forces are radial, i.e.,
normal to the contact surface on C1, in an ideal, frictionless support, as
suggested by Hypothesis 6.2. The vector representing the force applied by
C2 on C1 over a cylindric support is then of the form:
d �f = (dfx, dfy, 0) (6.7)
where the z-axis coincides with the cylinder axis.
The moment, at point O, of an infinitesimal force d �f = (dfx, dfy, 0)
is given by the equation d�t = (P� − O� ) × d �f, where O� = (0, 0, 0) is the
3We actually consider a screw space here, i.e., a space of all screws generated by linear
combinations of one screw of the given form, instead of a single screw, and its reciprocal
screw space. We, however, stick to the term screw in the rest of the document for the
sake of simplicity.Qualitative representation of physical properties 119
z
y
x
Figure 6.1: Vectors of position P� (axial, Q� , and radial, R� , components), force,
F� , and torque �t of a cylindric support, represented in the local coordinate
system of a cylindric contact.
origin of the local coordinate system in use, and P� is the position where the
infinitesimal force applies. P� can be decomposed into two components; the
axial component Q� = (0, 0, z), and the radial component R� = (x, y, 0), we
note that x . dfy = y . dfx since the infinitesimal force applies at P� (see
Figure 6.1).
d�t = (P� − O� ) × d �f, ,
= (Q� + R� ) × d �f,
= Q� × d �f + R� × d �f,
= (0, 0, z) × (dfx, dfy, 0) + (x, y, 0) × (dfx, dfy, 0),
= (0, 0, z) × (dfx, dfy, 0) +�0,
= (dtx, dty, 0).
The sum of such infinitesimal torques about the origin O, is then of the
form:
�t(x0,y0,z0) = (tx, ty, 0). (6.8)
Again, Equations 6.7 and 6.8 can be qualitatively expressed by means of
a wrench screw W2:
W2 =
� �
� �
� �
. (6.9)120 Chapter 6. Qualitative Behavioral Analysis
From a kinematic standpoint, a loose fit can be defined by its twist screw
as follows:
T2 =
0 0
0 0
wz vz
. (6.10)
T2 can be also interpreted from a functional perspective where vz and wz
are the output parameters that express the relative movements of C2 with
respect to C1.
Taking the reciprocal screw of T2, we obtain the wrench screw of this
FI:
W2 =
fx tx
fy ty
0 0
. (6.11)
Using qualitative values of Table 6.1, we obtain the same wrench screw
as in Equation 6.9, showing that no other condition needs to be added to
describe a loose fit.
Qualitative wrench screws applied to contacts
In an analogous manner, a qualitative wrench screw is assigned to each FI.
Table 6.2 shows examples of FIs, and their associated qualitative wrench
screws deduced using the same reasoning as mentioned above. Screws shown
in the table are to be interpreted in the local coordinate systems of the
corresponding CIs, as shown in Figure 5.4. Here, it is important to note
that not all the FIs conform to Hypothesis 6.2. From a functional point
of view, it is necessary to consider configurations where adherence between
C1 and C2 plays a central role. This can be observed when comparing the
loose fit a the snug fit. Independently, of the materials of C1 and C2 and
of the diameter differences between C1 and C2, the design principle of this
fitting is to resist to components fz and tz under working conditions of
a product. This justifies the content of W and T compared to the loose
fit. This observation is critical since, the qualitative screws of the snug fit
differ from that of the loose fit whereas their CI is identical, i.e., in the
assembly model the conventional representations of these FIs are identical
(see Chapters 4 and 5).
Though this is not detailed for sake of conciseness, a similar analysis
applies to the conical support and self-locking fit where adherence is also of
functional effect though it is combined, in this case, with the apex angle of
the cone. This angle is a geometric parameter that influences the adherence
effect of the conical fit. This could hinder the qualitative approach but the
purpose is not to evaluate a design configuration, it is the analysis a valid
ones. Consequently, a first approach can be the categorization of apex angles
from a functional point of view. In this case, apex angles can be categorizedQualitative representation of physical properties 121
efficiently into conical support and self-locking fit using an angle threshold
because this adherence phenomenon varies slowly with respect to the apex
angle and is rather insensitive with respect to the categories of constitutive
materials of C1 and C2. This approach, however, is not the most generic
one. A second one consists in dropping the reference to the apex angle, i.e.,
to geometry and refer to a specific physical behavior. This is the solution
described here at Section 6.5.1.
6.3.2 Algebraic structure of qualitative values
To enable the use of qualitative screws against static equilibrium equations,
certain arithmetic has to be defined on qualitative values represented in Table
6.1. Notably, the addition (+) and multiplication (.) operators. The semantics
of these operators is defined through interval arithmetic [59], where
each qualitative values represent real intervals as Table 6.1 shows.
Given K and L ∈ [R], a set of real intervals, an interval operator � :
[R]
2 → [R] is defined as the interval extension of the real operator � : R2 → R
as follows [59]:
K � L = {z|∃(x, y) ∈ K × L, z = x � y}. (6.12)
To this end, we define addition and multiplication operators on the set
of qualitative values Q = {�, �, �, �, �} as an extension of real addition
and multiplication, by replacing K and L in Equation 6.12 by the interval
each value represents. We obtain the Cayley tables shown in Table 6.3.
Studying addition (+) in Table 6.3, we observe that:
• addition is closed on Q, i.e., all table cells are included in the entries;
• addition is associative, i.e., this can be established using Light’s algorithm
[97]);
• addition has an identity element �, i.e., its raw and column match the
entries;
• addition is commutative, i.e., the table is symmetric.
We establish then, that (Q, +) is a commutative monoid. Now, studying
product (.) in Table 6.3, we observe that:
• product is closed on Q, i.e., all table cells are included in the entries;
• product is associative, i.e., this can be established using Light’s algorithm;
• production is commutative, i.e., the table is symmetric.122 Chapter 6. Qualitative Behavioral Analysis
Table 6.2: Different FIs and the CIs they originate from. Each FI is given
a physical dimension using a qualitative wrench screw W and a qualitative
twist screw T, defining its static and kinematic behaviors, respectively.
Screws are expressed in the local coordinate system of the corresponding CI
(see Figure 5.4).
FI W T CI(s)
Threaded Link
� �
� �
� �
� �
� �
� �
Cylindric Interference
Planar Support
� �
� �
� �
� �
� �
� �
Planar Contact
Spline Link
� �
� �
� �
� �
� �
� �
Cylindric Interference
Snug Fit
� �
� �
� �
� �
� �
� �
Cylindric Contact
Loose Fit
� �
� �
� �
� �
� �
� �
Cylindric Contact
Linear Support
� �
� �
� �
� �
� �
� �
Rectilinear Contact
Circular Lateral Support
� �
� �
� �
� �
� �
� �
Circular Contact
Circular Axial Support
� �
� �
� �
� �
� �
� �
Circular Contact
Conical Support
� �
� �
� �
� �
� �
� �
Conical Contact
Self-locking Fit
� �
� �
� �
� �
� �
� �
Conical ContactQualitative representation of physical properties 123
Table 6.3: Addition (+) and production (.) Cayley tables over qualitative
vector values.
+ � � � � �
� � � � � �
� � � � � �
� � � � � �
� � � � � �
� � � � � �
. � � � � �
� � � � � �
� � � � � �
� � � � � �
� � � � � �
� � � � � �
We establish then that (Q, .) is a commutative semi-group [98].
It can be shown, on a case-by-case basis, that product is distributive over
addition, we thus infer that (Q, +, .) is a semi-ring [98], which is commutative
with � as identity.
We also observe that:
∀p, q ∈ Q, p+q = � =⇒ p = � ∧ q = �;
∀p, q ∈ Q, p . q = � =⇒ p = � ∨ q = �.
It follows that (Q, +, .) is a semi-field [98].
Qualitative values and their arithmetic are defined through the class
ScrewValue in our software application. The class also implements multiplication
between real scalars and qualitative values using interval arithmetic
again. A scalar x is replaced by its singleton interval equivalent [x, x] in this
case.
6.3.3 Coordinate systems alignment
Wrench and twist screws are expressed in the local coordinate systems of
their corresponding FI by means of dual vectors which are referred to as
local dual vectors.
Each local dual vector (an object of class RelativeScrew in our implementation)
has its own Cartesian coordinate system in 3D. When dual
vectors are added, subtracted or multiplied, they must be expressed in the
same coordinate system, i.e., same reference frame and same origin. Unless
all dual vectors share the same coordinate system, a coordinate-system
alignment is thus necessary whenever dual vectors are summed.
Given a dual vector S = {�v|m� } represented in a Cartesian coordinate
system (o, e�x, e�y, e�z), we represent S as {�v�
|m� �
} in a new Cartesian coordinate
system (o, e�x
�
, e�y
�
, e�z
�
). We note that:
�v� = Ω × �v,
m� � = Ω × m, � (6.13)124 Chapter 6. Qualitative Behavioral Analysis
where Ω is the rotation matrix of �v and m� in the new coordinate system:
Ω =
e�x
�
.e�x e�x
�
.e�y e�x
�
.e�z
e�y
�
.e�x e�y
�
.e�y e�y
�
.e�z
e�z
�
.e�x e�z
�
.e�y e�z
�
.e�z
.
If the two local coordinate systems share the same axes, but not the same
origin, it means that the underling wrench or twist screws do not share the
same point of application. Given a dual vector S = {�v|m� } represented in
a Cartesian coordinate system (o, e�x, e�y, e�z), we represent S as {�v�
|m� �
} in a
new Cartesian coordinate system (o�
, e�x, e�y, e�z). We note that:
�v� = �v
m� � = m� + �
λ × �v, (6.14)
where �
λ is the translation vector starting at o� and ending at o, �
λ = −→
o�
o.
Now when neither axes are aligned nor the origin is shared between the
new and the current Cartesian coordinate systems, we first apply Equation
6.13, then Equation 6.14 to obtain a dual vector expressed in the new
coordinate system.
These operators are implemented by the method changeBasis(gp Ax2)
of the class RelativeScrew in our software.
6.4 Reference state I: Static equilibrium
Static mechanical equilibrium RS builds on the fundamental law of dynamics
(Newton’s second law), assuming that all components are at rest.
Hypothesis 6.4 (Static equilibrium). Components of an assembly are at
static equilibrium.
This means that mechanical equilibrium equations hold on each component.
More precisely, components in a DMU should not fall apart either
when the assembly is at rest state or in working conditions. This is equivalent
to consider that every component should not be free to move along
any translational movement, which can allow it to fall apart. A component
however, can rotate freely because a rotational movement cannot separate
a component from its assembly. Because of these observations, this RS can
be applied to a very wide range of DMUs.
Those equations extend our knowledge about the DMU that is built on
its pure geometry model so far. They thus allow the qualitative analysis to
proceed with farther reasoning, particularly, the reduction of the number
of FIs. The mechanical system studied is reduced to a standalone component
and its equilibrium is studied under the actions of its neighboring
components onto it.Reference state I: Static equilibrium 125
6.4.1 Static equilibrium equations
A rigid body, i.e., an assembly component, is at mechanical equilibrium if
and only if it satisfies the following conditions:
1. The vector sum of all external forces applied to this rigid body is zero;
2. The vector sum of all external torques applied to this rigid body is
zero around any given axis.
Since CIs encapsulate all geometric interactions of a component, all mechanical
forces are applied through these interfaces. In the light of Hypothesis
6.3, we can thus state that all forces external to a component are applied
through its CIs.
Let IC be the set of all CIs of a component C. Given �fi the force vector
and t
�i the torque vector that represent the resultants of external forces
applied to C [132] through its i
th interface by its i
th neighboring component,
i ∈ IC. �fi and t
�i are the components of a wrench screw Wi = {�fi|t
�i} applied
to C at its i
th CI, i ∈ IC, then the static mechanical equilibrium of C is
obtained when all such wrench screws sum up to zero {�0|
�0}:
�
i ∈ IC
{�fi|t
�i} = {�0|
�0}. (6.15)
Hence, the goal of the static equilibrium RS, is to check functional interpretations,
FIs, associated to each CI against equation 6.15. This means
that more than one wrench screw Wi, i.e., more than one FI, may exists per
CI and it is the purpose of the behavior expressed by the static equilibrium
RS to provide the qualitative analysis with output parameters that express
the behavior of C with respect to this state. Checking a FI ends up verifying
if C can reach a static equilibrium state.
Summation (addition or subtraction) can only take places on wrench
screws sharing the same coordinate system. In our implementation, summation
of two dual vectors generate a third one expressed under the local
coordinate system of the first operands, where a copy of the second operand
undergo a coordinate system alignment, as explained in Section 6.3.3, before
being summed up. This functionality is implemented by methods
add(Screw) and subtract(Screw) of the class RelativeScrew.
Scaling (multiplication by a scalar) is also defined on qualitative dual
vectors by the method scale(), which accepts either a real scale(float)
or a qualitative value scale(ScrewValue) as a parameter.
6.4.2 Graph search to eliminate irrelevant FIs
An exhaustive search algorithm that returns all valid solutions of a system,
eliminating invalid functional interpretations for each CI, is presented in126 Chapter 6. Qualitative Behavioral Analysis
this section. A valid solution is a set of interpretations, that is a set of FIs,
that satisfy static mechanical equilibrium RS for a given CI. Algorithm 1
sketches the outlines of such an approach.
Algorithm 1 Mechanical analysis
Procedure: analyze
for each component c do
mark c as OPEN
end for
while there is still a component marked as OPEN do
c ← nextOpenComponent()
initScrew ← {(�, �, �)|(�, �, �)}
mark all FIs of all CIs of c as invalid
calculateSum(c, 0, 0, initScrew)
for all invalid FIs: f i do
ci ← CI of f i
other ← opposite component of ci
mark other as OPEN
drop f i from possible interpretations of ci
end for
if Q(c) didn’t change then
mark c as CLOSED
end if
end while
Procedure: calculateSum(c, level, i, base)
if base = {(�, �, �)|(�, �, �)} then
mark all visited FIs as valid
mark all FIs yet to be visited from here as valid
else
if level = |I∗
c | then
if isNullable(base) = true then
mark all visited interpretations as valid
end if
else
ci ← level-th element of I∗
c
for i = 0 to number of interpretation of ci do
f i ← i-th interpretation of ci
screw ← base + f i.screw
calculateSum(c, level + 1, i, screw)
end for
end if
end if
This algorithm traverses the CIG through procedure analyze(), visitingReference state I: Static equilibrium 127
each node at least once, to study the component equilibrium against Equation
6.15. All nodes of the CIG are initially marked as open, i.e., they are
still to be visited. Though the RS described at Section 6.4.1 applies to a
unique component, Algorithm 1 traverses the entire assembly model because
the RS is applied individually to each component of a DMU.
The function nextOpenComponent() returns the next component to
visit. This is the open component with maximum certainty. The certainty
of a component c ∈ C is defined as the reciprocal (multiplicative inverse) of
the product of the number of interpretations over functionally-valid FIs of
the component:
Q(c) =
�
i∈I∗
c
|i|
−1
, (6.16)
where |i| is the number of functional interpretations of the interface i, i.e.,
the number of associated FIs, and I∗
c is the set of CIs involving c for which
there exists at least one functional interpretation (see Section 6.4.3).
If two components happen to have the same certainty, the one with the
smallest |I∗
c | is chosen. This heuristic picks components with higher entropy,
thus higher potential to introduce new information, therefore enhancing algorithm
convergence time.
For the sake of efficiency, certainty is initially calculated and stored
in terms of its reciprocal for each component. Certainty is only updated
component-wise when a functional interpretation reduction occurs to one of
its CI. Comparing certainties reduces to comparing their stored reciprocal,
that are integers.
Component equilibrium is studied through procedure calculateSum().
Before the call to this procedure, all possible functional interpretations are
marked as invalid. Procedure calculateSum() marks an interpretation as
valid if it participates to a solution that satisfies Equation 6.15, as will be
explained shortly. After the call, all interpretations that are still invalid
clearly contradict the mechanical equilibrium RS, thus they are eliminated.
If the call to calculateSum() leads to the elimination of at least one
interpretation, not only the state of the current component is preserved as
open, also the opposite component of the eliminated interpretation interface
is marked as open as well, even if it was closed before. This is because the
removal of one functional interpretation of a CI introduces new knowledge
that may in turn allow for new conclusions if equilibrium equations are
checked again against the involved component.
If no functional interpretation is removed, this means that further reasoning
on the component is meaningless, since it will lead to the same result
(unless this fact is changed, by reducing the number of interpretations again
through the reasoning on a neighboring component, see the previous paragraph),
and the component then is marked as closed.128 Chapter 6. Qualitative Behavioral Analysis
The procedure calculateSum() traverses each FI of component CIs recursively,
through a depth first graph search, where each CI represents a level
in the search tree. The search combines solutions at each node and checks
their validity against Equation 6.15 at leaf level. This is done through the
accumulation of wrench screws, where the wrench screw of the currently
visited FI is added to a sum. The sum is eventually checked whether it is
nullable or not; that is, whether or not Equation 6.15 may hold true. A nullable
qualitative dual vector has all its values in Q0 = {�, �}. As mentioned
at the beginning of Section 6.4 when stating more precisely the concept of
static equilibrium of components used to filter out some FIs, a component
able to rotate only cannot fall apart. Consequently, its strict static equilibrium
equations that end up with: Q0 = {�, �} (see Equation 6.15) can
be relaxed into a weaker form: Q0 = {�, �, �, �, �}, that authorizes the
component to rotate but not to translate.
If the resulting wrench screw is indeed nullable, all visited functional
interpretations are marked as valid. To enable this backtracking, a record
of visited interpretations is kept. This bookkeeping is not mentioned in the
outlines of Algorithm 1 for the sake of simplicity.
An enhancement is introduced to the algorithm by the early determination
of valid solutions when the sum of wrench screws related to component
c represents a rigid link, that is, it equals the qualitative dual vector
{(�, �, �)|(�, �, �)} stating that c cannot move with respect to its
neighboring components. In this case, summation will always lead to the
same wrench screw, which is indeed nullable. Therefore, the recursion is
interrupted, and interpretations still to be unfolded from this point, besides
those already visited, are marked as valid, as the algorithm shows. This
enhancement is justified by the fact that a fair amount of components in an
assembly are generating such rigid links, e.g., screws, nuts. Consequently,
their specific processing speeds up the overall treatment of an assembly.
At each iteration in procedure analyze(), calculateSum() is called, after
which either a component is closed or at least one functional interpretation is
dropped. A component can only be reopened at the expense of one dropped
functional interpretation. Since the number of components is bound in a
DMU, and so is the number of functional interpretations, the algorithm
is guaranteed to terminate in finite time, given that calculateSum() does.
Note that the number of functional interpretations is only a theoretical upper
bound to the number of iterations, since only a limited number of functional
interpretations are actually dropped from a given CIG.
Procedure calculateSum() is a breadth-first traversal algorithm, that
runs in O(
�
I |i|) time in the worst case. This complexity however, is significantly
reduced by early determination of rigid links.
Algorithm 1 is implemented by the method analyseInterpretations()
of the class ExhaustiveMechanicalAnalyser.Reference state I: Static equilibrium 129
6.4.3 Local failure of functional interpretation
A component fails to be functionally interpreted when no valid functional
solution is found by Algorithm 1 for that component under assumed hypotheses.
This occurs either when friction is involved (Hypothesis 6.2 does
not hold) or when the model is not consistent (Hypothesis 6.4 does not hold,
and components are likely to fall apart). In either case, the corresponding
component is signaled to the user as a potential inconsistency. A failure in
case of inconsistency related to the friction hypothesis can effectively occur
when components are touching each other along planar faces in the assembly
model and no other information is available. Back to the concept of
conventional representation, this can refer to configurations where the corresponding
CI is not a FI of type planar support but should be interpreted
as a glued link or a weld. Though this type of FI has not been mentioned
in Chapter 4 and Chapter 5, DMUs often represent welds and glued links as
contact configurations. Processing efficiently these configurations is left for
future work. Similarly, if the failure reflects a assembly model inconsistency,
this is not in the scope of the present approach and is part of future work.
As a result, all functional interpretations of all CIs of the component
are dropped. The set I∗
c reduces to the empty set in this case, and the
uncertainty of the component is assumed zero.
To avoid a cascading collapse in which a failure to interpret component
CIs propagates to neighboring components, resulting in a failure to interpret
them as well, an so on across the assembly model, graceful failure measures
are inserted into the algorithm. This is obtained by virtually dropping
defective CIs, introducing I∗ ⊆ I, the set of functionally-yet-valid CIs; that
is the set of CIs for which at least one functional interpretation exists.
This fault tolerant approach prevents a local inconsistency from hindering
reasoning elsewhere across the DMU.
6.4.4 Graph search example
In this section we show a simple example that demonstrates the abovementioned
algorithm. The same principles also apply on more complex and
complete assembly models.
We build on the example of the capscrew-nut assembly shown in Figure
5.5. Only the CIG of the model is passed as input to Algorithm 1,
enriched with functional interpretations as shown in Figure 5.6.
Since the model is partial, and for the sake of conciseness, we only demonstrate
here the execution of the algorithm on one component; that is C.
Initially, components C and D are open. We know that the algorithm picks
component C first, as its certainty,
Q(C) = (|CI1| × |CI2|)
−1 = 1/(2 × 1) = 1/2130 Chapter 6. Qualitative Behavioral Analysis
is the highest one in the assembly. For example, the certainty of component
D,
G(D) = (|CI1| × |CI4|)
−1 = 1/(2 × 2) = 1/4
is lower than that of C.
Figure 6.2 shows the complete search tree that procedure analyze() of
Algorithm 1 traverses to find valid solutions. The figure shows that at each
level of the tree; that is a functionally-yet-valid CI of the component, two
things happen:
• Firstly, the search tree forks in as many branches as remaining functional
interpretations of CI;
• Secondly, and for each branch, the wrench screw of the FI of the
corresponding functional interpretation is added qualitatively to the
wrench screw sum.
At the leaf level, and when no more CIs are to be visited, the wrench
screw sum is checked for ‘nullifiability’. The example shows two paths, the
first one led to the wrench screw {(�, �, �)|(�, �, �)} produced by the FI
spline link. This solution path is rejected because of the existence of the
strictly negative qualitative value �, that cannot be nullified, contradicting
Hypothesis 6.4. From a technological point of view, this is consistent because
replacing the screw thread by a spline link would let the component D fall
apart, as well as C.
The second solution path led to the wrench screw {(�, �, �)|(�, �, �)}.
This solution is acceptable, as all values of the wrench screw are nullable,
satisfying the mechanical equilibrium RS. Consequently, all functional interpretations
along the way to this valid solution are marked as valid. Namely,
CI1 as a threaded link and CI2 as a planar support.
As the functional interpretation of CI1 as a spline link did not appear
in any valid solution, it remains marked as invalid, and thus is eliminated.
Certainty of component C is then updated to its new value Q(C) = 1, which
ends the algorithm in the present case.
6.5 Reference state II: Static determinacy
The first RS leads to the reduction of the number of functional interfaces,
eliminating geometrically suggested solutions that are mechanically invalid.
This is a first illustration of a qualitative behavior analysis that is coupled to
geometry, i.e., the shape of CIs, and functions, i.e., the FIs associated with
CIs, to exploit the dependencies between form – function – behavior and
robustly enrich a DMU with functional information at the level of component
interfaces.Reference state II: Static determinacy 131
or
and
Start
and
Spline Link
and
Threaded Link
or or
and
Planar Support
and
Planar Support
Cylindric Interference
Planar Contact Planar Contact
CI1
CI2
ΣW= ΣW=
ΣW=
ΣW= ΣW=
+
+
+
+
Figure 6.2: The search tree visited by Algorithm 1 in order to check the
static equilibrium validity of FI of CI of component C shown in Figure 5.5.
The tree shows two paths, one leading to a nullable qualitative dual vector,
i.e., a valid solution, and the other one leads to a non-nullable qualitative
dual vector, i.e., an invalid solution. This leads to the elimination of the
function interpretation binding interface CI1 with the FI spline link.
However, this elimination does not always lead to a one-to-one mapping
between CIs and FIs, as for some configurations, more than one solution
actually satisfies mechanical equilibrium, thus RS I.
To demonstrate such a configuration, we consider the example of a bolted
assembly shown in Figure 5.5 with a conical head capscrew as component
D on which we now focus. We recall that this functional knowledge about
components, i.e., the ‘component names’, and component groups, i.e., the
concept of bolted assembly, is not yet available at this stage of reasoning.
Section 6.4.4 showed how Algorithm 1 runs on component C of this bolted
assembly where C features a ‘planar support’ rather than a conical one,
successfully reducing the number of valid solutions to one, thus setting the
number of FI per CI to exactly one for C. Interfaces CI1 and CI2 are said
to be definitively interpreted.132 Chapter 6. Qualitative Behavioral Analysis
or
and
Start
and
Self-lock
and
Conical Supprot
or or
and
Threaded Link
and
Threaded Link
Conical Contact
Interference Interference
CI4
CI1
ΣW= ΣW=
ΣW=
ΣW= ΣW=
+
+
+
+
Figure 6.3: The search tree visited by Algorithm 1 in order to check the
static validity of FIs of CIs of component D shown in Figure 5.5. The
tree shows that all leaves, two in this case, leads to a nullable qualitative
dual vector, thus a statically valid solution. No functional interpretation is
eliminated in this case.
Now, considering the equilibrium of component D in accordance with
Algorithm 1, we first note that only two solutions are left after the elimination
of the interpretation of CI1 as a spline link. The remaining solutions
are:
• Interpreting CI1 as a threaded link, and CI4 as a conical support;
• Interpreting CI1 as a threaded link, and CI4 as a self-locking link.
As shown in Figure 6.3, both remaining solutions are indeed statically
valid. The execution of procedure analyze() leads to no reduction in number
of functional interpretations, thus no change in components uncertainty
H(D). Consequently, component D is closed, and will remain this way until
the algorithm converges and returns.Reference state II: Static determinacy 133
This uncertainty prevents us form attributing functional properties to
geometric elements in a decisive manner. The problem stems from the existence
of more than one valid solution, even though solution are not equally
relevant.
A mechanism should thus be established to evaluable the relevance of a
valid solution. If such a mechanism existed, discouraged, e.g., unnecessarily
costly, solutions can be further rejected in favor of more convenient ones.
6.5.1 Statically indeterminate configurations
A close study of the example illustrated above shows that the two remaining
solutions differ from each other in a discriminant way. Although both of
them are statically valid, as the Algorithm 1 proves, the first solution is
isostatic, or statically determinate, while the second one is hyperstatic, or
statically indeterminate [123]. A statically indeterminate system can be
characterized as follows (see Figure 6.4). This example shows a horizontal
cantilevered beam at point A and its opposite extremity B leans on a rigid
contact. Now, considering the static equilibrium equations of the beam that
reduces to a simple planar problem, it comes, in the reference frame (A, �x, �y):
fAx = 0, (6.17)
fAy + fBy − F = 0, (6.18)
tA + LfBy − L
2
F = 0, (6.19)
where the wrench screw at point A is defined by {fAx, fAy|tA} and with
{0, fBy|0} at point B, L is the length of the beam, and F is an external
force.
It appears that this equation system is under determined, i.e., there are
three unknowns and two equations. From a mechanical point of view, this
system is said statically indeterminate of order 1. Such a configuration is
classical in strength of materials and the approach commonly used to find
a solution is to refer to the deformation behavior of the beam. Indeed, the
bending behavior of the beam brings one more independent equation that
can be used to solve the system. From a mechanical point of view, it means
that the internal energy of the beam, i.e., its strain energy, contributes to
the wrench screws at the interfaces A and B of the beam.
Now, coming back to the example of Figure 5.5 and the two alternatives
of FIs that can be assigned to the conical contact of D, they differ from each
other by the adherence effect that takes place with the self-locking fit when
the cone apex angle is small (see Section 6.3.1). In this case, the adherence
and compression of the conical component is able to develop an axial force,
opposite to an external one, hence the designation self-locking fit.134 Chapter 6. Qualitative Behavioral Analysis
Figure 6.4: An example of statically indeterminate mechanical system with
one parameter.
In the first solution of component D, i.e., conical support, and in the only
solution of component C, each and every interface participates to the equilibrium
of D. Dropping one interface would render the component invalid
statically since the conical support does not incorporate any friction effect.
This makes these solutions statically minimal, or determinate. In contrast,
the second solution of component D, i.e., self-locking fit, is redundant in the
sense that not every interface is strictly necessary to the equilibrium. In
fact, a self-locking link is enough on its own to maintain the component D
along the z-axis. Subsequently, a threaded link acting along the same axis
with the same orientation as the self-locking fit increases the internal energy
of this simple mechanical system while not being strictly necessary to the
static equilibrium of D. This makes this second solution statically redundant,
or indeterminate. Geometrically, this second solution is only valid for
small cone apex angles.
Because of this redundancy, statically indeterminate configurations are
avoidably expensive. They are thus uncommon in industrial products if not
strictly necessary, e.g., in Figure 6.4, the rigid contact added at point B reduces
the displacement of the beam at the point where F is applied compared
to the displacement at the same point if the beam was cantilevered only.
Here, adding the rigid contact increases the stiffness of the beam but adding
this contact requires more components than the solution with a simple cantilevered
beam, hence this solution is more complex to set up. However, a
designer may resort to deliberately introduce statically indeterminate mechanism
to convey certain functionality, such as reinforced fastening. This
leads to the following hypothesis.
Hypothesis 6.5 (Static determinacy). Unless functionally justified, statically
indeterminate structures are disfavored in a product assembly.Reference state II: Static determinacy 135
Consequently, the self-locking fit of Figure 5.5 is filtered out. It has to
be pointed out that this filtering criterion is generic, hence it is independent
of any threshold value, e.g., the cone apex angle threshold mentioned at
Section 6.3.1.
More generally, Figure 6.5 shows examples of two plates assembled together
by means of fasteners. Their assembly can be achieved through
statically determinate structures, using one or two threaded links (see Figure
6.5a, b). Fastening can be secured through a statically indeterminate
configuration with an additional locking nut, where static indeterminacy
plays a functional role (see Figure 6.5c). Finally, Figure 6.5d shows a nonfunctional
statically indeterminate configuration, if the cylindric contact is
to be interpreted as a snug fit. The latter interpretation exhibits functional
inconsistency and should be avoided in industrial products.
Hypothesis 6.5 provides the necessary criterion against which statically
valid solutions that survived RS I can be filtered out.
In fact, statically indeterminate configurations could have been recognized
during the evaluation of mechanical equilibrium in Algorithm 1. For
example, a statically indeterminate solution could have been identified while
wrench screws are summed, when a nullable qualitative value, i.e., � or �,
is added to another qualitative value rather than zero �. Accordingly, undesired
statically indeterminate solution could have been eliminated since
the first round.
However, some of statically indeterminate configurations constitute the
only possible static solution of a component. In this case, the static indeterminate
configuration is functional. Such a solution should not be eliminated
when it is unique, however, whenever there is a functional interpretation
conflict, a statically determinate solution prevails.
Consequently, statically indeterminate solution necessity cannot be judged
component-wise. Since if a statically indeterminate solution is found unnecessary,
as it has a statically determinate alternative for a given component,
all functional interpretations participating to the solution would not be validated,
thus are likely to be dropped (unless they participate to one of the
statically determinate solutions). This elimination, however, may affect the
propagation of equilibrium on neighboring components.
The static validity of model should thus be checked independently from
its static determinacy. For this reason, the ‘pruning’ of the solution tree must
occur after reasoning on the RS I is done, where all components playing a role
in a statically indeterminate structure are studied at once. If a solution is
to be eliminated, another statically determinate solution should be ensured
for the whole structure. This analysis shows that RS II can be regarded as
a reference state independent of RS I and must be applied after RS I.
This requires the study of internal forces propagation paths. In fact,
statically indeterminate structures are characterized by a cyclic force propagation
along one or more axis, e.g. in case of the example in Figure 6.4,136 Chapter 6. Qualitative Behavioral Analysis
(a) (b)
(c) (d)
Figure 6.5: An assembly of two plates by means of a fastener: (a) A statically
determinate solution, using a capscrew and a nut, with one threaded
link, thus one internal load generator, (b) Another statically determinate solution,
using a bolt with two nuts, and two threaded links, thus two internal
load generators, (c) A statically indeterminate solution, with one capscrew
and two nuts, the lowest one acting as locking nut. Static indeterminacy
plays a functional role here, which is to reinforce fastening, (d) A statically
indeterminate configuration if the cylindric interface between the capscrew
and the upper plate (light brown) is to be interpreted as a snug fit. Static
indeterminacy is non-functional here, and is considered as an unnecessary
burden.Reference state II: Static determinacy 137
the statically indeterminate configuration is characterized by the load cycle
along the �y axis. In order to outline indeterminate configurations, internal
force propagation cycles should first be reported.
6.5.2 Force propagation and force propagation graphs
Internal force propagation paths can be formalized through force propagation
graphs (FPGs), which are defined as follows.
Definition 6.2 (Force Propagation Graph). A force propagation graph
(FPG) is a graph Γ(D, J) that represents the propagation of internal forces
in a model, along a given direction.
We know that each FPG is a subgraph of the CIuG, augmented with
an orientation at each edge according to the conventional positive orientation
of the force propagation direction taken as reference. This is a result
of Hypothesis 6.3 that implies that internal forces only propagate through
CIs, which are CIuG edges. Edge orientation is a matter of convention in
both CIG and FPG. Orientation convention in the CIG (see Section 5.2.5)
becomes meaningless when applied to force propagation, therefore we refer
to the CIuG, the undirected version of CIG, as the super undirected graph
of all FPGs.
In a given assembly model, there are as many FPGs as there are force
propagation directions defined by FIs. Theoretically, a force can propagate
in an assembly in all directions, that is, an infinite number of propagation
directions in 3D space. This is justified when considering that components
are behaving like deformable media, producing stress and strain fields when
subjected to external forces. This leads to an infinite number of potential
force propagation graphs. Here, we refer to Hypothesis 6.1 where components
are rigid bodies. Consequently, forces follow the directions given by
FIs and because the number of edges in CIuG is bound, there exists an upper
limit on the number of its subgraphs, thus an upper limit on the number
of FPGs.
Figure 6.6a gives an example of such a load cycle. This load cycle is
initiated by an FI of type threaded link connecting C1 and C4. The direction
assigned to the force cycle is prescribed by the force of this threaded
link. This force is then propagated with static equilibrium equations in that
direction. Considering C1 as reference component, its equilibrium equation
determines the force applied by C2 (light brown downward on Figure 6.6a).
Then, moving to component C2, its equilibrium equation determines the
force applied by C3 (green upward on Figure 6.6a). Then, moving to component
C3, its equilibrium equation determines the force applied by C4 (red
upward on Figure 6.6a). Finally, moving to component C4, its equilibrium
equation determines the force applied by C1 (gray upward on Figure 6.6a)138 Chapter 6. Qualitative Behavioral Analysis
C1
C2
C3
C4
C5
(a) (b)
Figure 6.6: (a) An example of load cycle. Ci designates the components
involved in the load cycle. C1 contains a threaded link that originates the
load cycle. The dotted rectangles represent the external forces applied to the
corresponding component Ci. (b) An example of load cycle incorporating a
statically indeterminate configuration. Here, the component C1 is subjected
to multiple forces with the same orientation that characterizes its static
indeterminacy.
that is consistent, i.e., opposite, with the force applied by C4 on C1 that has
been used initially. This ends the determination of the load cycle.
6.6 Reference state III: Assembly joint with threaded
link as functional cluster
As Chapter 7 will reveal, later stages of our approach build on the organization
of sets of components that participate to the fulfillment of one
functionality in one functional group, and on the labeling of such groups
by their corresponding FCs (see Section 4.2.4). An example is the clustering
of components that are held up together using a tightening mechanism.
The corresponding cluster defines effectively a functional group where the
function can be stated as fastening a set of components, i.e., the tightened
components are a subset of the cluster and the complementary subset describes
the fasteners contributing to this function. If such a fastening process
is accomplished through a threaded link, the functional group can be labeled
as assembly joint with threaded link where assembly joint with threaded link
is a FC designating a set of components held –or joint– together by means
of a threaded component.
In fact, the detection of cyclic internal force propagation, required forReference state III: Assembly joint with threaded link 139
static determinacy analysis, regroups components that participate to common
functions such as fastening. This enables their clustering into functional
groups of assembly joint with threaded link.
Effectively, the set of components refers to a function. One component,
the fastener, generates a given input parameter, i.e., here it is a force, and the
interaction forces between components propagate through the assembly. The
output parameters are characterized by the corresponding force propagation
cycles and the force parameters at each CI of the cycle. This analysis enables
the definition of a reference state expressing a fastening process. This is
designated as RS III since the behavior observed is based on the action of a
fastener and this action is effectively independent of the criteria governing
RS I and II.
Hypothesis 6.6 (Force propagation). An FI capable of a fastening action
generates a force through its neighboring components that propagates
through the assembly and ends up producing a cyclic graph.
In case the force propagation mechanism does not produce a cycle it
means that a fastening process may exist but:
• it takes place with objects outside the product, e.g., a vice has a fastening
function but this function is performed on an object external
to the product;
• or it indicates an inconsistent design.
In both cases, a user input is mandatory to characterize these configurations
and they fall out of the scope of the proposed approach which concentrates,
in a first place, on the assembly as a standalone set of components.
To achieve the above-mentioned benefits, an algorithm has to be established
to detect cyclic internal force propagation paths.
6.6.1 Detection of force propagation cycles
In this section we define an algorithm that integrate Hypothesis 6.5 into our
qualitative reasoning to further reduce the number of function interpretations
per CI by the elimination of statically indeterminate solutions, whenever
another statically determinate solution exists for the studied structure.
As mentioned in the previous section, force propagation cycles are also useful
to identify functional clusters of type assembly joint with threaded link. This
algorithm will be used also in these configurations, whenever a threaded link
is involved in such a cycle.
We are interested in the type of statically indeterminate structures that
involve a FI generating forces internal to an assembly. We refer to those
interfaces as internal load generators. Examples of such FIs are threaded
links and self-locking links. Figure 6.6b gives a example configuration where140 Chapter 6. Qualitative Behavioral Analysis
the load cycle produces a statically indeterminate loading of component
C1. As observed, components C4 and C5 each apply a force on C1 in the
same direction and with the same orientation. This results in a statically
indeterminate configuration of C1. Now, the criterion to identify a statically
indeterminate configuration can be stated as follows. A component
is subjected to statically indeterminate loading in the direction set for the
load propagation process if there exists at least two forces applied to this
component that share the same orientation.
FPGs are not readily separable from their supergraph; the CIuG. This is
because the CIG, thus the CIuG, has no notion of force propagation direction
expressed in a global coordinate system. Although this can be calculated
based on CIs’ associated local coordinate systems and their transformation
matrices in the assembly coordinate system, this exhaustive subgraph generation
is unnecessarily costly.
Alternatively, relevant force propagation subgraphs are generated incrementally,
following edges of the CIuG, and starting with an edge that is
indeed an internal load generator.
Procedure f indLoadCycles() iterate over all interfaces that qualify as
load generators, and identify the force cycle to which they participate by a
call to function followLoad(). If the original load generator is actually a
threaded link, as decided by function threadedLink(), the identified cycle is
marked as functional group, and labeled as an assembly joint with threaded
link.
Function followLoad() uses a classical breadth-first cycle detection algorithm.
The initial call of the function takes an interface i which is guaranteed
to be a load generator by the calling procedure. It also takes the force propagation
direction and orientation, represented by its unit vector �χ, which is
an intrinsic property of each load generator. The algorithm applies to the
FPG characterized by the direction �χ, we refer to this graph as Γ�χ.
Since FPGs are not generated ahead of time, function f indReciprocal()
is used to ‘sense’ the CIG edges, and follow those who actually belong to Γ�χ.
Function f indReciprocal() is also responsible of the elimination of statically
indeterminate functional interpretations. Static determinacy is evaluated
each time the function is called, according to the direction �χ. If at least one
functional interpretation maintain a statically determinate solution, other
static indeterminate functional interpretations are dropped.
Once a cyclic path is detected, the generation of the subgraph; i.e.,
Γ�χ, is stopped, and a candidate functional group is reported to procedure
f indLoadCycles(). The breadth first algorithm guarantees that the smallest
cycle is detected for a given internal load generator.
Cases of statically indeterminate configurations are essentially characterized
when the number of cumulative forces with the same orientation exceeds
one. More general configurations are left for future work and reveal some
design inconsistencies that are not in the scope of the present approach.Reference state III: Assembly joint with threaded link 141
Algorithm 2 Load Cycles Detection
Procedure: f indLoadCycles
boltedJoints ← ∅
for all load generating interfaces i do
mark all components of the assembly as WHITE.
cycle ← followLoad(i, �χ)
if threadedLink(i) then
boltedJoints ← boltedJoints + cycle
end if
end for
Function: followLoad(i, �χ)
u ← right(i)
while true do
mark u as GRAY
for all j in f indReciprocal(i, u, �χ) do
v ← opposite(u, j)
if v is GRAY then
lc ← new empty load cycle
while v �= u do
add v to lc
backEdge ← pred[v]
v ← opposite(v, backEdge)
end while
return lc
else if v is WHITE then
pred[v] ← j
followLoad(j, �χ)
end if
end for
mark u as BLACK
end while142 Chapter 6. Qualitative Behavioral Analysis
6.7 Conclusions
In this chapter, concrete methods and data structures are presented to capture
mechanical behaviors at the interface, the component, and the component
group levels. Each mechanical behavior is then employed to attribute
functional knowledge to geometric elements at each of these levels, in relation
to what was established in the literature, and studied in Section 2.3.
To enable this employment, referential behavioral standards are formalized
in terms of RSs, defined in Definition 6.1. RSs add up to the knowledge
base through the formalization of domain knowledge into hypotheses that
are assumed to hold true in the context of a given state of the product (see
Section 6.2).
A qualitative behavioral framework based on nominal physical values is
defined in Section 6.3, to empower the purely qualitative approach promoted
in Section 4.1. This framework casts a physical dimension onto different FIs
in relation with the geometric configurations they interpret, as represented
by their associated CIs. This physical reading of the model allows qualitative
simulation processes to assess the model mechanical and functional validity.
Before any RS is applied to the model, the functional knowledge consists
in what could be induced on pure geometrical basis; that is a number of
functional associations, in terms of FIs, to each CI, as shown in Section 5.4.1.
However, this number is not always one per interface. The multiple nature
of functional interpretations in the general case introduces uncertainty to
the knowledge base. This half-knowledge needs to be cleared if any reliable
functional conclusion is to be withdrawn to the benefit of applications such
as FE simulation and analysis.
To this end, Section 6.4 presented RS I, that is used to check knowledge
consistency against static equilibrium equations. This leads to the reduction
of uncertainty as statically invalid functional associations of CIs are dropped.
However, examples show that although all statically invalid solutions are
selected out, the number of those remaining; i.e., statically valid, still does
not allow for a single positive functional solution.
RS II presented in Section 6.5 provides the qualitative approach with a
supplementary criterion that takes into account not only solution validity,
but also its quality with respect to its complexity, therefore its cost. Solution
complexity is determined in view of its static determinacy. Unless static
indeterminacy is functional in a solution, it is considered to be unrealistic
in an industrial context, consequently such a solution is eliminated, leading
to a further decrease in the number of FIs per CI.
RS III presented in Section 6.6 adds also another criterion that relates
to the fastening function of a group of components. This function interacts
with RS II through the definition of load cycles.
Most importantly, the qualitative approach set up has shown how it
combines with the geometry of CIs to enforce functional information at theConclusions 143
level of FIs and extend to the components and to groups of components.
Finally, if the number of remaining statically determinate interpretations
per CI still exceeds one, the most ‘probable’ solution would become
a criterion. Probability here is defined by means of solution popularity in
industrial DMUs when more than one survive RS I and RS II. Note that
this measure is only taken as a last resort, in order to force a single FI per
CI. In the studied industrial examples, however, this last filtering was not
needed, hence not used and left for future work like other configurations
where user’s interactions would be needed to process design inconsistencies
or functions involving objects outside the DMUs.
The qualitative approach visited in this chapter allowed for the cleansing
of the function knowledge associated to a DMU, reducing it to only positive
facts about component interfaces and component groups. These facts
actually provide the seeds of more elaborate knowledge, if combined with
inference rules, as the following chapter will develop.Chapter 7
Rule-based Reasoning to
Derive Functional
Denominations
As for now, only functional interactions were addressed in our qualitative
analysis to filter out FIs and produce a precise spatial distribution
of FIs. These FIs are consistent with the DMU both from
some behavior point of view as well as geometrically. Now, the
DMU is functionally interpreted in a definitive manner at the levels
of functional interfaces and functional groups to take advantage
of its form - behavior consistency and derive a consistent function
at the level of each of its components.
However, in order to provide a complete functional description
of a model, functionality at the functional unit level should be
addressed. This chapter deals with annotating components with
their functional denominations, i.e., their FDs.
Section 7.1 first illustrates the importance of such functional
information, before Section 7.2 shows that this knowledge is the
extension of the knowledge acquired so far after the application of
domain specific rules, i.e., it takes advantage of the function dependency
with respect to behavior and form concepts. Section 7.3
discusses alternative solutions to integrate such domain rules into
our knowledge base. As a strongly related topic, knowledge representation
is addressed in Section 7.4, before that Section 7.5 gives
an in-depth demonstration of the formal reasoning process. Section
7.6 concludes, showing how functional knowledge is saturated
generating the required functionally interpreted DMU model.146 Chapter 7. Rule-based Reasoning
7.1 Knowledge at the functional unit level
The previous chapter showed a qualitative method that used algorithms,
such as graph searches, to extend knowledge or reduce uncertainty about
functional properties of an assembly. This method came out with functional
facts, particularly at the levels of component interactions, that is, at the
functional interface and the functional group levels, in a reference to what
was outlined in Section 3.4. The corresponding algorithms mapped a consistent
and qualitative behavior to functional interfaces, uniquely associating
each CI to one FI. As an example of such behavior, this mapping also permitted
the clustering of components tightened up together by means of a
threaded link into functional groups referred to as bolted joints. In addition
to the CIG, each behavior extends the DMU structure with a spatial
mapping of the behavior functional meaning.
This algorithmic inference enriched our knowledge about the DMU in
two ways:
• First, reducing ambiguity in statements such as interface i is either
a threaded link or a spline link. This is done through the elimination
of invalid, and unsuitable alternatives (see Section 6.4). For example,
interface CI1 in Figure 5.5 is definitively identified as threaded link.
• Introducing new facts such as stating that interface i participates to an
assembly joint with threaded link. This is done through the detection
of internal load cycles that tighten up components together (see Section
6.5). For example, interfaces CI1, CI2, CI3 and CI4 in Figure 5.5
are found to take part to the same assembly joint with threaded link.
In this sense, our knowledge base only contains positive facts after the
application of RSs validation. The functional interpretations of geometric
configurations are now unique, and uncertainty is reduced to zero. However,
the functional knowledge about the DMU is still not complete. In fact, we
still know little about functional attributes at the component level; that is,
the functional unit level (see Section 3.4). Section 4.2.3 showed that the
functional role, or roles, that a component plays in an assembly identify
its FD. This information is necessary to meet the functional requirement of
geometric model transformation for simulation purposes because an engineer
is used to refer to a function or a group of functions in a synthetic manner
using a ‘component name’ or a simple expression ‘qualifying a component’.
7.2 Inference rules as domain knowledge
This functional knowledge, however, is not beyond our reach. In fact, positive
facts that emerge from the qualitative study explained in Chapter 6 open
new opportunities for reasoning and provide seeds to express new knowledge.Inference rules as domain knowledge 147
To demonstrate this, we take the example of a component X that has
only two FIs. One of them is a planar support, while the other is a threaded
link, and they participate to a functional group LC which has assembly joint
with threaded link as its FC (see Figure 5.5). We can then rationalize that
such a component is indeed a nut, identifying its FD.
It is worth noticing that the newly obtained fact is the result of the application
of an inference rule inspired by the domain knowledge that states
that ‘a statically valid component having only two functional interfaces: a
planar support and a threaded link by means of an internal thread, and involved
in a assembly joint with threaded link, is a nut’. This rule is not
formalized in any RSs.
This type of reasoning can then propagate throughout the assembly
model, building on newly acquired knowledge to generate new facts, until
the knowledge base converges toward saturation. For instance, the application
of another rule stating that ‘a statically valid component that links to a
nut through a threaded link, and that has another functional interface which
is a planar support, is a capscrew’, allows us to deduce that the component
D in Figure 5.5 is indeed a capscrew.
The previously mentioned rules can be formally stated by means of First
Order Logic (FOL) as follows:
nut(X) ⇐= component(X) ∧
threadedLink(I1) ∧
planarSupport(I2) ∧
boltedJoint(LC) ∧
innerF orms(X, I1) ∧
forms(X, I2) ∧
∀I(forms(X, I) =⇒ I = I1 ∨ I = I2) ∧
regroups(B, X)
(7.1)
capscrew(X) ⇐= component(X) ∧
nut(Y ) ∧
threadedLink(I1) ∧
planaSupport(I2) ∧
outerF orms(X, I1) ∧
forms(Y, I1) ∧
forms(X, I2)
(7.2)
In this formalization, each of component, threadedLink, planarSupport,
boltedJoint, nut, and capscrew is a unary predicate, while forms, innerF
orms, outerF orms, and regroups are binary ones.
We note that the variable I in Formula 7.1 is bound. Unlike the other
free variables of the formula that appear in more that one condition of the148 Chapter 7. Rule-based Reasoning
implication, linking them together, I appears only in one condition. It is
thus universally qualified.
Even though the second rule expressed by Formula 7.2 does not mention
components participation to a assembly joint with threaded link in an
explicit manner, this information is implied from the fact that X links to a
nut through a threaded link.
Those rules reflect expertise about the domain of discourse, thus they are
not part of any RS, as they are not hypotheses made in view of a given state
of the product. However, the incorporation of such rules in the knowledge
base is compulsory if functional information of the model is to be explored
sufficiently to meet the objectives of this work (see Section 3.4).
7.3 Reasoning alternatives
A mechanism should thus be established to account for such domain knowledge.
One may suggest the formalization of such rules into algorithms in a
similar manner to RSs. This would mean the expression of each rule through
a code path that assesses the satisfaction of its conditions, before applying
its action. However, such an integration at the implementation level leads
to static rules. Each time a new rule is to be introduced, the code must be
amended, and resources must be recompiled.
While hypotheses made through RS are independent of the particular
domain of application, as static validity and determinacy apply to all disciplines
of mechanical engineering, inference rules are closely related to specific
types of industries and industrial practices. In fact, a list of functional interactions,
i.e., FIs and FCs, can be deemed exhaustive and complete with
respect to a given set of conventional representations of components. A list
of their possible combinations to produce FDs becomes more difficult to set
up because new categories of components may appear. Anyhow, such lists
cannot be ensured to include all FIs, FDs used in all mechanical industries
at present time since conventional representations are not standardized at
present (see Sections 1.6 and 3.2). To cope with this heterogeneous con-
figuration, considering also that the proposed approach builds up on conventional
representations whose consistency has not been analyzed, it is
important to dynamically adjust inference rules, add new ones, or remove
existing ones.
7.3.1 Dynamic formalization of domain specific rules
It is thus advantageous to enable the dynamic addition and modification of
such rules, in order to tune our reasoning in accordance with specific needs of
the particular domain of application, e.g., aeronautic or automotive industries.
The implementation of inference rules as static, hard-coded execution
paths is thus inadequate for such a requirement.Reasoning alternatives 149
The ability to formalize rules in terms of FOL formulas such as Formulas
7.1 and 7.2 incites us to make use of this uniformity. If the sought
system can take such formalization as an input, and then use it to produce
new knowledge, rules can be adapted and augmented according to the
particular domain where they apply.
7.3.2 Problem decidability
In fact, algorithms —referred to as deductive systems— exist to treat rules
and facts expressed in FOL, and deduce new knowledge from them [61, 33,
91]. However, FOL is proven to be undecidable [51, 170]. This means that
although FOL deduction can always find the answer in infinite time if the
answer is positive (FOL deduction is complete), and that answers are valid
when they exist (FOL deduction is sound), no algorithm is guaranteed to
find the answer to any given question in an infinite time of execution.
This is in fact the price of high expressiveness of FOL. If a decidable
deductive system is to be found, some logic constructs, thus some logic
expressiveness, is to be sacrificed. Efforts have indeed been paid in this
direction, to come up with fragments of FOL that are decidable. In this
work we are particularly interested in a family of formal logic languages
that is referred to as Description Logic (DL) [28].
In fact, DL is a family of decidable FOL fragments1 that allow the fine
tuning of reasoning algorithms complexity as a compromise on the logic
expressive power. Moreover, DL provided the theoretical basis upon which
OWL —the ontology language recommended by W3C— is built. Section 7.4
promotes the use of OWL ontologies as the knowledge base containers in this
work.
Algorithms with controllable complexities are developed to allow effi-
cient reasoning using DL. This led to a variety of reasoners that implement
those algorithms, either for commercial use such as RACER [78], or with
open source licencing agreements such as HermiT [155], Pellet [156] and
FaCT++ [169]. Different reasoners treat different variants of DL. Because
of its simple, yet well-defined formalism, interfacing protocols to communicate
facts and queries to reasoners are also established, such as DIG [15].
From the previous analysis and the above-mentioned reasons, the use of
DL to formulate inference rules suggests itself as a natural choice so that
algorithm complexity can be mastered. This is indeed an important point
to stay consistent with the geometric issues addressed in Chapter 5 and
the qualitative reasoning process set up in Chapter 6 so that the overall
DMU enrichment process can be mastered from an algorithmic complexity
standpoint. Section 7.5 will develop in depth on issues related to the formal
1Some DL variants go beyond FOL capabilities, providing operators that require higher
order logic, such as transitive closure of roles or fixpoints [28].150 Chapter 7. Rule-based Reasoning
reasoning employed in our work. Before that, Section 7.4 addresses a closely
related topic, that is knowledge representation.
7.4 DMU knowledge representation
In order to enable the reuse of the acquired functional knowledge about a
DMU at different stages of a PDP, it must be formalized and stored in a
persistent manner. This brings forth the question of how knowledge should
be represented.
Unlike most of other information systems, in an expert system the choice
of method to achieve knowledge persistence is highly related to other choices
about problem solving. This is because the issue of reasoning cannot be
addressed in disregard of that of knowledge representation.
In fact, the way knowledge is represented decides how this knowledge is
made available, in which way it is structured, and what elements it is made
of. Those choices highly influence what kind of reasoning can be made on
that knowledge, and what other information can be driven from. Therefore,
both problems are coupled, and often addressed together in what is referred
to as Knowledge Representation and Reasoning (KRR).
Section 2.6.2 showed that the literature intensively used ontologies to
represent additional non-geometric knowledge about the DMU. Even though
little has been done beyond the representation of facts in the analyzed
works, ontologies, particularly with the powerful semantics of OWL, were
shown to provide solid grounds not only for the representation of functional
knowledge, but also for reasoning on it. Earlier works in the domain of
CAD [127, 157] that concentrated on inference mechanisms was based on
inference engine technologies that was not formalized as DL currently is.
Consequently, there was no reference to the algorithmic complexity of these
processes. Additionally, these approaches were connecting design parameters
to geometric models of components in rather loose manner which was
preventing them from referencing the precise and appropriate geometric areas
of components and the integrity of the geometric model was not necessarily
preserved, i.e., a solid may be transformed into an object that is no
longer a solid. KBE approaches (see Section 2.6.3) appeared as evolutions
of these early approaches linking geometry and artificial intelligence techniques.
KBE concentrates on quantitative approaches to dimension components
or sub-systems, i.e., it refers to the form – behavior dependency. Here,
the knowledge representation is qualitative and can be expressed symbolically,
which is well suited with the use of ontology-based approaches.
In a tight connection to the choice of reasoning formalism, that is DL,
explained in Section 7.3, we opt in this work for representing acquired knowledge
in terms of ontologies, and using OWL-DL language. This has the
following advantages:DMU knowledge representation 151
• The use of OWL ontologies, as a recommended standardized language
[5], enables communication channels with other services through
the well-established paradigms of the Semantic Web. Services may
either be providers to which some tasks can be outsourced, e.g., reasoners,
or consumers that make use of our expert system, e.g., FE
pre-processors;
• OWL has a semantic advantage over its counterparts Resource Description
Framework (RDF) and RDF-S which it actually extends with
agreed-upon high-level semantics. This enables the formalization of
fact and rules in a rather intuitive manner;
• OWL-DL offers a good trade-off between expressive OWL-Full with
poor computational properties, and rather efficient, but quite restrictive
OWL-Lite;
• The use of OWL-DL enables a seamless integration with DL reasoners,
as DL is the formal logic on top of which the language is constructed.
As shown in Section 2.6.2, an ontology has two components. The terminological
part, or TBox noted T , and the assertional part, or ABox noted A.
Both the TBox and the ABox constitute the knowledge base K = �T , A�.
The TBox T contains concept names and role names, and restrictions
on them. While the ABox A contains axioms, which are individual names
and their instantiations.
7.4.1 Ontology definition through its concepts and roles
The proposed ontology is identified by its Uniform Resource Identifier (URI)2,
and defined by its TBox, as it contains the domain knowledge (see Section
2.6.2). ABoxes, containing the model knowledge, are then generated
and stored apart, for each analyzed model. We recall that model knowledge
is only interpretable in the context of domain knowledge, as Section 2.6.1
has shown. Therefore, before the model is treated, the ontology, in terms of
its TBox, is loaded.
All introduced concept and role names have the namespace romma. In
this text, and for the sake of readability, we refer to the concept name
romma:Component as simply :Component, assuming that romma is the default
namespace.
For the sake of clarity, we use the CamelCase notation in our naming
conventions. Names starting with capital letters refer to concept names,
while those starting with small letters indicate role names. Individual names
are written in all caps.
2http://pagesperso.g-scop.grenoble-inp.fr/~shahwana/romma152 Chapter 7. Rule-based Reasoning
The TBox defines functional taxonomies (see Section 4.2.6) through concept
hierarchies. The FD taxonomy, which is partially shown in Figure 7.1,
is defined by a concept hierarchy rooted at :Component. FDs are defined at
the leaf level of the hierarchy, such as :Capscrew, :Nut and :LockingNut.
While the root of FI taxonomy is the concept3 :Interface, FIs are again de-
fined at the leaf level by concepts such as :PlanarSupport, :ThreadedLink,
and :SpineLink.
FCs are defined as subclasses of the concept :FunctionalCluster. Examples
are :BoltedJoint and :RivetedJoint.
The relationship between components (instances of :Component) and
interfaces (instances of :Interface) is defined through the role :forms,
that relates a component to an interface it forms. This role represents the
binary relation �f defined in Section 4.2.5. The role :links is defined to
be the inverse role of :forms (an interface links a component). This role
represents the binary relation �l defined in Section 4.2.5. A restriction is
added to the TBox to ensure that one interface links exactly two components.
The role :forms is specialized into two sub-roles, namely :innerForms
and :outerForms. This is to faithfully represent geometric configurations
where the interface is not symmetric. Examples of asymmetric interfaces are
threaded links, spline links, snug fits, etc. In this case, we distinguish the
outer component that outer-forms the interface, from the inner component
that inner-forms it.
The relationship between components and their functional groups (instances
of :FunctionalCluster) is defined through the role :regroups
where a functional group regroups a component. The role :participatesTo
is defined as the the inverse role of :regroups, i.e., a component participates
to a functional group.
The ontology editor Prot´eg´e [3] is used in the context of this work to design
the ontology. This framework allows the intuitive authoring of concepts,
roles, and their hierarchies. Moreover, the seamless integration that Prot´eg´e
provides with reasoners (embedded support for HermiT and FaCT++ version
4) enables an easy check of concepts satisfiability. This permitted the
reporting of inconsistencies as soon as they appeared.
7.4.2 Ontology population with model knowledge
Once the qualitative reasoning demonstrated in Chapter 6 is done, the resulting
functionally enriched CIG is translated into an ABox of the abovementioned
ontology. To this end, the ontology is first loaded. Then the
following steps take place:
• All nodes of the CIG are defined as individuals. For each node, an
3For the sake of conciseness, the terms concept and role are used instead of concept
name and role name, whenever this use is not ambiguous.DMU knowledge representation 153
:CapScrew
:Screw
...
:Locking Nut
:Nut
:BoltReceiver
:Fastener
:Component
...
...
:SnugFit
:ThreadedLink
:ClampLink
...
:Linear Support
:PlanarSupport
:Support
:Interface
owl:Thing
...
...
:PowerTransmitter
:FunctionalCluster
:IrreversibleThreadAssembly
:Gear
...
...
:links
:regroupes
romma
Figure 7.1: Partial graphical representation of romma ontology, showing concept
and role names. Solid stroke arrows represent the concept hierarchy
relationship, while dashed stroke arrows represent named object roles. The
rounded rectangle delimits the name space.154 Chapter 7. Rule-based Reasoning
axiom is added stating that the corresponding individual is an instance
of :Component;
• All edges of the CIG are defined as individuals. For each edge, an
axiom is added stating that the corresponding individual is an instance
of the concept representing the FI associated to the underlying edge,
i.e., a sub-concept of :Interface. Please note that as a result of the
qualitative reasoning, each CI, thus each node of the CIG, is associated
to one and only one FI. Indeed, all edges of CIG become instances of
FIs defined as leaves in the taxonomy of interfaces;
• All recognized functional groups are defined as individuals. For each
functional group, an axiom is added stating that the corresponding
individual is an instance of the concept representing the group FC,
i.e., a sub-concept of :FunctionalCluster. An assembly joint with
threaded link (see Section 6.6) defined over a subset of the CIG nodes
is an example of sub-concept of :FunctionalCluster;
• For each edge of the CIG, two axioms are added stating that the
individual representing the interface links two other individuals representing
the nodes at each extremity of the edge through the role
:links or one of its sub-roles;
• For each recognized functional group, as many axioms as its participating
components are created. Each stating that the individual representing
the recognized functional group relates to the individual representing
the corresponding component through the role :regroups.
An example is the set of components belonging to an assembly joint
with threaded link.
Now that the acquired knowledge is modeled using an ontology, the
knowledge base is ready to be reasoned upon, generating new facts until
saturation, i.e., until no new facts can be derived. The following section
details this issue.
7.5 Formal reasoning to complete functional knowledge
Section 7.3 showed the merit of using a formal language to represent domainspecific
expert rules. The choice of DL proves ideal for the needs of DMU
functional knowledge. However, DL is a family of languages that vary with
respect to their expressiveness, thus, with respect to their computational
properties [17]. Variants of DL and the linguistic constructs they provide
are visited in Appendix D. In this work, we employ the DL language SHOIQFormal reasoning to complete functional knowledge 155
which is supported by OWL-DL, starting version 1.1, in agreement with our
knowledge representation choice (see Section 7.4).
Even though, starting version 1.1, OWL-DL actually supports SROIQ-
(D) [88], that is SHOIQ augmented with complex restrictions on roles
and data types constructs. In our work, we do not use these additional
features. Disallowing data types in logical constructs aligns with the purely
qualitative method advocated in Section 4.1 and described in Chapter 6.
Moreover, avoiding the use of such costly constructs and restrictions spares
the reasoning process a remarkable computational overhead [116].
DL family is backed by strong semantics that defines how different constructs
of a given variant should be interpreted. Appendix D gives more
details about the semantics of DL.
7.5.1 Inference rules in DL
Statements such as those expressed through Formulas 7.1 and 7.2 can be
expressed in DL using General Concept Inclusion (GCI). A GCI in this
sense defines an inference rule that applies across the underlying domain.
Those rules are actually used to identify components FDs.
For example, the aforementioned formulas describing a nut and a capscrew
are translated into DL as follows in their respective order:
Nut � Component �
∃innerForms.ThreadedLink �
∃forms.PlanarSupport �
∃participatesTo.BoltedJoint �
=2forms
(7.3)
Capscrew � Component �
∃outerForms.(ThreadedLink � ∃links.Nut) �
∃forms.PlanarSupport
(7.4)
In connection to what has been argued in Section 4.2.6, the hierarchical
structure of the FD taxonomy allows inferences to gradually identify a
component functional class. A rule can either describe an FD in one statement,
or express an intermediate concept only, that leads to the definition
of an FD when another rule is applied. Those intermediate concepts can
be either inner node (nodes at upper level than leaves) in the FD taxonomy,
or auxiliary concepts introduced to the ontology to allow the reuse of
inference rules, independently of the FD taxonomy. In the latter case, the
intermediate concepts holds no intrinsic functional meaning.
For example, the concept name :BoltReceiver can be used to refer to
female threaded fasteners. It can then be described as follows:156 Chapter 7. Rule-based Reasoning
BoltReceiver � Component �
∃innerForms.ThreadedLink �
∃forms.PlanarSupport �
∃participatesTo.BoltedJoint
(7.5)
The previous description includes any component with a threaded hole
that receives another threaded shaft. The description of a nut can then be
narrowed down as follows:
Nut � BoltReceiver �
=2forms (7.6)
The above-mentioned approach allows us to reuse the concept described
in Formula 7.5 to describe other concepts, without the need of re-writing the
whole statement each time the concept is reused. For example, a :InnerNut
can be described as a :BoltReceiver with further restrictions:
InnerNut � BoltReceiver �
=2forms.PlanarSupport �
=3forms
(7.7)
This states that a statically valid component (as defined in Chapter 6)
that has only three interfaces: a threaded link, two planar supports, and
that takes part to an assembly joint with threaded link, is an inner nut (see
Figure 7.2). A locking nut can then be defined as a nut, whose neighboring
component is an inner nut.
LockingNut � Nut �
∃forms(PlanarSupport � ∃links.InnerNut) (7.8)
We note that individual rules are not definitions. This means that each
rule is actually an implication rather than an equivalence. This allows us to
describe a given FD by means of two or more rules. If an individual satisfies
any of those rules, it is identified as belonging to the corresponding FD.
An example is to add another GCI stating that a statically valid component
that forms a threaded link by means of an external thread, and that has at
least one planar or conic support, and that participates to a bolted joint, is
a capscrew, as follows:
Capscrew � Component �
∃outerForms.ThreadedLink �
∃forms.(PlanarSupport � ConicSupport) �
∃participatesTo.BoltedJoint
(7.9)Formal reasoning to complete functional knowledge 157
Locking Nut
Inner Nut
Capscrew
Threaded Links
Planar Supports
Conic Supports
(a) (b)
Figure 7.2: (a) A bolted joint (which is an assembly joint with threaded
link), involving a capscrew, a nut, and a locking nut. According to inference
rules, the nut would be identified as an inner nut. (b) Some of the FIs
involved in the assembly.
By adding such a rule, a capscrew can still be identified, even when it
is not connected with a nut. While the rule stated by Formula 7.9 is still
valid.
It is worth noticing that all of the above-mentioned rules are expressed
using only SHOIQ constructs. They are therefore expressible in OWL-DL.
Again, we use Prot´eg´e to define expert rules, checking ontologies consistency
and the satisfiability of concepts at each stage.
During a testing phase, Prot´eg´e is also used as a workbench, creating
example ABoxes and using its reasoning capability to assess results completeness.
The real feeding of the ABox axioms of a given model, however,
is done from within our application, and not through Prot´eg´e. This will be
developed in more details in Section 7.5.4.
In spite of the soundness of inference rules, expected results cannot be
obtained by the mere instantiation of individuals and their relations as shown
in Section 7.4.2. This is because of two inherent reasoning characteristics of
OWL and DL that are the Unique Name Assumption (UNA) and the Open
World Assumption (OWA). The upcoming two sections develop on these
issues.
7.5.2 The unique name assumption
The Unique Name Assumption (UNA) assumes that distinct terms denote
distinct individuals [135]. OWL, however, does not make this assumption.
In fact, a URI is not required to be unique for a given entity in the Semantic
Web philosophy. OWL even has the owl:sameAs property to denote158 Chapter 7. Rule-based Reasoning
individuals identity, even though having two different URI, i.e., names.
Most of DL reasoners thus do not account for this assumption by default.
This prevents making simple judgments, such as those on lower bound cardinality
restrictions. For example, even if an individual x is declared to relate
to individuals y and z through the role r in the knowledge base ABox, the
conclusion that x is an instance of ≥2r cannot be made, in the absence of
further knowledge. This is because names x and y may actually refer to the
same individual.
To work around this issue, the UNA should be made explicitly. This can
be done by means of SHOIQ constructs by defining a singleton for each
individual, i.e., a concept having only one individual, then declaring those
concepts to be mutually disjoint. This is made possible through the nominal
construct of SHOIQ that allows rules to describe a concept by listing its
individuals.
OWL defines the property owl:differentFrom that declares two names
as referring to two distinct individuals. It also offers the owl:AllDifferent
construct that declares a mutually distinct individuals. These OWL constructs
are no more than syntactic shorthands to creating mutually disjoint
singletons. In this work, however, the UNA is made using SHOIQ primitive
constructs to guarantee compatibility with the communication protocol
used (see Section 7.5.4).
7.5.3 The open world assumption
The Open World Assumption (OWA) assumes that facts which cannot be
proven to be true remain unknown. This is in contrast to the Closed World
Assumption (CWA), where facts that cannot be proven to be true are assumed
false.
Under the OWA, partial knowledge is permitted, and conclusions made
at some point cannot be falsified by the introduction of new facts to the
knowledge base. While under the CWA, knowledge is assumed complete at
each point of the reasoning. This leads to invalidate some conclusions that
are made in absence of certain facts, once those facts are introduced to the
knowledge base [75].
The OWA thus has the advantage of allowing partial knowledge, while
keeping temporal consistency of the knowledge base. The CWA requires
complete knowledge, that might not be available in the context of the Semantic
Web services and applications. For this reason, OWL and DL make
the OWA.
This assumption of an open world, however, may hinder reasoning. In
fact, in the absence of some closure measures, inferences such as concept
negation are not possible. The fact that an individual x, cannot be proven
to belong to the concept C, does not mean that it belongs to its complement
¬C. In fact, x belongs to neither concepts. The same applies to upperFormal reasoning to complete functional knowledge 159
bound cardinality restrictions, the fact that an individual x is stated to be
involved only once in a role r does not prove its membership of the concept
≤1r, unless another involvement in the same role shows to be impossible.
This problem, however, can be solved by means of some sort of local
closure of the world of discourse. For example, if the individual x is proven
to be an instance of the concept D, while D and C are stated to be disjoint
in the TBox of the knowledge base C � ¬D, then ¬C(x) becomes provable
(and we write K |= C(x)). This is because x cannot belong to D and C at
the same time.
To work around this issue in the proposed approach, we allow for local
closure of the knowledge base at the TBox level by defining concepts of
different taxonomies (FI, FD and FC) to be mutually disjoint at each level
of the taxonomy. Moreover, the closure is ensured at the ABox level, and for
each treated model individually, by explicitly stating how many interfaces a
component forms, and how many components a function cluster regroups.
For instance, a component :C (see Figure 5.5) can be stated to have exactly
two interfaces as follows {C} � =2forms�. Again, nominal definition of a
singleton (namely {C}) is used here, as enabled by the nominal construct of
SHOIQ (see Section 7.5.2).
7.5.4 Integration of DL reasoners into application framework
As mentioned earlier in Section 7.3.2, efficient and robust algorithms are
established in order to reason upon DL knowledge bases. The choice of
OWL-DL as ontology language allows us to use these algorithms to saturate
the knowledge base with valid new facts.
DL reasoning algorithms are implemented in terms of reasoners, which
are expert systems that receive the knowledge base as an input, before inference
algorithms are run against this knowledge in order to answer user’s
queries.
To allow the communication of facts and rules, as well as queries, a
reasoner provides the software developer with interfaces to client systems.
We distinguish two types of communication channels:
Application level communication. This is done through a well-defined
API, and by means of a software library offered by the reasoner;
Network level communication. This is done through a well-defined network
protocol, and by means of server applications offered by the reasoner.
The first solution, on the one hand, is suited for standalone software
applications that are characterized by transparent communications with a
minimal overhead. However, and in spite of efforts for standardization [87],
different reasoners still define different APIs. This is partially because of the160 Chapter 7. Rule-based Reasoning
difference of implementation techniques, e.g., programming languages, used
by each reasoner. This disadvantages makes it impractical to switch between
reasoners once the binding is done, hence it becomes tedious to switch from
one reasoner to another to be able to evaluate their performances.
The second solution, on the other hand, goes through standardized communications.
A reasoner that provides a network interface implements a
well-defined protocol to this end. This allows the software developer to
use an arbitrary reasoner, with complete abstraction of the implementation
technique at the server and the client sides, as long as both sides implement
and use the same protocol. Moreover, a different reasoner can be used,
even after the interface is built, given that it provides the developer with
a network interface. Following the client-server paradigm, this solution enables
the assignment of dedicated reasoning servers for industrial as well as
research applications.
A protocol for DL reasoners network communication actually exists, DL
Implementation Group (DIG) is the de facto DL reasoner network communication
standard [15]. It is used by many of them such as RACER, Pellet,
and FaCT++ to name only a few.
To be able to evaluate the above-mentioned reasoners, we choose to use
the architecture solution of network communication channel, implementing
the DIG interface from a client perspective, to insert formal reasoning processes
in the proposed approach as shown in Figure 7.3.
To this end, and for a given execution of our application, a connection
to the reasoning server is then made, and a new knowledge base is initialized.
The ontology TBox, translated into DIG tell-commands, is read. A
tell-command informs the reasoner about rules (in terms of GCI) and facts
(in terms of axioms). The ontology tell-commands is then submitted to
the reasoner. After the geometric and qualitative analysis demonstrated in
Chapters 5 and 6, the ABox of the knowledge base is also submitted to the
reasoner, again in terms of tell-commands. Once all relevant facts are declared
to the reasoner, i.e., the functionally enriched CIG as interpreted in
Section 7.4.2, the individual names are declared unique (see Section 7.5.2)
and the world of discourse is locally closed (see Section 7.5.3) using the relevant
rules communicated as tell-commands. The reasoner is then queried by
means of ask-commands about instances belonging to different FD classes.
An ask-command requests the reasoner about a specific piece of information.
The reasoner returns, for each ask-command, a list of individual names that
belong to the requested concept, that is an FD in our case. These lists are
used to annotate corresponding components with their respective FDs. Figure
7.4 illustrates different stages of this process, showing communication
messages between the proposed application and a dig server in terms of a
sequence diagram.
The above-mentioned scheme is totally independent of the underlying
reasoner implementation. To carry out our experiments, we used bothFormal reasoning to complete functional knowledge 161
Ontology / DIG
HTTP
Ontology / OWL Geometric Analysis
Behavioral Analysis
DIG Client
Developed
Used
DIG Server
DL Reasoner
Figure 7.3: A diagram showing the architecture of the developed application,
and its interface with the reasoning server. The diagram shows communication
channels between different modules and applications.
FaCT++, a C++ implementation of a SHOIQ(D) reasoner [169], and Pellet,
a Java implementation of a SROIQ(D) reasoner [156].
To allow the submission of the TBox to the reasoner, the ontology, expressed
in OWL-DL, needs to be translated to DIG tell-commands first.
Even though version 3 of Prot´eg´e provided an option to generate the DIG
code corresponding to a given ontology, experiment showed that this code
is broken. Prot´eg´e 3 actually communicates a different code when it binds
to a DIG server, a property that was dropped in Prot´eg´e 4. For the purpose
of this work, the TBox of the OWL ontology is translated manually
to DIG tell-commands, while the rest of ABox tell-commands are formulated
inside our application, in accordance with the facts acquired at the
qualitative behavioral analysis stage. In order to complete the functional
knowledge about the model on hand, the application queries the reasoner
about instances belonging to concepts that represent FDs. A query is thus
created per FD. Queries are formulated in terms of ask-commands. This
functionality is implemented by the class DigOntologyHandler in our code.
For each query the application sends, the reasoning server sends back a
set of individual names that belong to the FD in question. Individual names
are then mapped to their corresponding components and components are
annotated with the FD.162 Chapter 7. Rule-based Reasoning
Figure 7.4: A sequence diagram showing communication between the proposed
application and the DIG server.Conclusions 163
7.6 Conclusions
After their identification at the functional interaction level, functional properties
still need to be identified at the functional unit level. This can be
materialized by assigning relevant FDs to their corresponding components.
Section 7.1 emphasized this need to complete the functional enrichment process
of the DMU.
Even though this information is still not available when the qualitative
behavioral study, described in Chapter 6, concludes, Section 7.2 showed how
this knowledge can be obtained. The assignment of FDs to their respective
components showed to be the logical entailment of acquired knowledge at
the interaction levels, i.e., the FI and FC levels, coupled with inference rules
that are inspired from a particular domain of application. Indeed, while
the qualitative analysis process refers to a behavior to filter out some FIs,
it brings in a consistent set of dependencies between shapes, behavior and
function at the level of interfaces between components. Section 7.2 showed
how these dependencies at the component interface level could be extended
to the component level through inferences.
Section 7.3 showed that a pre-defined set of such rules cannot be deemed
complete for all mechanical engineering disciplines, thus the need for a dynamic
adaptation of inference rules to the context in which a given DMU
is defined. This requirement narrowed down the choice of the method to
be used to define inference rules to formal logics that brings such agility.
Although FOL suggested itself as a theoretically grounded solution, its unpredictable
computational behavior made it an inconvenient choice. The
advantage of expressing rules using DL, as a family of formal languages, is
its well-understood computational properties. This is an important point to
produce an application framework that can be mastered from an algorithmic
complexity standpoint, both at the geometry and knowledge processing
levels.
The choice of rules expression languages was made in close connection to
the choice of knowledge representation shown in Section 7.4, and the choice
of reasoning formalisms developed in Section 7.5. Our OWL-DL ontology
was introduced in Section 7.4.1, before Section 7.4.2 showed how a given
model is instantiated in view of its concepts and roles.
Section 7.5 demonstrated how inference rules can be formalized by means
of DL SHOIQ constructs. Reasoning obstacles and their workarounds were
then explained in Sections 7.5.2 and 7.5.3.
After establishing the reasoning process theoretically, Section 7.5.4 provided
an insight into some implementation issues, such as the use of third
party DL reasoners, and how knowledge, queries, and answers were communicated
back and forth to such reasoners.
This chapter concludes the presentation of our purely qualitative approach.
As a result of such a process, the DMU model is now restructured164 Chapter 7. Rule-based Reasoning
geometrically to allow algorithms to recognize functional interaction zones
(see Chapter 5) and identify some components using their FD. After interactions
were recognized geometrically, their behavior was analyzed to recognize
their functional attributes. Interaction zones, identified by CIs, and
interaction groups, identified by components sets, were annotated with their
functional semantics, i.e., their respective FIs and FCs (see Chapter 6). As a
final stage to a complete functional interpretation of the DMU, components
as functional units were annotated with their applicable FD, as part of a
formal reasoning process. Indeed, this overall process describes the adequate
data structure of a functional component as mentioned at Section 7.5.1Chapter 8
Results and Comparative
Study
In this chapter we evaluate the proposed application of DMU enrichment
with functional information through different use cases,
ranging from simple illustrative examples up to industrial scale
models.
The general application architecture is first visited in Section 8.1.
Section 8.2 walks through and comments the result of a range of examples.
A successful case study of the integration with a templatebased
simulation pre-processor is demonstrated in Section 8.3.
8.1 Application architecture
Figure 8.1 shows the major modules of the proposed application. It also
shows modules that the application uses to deliver its output. The system
comprises three main modules that are the geometric processor seen
in Chapter 5, the qualitative analyzer seen in Chapter 6 and the semantic
annotator seen in Chapter 7. The three modules communicate by means of
the CIG that is enriched with different levels of information according to
the processing stage.
Open Cascade Technology [149] is used in the geometric processor to
read a STEP file and perform primitive geometric and topological operations
where the CIs between components are identified and the CIG is then
generated. The geometric processor is used again in the semantic annotator
to write down the STEP file, now enriched with the CIs between components
and the functional knowledge about components. At this stage, the
geometric model of each component is structured with all its CIs attached.
As shown in Section 7.5.4, a DIG reasoner is used, such as FaCT++ [169]
or Pellet [156] to apply rules of the ontology defined in Section 7.4.1 onto the
functional knowledge obtained through the qualitative analyzer, generating166 Chapter 8. Results and Comparative Study
Figure 8.1: Component diagram showing the developed solution as encapsulated
in package romma, along with external libraries that take part in the
proposed approach.
new facts that relate components with their FDs.
Other software libraries have also been used in the developed application,
such as Xerces-C++ [6] to parse and generate Extensible Markup Language
(XML) strings, and cURL [2] to handle network communications.
The system takes as an input a DMU as represented by its geometry
in a STEP format. In fact, most commercial CAD applications provide an
interface to export CAD models to this format, as it is an ISO standard.
Even tough other information rather than geometry can be encapsulated in
a STEP file, we only consider the geometry and topology of each component
of the DMU. They represent closed B-Rep surfaces forming a volume each
that represents a component.
The final output of the proposed system is again a STEP file. However,
the generated STEP file differs from the read one in two aspects:
• The new geometry of the DMU is restructured according to functional
interaction zones between components, and with respect to the functional
breakdown seen in Section 4.2.3. That is, contacts and interferences
are imprinted onto the original surfaces of each component
participating to the interaction, generating new curves, thus new faces
in the geometric model of each component;
• The new STEP file is semantically annotated. This is done in a tightApplication to industrial examples 167
relation to the ontology defined in Section 7.4.1. Functional interaction
zones are now named after their FIs designators as represented in
the ontology. At this stage, one FI is associated with one CI; Moreover,
functionally recognized components are also named according to
their unambiguous FD, as borrowed from the same ontology. The connection
to an agreed-upon ontology guarantees the meaningfulness of
this supplementary information in the outcome DMU.
The proposed software can either be used as a command line application,
or as a software library. In both cases, it will need a running DL reasoner
server, supporting the DIG interface, in order to run properly. Documentation
of the software API is available online1.
8.2 Application to industrial examples
The proposed application has been run against different examples to evaluate
its robustness. Tests included primitive DMUs that did not necessarily
convey an industrial meaning, as well as full-scale industrial examples. In
the first case, the system validity to generate coherent results with respect
to the objectives set in Section 3.4 has been evaluated. In the second case,
application scalability has been put to test using industrial use cases.
At first, we consider an illustrative example of a simple DMU. It is
described purely geometrically and can be interpreted as a bolted joint assembly.
The assembly consists of three plates fastened together by means
of a capscrew, a nut, and a locking nut. We recall that those denominations
are not available at the outset of the DMU analysis. A cross-section
in the assembly model is shown in Figure 8.2. This figure also shows the
CIG corresponding to the studied DMU, and generated by the geometric
analyzer. RS I analysis is reflected in the elimination of statically invalid
interpretations, namely both spline links FIs in this case. RS II comes then
to filter out FIs leading to unnecessary static indeterminacy. This leads to
the elimination of snug fits and the self-locking fit. Finally, RS III identifies
an internal load cycle. This leads to the labeling of the group of components
that participate to this cycle as an assembly joint with threaded link.
Once functionality is determined at the interaction level, the CIG is
passed to the semantic annotator, which loads the ontology and connects to
the reasoning server. The CIG is then translated into facts, in light of the
ontology concepts and roles as shown in Section 7.4.2. After the reasoner
is fed with available knowledge, it is inquired about FDs of components.
Figure 8.3 shows recognized FDs as a result of the reasoning process. In
addition to the capscrew in green and the nut in blue, the application also
recognized the locking nut, colored in red. In fact, even though both the nut
1http://pagesperso.g-scop.grenoble-inp.fr/˜shahwana/StepByStep/168 Chapter 8. Results and Comparative Study
Conic Contact
Conical Support
Cylindric Interference
Thread Link
Spline Link
#0
Planar Contact
Planar Support
Planar Contact
Planar Support
Cylindric Contact
LooseFit
SnugFit
#1
Cylindric Contact
LooseFit
SnugFit
#2
Cylindric Contact
LooseFit
SnugFit
Planar Contact
Planar Support #3
Cylindric Interference
Thread Link
Spline Link
#4
Planar Contact
Planar Support
#5
Internal Load Generator
Internal Load Cycle
A Statically Invalid Interpretation
#3
#1
#0
#2
#4
#5
Slef-locking Fit
A Statically Indeterminate Interpretation
Figure 8.2: A cross-section in a simple bolted joint example tying up three
plates, along with its corresponding CIG as generated by the geometric
analyzer. Functional interpretations are also reduced to one FI per CI, and
an internal load cycle is recognized as a result of RS qualitative analysis.
and the locking nut have the same shape, they are distinguished based on
their CIs and FIs. The locking nut has two CIs whereas the nut has three.
It has to be noticed that in a standard setting of a bolted joint with a single
nut, this nut has only two CIs. It is because this nut is in contact with
another nut that it functionally becomes a locking nut whereas the nut it is
in contact with is functionally designated as a nut even though it has three
CIs. To enable this distinction, the auxiliary concept of a general nut needs
to be introduced to the ontology. A locking nut is then defined as a general
nut that forms exactly one planar support with another general nut.
This simple example shows how FDs are influenced by FIs as well as
other neighboring components: a complexity that can be handled with the
reasoning mechanisms of the qualitative analysis and the inference mecha-Application to industrial examples 169
Figure 8.3: A bolted joint assembly showing a recognized capscrew in green,
a recognized nut in blue, and a recognized locking nut in red.
nisms associated with the proposed ontology.
The model of the centrifugal pump, first introduced in Figure 1.5, provides
a more elaborate example. The DMU contains 43 components. The
geometric analysis of this DMU thus generates a CIG with 43 nodes. Model
components, as represented by CIG nodes, are connected through 100 edges,
that is 100 CIs. The CIs identified are of types surface contacts (planar and
cylindrical), cylindrical interferences, linear contact.
Figure 8.4 shows the result of the running of the proposed application
against the centrifugal pump model. This figure shows how the following
FD could be recognized: a capscrew in green, nuts in blue, studs in yellow,
plug screws in cyan and a set screw in magenta.
We note that since the capscrew, the studs, and the set screw all have
an outer thread that participates to a threaded link, they are classified as
threaded shafts. However, the distinction between one FD and another is
made in light of components participation to other FIs. A stud for instance
is guaranteed to form only threaded links as FIs. The diversity of FDs
processed in this example demonstrate the interest of ontology structure
and its associated inferences that can be enriched easily to adapt to new
categories of components. This is an efficient complement to the qualitative
analysis module that is generic and builds upon basic mechanical concepts.
The example illustrated in Figure 8.3 showed that even if two components
share exactly the same shape, they still can be interpreted differently.
It is also worth mentioning that the form of the stand-alone component does
not affect the judgment of its FD. In fact, what does matter is components
interactions, reflected first at the geometric level by their CIs, and then interpreted
functionally by means of FIs. For example, a nut is recognized170 Chapter 8. Results and Comparative Study
(a)
(b)
Figure 8.4: The example of the centrifugal pump after it has been treated by
the proposed qualitative approach to detect its FD. (a) A semi-transparent
rendering of the DMU, detected CIs of type interference are shown in dark
black. (b) A cross-section cut has been applied to the generated DMU to
show internal parts. Recognized components are a capscrew in green, nuts
in blue, studs in yellow, plug screws in cyan and a set screw in magenta.Application to industrial examples 171
(a) (b)
Figure 8.5: Two different conventional representations of an inner thread
corresponding to a screw thread. (a) The inner thread is represented with
detailed helical shape on the screw, while the outer thread is simplified
as a simple cylinder on the housing. This leads to a complex interference
zone, which highly depends on components relative position. (b) The inner
thread, as well as the outer thread, are represented as cylinders, leading to
a cylindric interference between these two components.
regardless whether it is a cap nut or a simple nut with hole, as long as it
satisfies the nut functionality, as Figure 8.4 shows.
Figure 8.5a shows a different representation of the capscrew of the pump
model, as compared to the one used in the first example, and illustrated
closely in Figure 8.5b. In fact, different representations are due to different
conventions, as discussed in Section 3.2. Our algorithm shows to be general
enough to recognize both conventions, and interpret them correctly, as the
figure shows. In fact, even though the convention illustrated in Figure 8.5a
represents the thread in more details with a helical shape at the capscrew
side, generating a fairly complex geometric interface, the geometric analyzer
of the proposed application reduces it to a simple cylindrical interference to
allow the subsequent qualitative reasoning to take place. The real shape of
its geometric interface is highly dependent on positioning parameters that
are usually relaxed during the designing phase, it has thus to be simpli-
fied before it is mapped to an interpretable CI. Here, the analysis based
on the relative position of cylindrical surfaces is the key property of this
simplification process.
Table 8.1 shows execution time for the example of the centrifugal pump,
run on a machine with an Intel� CoreTM 2 Duo processor at 2.40GHz and
4GB of memory. It also shows how execution time varies with respect to
the number of detected FDs that decides the size of the underling ontology;172 Chapter 8. Results and Comparative Study
Table 8.1: Execution time of the proposed method (in seconds), run against
the example of the centrifugal pump, as a function the number of detected
FDs.
Number of detected FDs 3 4 5 6
Execution time (seconds) 15.69 16.26 16.34 16.54
i.e., the number of its rules.
Another example that is used to evaluate the proposed method scalability
is the root joint example. This structure is a small subset of an aircraft
structure connecting a wing to the aircraft fuselage. It is a use-case set
during the ROMMA project [1] submitted by Airbus as project partner.
Figure 8.6 shows the model of the root joint as an output of the suggested
application. The DMU of the root joint contains 148 components. The
geometric analysis of such a model shows that components connect to each
other through 512 geometric interfaces.
It is worth noticing that the execution time of the geometric processing
and qualitative analysis is negligible when compared to that of the semantic
reasoning, done externally to our application by means of a DL reasoner.
In fact, even though DL reasoning complexities have well-known and understood
bounds, those bounds are shown to be ExpTime-complete in the
general case [27]. Many factors influence the DL reasoning time, among
which the amount of provided facts, that is in our case a function of the
number of components and CIs. Another important factor is the size of
the ontology, which dictates the number of rules taken into account when
the reasoning takes place (see Table 8.1). To alleviate the time complexity
problem while dealing with large-scale industrial models, an ontology can be
simplified to only include rules that define FD that are relevant to the studied
model and phenomenon. Such an adaptive ontology has been applied
to the root joint example to allow reasoning in a timely manner (less than
one minute on a personal computer) while still giving relevant and accurate
results. In the above-mentioned example, the ontology rules were reduced
to only recognize capscrews, nuts, and locking nuts.
It has to be noticed however that the general ontology used efficiently
against the centrifugal example, is also used against a sub-assembly of the
root joint as shown in Figure 8.3, while keeping execution time reasonable
(few seconds). In this case, and instead of reducing the number of rules in an
ontology, the number of facts is decreased by examining only a sub-assembly
of the whole DMU. Similarity and symmetry properties can then be used
to generalize obtained conclusions to the rest of the DMU while keeping
timely execution. Figure 8.7 shows execution time of the proposed methodIntegration with FEA pre-processors 173
Figure 8.6: An industrial example of a root joint after it has been processed
by the proposed application. Recognized FD in this model are capscrews,
nuts, and locking nuts.
run against the example of root joint, as well as other sub-assemblies of the
same structure. Execution time is plotted as a function of the number of
components in each substructure. Experiments are run on a machine with
an Intel� CoreTM 2 Duo processor at 2.40GHz and 4GB of memory.
8.3 Integration with FEA pre-processors
The proposed approach has proved to integrate seamlessly with automatic
FEA pre-processing task [42] as to meet its target. In fact, the output of the
proposed application can be fed to a FEA pre-processor as its input. A preprocessor
that is aware of the ontology we put forward in Section 7.4.1 can
then read the produced functionally enriched DMU, in its STEP format, as
well as the FD of each component, in order to prepare a simulation model,
while taking into account the simulation objectives (see Figure 1.19). Functional
information available in the produced model allows the pre-processor
to robustly relate geometry at different levels, i.e., geometric interface, component,
and component group, to functionality as defined in the ontology.
The pre-processor can then choose the adequate simplifications and/or idealizations
to apply on that particular geometric zone in lights of simulation174 Chapter 8. Results and Comparative Study
Figure 8.7: Execution time of the proposed approach against the example
of root joint and its sub-assemblies, as a function of number of components.
objectives and hypotheses.
Figure 8.8 shows how the template-based approach proposed in [42]
builds on functional annotations provided by the hereby proposed application
to simplify a bolted joint connection in accordance with simulation
purposes. To allow geometric pre-processing, a set of templates are defined,
to which a set of transformations can be associated, according to simulation
objectives. For example, the functional group of bolted joint is first
recognized as it is labeled as a assembly joint with threaded link by the
hereby proposed approach. It is thus matched to a template T. Links are
also established between elements of T and functional group components
and interfaces, based on their FDs and FIs. This is made possible because
the DMU, restructured and functionally enriched through the proposed approach,
is no longer a mere annotation of components but this annotation
relates to the geometric structure of components using their FIs and load
cycles that completely define each bolted joint. Once components and interfaces
are matched to template elements, geometric transformations can be
applied and adapted to the screw diameter, the number of plates tightened
together, the type of screw head, the existence or not of locking nuts, i.e.,
the template is largely parameterized and becomes generic. Rather than
selecting individually each component and performing low level geometric
tasks on each component, the engineer can now select components based on
their functional meaning, here the assembly joint with threaded link, which
is very useful in the present case to transform the screws and nuts into
connectors as needed for FEA simulation purposes.
In the illustrated case, and for the sake of structural simulation, the
locking nut was first removed as its functionality was detected as secondary
by the template T. The capscrew and the nut were then merged together,
removing the binding threaded link. Loads are created as normal to theConclusions 175
Locking Nut
Nut
Screw Threaded Link
Pre-load
Pressure
Friction Domain
Decomposition
(a) (b) (c) (d) (e)
Figure 8.8: A template-based simplification of a bolted joint assembly for
FEA simulation purposes [42]. (a) The original sub-assembly model annotated
with FD and FI as an outcome of the hereby proposed application.
Since it is recognized as an assembly joint with threaded link, the subassembly
is matched with a template T. (b) The locking nut is removed, as
recognized as a secondary FD in the context of assembly joint with threaded
link by T. (c) The removal of the threaded link to merge the screw and the
nut. (d) Domain decomposition takes place around the cylindric support
interaction zone. (e) Screw head transformation extends the range of screws
to flat-headed ones.
planar support, while friction areas are added under the screw head and
the planar support of the nut. Then, the object resulting from the fusion
of the capscrew and the nut is further simplified as a flat-headed fastener.
Finally, the load cycle of each bolted junction gives access to the plates it
tightens and a sub-domain can be created in these plates around the screw
as needed to set frictions areas between the plates and adapt the FE mesh
generation technique in that area. This generates a simulation model that
complies with hypotheses and objectives, and readily allows the generation
of the FEM.
Overall the proposed approach enabled the time reduction in processing
this model from five days to interactively process this DMU as required by an
engineer with the current software tools to one hour with the newly proposed
approach using the template-based operator exploiting the enriched DMU
with the functional information generated by the proposed approach.
8.4 Conclusions
In this chapter the proposed approach has been studied from a pragmatic
standpoint. Developed algorithms and advocated methods have been put to
test with concrete examples to evaluate their validity and scalability.
Results show the merit of a qualitative approach, which generates functional
knowledge from a purely geometric model, based on an adaptive set
of domain expert rules, while taking into account mainstream industrial
practices and conventions. They also show potentials of enhancement and176 Chapter 8. Results and Comparative Study
optimization. The following chapter concludes this work, and presents some
perspectives to extend this work.Chapter 9
Conclusions and Perspectives
9.1 Conclusions
The proposed approach to structure and enrich DMUs with functional information
has analyzed, in a first place the effective content of DMUs in terms
of functionally related information available as well as other technological information
that could be processed to meet our objective. Chapter 1 showed
that B-Rep models of components where the generic basis available in any
CAD or FEA software and other technological or functionally-related information
was sparse and, generally inexistent. The DMU structure, i.e., its
hierarchical description, as well as position constraints or kinematic connections
between components are not intrinsic to a DMU. The DMU structure
may not reflect its kinematic behavior and position constraints or kinematic
connections between components, when available, are not intrinsically related
to the interfaces between these components. Similarly, component
names are not reliable information that can be related somehow to component
functions. Consequently, the proposed approach has been based on
the B-Rep models of components, positioned in 3D space independently of
each other, as DMU representation that can be reliably used as input for
our enrichment process.
The analysis of prior work (see Chapter 2) has shown that functional
information has been processed mostly through top-down approaches, with
function definitions loosely related to the geometric entities, i.e., faces, edges,
vertices, of components. Strong dependencies, however, between shape –
function – behavior is commonly recognized though not formalized in details
from a geometric point of view. Feature-based approaches on standalone
components have led to numerous applications, however, functional
information has not been fruitfully addressed. Processing assembly models
brought more information about their geometric interfaces but few contributions
addressed this level and none of them focused on the enrichment
with functional information. Design knowledge modeling and KBE178 Chapter 9. Conclusions and Perspectives
approaches added design and functional knowledge to components, essentially
through interactive means, KBE approaches being more automatized
but reduced to a narrow application range. Anyhow, the technological or
functional information is loosely connected to the component shape and
does not strongly influence the geometric structure of components. Where
ontology-based approaches have been proposed, reasoning capabilities have
rarely been proposed, KBE ones however extensively use dedicated behaviors
for very specific applications. The proposed approach is bottom-up to
take advantage of intrinsic and robust data as input, i.e., component shape
and their relative positions. Also, it is tightly related to shape – function
– behavior dependencies, which have not been precisely investigated to the
best of our knowledge. Ontology-based reasoning processes bring a well formalized
framework with algorithmic complexity characterization that brings
more efficiency compared to the use of ruled-based systems used in the CAD
area in prior work.
From these settings, Chapter 3 pointed out that frequently, a real component
shape does not match its digital representation. This difference has
to be taken into account since it influences the geometric interfaces between
components, hence the reasoning processes that can be set up from digital
models of components must take into account these differences. Because
the concept of function tightly relates to the concept of interactions between
components, the focus has been placed on the geometric interfaces
between components. The differences between real and digital shapes has
been formalized through the concepts of CIs and FIs and knowledge related
to these interfaces has been structured through appropriate taxonomies (see
Chapter 3 and Chapter 4). Indeed, the differences between real and digital
interfaces between components end up as multiple interpretations that require
a reasoning process to filter them out and generate a DMU enrichment
process that can be automated.
The determination of the geometric interfaces between components is
not a straightforward process, as pointed out in Chapter 5. This chapter
has shown how the accurate definition of imprints of interfaces between components
can be sped up and obtained. Though digital shapes of components
lead to three categories of interfaces, i.e., contact, clearance and interference,
their analysis has concluded that contacts and interferences are the only intrinsic
categories that can be used initially to enrich an assembly model
with functional information. This choice is consistent with respect to the
definition of an approach that relies on intrinsic information. The taxonomy
of FIs connected to the precise geometric description of interfaces over
components is a first setting of the dependency between shape and function.
At this stage, components geometric models are structured as well as the
assembly model through its CIG. All this information and the structured
models can now be used to take advantage of dependencies between shape,
function, and behavior to filter out the multiple interpretations existing atConclusions 179
some component interfaces. To this end, the concept of reference state has
been introduced that can be associated with a wide range of DMU configuration
throughout a PDP. Then, several qualitative behaviors have been
described that rely on generic mechanical properties, i.e., static equilibrium
of a component, load propagation cycles, and statically indeterminate configurations,
and enable to filter out FIs (see Chapter 6). These reference states
are automatically applied and stand for a first reasoning process performed
algorithmically. Therefore, its efficiency can be analyzed and its termination
can be established. These reference states, as well as the FIs cover
only a subset of the possible interfaces between components. Consequently,
the straightforward application of these qualitative behavioral models to an
arbitrary DMU can lead to incomplete results if CIs are not falling into the
proposed taxonomy. In a correct setting, however, the qualitative analysis
produces a unique FI per CI, which strengthens the relationship between
each CI and its corresponding FI. The DMU thus obtained is consistent at
the interface-level and knowledge has been gained at the cluster-level, which
structures further the assembly model.
Finally, the previous results are input in the second step of reasoning,
which is based on a ontological approach. The previous taxonomies of FIs
are associated with a pre-defined, generic taxonomy of FDs to lead to the
assignment of an FD per component. This parameter becomes an identifier
of a component that combines with its FIs and its geometry structured with
the imprints of its CIs and other FIs of neighboring components as required
by its FD to form the generic information characterizing functionally the
component inside its DMU (see Chapter 7). The FD assignment process
is obtained through a rule-based process. Inferences are expressed using
descriptive logic whose algorithmic complexity is established. Consequently,
the overall process of DMU enrichment is guaranteed to terminate and its
algorithmic complexity can be mastered. The enrichment is now obtained at
component-level as well as component cluster-level. This process is therefore
well suited for industrial DMUs and particularly complex ones as they can
appear in the aircraft industry. The enrichment thus obtained is robust, i.e.,
it is consistent and independent of user’s interactions, since the enrichment
process is automatic.
Chapter 8 has illustrated the results of the proposed approach with various
examples. The DMU functional enrichment thus obtained has been
successfully used in the context of FEA preparation processes. There, it
can be demonstrated how the functional enrichment can contribute to the
component selection process for fasteners and save a fair amount of time.
Also, Chapter 7 and Chapter 6 have shown how they can be extended to
analyze the consistency of a DMU.180 Chapter 9. Conclusions and Perspectives
9.2 Perspectives
Applications in Virtual Reality and Motion Planning
Although FEA model preparation is the first major objective behind this
work, applications are not restricted to this and other applications in a PDP
can benefit from the proposed approach. We show how our approach fits
other applications such as virtual and augmented reality and robotic and
motion planning.
VR Applications in PDP
DMU geometric model can be employed in VR applications, where the users
are immersed in a virtual environment and they can manipulate the product
and simulate its use and ergonomics. In return, virtual and augmented
reality techniques, varying from simple visualization to fully-immersive environments,
can be applied to PDP at different stages such as design and
assembly/disassembly planning and simulations [38, 141, 150].
VR approaches use simplified and approximate physical models to model
interactions between user avatars and other objects, and between objects
themselves, to allow real-time simulation of such an interaction. These
models are good enough to simulate a huge portion of expected interactions.
However, and for certain cases, a particular physical model fails to
provide realistic results. An example is contact simulation between rigid
bodies where collision detection algorithms are used to recognize contacts,
and generate appropriate forces. Such methods are usually based on objects
tessellated model (see Section 1.5.2). However, for special cases such
as shaft/bushing connections, simulation based on simple collision detection
algorithms generates an unstable behavior of haptic devices, as simplified
physical hypotheses and object dimensions are not compatible with the conventional
representation of components in a PDP. In such a case, when the
shaft approaches the housing, reciprocal forces are generated from the bushing
edges that push the shaft away because the shaft and bushing diameters
are either equal or closer to each other than the geometric deviation used
in collision detection algorithms, thus preventing the desired sliding effect
between these components.
Efforts have been paid to account for this inconvenience, where early
work shows how to use objects and agent specific attributes in order to realize
motion planning. Levison & Badler use behavioral object knowledge to
build an object-specific reasoner to enable a high-level action planning [110].
Kallmann & Thalmann propose a virtual interactive environment in which
smart objects define how they can be used and interacted with, by means
of a set of possible states, conditions, and instructions [96]. This allow the
adaption of the underlying physical model to the particular action to be performed,
avoiding unrealistic effect such as the shaft/bushing phenomenon.Perspectives 181
Jorissen & Lamotte generalize this approach to enable interaction between
all objects and human avatars in a virtual environment [93].
All previously presented approaches require functional annotations of
objects in order to assign them an appropriate behavior and interaction
scheme at the correct location around each object. In the presented works
this knowledge is provided during the design time of objects and virtual
environments, which suffer problems as mentioned in Chapter 2 and Chapter
4.
To allow the application of VR and motion planning to large scale models,
such as a product DMU, the manual functional annotation becomes cumbersome
(as seen in Section 3.4). Our works proposes an automated method
to boost functional annotations of objects and enable the location of interfaces
between components as a complement of prior work [89]. Incorporating
usage patterns based on objects functionality enables the application of the
above-mentioned approaches to industrial scale models and environments
because of the tight relationship between geometry, i.e., some local areas
of components, function as assigned through the proposed approach, and
behavior as needed for these simulations. Consequently, dedicated VR simulation
models could be trigged whenever needed for an interaction during
a VR simulation process. The use of appropriate VR component behavior
become transparent for the user, it is interaction-driven.
Contributions to CAD-to-FEA transformations
In their recent work, Boussuge et al. [42] introduced a set of automated
geometric transformations of CAD models in preparation for FEA. The
transformations are based not only on the mere geometry of the model,
but also on supplementary simulation-relevant annotations that go through
functional groups of components down to the geometric zones that delimit
functional interactions between pairs of components. This approach uses
the work presented in this manuscript to structure the geometric model of
components and connect this new structure to such functional annotations.
The categories of components under focus were fasteners. This need to be
extended with a larger range of categories of components to take advantage
of the proposed principle. To this end, the qualitative approach needs to
be extended with new reference states, particularly those that can refer to
kinematics, i.e., relative movements between components. This would enable
the identification of kinematic equivalence classes and their corresponding
components in a DMU.
Reasoning with these additional reference states would open the possibility
to set up new inferences to categorize components of type bearing,
gears, couplings, etc.
Even though the scheme described in the manuscript joins KBE in some
aspects, it is however a more robust approach. This is because functional182 Chapter 9. Conclusions and Perspectives
designations and functions are generic concepts in our approach. KBE aims
at structuring engineering knowledge and processing it with symbolic representations
[47, 143] using language based approaches. In this work, the
focus is placed on a robust connection between geometric models and symbolic
representations featuring functions, which has not been addressed in
KBE and, therefore, could be used in KBE approaches to extend their range
and improve their robustness when DMUs are modified during a PDP. Additionally,
KBE approaches as well as CAD-to-FEA transformations show
that the proposed approach can be regarded as a means to analyze and
structure a DMU at various stages of a PDP.
Among these stages, the design process, and even the early stages, can
benefit from the proposed approach to automate the enrichment of a DMU
with functional information in a top-down manner. As pointed out in Chapter
2, many design approaches based on hierarchical decompositions face
difficulties when refining the design downward to detailed geometric configurations.
These hierarchical decompositions needs evolutions to meet the
graph-based approach that is intrinsic to many mechanisms, as shown by
the CIG, the load cycles, and the complexity of inference processes. The
proposed DMU enrichment process is robust with respect to a range of
conventional representations of components, the influence of these representations
has not been addressed with respect to the enrichment process to
evaluate how it can be further improved or how it is robust to variants of representations.
Studying these issues would help setting up principles and/or
standards for a more efficient processing of DMUs at many stages of a PDP.
Similarly, studying the robustness of the enrichment process with respect to
variants of representations of components open the possibility to design more
tolerant software environments that would refer to a sketch-based paradigm
though they would stay robust while being more user-friendly.Appendix A
Fit Tolerancing and
Dimensioning
In mechanical engineering, a fit refers to a mating of two mechanical components;
on is a containing housing, referred to as the female part, and the
other is a contained shaft, referred to as the male part.
In technical drawing, both shaft and housing have the same nominal
diameter. Tolerancing, however, decides whether it is a snug fit, loose fit, or
nondeterminate fit.
ISO defines how to annotate drawing with such information in a standardized
manner. The tolerance is denoted by a tolerance code that constitutes
of a letter followed by a number. The letter defines the deviation
from the nominal dimension as a function of it. Small letters are used to
dimension shafts by defining the maximal deviation es = dmax −dnom, while
when used for housings the letter is capitalized defining minimal deviation
EI = Dnom − Dmin. For example, the letter H means zero distance from
the nominal diameter for the housing (referential housing), while the letter
h means zero distance from the nominal diameter of the shaft (referential
shaft).
Table A.1 shows tolerance letters for defining maximal and minimal deviation
of shaft and housing dimension (respectively) as a function of nominal
dimension.
Tolerance letters are followed by a number, defining tolerance quality.
The number is proportional to the tolerance, thus disproportional to the
manufacturing quality. Table A.2 shows 18 tolerance qualities defined by
ISO as a function of the nominal dimension.
Since the machining the shaft is more precise, shaft tolerance is usually
of higher quality rather than that of the housing. The combination of the
tolerance codes of each of the shaft and the housing decides whether the fit
is sung, loose, or nondeterminate.
Nominal dimensions are expressed in millimeters, after a symbol that184 Chapter A. Fit Tolerancing and Dimensioning
Table A.1: ISO deviation codes showing deviation of the nominal dimension
in µm as a function of nominal dimension (in mm).
Lettre c cd d e ef f fg g h
≤3 -60 -34 -20 -14 -10 -6 -4 -2 0
>3 & ≤ 6 -70 -46 -30 -20 -14 -10 -6 -4 0
>6 & ≤ 10 -80 -56 -40 -25 -18 -13 -8 -5 0
>10 & ≤ 14 -95 – -50 -32 – -16 – -6 0
>14 & ≤ 18 -95 – -50 -32 – -16 – -6 0
>18 & ≤ 24 -110 – -65 -40 – -20 – -7 0
>24 & ≤ 30 -110 – -65 -40 – -20 – -7 0
>30 & ≤ 40 -120 – -80 -50 – -25 – -9 0
>40 & ≤ 50 -130 – -80 -50 – -25 – -9 0
>50 & ≤ 65 -140 – -100 -60 – -30 – -10 0
>65 & ≤ 80 -150 – -100 -60 – -30 – -10 0
>80 & ≤ 100 -170 – -120 -72 – -36 – -12 0
>100 & ≤ 120 -180 – -120 -72 – -36 – -12 0
>120 & ≤ 140 -200 – -145 -85 – -43 – -14 0
>140 & ≤ 160 -210 – -145 -85 – -43 – -14 0
>160 & ≤ 180 -230 – -145 -85 – -43 – -14 0
>180 & ≤ 200 -240 – -170 -100 – -50 – -15 0
>200 & ≤ 225 -260 – -170 -100 – -50 – -15 0
>225 & ≤ 250 -280 – -170 -100 – -50 – -15 0
>250 & ≤ 280 -300 – -190 -110 – -56 – -17 0
>280 & ≤ 315 -330 – -190 -110 – -56 – -17 0
>315 & ≤ 355 -360 – -210 -125 – -62 – -18 0
>355 & ≤ 400 -400 – -210 -125 – -62 – -18 0
>400 & ≤ 450 -440 – -230 -135 – -68 – -20 0
>450 & ≤ 500 -480 – -230 -135 – -68 – -20 0
Lettre C CD D E EF F FG G H
≤3 +60 +34 +20 +14 +10 +6 +4 +2 0
>3 & ≤ 6 +70 +46 +30 +20 +14 +10 +6 +4 0
>6 & ≤ 10 +80 +56 +40 +25 +18 +13 +8 +5 0
>10 & ≤ 14 +95 – +50 +32 – +16 – +6 0
>14 & ≤ 18 +95 – +50 +32 – +16 – +6 0
>18 & ≤ 24 +110 – +65 +40 – +20 – +7 0
>24 & ≤ 30 +110 – +65 +40 – +20 – +7 0
>30 & ≤ 40 +120 – +80 +50 – +25 – +9 0
>40 & ≤ 50 +130 – +80 +50 – +25 – +9 0
>50 & ≤ 65 +140 – +100 +60 – +30 – +10 0
>65 & ≤ 80 +150 – +100 +60 – +30 – +10 0
>80 & ≤ 100 +170 – +120 +72 – +36 – +12 0
>100 & ≤ 120 +180 – +120 +72 – +36 – +12 0
>120 & ≤ 140 +200 – +145 +85 – +43 – +14 0
>140 & ≤ 160 +210 – +145 +85 – +43 – +14 0
>160 & ≤ 180 +230 – +145 +85 – +43 – +14 0
>180 & ≤ 200 +240 – +170 +100 – +50 – +15 0
>200 & ≤ 225 +260 – +170 +100 – +50 – +15 0
>225 & ≤ 250 +280 – +170 +100 – +50 – +15 0
>250 & ≤ 280 +300 – +190 +110 – +56 – +17 0
>280 & ≤ 315 +330 – +190 +110 – +56 – +17 0
>315 & ≤ 355 +360 – +210 +125 – +62 – +18 0
>355 & ≤ 400 +400 – +210 +125 – +62 – +18 0
>400 & ≤ 450 +440 – +230 +135 – +68 – +20 0
>450 & ≤ 500 +480 – +230 +135 – +68 – +20 0185
Table A.2: ISO tolerance codes showing tolerance margin in µm as a function
of nominal dimension (in mm).
Quality 01 0 1 2 3 4 5 6 7
≤ 3 0,3 0,5 0,8 1,2 2 3 4 6 10
> 3 & ≤ 6 0,4 0,6 1 1,5 2,5 4 5 8 12
> 6 & ≤ 10 0,4 0,6 1 1,5 2,5 4 6 9 15
> 10 & ≤ 18 0,5 0,8 1,2 2 3 5 8 11 18
> 18 & ≤ 30 0,6 1 1,5 2,5 4 6 9 13 21
> 30 & ≤ 50 0,6 1 1,5 2,5 4 7 11 16 25
> 50 & ≤ 80 0,8 1,2 2 3 5 8 13 19 30
> 80 & ≤ 120 1 1,5 2,5 4 6 10 15 22 35
> 120 & ≤ 180 1,2 2 3,5 5 8 12 18 25 40
> 180 & ≤ 250 2 3 4,5 7 10 14 20 29 46
> 250 & ≤ 315 2,5 4 6 8 12 16 23 32 52
> 315 & ≤ 400 3 5 7 9 13 18 25 36 57
> 400 & ≤ 500 4 6 8 10 15 20 27 40 63
Quality 8 9 10 11 12 13 14 15 16
≤ 3 14 25 40 60 100 140 250 400 600
> 3 & ≤ 6 18 30 48 75 120 180 300 480 750
> 6 & ≤ 10 22 36 58 90 150 220 360 580 900
> 10 & ≤ 18 27 43 70 110 180 270 430 700 1 100
> 18 & ≤ 30 33 52 84 130 210 330 520 840 1 300
> 30 & ≤ 50 39 62 100 160 250 390 620 1 000 1 600
> 50 & ≤ 80 46 74 120 190 300 460 740 1 200 1 900
> 80 & ≤ 120 54 87 140 220 350 540 870 1 400 2 200
> 120 & ≤ 180 63 100 160 250 400 630 1 000 1 600 2 500
> 180 & ≤ 250 72 115 185 290 460 720 1 150 1 850 2 900
> 250 & ≤ 315 81 130 210 320 520 810 1 300 2 100 3 200
> 315 & ≤ 400 89 140 230 360 570 890 1 400 2 300 3 600
> 400 & ≤ 500 97 155 250 400 630 970 1 550 2 500 4 000
defines the shape of the fit, �for instance is used for cylindric fits. In the
case of cylindric fit, the nominal dimension is the nominal diameter.
For single parts, the dimension and tolerance is expressed by a sequence
of shape symbol, nominal dimension, tolerance code. For example �50H7
defines a referential housing with 50mm nominal dimension while �13g6
defines a shaft with 13mm nominal dimension.
For assemblies, the symbol and nominal dimension are followed by housing
tolerance, then shaft tolerance codes. For example, in Figure 1.2 �69H8f7
refers to a cylindric loose fit of 69mm nominal diameter.
Considering Table A.1, it is worth noticing that switching tolerance letter
of assemblies do not change the fit nature. For instance H7f7 defines the
same loose fit as F7h7, and H7p6 defines the same snug fit as P7h6.Appendix B
Dual Vectors
Dual numbers
Dual numbers [53] are defined in a similar way that complex numbers are.
In analogy to the imaginary number ı that is used to define the imaginary
part of a complex number, the dual number ε is used to define the dual part
of a dual number. The dual number, however, is defined as non-zero element
whose powers are zeros, leading to different arithmetics than imaginary
numbers. The dual number is therefor called nilpotent.
General dual number ring
Provided G = {0, 1, ε} with multiplication operator ., where
ε �= 0
ε2 = 0.
we notice that (G, .) is a semigroup with 1 as identity.
Definition B.1 (General dual number ring). A general dual number ring
is the semigroup ring [98] of the semigroup G over a ring R [99].
A general dual number is then expressed as ˆx = a + εb where a, b ∈ R.
Addition and multiplication are extended on dual numbers. Given ˆx =
xa + εxb and ˆy = ya + εyb where xa, xb, ya, yb ∈ R, we write:
xˆ + ˆy = (xa + ya) +ε(xb + yb)
xˆ − yˆ = (xa − ya) +ε(xb − yb)
xˆ × yˆ = (xaya) +ε(xayb + xbya)
division ˆx = aˆ
ˆb
is defined as the solution of the equation ˆa = ˆb × xˆ.
We note that dual scalars are general dual numbers defined over the real
numbers ring (R, +, .).188 Chapter B. Dual Vectors
Dual vectors
When ring R in Definition B.1 is a vector field, the semigroup ring of G over
R defines a dual vector ring. A dual vector is denoted as ˆ
w� = �v + ε�u where
�v, �u ∈ R.
Dual semifields
Dual numbers can apply not only to rings (and fields) but also to semi-
fields [98].
Definition B.2 (General dual number semi-ring). A general dual number
semiring is the semigroup semiring [98] of the semigroup G over a semifield
(thus a semiring) R [99].
This extends the use of dual numbers to structures where not every
element has a multiplication inverse.Appendix C
Screw Theory
Mechanical crews
Screw theory [31] studies solid-bodies dynamics and kinematics. In a search
of a mathematical tool that can abstract both concepts while still accounting
for objects geometry, the theory proposes the use of screws, which it defines
as follows.
Definition C.1 (Screw). A screw is an ordered 6-tuple. The first triple represents
a line Euclidean vector associated, and the second triple represents
a free Euclidean vector applied to a point [19].
Each triple represents vector coordinate with respect to a coordinate
system B = {o, e�x, e�y, e�z}, where o is the origin of coordinates, e�x, e�y and
e�z are orthogonal right-handed unit vectors. The origin o then defines the
point to which the second vector is bound. The screw can then be expressed
as follows.
{v�1|v�2} =
vx
1 vx
2
vy
1 vy
2
vz
1 vz
2
The carrier line of the first vector is defined by v�1 itself, and a Euclidean
vector �r = v�1 × v�2 which defines a point on that line.
As mentioned above, screws are abstract mathematical tools. In order
to interpret screws, a context, either dynamic or kinematic, should be given.
Twist about a screw
Chasle theory showed that motion of a rigid body between two position
can be represented by a translation along an axis, and a rotation about the
same axis. The motion of a rigid body can thus be presented by a screw.
In this case, the first triple in the screw represents the angular velocity �ω;190 Chapter C. Screw Theory
its direction represents the rotation axis, while its magnitude represents the
rotation angle per time unit. The second triple represents the linear velocity
at the origin �v. Such a vector is then referred to as twist, and written as
follows.
T = {�ω|�v} =
ωx vx
ωy vy
ωz vz
Wrench on a screw
Poinsot theory showed that the system of external forces acting on a rigid
body can be reduced to a force and a torque on plane perpendicular to this
force. The system of external forces acting on a rigid body can thus be
represented by a screw. In this case, the first triple in the screw represents
the force �f. The second triple represents the torque at the origin m� . Such
a vector is then referred to as wrench, and written as follows.
W = { �f|m� } =
fx mx
fy my
fz mz
Co-moment of two screws
The co-moment of two screws A = {a�1|a�2} and B = {�b1|�b2} is defined as
follows:
A � B = a�1 · �b2 + �b1 · a�2.
When one of the screws is a wrench screw W, while the other is a twist
screw T, the co-moment of the two screws define their power.
P = W � T
= �f · �v + m� · �ω.
We can then state that the work done by a wrench screw W to displace
a rigid body body by a twist screw T during a time interval dt equals to
dW = (W � T)dt.
Reciprocal screws
Two screws are said to be mutually reciprocal if their virtual coefficient is
zero [31]. This means that the work done by a wrench on the first screw to
displace a rigid body by a twist about the second one is null over time [134].191
Definition C.2 (Reciprocal screws). A pair of wrench screw W = { �f|�t}
and twist screw T = {�ω|�v} is reciprocal when the virtual work of the wrench
on the twist equals zero.
Screws as dual vectors
Literature suggest the representation of screws, either twists or wrenches,
as dual vectors [36, 100]. Thus, a screw S = {v�1|v�2} can be written as
S = v�1 + v�2ε.
In the current work we adopt this convention. This allows the direct
application of algebraic properties of dual fields or dual semifields, depending
on the underling structure use: rings or semirings respectively.Appendix D
Description Logic
Decidability
Description Logic (DL) is a family of formal languages that deals with decidable
fragments of FOL [17]. It incorporate different languages that vary
according to their level of expressiveness. In fact, some DL variant go beyond
FOL capacities and define constructs that requires higher order logics,
they remain however decidable [28]. DL languages exhibit well-understood
computational behaviors.
Logic’s primitives
DL models the world by means of three logical entities.
Individuals that represent objects in the modeled world. Individuals are
comparable to constants in FOL.
Concepts that represent objects sets in the modeled world. Concepts are
comparable to unary predicates in FOL.
Roles that represent objects relations in the modeled world. Roles are
comparable to binary predicates in FOL.
Sets of primitive concepts and roles that identify a given domain are first
defined in a knowledge base. Primitive concepts are referred to as concept
names and primitive roles as role names. Language constructs are used
to extends the number of concepts that can be expressed by the language.
Newly introduced concepts are described using other role names, concept
names and concept descriptions, by means of language constructs. New
roles can also be described the same way, and used in concept descriptions.
The set of constructs allowed in a DL language dictates its expressiveness.
A kernel set of constructs that is embedded in all DL languages is194 Chapter D. Description Logic
Table D.1: A subset of DL constructs, their OWL equivalents, and their
semantics in terms of interpretations under the domain of discourse Δ. GCI
and axioms’ equivalents and interpretations are also shown [17, 28, 179].
DL construct OWL equivalent Construct semantic
ALC constructs
� owl:Thing Δ
⊥ owl:Nothing ∅
C � D owl:intersectionOf C ∩ D
C � D owl:unionOf C ∪ D
∀r.C owl:allValuesFrom {x, ∀y ((x, y) ∈ r ⇒ y ∈ C)}
∃r.C owl:someValuesFrom {x, ∃y ((x, y) ∈ r ∧ y ∈ C}
¬C owl:complementOf Δ/C
Other constructs
r ∈ p rdfs:subPropertyOf ∀x, y ((x, y) ∈ r ⇒ (x, y) ∈ p)
r
− owl:inverseOf {(x, y),(y, x) ∈ r}
GCI
C � D rdfs:subClassOf C ⊆ D
C ≡ D owl:equivalentClass C = D
Axioms
C(x) rdf:type x ∈ C
r(x, y) :r (x, y) ∈ r
referred to as ALC. In fact, ALC is a DL language on its own, that is the
simplest among its counterparts.
Table D.1 lists ALC constructs, and their respective equivalents in OWLDL.
Language semantics
DL is credited for its well-defined semantics. Semantics of the logic are
defined at the level of linguistic constructs in terms of interpretations. An
interpretation is possible under a domain of discourse Δ, whenever Δ �= ∅. It
maps each concept C to a set C ∈ Δ, and each role r to a relation r ∈ Δ×Δ.
Table D.1 shows the interpretation of each of ALC constructs with respect
to a domain of discourse Δ.
The TBox T of a knowledge base is defined in terms of a finite set of
General Concept Inclusion (GCI). A GCI is a restriction of the type C � D,
where C and D are DL-concepts. A GCI of the type C � D is interpreted as
C ⊆ D. A TBox T is interpreted as the conjunction of the interpretations
of all its GCIs.
Note that a concept equivalence, written C ≡ D is a syntactic sugar of195
the conjunction of two GCI; C � D and D � C. If one of the concepts in
C ≡ D is a concept name, the statement is then called a definition.
The ABox A of a knowledge base is defined in terms of a finite set of
axioms. An axiom can be of the type C(x) where C is a concept and x is an
individual. Such an axiom is interpreted as x ∈ C. Alternatively, an axiom
can be of the form r(x, y) where r is a role, and x and y are individuals.
Such an axiom is interpreted as (x, y) ∈ r. An ABox A is interpreted as the
conjunction of the interpretations of all its axioms.
A knowledge base K = �T , A� is interpreted as the conjunction of the
interpretations of its TBox and its ABox.
Expressive power
GCIs allow for the expression of domain knowledge in term of rules. They
can be used to represent concepts hierarchy in the modeled world, e.g.
Student � Person that states that all studets are people. They can also
be used to restrict the domain of a role, e.g. ∃teachs.� � Teacher that states
that only teachers can teach. They can even express more complex rules such
as ∃teachs.Math � Teacher � ∃hasDegree.SientificDiploma that states that in
order to teach math, one has to be a teacher with at least one scientific
degree.
We note that expressiveness of the language is highly dependant on the
allowed structures. For instance, with ALC only we cannot put restrictions
on roles range. To this end new constructs were added to ALC, producing
new DL languages, at the expense of some computational advantages.
For example, the introduction of the inverse role allows the expression
of range restrictions, and much more. Given a role r, an inverse role r
− is
defined and interpreted as r− = {(x, y),(y, x) ∈ r}. More constructs are also
defined such as transitive roles, subroles, concrete domains and nominals.
A convention exists to name DL languages by adding a letter to the name
for each introduced construct. To avoid lengthy names, the core language
ALC augmented by transitive roles is abbreviated as S. In this work we are
particularly interested in the language SHOIQ, which supports nominals
O, inverse roles I, and qualified cardinality restriction Q, besides core constructs
S. A more expressive language variant, SROIQ [88], is supported
by OWL-DL since version 1.1.Bibliography
[1] ANR ROMMA project. http://romma.lmt.ens-cachan.fr.
[2] cURL. http://curl.haxx.se/.
[3] Prot´eg´e ontology editor. http://protege.stanford.edu/.
[4] TraceParts. http://www.traceparts.com.
[5] World Wide Web Consortium. http://www.w3.org.
[6] Xerces-C++ XML parser. http://xerces.apache.org/xerces-c/.
[7] ISO 10303-1:1994. Industrial automation systems and integration –
Product data representation and exchange – Part 1: Overview and fundamental
principles. Standard, International Organization for Standardization,
Geneva, Switzerland, 1994.
[8] ISO 10303-203:1994. Industrial automation systems and integration –
Product data representation and exchange – Part 203: Application
protocol: Configuration controlled 3D design of mechanical parts and
assemblies. Standard, International Organization for Standardization,
Geneva, Switzerland, 1994.
[9] ISO 10303-28:1998. Industrial automation systems and integration –
Product data representation and exchange – Part 28 - Implementation
methods: XML representations of EXPRESS schema and data.
Standard, International Organization for Standardization, Geneva,
Switzerland, 1998.
[10] ISO 10303-21:2002. Industrial automation systems and integration –
Product data representation and exchange – Part 21: Implementation
methods: Clear text encoding of the exchange structure. Standard,
International Organization for Standardization, Geneva, Switzerland,
2002.
[11] ISO 10303-22:2002. Industrial automation systems and integration –
Product data representation and exchange – Part 22 - Implementation198 Bibliography
methods: Standard data access interface. Standard, International Organization
for Standardization, Geneva, Switzerland, 2002.
[12] ISO 10303-214:2003. Industrial automation systems and integration
– Product data representation and exchange – Part 214: Application
protocol: Core data for automotive mechanical design processes.
Standard, International Organization for Standardization, Geneva,
Switzerland, 2003.
[13] ISO 10303-11:2004. Industrial automation systems and integration –
Product data representation and exchange – Part 11: Description
methods: The EXPRESS language reference manual. Standard, International
Organization for Standardization, Geneva, Switzerland, 2004.
[14] OWL Web Ontology Language Overview.
http://www.w3.org/TR/owlfeatures/, 2004.
[15] DL Implementation Group. http://dl.kr.org/dig/, 2006.
[16] Technical drawings – Indication of dimensions and tolerances – Part 1:
General principles. Standard, International Organization for Standardization,
Geneva, Switzerland, 2014.
[17] Abiteboul, S., Manolescu, I., Rigaux, P., Rousset, M.-C.,
Senellart, P., et al. Web data management. Cambridge University
Press, 2012.
[18] Acheson, D. Elementary Fluid Dynamics. Oxford Applied Mathematics
and Computing Science Series. Oxford University Press, 1990.
[19] Adams, J. D. Feature based analysis of selective limited motion in
assemblies. PhD thesis, Massachusetts Institute of Technology, 1998.
[20] Agrawala, M., Phan, D., Heiser, J., Haymaker, J., Klingner,
J., Hanrahan, P., and Tversky, B. Designing effective step-bystep
assembly instructions. In ACM Transactions on Graphics (TOG)
(2003), vol. 22, ACM, pp. 828–837.
[21] Aidi, M., Tollenaere, M., and Pourroy, F. Towards a numerical
simulation scheduling in an engineering system approach. In Systems,
Man and Cybernetics, 2002 IEEE International Conference on (2002),
vol. 4, IEEE.
[22] Albers, A., Braun, T., Clarkson, P. J., Enkler, H.-G., and
Wynn, D. C. Contact and channel modelling to support early design
of technical systems. In Proc. International Conference on Engineering
Design, ICED’09 (Stanford, CA, USA, 2009).Bibliography 199
[23] Albers, A., Burkardt, N., and Ohmer, M. Contact and channel
model for pairs of working surfaces. In Advances in Design, H. A.
ElMaraghy and W. H. ElMaraghy, Eds., Springer Series in Advanced
Manufacturing. Springer London, 2006, pp. 511–520.
[24] Albers, A., Matthiesen, S., and Lechner, G. Konstruktionsmethodisches
grundmodell zum zusammenhang von gestalt und funktion
technischer systeme. Konstruktion, 7-8 (2002), 55–60.
[25] Allada, V., and Anand, S. Feature-based modelling approaches for
integrated manufacturing: state-of-the-art survey and future research
directions. International Journal of Computer Integrated Manufacturing
8, 6 (1995), 411–440.
[26] Ames, A. L. Production ready feature recognition based automatic
group technology part coding. In Proceedings of the First ACM Symposium
on Solid Modeling Foundations and CAD/CAM Applications
(New York, NY, USA, 1991), SMA ’91, ACM, pp. 161–169.
[27] Baader, F., Brandt, S., and Lutz, C. Pushing the EL envelope.
In Proceedings of the 19th International Joint Conference on Artifi-
cial Intelligence (San Francisco, CA, USA, 2005), IJCAI’05, Morgan
Kaufmann Publishers Inc., pp. 364–369.
[28] Baader, F., Horrocks, I., and Sattler, U. Chapter 3 description
logics. In Handbook of Knowledge Representation, V. L. Frank van
Harmelen and B. Porter, Eds., vol. 3 of Foundations of Artificial Intelligence.
Elsevier, 2008, pp. 135 – 179.
[29] Bacon, S. Reasoning about Mechanical Devices: A Top-down Approach
to Deriving Behavior from Structure. 1988.
[30] Baldwin, C., and Clark, K. Design Rules: The power of modularity.
Design Rules. MIT Press, 2000.
[31] Ball, R. A treatise on the theory of screws. Cambridge University
University Press, 1900.
[32] Barbau, R., Krima, S., Rachuri, S., Narayanan, A., Fiorentini,
X., Foufou, S., and Sriram, R. D. Ontostep: Enriching
product model data using ontologies. Computer-Aided Design 44, 6
(2012), 575–590.
[33] Barrett, C. W., Dill, D. L., and Stump, A. Checking satis-
fiability of first-order formulas by incremental translation to sat. In
Computer Aided Verification (2002), Springer, pp. 236–249.200 Bibliography
[34] Baysal, M. M., Roy, U., Sudarsan, R., Sriram, R. D., and
Lyons, K. The open assembly model for the exchange of assembly
and tolerance information: overview and example. In ASME 2004 International
Design Engineering Technical Conferences and Computers
and Information in Engineering Conference (2004), American Society
of Mechanical Engineers, pp. 759–770.
[35] Berners-Lee, T., Hendler, J., Lassila, O., et al. The semantic
web. Scientific american 284, 5 (2001), 28–37.
[36] Bidard, C. Dual basis of screw-vectors for inverse kinestatic problems
in robotics. In Advances in Robot Kinematics and Computational Geometry,
J. Lenarcic and B. Ravani, Eds. Springer Netherlands, 1994,
pp. 339–348.
[37] Blount, G. N., Kneebone, S., and Kingston, M. R. Selection
of knowledge-based engineering design applications. Journal of Engineering
Design 6, 1 (1995), 31–38.
[38] Blumel, E., Straßburger, S., Sturek, R., and Kimura, I. ¨
Pragmatic approach to apply virtual reality technology in accelerating
a product life cycle. In Proc. of International Conference INNOVATIONS
(Slany, Czech Republic, June 2004), pp. 199–207.
[39] Bobrow, J. E. Optimal robot plant planning using the minimumtime
criterion. Robotics and Automation, IEEE Journal of 4, 4 (1988),
443–450.
[40] Bogart, K., Drysdale, S., and Stein, C. Discrete math for
computer science students, 2004.
[41] Boussuge, F., Leon, J.-C., Hahmann, S., and Fine, L. An
analysis of DMU transformation requirements for structural assembly
simulations. In The Eighth International Conference on Engineering
Computational Technology (Dubronik, Croatie, Sep 2012), B.H.V.
Topping, Civil Comp Press.
[42] Boussuge, F., Shahwan, A., Leon, J.-C., Hahmann, S., Fou- ´
cault, G., and Fine, L. Template-based Geometric Transformations
of a Functionally Enriched DMU into FE Assembly Models.
Computer-Aided Design and Applications 11, 04 (2014), 436–449.
[43] Briggs, C., Brown, G., Siebenaler, D., Faoro, J., and Rowe,
S. Model based definition, April 2010.
[44] Canny, J. F., and Lin, M. C. An opportunistic global path planner.
Algorithmica 10, 2-4 (1993), 102–120.Bibliography 201
[45] Carslaw, H., and Jaeger, J. Conduction of Heat in Solids. 2nde
edition. Oxford Science Publications. Clarendo Press, 1986.
[46] Chakrabarti, A., and Bligh, T. An approach to functional synthesis
of solutions in mechanical conceptual design. part i: Introduction
and knowledge representation. Research in Engineering Design
6, 3 (1994), 127–141.
[47] Chapman, C. B., and Pinfold, M. Design engineering - a need to
rethink the solution using knowledge based engineering. KnowledgeBased
Systems 12, 5-6 (October 1999), 257–267.
[48] Chapman, C. B., and Pinfold, M. The application of a knowledge
based engineering approach to the rapid design and analysis of an
automotive structure. Adv. Eng. Softw. 32, 12 (Nov. 2001), 903–912.
[49] Chardonnet, J.-R., and Leon, J.-C. Designing interaction in
virtual worlds through a passive haptic peripheral. In 2012 IEEE
RO-MAN (France, 2012), pp. 284–289.
[50] Chouadria, R., and Veron, P. ´ Identifying and re-meshing contact
interfaces in a polyhedral assembly for digital mock-up. Eng. with
Computers 22, 1 (2006), 47–58.
[51] Church, A. An unsolvable problem of elementary number theory.
American journal of mathematics 58, 2 (1936), 345–363.
[52] Clark, B., Hanks, B., and Ernst, C. Conformal assembly meshing
with tolerant imprinting. In Proceedings of the 17th international
meshing roundtable (Pittsburg, USA, 2008), Springer, pp. 267–280.
[53] Clifford, W. Preliminary Sketch of Biquaternions. Proceedings of
The London Mathematical Society s1-4 (1871), 381–395.
[54] Condoor, S. Integrating design in engineering graphics courses using
feature-based, parametric solid modeling. In Frontiers in Education
Conference, 1999. FIE ’99. 29th Annual (1999), vol. 2, pp. 12D2/13–
12D2/17.
[55] Corallo, A., Laubacher, R., Margherita, A., and Turrisi,
G. Enhancing product development through knowledge-based engineering
(kbe): A case study in the aerospace industry. Journal of
Manufacturing Technology Management 20, 8 (2009), 1070–1083.
[56] Curran, R., Verhagen, W. J., van Tooren, M. J., and
van der Laan, T. H. A multidisciplinary implementation methodology
for knowledge based engineering: KNOMAD. Expert Systems
with Applications 37, 11 (2010), 7336–7350.202 Bibliography
[57] Dai, F., and Reindl, P. Enabling digital mock-up with virtual reality
techniques – vision, concept, demonstrator. In Design Engineering
Technical Conferences and Computers in Engineering Conference
(1996).
[58] Date, H., Kanai, S., Kishinami, T., and Nishigaki, I. Flexible
feature and resolution control of triangular meshes. In Proceedings of
the sixth IASTED international conference on visualization, imaging
and image processing (2006).
[59] Dawood, H. Theories of Interval Arithmetic: Mathematical Foundations
and Applications. Hend Dawood and LAP LAMBERT Academic
Publishing, 2011.
[60] De Kleer, J. How circuits work. Artificial Intelligence 24, 1 (1984),
205–280.
[61] De Moura, L., and Bjørner, N. Z3: An efficient smt solver. In
Tools and Algorithms for the Construction and Analysis of Systems.
Springer, 2008, pp. 337–340.
[62] Deng, Y.-M., Britton, G., and Tor, S. A design perspective
of mechanical function and its object-oriented representation scheme.
Engineering with Computers 14, 4 (1998), 309–320.
[63] Dixon, A., and Shah, J. J. Assembly feature tutor and recognition
algorithms based on mating face pairs. Computer-Aided Design and
Applications 7, 3 (2010), 319–333.
[64] Drieux, G., Leon, J.-C., Guillaume, F., and Chevassus, N.
Processes to integrate design with downstream applications through
product shapes adaptation. Systems Journal, IEEE 3, 2 (2009), 199–
209.
[65] Emberey, C., Milton, N., Berends, J. P. T. J., Tooren, M.
J. L. V., der Elst, S. V., and Vermeulen, B. Application of
knowledge engineering methodologies to support engineering design
application development in aerospace. In 7th AIAA Aviation Technology
(Belfast, Northern Ireland, 2007), Integration and Operations
Conference (ATIO).
[66] Falcidieno, B., and Giannini, F. Automatic recognition and representation
of shape-based features in a geometric modeling system.
Comput. Vision Graph. Image Process. 48 (October 1989), 93–123.
[67] Fiorentini, X., Gambino, I., Liang, V.-C., Rachuri, S., Mani,
M., and Bock, C. An ontology for assembly representation. Tech.Bibliography 203
rep., National Institute of Standards and Technology NISTIR 7436,
Gaithersburg, MD 20899, USA, July,, 2007.
[68] Foucault, G., Cuilliere, J.-C., Franc¸ois, V., Maranzana, R., `
and Leon, J.-C. ´ Adaptation of CAD model topology for finite element
analysis. Computer-Aided Design 40, 2 (2008), 176–196.
[69] Foucault, G., Shahwan, A., Leon, J.-C., and Fine, L. ´ What
is the content of a DMU? Analysis and proposal of improvements. In
Actes du 12`eme Colloque National AIP PRIMECA, Le Mont Dore, 29
Mars – 1er avril 2011 : Produits, Proc´ed´es et Syst`emes Industriels :
int´egration R´eel-Virtuel (Le Mont Dore, France, 2011).
[70] French, T., Helsel, J., Urbanick, B., and Svensen, C.
Mechanical Drawing CAD Communications. Glencoe/McGraw-Hill
School Publishing Company, 1990.
[71] Garbade, R., and Dolezal, W. DMU@Airbus – Evolution of the
Digital Mock-up (DMU) at Airbus to the Centre of Aircraft Development.
In The Future of Product Development, F.-L. Krause, Ed.
Springer Berlin Heidelberg, 2007, pp. 3–12.
[72] Gero, J. S. Design prototypes: a knowledge representation schema
for design. AI Mag. 11, 4 (Oct. 1990), 26–36.
[73] Gero, J. S., and Kannengiesser, U. The situated functionbehaviour.
Design Studies 25 (2004), 373–391.
[74] Gopalakrishnan, P. Handbook Of Materials Management. Eastern
economy edition. Prentice-Hall Of India Pvt. Limited, 2004.
[75] Grimm, S., and Motik, B. Closed world reasoning in the semantic
web through epistemic operators. In OWL: Experiences and Directions
(2005).
[76] Gruber, T. R. A translation approach to portable ontology specifi-
cations. Knowledge acquisition 5, 2 (1993), 199–220.
[77] Gui, J.-K., and Mantyl ¨ a, M. ¨ New concepts for complete product
assembly modeling. In Proceedings on the second ACM symposium on
Solid modeling and applications (New York, NY, USA, 1993), SMA
’93, ACM, pp. 397–406.
[78] Haarslev, V., and Moller, R. ¨ Racer: A Core Inference Engine
for the Semantic Web. In Workshop on Evaluation of Ontology-based
Tools (2003).204 Bibliography
[79] Haghighi, K., and Kang, E. A knowledge-based approach to
the adaptive finite element analysis. In Modeling, Mesh Generation,
and Adaptive Numerical Methods for Partial Differential Equations.
Springer, 1995, pp. 267–276.
[80] Hamri, O., Leon, J.-C., Giannini, F., Falcidieno, B., Poulat, ´
A., and Fine, L. Interfacing product views through a mixed shape
representation. part 1: Data structures and operators. International
Journal on Interactive Design and Manufacturing (IJIDeM) 2, 2
(2008), 69–85.
[81] Han, J., Pratt, M., and Regli, W. C. Manufacturing feature
recognition from solid models: A status report. IEEE Transactions
on Robotics and Automation 16 (2000), 782–796.
[82] Han, S. M., Benaroya, H., and Wei, T. Dynamics of transversely
vibrating beams using four engineering theories. Journal of Sound and
Vibration 225, 5 (1999), 935 – 988.
[83] Hartenberg, R., and Denavit, J. Kinematic synthesis of linkages.
McGraw-Hill series in mechanical engineering. McGraw-Hill,
1964, ch. Concepts and Notations Related to Mechanisms, pp. 28–67.
[84] Hashim, F. M., Juster, N., and Pennington, A. A functional
approach to redesign. Engineering with Computers 10, 3 (1994), 125–
139.
[85] Henderson, M. R., and Taylor, L. E. A meta-model for mechanical
products based upon the mechanical design process. Research in
Engineering Design 5, 3-4 (1993), 140–160.
[86] Hirtz, J., Stone, R. B., McAdams, D. A., Szykman, S., and
Wood, K. L. A functional basis for engineering design: reconciling
and evolving previous efforts. Research in Engineering Design 13, 2
(2002), 65–82.
[87] Horridge, M., and Bechhofer, S. The OWL API: A java API
for OWL ontologies. Semantic Web 2, 1 (2011), 11–21.
[88] Horrocks, I., Kutz, O., and Sattler, U. The even more irresistible
SROIQ. KR 6 (2006), 57–67.
[89] Iacob, R., Mitrouchev, P., and Leon, J.-C. ´ Contact identification
for assembly–disassembly simulation with a haptic device. The
Visual Computer 24, 11 (2008), 973–979.
[90] Iyer, N., Jayanti, S., Lou, K., Kalyanaraman, Y., and Ramani,
K. Three-dimensional shape searching: state-of-the-art review
and future trends. Computer-Aided Design 37, 5 (2005), 509–530.Bibliography 205
[91] Jackson, D. Automating first-order relational logic. In ACM SIGSOFT
Software Engineering Notes (2000), vol. 25, ACM, pp. 130–139.
[92] Jones, M., Price, M., and Butlin, G. Geometry management
support for auto-meshing. In Proceedings of 4th International Meshing
Roundtable (1995), pp. 153–164.
[93] Jorissen, P., and Lamotte, W. A framework supporting general
object interactions for dynamic virtual worlds. In Smart Graphics,
A. Butz, A. Kr¨uger, and P. Olivier, Eds., vol. 3031 of Lecture Notes
in Computer Science. Springer Berlin Heidelberg, 2004, pp. 154–158.
[94] Joshi, S., and Chang, T. C. Graph-based heuristics for recognition
of machined features from a 3d solid model. Comput. Aided Des. 20
(March 1988), 58–66.
[95] Jourdes, F., Bonneau, G.-P., Hahmann, S., Leon, J.-C., and ´
Faure, F. Computation of components’ interfaces in highly complex
assemblies. Computer-Aided Design 46 (2014), 170–178.
[96] Kallmann, M., and Thalmann, D. Direct 3d interaction with
smart objects. In Proceedings of the ACM symposium on Virtual reality
software and technology (New York, NY, USA, 1999), VRST ’99,
ACM, pp. 124–130.
[97] Kalman, J. Bednarek’s extension of light’s associativity test. Semigroup
Forum 3, 1 (1971), 275–276.
[98] Kandasamy, W. Smarandache Semirings, Semifields, and Semivector
Spaces. American Research Press, 2002.
[99] Kandasamy, W., and Smarandache, F. Dual Numbers. Zip Publishing,
2012.
[100] Keler, M. L. On the theory of screws and the dual method. In Proceedings
of A Symposium Commemorating the Legacy, Works, and
Life of Sir Robert Stawell Ball Upon the 100th Anniversary of A Treatise
on the Theory of Screws (2000), University of Cambridge.
[101] Khatib, O. Real-time obstacle avoidance for manipulators and mobile
robots. The international journal of robotics research 5, 1 (1986), 90–
98.
[102] Kim, K.-Y., Manley, D. G., and Yang, H. Ontology-based assembly
design and information sharing for collaborative product development.
Computer-Aided Design 38, 12 (2006), 1233–1250.206 Bibliography
[103] Kim, K.-Y., Wang, Y., Muogboh, O. S., and Nnaji, B. O. Design
formalism for collaborative assembly design. Computer-Aided Design
36, 9 (2004), 849 – 871.
[104] Kitamura, Y., and Mizoguchi, R. An ontological schema for sharing
conceptual engineering knowledge. In International workshop on
semantic web foundations and application technologies (2003), pp. 25–
28.
[105] Kuttig, D. Potential and limits of functional modelling in the cad
process. Research in Engineering Design 5, 1 (1993), 40–48.
[106] Kyprianou, L. K. Shape classification in computer-aided design.
PhD thesis, University of Cambridge, 1980.
[107] Lee, J., and Lai, K.-Y. What’s in design rationale? Human–
Computer Interaction 6, 3-4 (1991), 251–280.
[108] Leizerowicz, W., Bilgic, T., Lin, J., and Fox, M. S. Collaborative
design using www. In Proc. of WET-ICE’96 (1996), University
of West Virginia.
[109] Leon, J. C., and Fine, L. A new approach to the preparation of
models for fe analyses. Int. J. of Computer Applications in Technology
23 (2005), 166–184.
[110] Levison, L., and Badler, N. I. How animated agents perform
tasks: connecting planning and manipulation through object-specific
reasoning. In AAAI 1994 Spring Symposium Series. Proceedings
(1994), ScholarlyCommons, Penn Engineering.
[111] Li, K. Shape Analysis of B-Rep CAD Models to Extract Partial
and Global Symmetries. PhD thesis, Grenoble University, Grenoble,
November 2011.
[112] Liang, V.-C., and Paredis, C. J. A port ontology for conceptual
design of systems. Journal of Computing and Information Science in
Engineering 4, 3 (2004), 206–217.
[113] Lin, M. C., and Canny, J. F. A fast algorithm for incremental
distance calculation. In Robotics and Automation, 1991. Proceedings.,
1991 IEEE International Conference on (1991), IEEE, pp. 1008–1014.
[114] Lou, R., Pernot, J.-P., Mikchevitch, A., and Veron, P. ´ Merging
enriched finite element triangle meshes for fast prototyping of alternate
solutions in the context of industrial maintenance. ComputerAided
Design 42, 8 (2010), 670–681.Bibliography 207
[115] Lovett, P., Ingram, A., and Bancroft, C. Knowledge-based engineering
for SMEs – a methodology. Journal of Materials Processing
Technology 107, 1–3 (2000), 384 – 389.
[116] Lutz, C. The Complexity of Reasoning with Concrete Domains. PhD
thesis, RWTH Aachen, 2001.
[117] Makem, J. E., Armstrong, C. G., and Robinson, T. T. Automatic
decomposition and efficient semi-structured meshing of complex
solids. In Proc. of the 20th international meshing roundtable. Springer,
2012, pp. 199–215.
[118] Mandil, G. Mod´ele de repr´esentation g´eom´etrique int´egrant les ´etats
physiques du produit. PhD thesis, Universit´e de Sherbrooke, Quebec,
2012.
[119] Mantyla, M. Topological analysis of polygon meshes. ComputerAided
Design 15, 4 (1983), 228–234.
[120] Mantyl ¨ a, M. ¨ An Introduction to Solid Modeling. Principles of computer
science series. Computer Science Press, 1988.
[121] Mantyl ¨ a, M., Nau, D., and Shah, J. ¨ Challenges in feature-based
manufacturing research. Commun. ACM 39, 2 (Feb. 1996), 77–85.
[122] Marr, D., and Nishihara, H. K. Representation and recognition
of the spatial organization of three-dimensional shapes. Proceedings of
the Royal Society of London. Series B. Biological Sciences 200, 1140
(1978), 269–294.
[123] Matheson, J. A. L. Hyperstatic Structures: An Introduction to the
Theory of Statically Indeterminate Structures, vol. 1 of Hyperstatic
Structures: An Introduction to the Theory of Statically Indeterminate
Structures. Butterworths, 1971.
[124] McMahon, C., and Browne, J. CADCAM: Principles, Practice
and Manufacturing Management. ADDISON WESLEY Publishing
Company Incorporated, 1998.
[125] Mitra, N. J., Yang, Y.-L., Yan, D.-M., Li, W., and Agrawala,
M. Illustrating how mechanical assemblies work. vol. 29, ACM, p. 58.
[126] Mokhtarian, F., and Mackworth, A. K. A theory of multiscale,
curvature-based shape representation for planar curves. IEEE Transactions
on Pattern Analysis and Machine Intelligence 14, 8 (1992),
789–805.
[127] Ohsuga, S. Toward intelligent CAD systems. Computer-aided design
21, 5 (1989), 315–337.208 Bibliography
[128] Orton, J. D., and Weick, K. E. Loosely coupled systems: A
reconceptualization. Academy of Management Review 15, 2 (1990),
203–223.
[129] Pahl, G., Beitz, W., and Wallace, K. Engineering Design: Systematic
Approach. Springer-Verlag GmbH, 1996.
[130] Piegl, L. A., and Tiller, W. The NURBS book. Springer, 1997.
[131] Poincare, H. ´ Analysis situs. Journal de l’Ecole polytechnique 11 ´
(1895).
[132] Poinsot, L. El´ements de statique. Mallet-Bachelier, 1861.
[133] Pommier, S., and Berthaud, Y. M´ecanique G´en´erale. In [134],
2010, ch. Actions, Liaisons, pp. 83–112.
[134] Pommier, S., and Berthaud, Y. M´ecanique G´en´erale. Dunod,
Paris, 2010.
[135] Poole, D. L., and Mackworth, A. K. Artificial Intelligence: foundations
of computational agents. Cambridge University Press, 2010.
[136] Qian, L., and Gero, J. S. Function-behavior-structure paths and
their role in analogy-based design. AI EDAM 10, 4 (1996), 289–312.
[137] Quadros, W. R., and Owen, S. J. Defeaturing cad models using
a geometry-based size field and facet-based reduction operators.
Engineering with Computers 28, 3 (2012), 211–224.
[138] Quinlan, S. Efficient distance computation between non-convex objects.
In Robotics and Automation, 1994. Proceedings., 1994 IEEE
International Conference on (1994), IEEE, pp. 3324–3329.
[139] Quinlan, S., and Khatib, O. Elastic bands: Connecting path planning
and control. In Robotics and Automation, 1993. Proceedings.,
1993 IEEE International Conference on (1993), IEEE, pp. 802–807.
[140] Quintana, V., Rivest, L., Pellerin, R., Venne, F., and Kheddouci,
F. Will model-based definition replace engineering drawings
throughout the product lifecycle? a global perspective from aerospace
industry. Computers in Industry 61, 5 (2010), 497 – 508.
[141] Raghavan, V., Molineros, J., and Sharma, R. Interactive evaluation
of assembly sequences using augmented reality. IEEE Trans.
Robot. Autom. 15, 3 (1999), 435–449.
[142] Rahmani, K., and Thomson, V. Ontology based interface design
and control methodology for collaborative product development. Comput.
Aided Des. 44, 5 (May 2012), 432–444.Bibliography 209
[143] Rocca, G. L. Knowledge based engineering: Between AI and CAD.
Review of a language based technology to support engineering design.
Advanced Engineering Informatics 26, 2 (2012), 159 – 179.
[144] Rocca, G. L., and Tooren, M. J. L. V. Enabling distributed
multi-disciplinary design of complex products: a knowledge based engineering
approach. Journal of Design Research 5, 3 (2007), 333–352.
[145] Rocca, G. L., and van Tooren, M. A knowledge based engineering
approach to support automatic generation of fe models in aircraft
design. In 45th AIAA Aerospace Sciences Meeting and Exhibit (2007).
[146] Roy, U., and Bharadwaj, B. Design with part behaviors: behavior
model, representation and applications. Computer-Aided Design 34, 9
(2002), 613 – 636.
[147] Roy, U., Pramanik, N., Sudarsan, R., Sriram, R., and Lyons,
K. Function-to-form mapping: model, representation and applications
in design synthesis. Computer-Aided Design 33, 10 (2001), 699 – 719.
[148] Russ, B., Dabbeeru, M. M., Chorney, A. S., and Gupta, S. K.
Automated assembly model simplification for finite element analysis.
In ASME 2012 International Design Engineering Technical Conferences
and Computers and Information in Engineering Conference
(2012), American Society of Mechanical Engineers, pp. 197–206.
[149] SAS, O. C. Open CASCADE Technology, 3D modeling & numerical
simulation. http:/www.opencascade.org.
[150] Schenk, M., Straßburger, S., and Kissner, H. Combining
virtual reality and assembly simulation for production planning and
worker qualification. In Proc. of International Conference on Changeable,
Agile, Reconfigurable and Virtual Production (Munich, Germany,
2005).
[151] Sederberg, T. W. Computer Aided Geometric Design. Brigham
Young University, 2011, ch. Tensor-product Surfaces.
[152] Shah, J., and Mantyl ¨ a, M. ¨ Parametric and Feature-Based
CAD/CAM: Concepts, Techniques, and Applications. A WileyInterscience
publication. Wiley, 1995.
[153] Shah, J., Sreevalsan, P., and Mathew, A. Survey of
CAD/feature-based process planning and NC programming techniques.
Computer-Aided Engineering Journal 8, 1 (Feb 1991), 25–33.
[154] Shah, J. J., Anderson, D., Kim, Y. S., and Joshi, S. A discourse
on geometric feature recognition from cad models. Journal of Computing
and Information Science in Engineering 1, 1 (2001), 41–51.210 Bibliography
[155] Shearer, R., Motik, B., and Horrocks, I. Hermit: A highlyefficient
OWL reasoner. In OWLED (2008), vol. 432.
[156] Sirin, E., Parsia, B., Grau, B. C., Kalyanpur, A., and Katz,
Y. Pellet: A practical OWL-DL reasoner. Web Semantics 5, 2 (June
2007), 51–53.
[157] Smithers, T. AI-based versus geometry-based design or why design
cannot be supported by geometry alone. Comput. Aided Des. 21, 3
(Apr. 1989), 141–150.
[158] Sonthi, R., Kunjur, G., and Gadh, R. Shape feature determination
usiang the curvature region representation. In Proceedings of the
fourth ACM symposium on Solid modeling and applications (1997),
ACM, pp. 285–296.
[159] Sridharan, N. Classification, Parameterization, and Recognition of
NC Machining Features with Sculptured Surfaces. Arizona State University,
2000.
[160] Srinivasan, V., Lovejoy, W. S., and Beach, D. Integrated product
design for marketability and manufacturing. Journal of Marketing
Research (1997), 154–163.
[161] Stokes, M., and Consortium, M. Managing Engineering Knowledge:
MOKA: Methodology for Knowledge Based Engineering Applications.
Professional Engineering Publishing Limited, 2001.
[162] Sturges, R. H., O’Shaughnessy, K., and Kilani, M. I. Computational
model for conceptual design based on extended function logic.
Artificial Intelligence for Engineering, Design, Analysis and Manufacturing
10, 04 (1996), 255–274.
[163] Suh, N. The Principles of Design. Oxford series on advanced manufacturing.
Oxford University Press on Demand, 1990.
[164] Sunil, V., Agarwal, R., and Pande, S. An approach to recognize
interacting features from b-rep cad models of prismatic machined
parts using a hybrid (graph and rule based) technique. Computers in
Industry 61, 7 (2010), 686–701.
[165] Swamidass, P. Encyclopedia of Production and Manufacturing Management.
Springer, 2000.
[166] Thakur, A., Banerjee, A. G., and Gupta, S. K. A survey
of CAD model simplification techniques for physics-based simulation
applications. Computer-Aided Design 41, 2 (2009), 65–80.Bibliography 211
[167] Tomiyama, T., Umeda, Y., and Yoshikawa, H. A CAD for functional
design. CIRP Annals - Manufacturing Technology 42, 1 (1993),
143 – 146.
[168] Troussier, N., Pourroy, F., and Tollenaere, M. Mechanical
models management in engineering design. In IDMME (France, 1998),
vol. 4, pp. 1087–1094.
[169] Tsarkov, D., and Horrocks, I. Fact++ description logic reasoner:
System description. In In Proc. of the Int. Joint Conf. on Automated
Reasoning (IJCAR 2006 (2006), Springer, pp. 292–297.
[170] Turing, A. M. On computable numbers, with an application to the
entscheidungsproblem. J. of Math 58 (1936), 345–363.
[171] Ullman, D. The Mechanical Design Process. McGraw-Hill series in
mechanical engineering. McGraw-Hill, 2003.
[172] Ullman, D. G. A taxonomy for mechanical design. Research in
Engineering Design 3, 3 (1992), 179–189.
[173] Ullman, D. G. The mechanical design process. 2nd ed. New York:
McGraw-Hill, 1997.
[174] Umeda, Y., Takeda, H., Tomiyama, T., and Yoshikawa, H.
Function, behaviour, and structure. Applications of artificial intelligence
in engineering V 1 (1990), 177–194.
[175] Venkataraman, S., and Sohoni, M. Reconstruction of feature
volumes and feature suppression. In Proceedings of the seventh ACM
symposium on Solid modeling and applications (2002), ACM, pp. 60–
71.
[176] Verhagen, W. J., Bermell-Garcia, P., van Dijk, R. E., and
Curran, R. A critical review of knowledge-based engineering: An
identification of research challenges. Advanced Engineering Informatics
26, 1 (2012), 5 – 15. Network and Supply Chain System Integration
for Mass Customization and Sustainable Behavior.
[177] Wang, G. G. Definition and review of virtual prototyping. Journal
of Computing and Information Science in Engineering (Transactions
of the ASME) 2, 3 (2002), 232–236.
[178] Welch, R., and Dixon, J. Guiding conceptual design through behavioral
reasoning. Research in Engineering Design 6, 3 (1994), 169–
188.212 Bibliography
[179] Welty, C., McGuinness, D. L., and Smith, M. K. Owl web ontology
language guide. W3C recommendation, W3C (February 2004)
http://www. w3. org/TR/2004/REC-owl-guide-20040210 (2004).
[180] Whitney, D. Designing the design process. Research in Engineering
Design 2, 1 (1990), 3–13.
[181] Whitney, D. Mechanical Assemblies: Their Design, Manufacture,
and Role in Product Development. No. v. 1 in Mechanical Assemblies:
Their Design, Manufacture, and Role in Product Development. Oxford
University Press, 2004.
[182] Xu, X., and Hinduja, S. Recognition of rough machining features
in 2.5D components. Computer-Aided Design 30, 7 (1998), 503–516.
[183] Y14.5, A. Geometric Dimensioning & Tolerancing. ASME, 1982.
[184] Zhang, Q., Vonderembse, M. A., and Cao, M. Product concept
and prototype flexibility in manufacturing: Implications for customer
satisfaction. European Journal of Operational Research 194, 1 (2009),
143 – 154.
[185] Zhu, H., and Menq, C. B-Rep model simplification by automatic
fillet/round suppressing for efficient automatic feature recognition.
Computer-Aided Design 34, 2 (2002), 109–123.
Etude de l’anesthesie generale `a l’echelle atomique par
modelisation d’un homologue bacterien du recepteur
nicotinique humain
Benoist Laurent
To cite this version:
Benoist Laurent. Etude de l’anesthesie generale `a l’echelle atomique par modelisation d’un
homologue bacterien du recepteur nicotinique humain. Biomolecules. Universit´e Paris-Diderot
- Paris VII, 2014. French.
HAL Id: tel-01053431
https://tel.archives-ouvertes.fr/tel-01053431
Submitted on 30 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.Thèse de d o ctorat de l’un ivers ité Par is D iderot (Par is 7 )
École Doctorale Interdisciplinaire Européenne Frontières du Vivant
Étude de l’anesthésie générale à l’échelle
atomique par modélisation d’un
homologue bactérien du récepteur
nicotinique humain
Présentée par
Benoist Laurent
Pour obtenir le grade de Docteur de l’université Paris Diderot (Paris 7)
Spécialité : Biochimie informatique et statistique
èse soutenue le 16 juin 2014 devant le jury composé de :
Dr. Annick Dejaegere Université de Strasbourg Rapporteur
Dr. omas Grutter CNRS Rapporteur
Pr. Anne-Claude Camproux Université Paris Diderot (Paris 7) Examinateur
Dr. Nicolas Férey Université Paris Sud (Paris 11) Examinateur
Dr. Damien Laage CNRS Examinateur
Dr. Pierre-François Lavallée CNRS Examinateur
Dr. Marc Baaden CNRS Directeur de thèseÀ mon épouse, Lydie, mon modèle et ma source d’inspiration dans la science comme
dans la vie.
À ma lle, Flore, qui a plongé ma vie dans une incertitude insoluble qu’elle balaye
chaque fois qu’elle plonge son regard dans le mien.Remerciements
Mes remerciements s’adressent tout d’abord à mon directeur de thèse, Marc Baaden, qui s’est battu
avec moi pour obtenir un nancement et qui m’a accompagné pendant ces trois années. Tu m’as laissé la
liberté dont j’avais besoin (parfois plus!) et toujours respecté mes choix. Merci d’avoir choisi de ne jamais
rien m’imposer, mais de me convaincre au terme de débats souvent interminables.
Je remercie chaleureusement les laboratoires Servier pour avoir accepté de nancer ce travail pendant
plus de trois ans en me laissant la plus grande liberté, et plus particulièrement Olivier Nosjean qui m’a
soutenu dès le départ. Merci également à mon école doctorale, Frontières du Vivant et à la Fondation
Bettencourt Schueller.
Je tiens à remercier le Professeur Philippe Derreumaux pour m’avoir accueilli au sein du Laboratoire
de Biochimie éorique.
Mes sincères remerciements aux membres du jury qui ont accepté d’évaluer mes travaux. Un merci
particulier pour Nicolas Férey et Damien Laage qui ont été mes tuteurs tout au long de ma thèse et qui ont
partagé avec moi leur vision et leurs idées sur ce travail.
Je remercie très chaleureusement les membres du LBT, passés et présents, qui, chacun à sa manière,
contribuent à faire de ce laboratoire un lieu de travail stimulant que je quitte à regret. Merci à Samuel
qui m’a apporté son expertise dans de nombreux domaines et répondu à mes questions incessantes avec
patience et sarcasmes ! J’aimerais également adresser quelques mots à trois membres du LBT qui m’ont
particulièrement soutenus pendant cette thèse : Fabio Sterpone, Antoine Taly et Jérôme Hénin. Merci
Jérôme de m’avoir montré que même les choses les plus simples sont d’une complexité abyssale et d’avoir
su me les expliquer avec sérénité et courage.
Je n’oublie pas mes collègues de pasteuriens, Frédéric Poitevin, Ludovic Sauguet, Marie Prevost,
Pierre-Jean Corringer et Marc Delarue, pour m’avoir fait proter de leur expertise insondable des pLGICs.
Merci à mes amis, avec qui je partage depuis de nombreuses années mes joies, passions, doutes et
espoirs et sur qui j’ai toujours pu compter. Un mot particulier pour Paul qui, il y a maintenant huit ans,
m’a poussé à reprendre mes études et sans qui aujourd’hui, j’aurais sans doute un emploi stable !
Un dernier mot pour ma famille et plus particulièrement mes parents, sans qui, pour citer un de mes
illustres aînés, je ne serais pas là. Merci pour l’énergie que vous avez investi dès le plus jeune âge à m’éveiller
aux curiosités de la vie, probablement malgré vous. Je ne pourrais jamais vous rendre ce que vous m’avez
donné en me permettant de reprendre mes études et d’aller au bout de mes rêves.Abbreviations
5-HTR 5-HydroxyTryptamine Receptor
ATP Adenosin Triphosphate
BAR Bennett’s Acceptance Ratio
cAMP cyclic Adenosine Monophosphate
CeCILL Ce(A) C(NRS) I(NRIA) L(ogiciel) L(ibre)
CHARMM Chemistry at HARvard Molecular Mechanics
CNS Central Nervous System
CPU Central Processing Unit
CSS Cascading Style Sheets
DSF Desurane
ECD Extracellular Domain
ELIC Erwinia chrysanthemi Ligand-gated Ion Channel
FEB Free Energy of Binding
FFT Fast Fourier Transforms
GA General Anesthetic
GABA γ-Aminobutiric Acid
GABAAR GABA Receptor of type A
GLIC Gloeobacter violaceus Ligand-gated Ion Channel
GluCl Glutamate-gated Chloride ion channel
GlyR Glycine Receptor
GNU GNU’s Not Unix!viii
GPL General Public License
GROMACS Groningen Machine for Chemical Simulations
HTML Hypertext Markup Language
IDRIS Institut du Développement et des Ressources en Informatique Scientique
IMD Interactive Molecular Dynamics
LC Locally Closed
MBR Bromoform
MD Molecular Dynamics
nAChR Nicotinic Acetylcholine Receptor
NAMD Not (just) Another Molecular Dynamics program
NetCDF Network Common Data Form
NMR Nuclear Magnetic Resonance
NPT Number of particles Pressure Temperature
NVT Number of particles Volume Temperature
OPEP Optimized Potential for Ecient rotein structure Prediction
PBC Periodic Boundary Conditions
PBE Poisson-Boltzmann Equation
PDB Protein Data Bank
PFL Propofol
pLGIC pentameric Ligand-Gated Ion Channel
PME Particle Mesh Ewald
PNS Peripheral Nervous System
reST reStructured Text
RMSD Root Mean Square Deviation
SAXS Small-Angle X-ray Scattering
TMD Transmembrane Domain
VMD Visual Molecular Dynamics
WT Wild-TypeContents
0 A short primer about this thesis 1
1 Biological Background 3
1.1 The human nervous system, a central player in general anesthesia . . . . . . . . . . 3
1.1.1 Overall structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1.2 The synapse - creating the right interconnections . . . . . . . . . . . . . . . . 6
1.1.3 The action potential . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.1.4 Medical implications: general anesthesia . . . . . . . . . . . . . . . . . . . . . . 7
1.1.5 Neuroreceptors, a likely target for general anesthetics . . . . . . . . . . . . . 9
1.2 Bacterial and invertebrate homologues to the human nicotinic receptor . . . . . . . 12
1.2.1 Why study channels from bacteria? . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.2 A conserved general receptor organization . . . . . . . . . . . . . . . . . . . . . 13
1.2.3 Key features of an ion channel: opening and closing . . . . . . . . . . . . . . . 14
1.3 pLGICs are modulated by a variety of molecules . . . . . . . . . . . . . . . . . . . . . . 15
1.3.1 Modulation through the sites in the ECD . . . . . . . . . . . . . . . . . . . . . . 17
1.3.2 Modulation through the sites in the TMD . . . . . . . . . . . . . . . . . . . . . 17
1.4 Context in October 2010 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
2 Molecular Modeling: Theory And Practice 23
2.1 Force Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2.2 Molecular Dynamics Simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.2.1 Equation of motion integration algorithms . . . . . . . . . . . . . . . . . . . . . 25
2.2.2 Integration time step . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.3 Non-bonded interactions under periodic boundary conditions . . . . . . . . 27
2.2.4 Statistical ensembles: thermostats and barostats . . . . . . . . . . . . . . . . . 29
2.3 Free energy calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.4 Application: bromoform force field parameterization . . . . . . . . . . . . . . . . . . . 32
2.4.1 Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4.2 Methods . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.4.3 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.5 Difficulties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34x Contents
2.5.1 System composition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.5.2 Concentrations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.5.3 Protonation state . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.5.4 Solvation in special/unusual environments . . . . . . . . . . . . . . . . . . . . 41
2.5.5 Sampling, statistics, timescale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.6 Setups and methods used in this work . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.6.1 Short 8 ns long MD simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.6.2 Long MD simulations beyond the hundred nanoseconds timescale . . . . . . 45
2.6.3 Free energy calculations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.6.4 Confidence interval on means calculation . . . . . . . . . . . . . . . . . . . . . 47
2.6.5 Binding site occupancies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.6.6 Pocket volume calculation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.6.7 Contacts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3 High-Performance Computing And Large Scale Data Analysis 49
3.1 Computing the simulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.1.1 The need for high-performance computers . . . . . . . . . . . . . . . . . . . . . 49
3.1.2 Optimizing the available resources . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.1.3 Data storage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.2 Scaling and parallelization of the analysis processes . . . . . . . . . . . . . . . . . . . 52
3.3 Efficient Analysis Software Need: The Epock Software . . . . . . . . . . . . . . . . . . 53
3.3.1 Program features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.3.2 Application: the GLIC ion channel . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.3.3 Making Epock public . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.4 BioSpring: an Augmented Spring Network Simulation Engine . . . . . . . . . . . . . 57
3.4.1 Principle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.4.2 My contribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4 Probing pLGICs with bromoform reveals many interconnected anesthetic binding
sites 63
4.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.1.1 Bromoform-bound crystal structure of the GLIC channel in its locallyclosed
conformation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.1.2 Molecular Dynamics simulations to explore and quantify anesthetics binding 65
4.1.3 Crystallographic sites are spontaneously reachable . . . . . . . . . . . . . . . 65
4.1.4 All sites are interconnected, with gates between them . . . . . . . . . . . . . 67
4.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.2.1 Multi-site allosteric modulation, a delicate balance toward potentiation
or inhibition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
4.2.2 A residue gating the access to anesthetic allosteric binding sites . . . . . . . 73
4.2.3 H11’ protonation state impacts the potentiating site . . . . . . . . . . . . . . . 74Contents xi
4.2.4 The “pore binding site” hypothesis is supported by crystallographic and
simulation data. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
5 Propofol & desflurane simulations provide new insights into anesthetic action
at the atomic scale 77
5.1 Results . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.1.1 An extensive sampling close to the crystal structure . . . . . . . . . . . . . . . 78
5.1.2 Anesthetics are mobile within the W1 binding site . . . . . . . . . . . . . . . . 78
5.1.3 Different mobilities impact the number of contacts with the receptor . . . . 79
5.1.4 Ligand binding stretches the intrasubunit pocket . . . . . . . . . . . . . . . . . 81
5.1.5 Ligand binding does not impact neighboring cavities . . . . . . . . . . . . . . 82
5.1.6 Tyrosine 197 conformations are stabilized by hydrogen bonds . . . . . . . . 83
5.1.7 Y197’s stability is modulated by the T255A mutation . . . . . . . . . . . . . . 84
5.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
5.2.1 Binding to the intersubunit site B2 confirmed . . . . . . . . . . . . . . . . . . . 85
5.2.2 A more detailed contact map: the role of Y197 confirmed . . . . . . . . . . . 86
5.2.3 Influence of the ligand binding symmetry . . . . . . . . . . . . . . . . . . . . . 86
5.2.4 Understanding anesthetic’s action . . . . . . . . . . . . . . . . . . . . . . . . . . 87
5.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6 Concluding Remarks, Perspectives & Thoughts 91
6.1 Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
6.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Appendix Appendices 97
Bibliography 123List of Figures
1.1 e structure of a neuron. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2 Dierent types of glia interact with neurons and the surrounding blood vessels. . . . . . . 5
1.3 e chemical synaptic transmission. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1.4 e action potential. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.5 Structure of common general anesthetics. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
1.6 Examples of compounds that do not obey Meyer Overton’s rule. . . . . . . . . . . . . . . . 10
1.7 e structure of the nicotinic receptor from Torpedo marmorata. . . . . . . . . . . . . . . . 12
1.8 GLIC: a bacterial homologue to the human nicotinic receptor. . . . . . . . . . . . . . . . . 13
1.9 Comparing GLIC and ELIC closed state. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.10 Location of the anesthetic binding sites highlighted in pLGICs transmembrane domain. . 18
1.11 Hypothesis of anesthetic action on the function of ionotropic channels. . . . . . . . . . . . 20
2.1 Equation of potential energy and schematic representation of the various contributions. . 24
2.2 e algorithm underpinning molecular dynamics simulations. . . . . . . . . . . . . . . . . 25
2.3 Sympletic vs non-symplectic integrators. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.4 Periodic boundary conditions. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.5 Spherical cuto schemes for non-bonded interactions. . . . . . . . . . . . . . . . . . . . . . 29
2.6 A thermodynamic cycle for the computation of the free energy of binding of a ligand to a
receptor. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.7 Biological solutions are crowded mixtures. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.8 System set-up used to study ion permeation through GLIC according to the double bilayer
method. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.9 Isourane and ethanol partitioning along ooding simulations. . . . . . . . . . . . . . . . . 38
2.10 Localization of ionizable residues shown in a cross-section of the GLIC ion channel (grey). 39
2.11 pKa shi predictions with respect to standard values for all ionizable residues in GLIC
obtained using dierent soware packages. . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.12 Hydration traces of GLIC’s pore during two representative simulations. . . . . . . . . . . . 41
2.13 Sodium ion occupancy and related relative Boltzmann energy accumulated during a one
microsecond MD simulation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.14 Extensive screening of bromform’s anity for GLIC. . . . . . . . . . . . . . . . . . . . . . . 47xiv List of Figures
3.1 Benchmarking the speed of a simulation on a machine. . . . . . . . . . . . . . . . . . . . . 51
3.2 Calculation of a pore prole with Epock. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.3 From Epock setup to result analysis. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
3.4 Writing Epock’s website. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.5 e NetCDF array-oriented format. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.6 GNU autoconf and automake process for generating makeles. . . . . . . . . . . . . . . . . 62
4.1 A bromoform-bound structure of GLIC in its locally closed conformation. . . . . . . . . . 64
4.2 Two distinct conformations of residue Y197. . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.3 Key residues of the intrasubunit pocket. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.4 Bromoform exploration in ooding simulations. . . . . . . . . . . . . . . . . . . . . . . . . 68
4.5 Y197 side chain orientation along ooding simulations. . . . . . . . . . . . . . . . . . . . . 69
4.6 Transition of a bromoform molecule from the membrane to the B1 site. . . . . . . . . . . . 69
4.7 Free energies of binding of bromoform to the ve binding sites. . . . . . . . . . . . . . . . 71
4.8 Bromoform exploration of the intra- and intersubunit binding pockets in short MD
simulations. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.1 A sampling close to the crystal structure. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.2 Exploration of anesthetic molecules bound to W1. . . . . . . . . . . . . . . . . . . . . . . . 80
5.3 Anesthetics contacts with open GLIC. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
5.4 Volume of the intrasubunit pocket W1 occupied by 3 dierent anesthetics. . . . . . . . . . 82
5.5 Volume of the intersubunit pocket B1 occupied by bromoform. . . . . . . . . . . . . . . . . 82
5.6 Inuence of propofol binding on neighboring pockets. . . . . . . . . . . . . . . . . . . . . . 83
5.7 Inuence of bromoform binding to B1 on W1. . . . . . . . . . . . . . . . . . . . . . . . . . . 83
5.8 Y197 hydrogen bonds to surrounding residues. . . . . . . . . . . . . . . . . . . . . . . . . . 84
5.9 Tyrosine 197 side chain orientation in open and LC GLIC. . . . . . . . . . . . . . . . . . . . 85
A.1 Compared packing of the nAChR and GLIC structures. . . . . . . . . . . . . . . . . . . . . 97
B.1 Bromoform parameters for GROMACS. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
D.1 Contact maps of anesthetics bound to locally closed GLIC variants. . . . . . . . . . . . . . 119
D.2 Pocket exploration by bromoform in short MD simulations. . . . . . . . . . . . . . . . . . 120List of Tables
1.1 Example neurotransmitters and associated signal type. . . . . . . . . . . . . . . . . . . . . . 11
1.2 Sequence similarities of non-human pLGICs. . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3 Crystal structure of general anesthetics, alcohols and channel blockers bound to a member
of the pLGIC family. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
2.1 Bromoform parametrization result summary. . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.2 A human synaptic membrane composition. . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3 Systems simulated by means of short MD simulations. . . . . . . . . . . . . . . . . . . . . . 45
3.1 Comparing common supercomputers. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.2 Composition of a minimal GLIC system. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.1 Sampling time and studied systems for bromoform characterization. . . . . . . . . . . . . 66
4.2 Bromoform binding site occupancy along MD simulations. . . . . . . . . . . . . . . . . . . 66
4.3 Free energy of binding of bromoform as a function of H235 protonation state . . . . . . . 71
4.4 Bromoform occupancy of intrasubunit sites along ooding MD simulations according to
the Y197 residue side chain orientation. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 74
5.1 Inhibition of GLIC by two general anesthetics. . . . . . . . . . . . . . . . . . . . . . . . . . 77
5.2 Propofol occupancy of crystallographic binding sites in short MDs. . . . . . . . . . . . . . 78
5.3 Desurane occupancy of crystallographic binding sites in short MDs. . . . . . . . . . . . . 79
5.4 Comparison of anesthetic occupancies of the intrasubunit pocket binding sites. . . . . . . 81
5.5 Volume of the intrasubunit pocket W1 in open GLIC in presence of anesthetic molecules. 82
5.6 Predictive eect of mutant D32A and Y119A on GLIC’s inhibition by propofol and desurane. 89
D.1 Volume of the intrasubunit pocket W1 in GLIC crystal structures. . . . . . . . . . . . . . . 121
D.2 Volume of the intersubunit pocket W1 in GLIC crystal structures. . . . . . . . . . . . . . . 121A short primer about this thesis 0
Neuroreceptors are membrane proteins responsible for nervous signal transduction between neurons and
every part of the body. At synaptic ends, they receive the signal from the presynaptic cell in the form of a
neurotransmitter and respond with the opening of an ion channel located on the postsynaptic cell, leading
to transmission of the signal across the nervous ending. Dysfunction of neuroreceptors is associated to
several disorders of the central nervous system including myasthenia gravis, epilepsy, addiction to nicotine
and alcohol and several cognitive and mental disorders such as schizophrenia, Alzheimer’s and Parkinson’s
diseases. ey are also involved in general anesthesia mechanisms.
In this work, I focused on the latter, trying to understand the open question of general anesthesia
mechanisms at the atomistic scale. General anesthetics have been shown to target neuroreceptors, in
particular the pentameric Ligand-Gated Ion Channel (pLGIC) family. As a threedimensional structure of
an eukaryotic member of this family is particularly dicult to solve, numerous groups worldwide focus now
on prokaryotic members on this family, including Gloeobacter violaceus Ligand-gated Ion Channel (GLIC).
GLIC is a homopentameric ion channel the opening of which is controlled by pH variations. Since its
rst crystallization in 2009, several high resolution structures of this bacterial channel have been resolved,
including mutants, open, locally closed and closed conformations, and co-crystals with modulating ions,
alcohols, benzodiazepines, local and general anesthetics.
My work is primarily based on crystals of general anesthetics propofol, desurane and bromoform
bound to GLIC in open and locally closed conformations. I attempt to characterize anesthetics behavior
while bound to allosteric sites in conformations close to the crystal structures thanks to in silico methods
such as Molecular Dynamics (MD) simulations and Free Energy of Binding (FEB) calculations.
is manuscript is structured as follows.
Chapter 1, “Biological Background”, briey introduces basic notions on the nervous signal transduction
in the human body, followed by a short history on the development of anesthesia. I then focus on the
structure and function of human neuroreceptors before concluding with the state-of-the-art of the study
of bacterial and unicellular members of the pLGIC superfamily.
In Chapter 2, entitled “Molecular Modeling: eory And Practice”, I shortly introduce the main
methods I applied in the context of this project: MD simulations and free energy calculations. I then
develop some of the principal recurring diculties that have to be faced calculating MD simulations of
biomolecules.2 Chapter 0. A short primer about this thesis
Chapter 3, “High-Performance Computing And Large Scale Data Analysis”, deals with the answer I
found to methodological issues I faced on a daily basis, mainly related to high-performance computing
and large scale data analysis. In particular, I present the Epock soware, which I implemented during my
PhD project and that aims to eciently calculate protein pocket volumes.
e next two chapters are devoted to the characterization of general anesthetics behavior bound to the
GLIC channel.
Chapter 4, “Probing pLGICs with bromoform reveals many interconnected anesthetic binding sites”,
aims to describe the bromoform interactions with GLIC while bound to several binding sites. For this
purpose, I combine three complementary simulation strategies, trying to answer three principal questions:
i) are bromoform crystallographic binding sites spontaneously accessible? ii) how does bromoform
dynamics evolve while bound to these sites? iii) what is bromoform’s anity for each binding site?
In the next chapter, ‘Propofol & desurane simulations provide new insights into anesthetic action at
the atomic scale”, I extend the problems addressed in studying bromoform to general anesthetics propofol
and desurane. I aim to check whether hypotheses I established for bromoform are veried on other
general anesthetics that exhibit quite dierent properties compared to bromoform. I also address several
additional issues such as the symmetry of anesthetic binding and the extensive characterization of pocket
volume.
e work is then concluded with nal remarks and a general perspective. Supplementary information
is provided in the appendix.Biological Background 1
1.1 The human nervous system, a central player in general anesthesia
Here I will briey describe in a top-down manner the structure of relevant parts of the human nervous
system in relation to general anesthesia. e nervous system is an ensemble of structures that coordinates
an animal’s voluntary and involuntary actions and transmits signals to dierent body areas. In vertebrates,
it consists of two main parts, called the Central Nervous System (CNS) and the Peripheral Nervous
System (PNS). e CNS consists of the brain and the spinal cord. e PNS consists mainly of nerves,
which are long bers that connect the CNS to every part of the body. e PNS also includes peripheral
ganglia and the enteric nervous system, a semi-independent part of the nervous system that controls the
gastrointestinal system.
1.1.1 Overall structure
e nervous system is made of two main categories of cells: neurons and glial cells.
Neurons, or nerve cells, are distinguishable from other cells in a number of ways but their most
fundamental property is that they communicate with other cells through specialized intercellular adhesion
sites called synapses. A typical neuron has four morphologically dened regions: the cell body, dendrites,
axon and presynaptic terminals as shown in gure 1.1. Dendrites provide a highly branched, elongated
surface for receiving signals. e axon conducts electrical impulses rapidly over long distances to their
synaptic terminal, which releases neurotransmitter onto target cells (Kandel et al., 2000). An axon can
extend to dierent parts of the body and make thousands of synaptic contacts. A nerve is a bundle of
axons.
All neural cells that lack the capacity of transmitting rapid signals in the form of an action potential
(see section 1.1.3) are categorized into a broad class termed glia. In mammals, glial cells include microglia,
astrocytes, Schwann cells and oligodendrocytes (gure 1.2). ey ensure a wide range of functions, some of
them probably unknown yet, including homeostasis maintenance, neuron support, nutrition and insulation
to speed up electrical communication (Allen and Barres, 2009). Glial cell are an essential component of
the nervous system and can constitute the major part of a brain: human brain has about 90 % glial cells,
an elephant’s brain 97 %.4 Chapter 1. Biological Background
Nuclear
envelope
Cell
body
Axon
Synaptic
vesicle
Myelin sheath
Transport
vesicle
Endoplasmic
reticulum
Golgi
apparatus
Dendrites
Synaptic
terminal
Muscle
Figure 1.1 –e structure of a neuron. e cell body and nucleus of a spinal motor neuron are surrounded
by a double-layered membrane, the nuclear envelope, which is continuous with the endoplasmic reticulum.
e space between the two membrane layers that constitutes the nuclear envelope is continuous with the
lumen of the endoplasmic reticulum. Dendrites emerge from the basal aspect of the neuron, the axon
from the apical aspect. From Kandel et al. (2000).1.1. e human nervous system, a central player in general anesthesia 5
Figure 1.2 – Dierent types of glia interact with neurons and the surrounding blood vessels. Oligodendrocytes
wrap myelin around axons to speed up neuronal transmission. Astrocytes extend processes
that en-sheath blood vessels and synapses. Microglia keep the brain under surveillance for damage or
infection. From Allen and Barres (2009).6 Chapter 1. Biological Background
Ca2+
Presynaptic
nerve
terminal
Receptorchannel
Transmitter
Postsynaptic
cell
Na+ Na+ Na+
A B C
Figure 1.3 – e chemical synaptic transmission. A) An action potential arriving at the presynaptic
terminus causes voltage-gated Ca2+ channels on the presynaptic membrane to open. B) e opening of the
Ca2+ channels causes high concentration of intracellular Ca2+ which causes synaptic vesicles containing
neurotransmitter molecules to fuse with the presynaptic membrane and transmitters to be liberated in
the synaptic cle. C) e released neurotransmitter molecules diuse across the synaptic cle and bind
the neuroreceptor on the postsynaptic membrane. As ion channels open, the membrane potential of the
postsynaptic cell changes. Adapted from Kandel et al. (2000).
1.1.2 The synapse - creating the right interconnections
e synapse is a specialized structure that mediates a functional interaction between two neurons or between
a neuron and another cell type. Synapses may be of chemical as well as electrical nature. Chemical and
electrical synapses dier not only by the mechanism of information transfer, but also in their morphological
organization. At electrical synapses, the pre- and postsynaptic cells communicate through gap junctions,
cell-to-cell pores that serve as a conduit between the cytoplasm of two cells. Consequently, the space
between the two cells, called the synaptic cle, is on the order of 2 to 4 nm wide. In contrast, in the much
more common chemical synapses, the synaptic cle is wider, on the order of 20 to 40 nm (Hormuzdi et al.,
2004).
Chemical synaptic transmission depends on the diusion of a neurotransmitter across the synaptic
cle. Neurotransmitter molecules are contained in synaptic vesicles. At arrival of an electrical signal,
voltage-gated Ca2+ channels at the presynaptic terminus open, allowing Ca2+ ions to enter the cell. e
rise of intracellular calcium initiates synaptic vesicle fusion with the presynaptic membrane, therefore the
neurotransmitter liberation in the synaptic cle (gure 1.3). e neurotransmitter diuses and binds to
its receptor on the postsynaptic membrane, which responds by opening and letting ions pass from the
extracellular environment to the cytosol. If the ion ow is adequate, it will provoke a depolarization of
the postsynaptic membrane which will be transmitted through the axon of the receptor cell. Importantly,
chemical synapses can amplify the signal they receive since one synaptic vesicle releases thousands of
neurotransmitter molecules that can open thousands of ion channels on the target cell. A small presynaptic
nerve which generates a weak electrical current can therefore depolarize a large postsynaptic cell.1.1. e human nervous system, a central player in general anesthesia 7
–50
0
50
Membrane potential (mV)
Open channels per µm2 of membrane
40
20
0
Action potential
ENa
EK
Na+ conductance (Na+ channels)
K
+ conductance (K+ channels)
Figure 1.4 –e action potential. e sequential opening of voltage-gated Na+ and K+ channels generates
the action potential. From Kandel et al. (2000).
1.1.3 The action potential
An enormous amount of work has been realized by Hodgkin and Huxley (1952) leading to the detailed
comprehension of the sequence of events that constitute the action potential. As described in section 1.1.2,
the neurotransmitters binding to their receptor lead to the opening of ion channels, therefore the entering
of ions in the intracellular space. Consequently, the membrane potential changes, rising if cations enter
(depolarization), declining if anions enter (hyperpolarization). If the depolarization is sucient, i.e.
exceeds a threshold value1
, voltage-gated Na+
channels rapidly open resulting in an inward Na+
current.
is current causes further depolarization, thereby opening more Na+
channels, resulting in a further
increase of the inward current. e opening of Na+
channels causes the rising phase of the action potential
(gure 1.4). e depolarization gradually inactivates the voltage-gated Na+
channels and opens, with some
delay, voltage-gated K+
channels, resulting in an outward K+ ow that tends to repolarize the membrane.
As these channels remain open for some time aer the resting potential has been reached, this current leads
to a transient shi of the membrane potential to values more negative than the resting potential (Kandel
et al., 2000). e combined eect of this increase in K+
conductance combined with the inactivation of
Na+
channels underlies the absolute refractory period, the brief period aer which an action potential
cannot be triggered. As some K+
channels begin to close and some Na+
channels recover from inactivation,
the membrane enters the relative refractory period, during which an action potential can be triggered
by applying stronger stimuli that those normally required to reach threshold. e membrane potential
returns to its resting value as all the K+
channels nally close and the initial concentration of intracellular
ions is restored by nongated and gated ion channels responsible for maintaining ion balance at rest.
1.1.4 Medical implications: general anesthesia
e development of general anesthesia
General anesthesia has several purposes:
1e action potential obeys the all-or-none principle: stimuli below the threshold do not produce an action potential while
stimuli above the threshold all produce an action potential with the same amplitude. e intensity of the stimulus aects the
action potential frequency.8 Chapter 1. Biological Background
• analgesia i.e. loss of response to pain,
• amnesia i.e. loss of memory,
• unconsciousness,
• immobility i.e. loss of motor reexes,
• relaxation of skeletal muscles.
In contrast, local anesthesia does not provoke amnesia or unconsciousness. Furthermore, the eect of a
local anesthesia is restricted to a small part of the body. In a strict sense, local anesthesia refer for example
to a tooth or an area of the skin. Any larger region such as leg or arm is covered under the term regional
anesthesia. Usually, a local anesthetic cannot be used as general anesthetic and conversely.
e rst attempts of anesthesia presumably occurred during prehistory through the administration
of herbal remedies. Opium and alcohol were used in the Antiquity as narcotic and sedative, respectively,
although the question of which people are at the origin of this usage is still debated (Krikorian, 1975).
Interestingly, a Chinese legend wants that a Chinese physician successfully used herbal decoctions to render
patients unconscious for several days and practice surgery upon them. e exact formula he used likely
disappeared at his death. For centuries, physicians used oral as well as inhaled anesthetics in therapeutics
in the form of herbal mixtures, oen composed in part of Papaver somniferum, a plant from which opium
is prepared.
Several notable advances in anesthesia, local and general, were made during the 19th century. e rst
documented successful use of general anesthesia is generally considered as Hanoka Seishu mastectomy on
13 October 1804 (Izuo, 2004). is Japanese surgeon, aer years of eorts, nally developed a formula
which he named tsusensan composed of several plants from which, by the way, opium is not present. e
same year, Friedrich Sertürner isolated morphine from opium, a molecule still commonly used as an
analgesic. Along the 19th century, several uses of diethyl ether, the analgesic properties of which have been
described in the 16th century, are reported for local as well as general anesthesia. In the middle 1800s,
chloroform was discovered in Europe and rapidly replaced ether in Europe and Western countries, but
was discarded because of its tendency to cause fatal cardiac arrhythmia. Most modern anesthetics have
been developed by pharmaceutical labs, including propofol and desurane; their action mechanism will be
discussed in chapter 5. e development of most anesthetics has been primarily empirical, even sometimes
fortuitous.
Hypotheses on general anesthetics action
Several theories have been formulated on general anesthetics action, always relative to the modulation
of membrane proteins in the neuronal membrane. Paul Ehrlich (1854–1915) rst proposed the concept
of highly specic interactions between drugs and receptors, stating that a drug acts only when bound
to its target (Weir, 2006). As this theory was judged hardly applicable to general anesthetics because of
their chemical and structural diversity (gure 1.5), theories implying nonspecic perturbations of neurons
have been formulated. In the early 20th century, HH Meyer and CE Overton independently reported
a correlation between the solubility of narcotics in olive oil and their anesthetic power: the greater the1.1. e human nervous system, a central player in general anesthesia 9
lipid solubility of the compound, the greater its anesthetic potency. is relation became known as the
Meyer-Overton correlation, rened by Meyer’s son in Meyer, 1937. eories have then been developed
mentioning that anesthetic solubilization in neuronal membranes alters the function of ion channels.
However, these theories suer several weaknesses:
• several compounds with structures similar to anesthetics and high lipid solubility do not act as
anesthetics (gure 1.6A,B),
• general anesthetic ability to perturb membranes in vitro can be reproduced by a temperature drop
to less than 1
○C, a change well within the physiological range and clearly not sucient to induce
loss of consciousness,
• some enantiomers of general anesthetics do not produce identical clinical eects, although they
have the same properties in lipid bilayers, (gure 1.6C)
• there appears to be a cuto eect above a certain molecular volume which is indicative of anesthetic
agents interacting with binding site(s) of nite dimensions (Bradley et al., 1984).
Finally, it has been demonstrated that a range of general anesthetics act as competitive antagonists
on the rey luciferase, a soluble protein (Franks and Lieb, 1984). Remarkably, inhibition of luciferase
was directly correlated with anesthetic potency, providing persuasive evidence that general anesthetic
drugs could selectively interact with proteins. However, some groups still argue that anesthetics may alter
membrane properties which would play a role in anesthesia (Bahri et al., 2007; Baenziger et al., 2008;
Hansen et al., 2013).
In vitro experiments demonstrated that general anesthetics alter the function of several neurotransmitter
receptors at clinically relevant concentrations (Weir, 2006) including the GABA Receptor of type
A (GABAAR), the Nicotinic Acetylcholine Receptor (nAChR), the Glycine Receptor (GlyR) and the
5-HydroxyTryptamine Receptor (5-HTR) of subtype 3 (5-HT3R).
1.1.5 Neuroreceptors, a likely target for general anesthetics
Neuroreceptors are membrane proteins localized on the postsynaptic membrane that share a few common
properties, including the binding of neurotransmitters.
A major second property is that, in contrast to molecular pumps, the ux of ions through the channel
is passive. It is therefore determined not by the channel itself, but rather by the electrostatic and diusional
driving forces across the membrane. Finally, those channels are selective, which means that they allow
particular types of ions to cross the membrane. Most channels are selective to only one type of ion that
is usually present is the extracellular environment. Anion channels conduct only one physiological ion,
chloride (Cl-
). Cation channels are selective to Na+
, K+
, or Ca2+
. e eect of a synaptic potential, i.e.
excitatory or inhibitory, depends on the type of ion that permeates into the postsynaptic cell: cations, that
increase the membrane potential, trigger action potentials while anions cause an inhibition of the signal.
Neurons can receive signals from both excitatory and inhibitory synapses. Although some transmitters
can produce excitatory as well as inhibitory potentials, most transmitters produce a single type of response
because they bind the same type of channel wherever they are met in the body. Excitatory synaptic action10 Chapter 1. Biological Background
A
C D
B
E F
Figure 1.5 – Structure of common general
anesthetics. A) Propofol. B) Ketamine. C) Des-
urane. D) Isourane. E) Chloroform (not used
clinically anymore). F) Sodium thiopental (also
known as sodium pentothal).
A
C
B
Figure 1.6 – Examples of compounds that
do not obey Meyer Overton’s rule. A) 2,3-
dichlorooctauorobutane has very high lipid
solubility and properties similar to anesthetic
but do not provoke anesthetia. B) Enurane
(isomere of isourane – gure 1.5C – that is 45
to 90 percent less potent than isourane). C)
Etomidate (R etomidate is 10 times more potent
that S etomidate).1.1. e human nervous system, a central player in general anesthesia 11
Neurotransmitter Receptor Receptor type Signal Type
Acetylcholine nAChR ionotropic excitatory
Glutamate iGluR ionotropic excitatory
ATP P2XR ionotropic excitatory
Glycine GlyR ionotropic inhibitory
GABA GABAAR ionotropic inhibitory
GABA GABABR metabotropic excitatory
Serotonin*
5-HTR metabotropic excitatory
Table 1.1 – Example neurotransmitters and associated signal type. Examples of common neurotransmitters
associated with their most common receptor type and action on the signal.
* Serotonin receptors are metabotropic receptors with the notable exception of the 5-HT3 receptor which is a ligand-gated Na+
and K+
channel. 5-HT receptors are excitatory receptors with the exception of subtypes 5-HT1 and 5-HT5 .
is usually mediated by ionotropic glutamate and nicotine receptor channels that are permeable to sodium
and potassium. Inhibitory synaptic action is usually mediated by GABA and glycine receptors that are
permeable to chloride, as summarized in table 1.1.
Neurotransmitters control the opening of ion channels on the postsynaptic cell either directly or
indirectly, by acting on dierent types of receptors.
Receptors that gate ion ow indirectly, known as metabotropic receptors, include for example the
serotonin receptor (5-HTR) and the GABA receptor of type B. ey are usually made of a single subunit,
at most two, that are distinct from the ion channel they regulate. Activation of these receptors stimulates
the production of a second messenger, cAMP for instance, which activates a protein kinase, an enzyme
that phosphorylates dierent substrate proteins. In many cases, the protein kinases directly phosphorylate
ion channels, leading to their opening or closing (Kandel et al., 2000). ese several steps account for the
delay in the synaptic transmission compared to direct gating.
Ligand-gated channels, or ionotropic receptors, gate ion ow directly by opening upon neurotransmitter
binding. ey are composed of three to ve identical or homologous subunits symmetrically
arranged around a central ionic pore. e channel displays an Extracellular Domain (ECD) where the
neurotransmitter binds and a Transmembrane Domain (TMD) that forms an ion-conducting pore (see
gure 1.7A-B). Besides the pentameric channels, this family includes the trimetric P2X receptors and the
tetrameric glutamate receptor2
. e pentameric superfamily comprises the nAChR, the GABAAR and
the GlyR. e pLGICs are also named Cys-loop receptors due to the presence in the extracellular domain
of a dening loop of approximately 13 residues anked by two canonical cysteines linked by a disulde
bridge. Most signaling between neurons in the CNS involves ionotropic receptors, as well as synapses at
the neuromuscular junction which involve exclusively nAChRs.
To date, the only complete structure of an animal3 Cys-loop receptor available is that of the nAChR
from Torpedo marmorata (gure 1.7; Unwin, 2005). It was solved at a 4 Å resolution by cryoelectron
microscopy, a resolution at which a high uncertainty exists on side chain localization. Besides, this structure
2e glutamate channel from Caenorhabditis elegans (GluCl) is pentameric and chloride selective (see section 1.2.2).
3Apart from that of the nematode C. elegans (see section 1.2).12 Chapter 1. Biological Background
A B
membrane
C
M2 helices
and central pore
Figure 1.7 –e structure of the nicotinic receptor from Torpedo marmorata. A) Side view of the whole
structure represented in cartoon. e extracellular, transmembrane and intracellular domains are colored
in brown, purple and pink, respectively. B) Top view of the transmembrane domain colored by subunit
type (α, γ, α, β, δ). Each subunit contributes four helices, the M2 helix lining the channel pore. C) View of
the extracellular half of the TMD in space lling representation showing the numerous gaps induced by
the low packing between helices (see also appendix A.1).
is, to date, highly controversial since important gaps exist between the TMD helices (gure 1.7C), gaps
that are hardly compatible with the hypothesis according to which they are lled with water as originally
assumed (Miyazawa et al., 2003) because of the strong density visible at these locations in the density
map used to obtain the structure of the nAChR TMD (PDB-id 1OED) and the hydrophobic nature of
the residues surrounding these gaps. Brannigan et al. proposed that these gaps are actually lled with
cholesterol, since they successfully docked cholesterol into it (Brannigan et al., 2008) and since cholesterol
is required for nAChR’s proper function (Dalziel et al., 1980). Furthermore, the lack of resolution of
electron microscopy data led to the introduction of residue assignment errors in helices in the rst atomic
model of the TMD alone (Miyazawa et al., 2003), in which residues are shied by one helical turn from
their correct position. e error became evident inspecting homologous structures (see section 1.2) and has
been formally proven from direct experimental testing (Mnatsakanyan and Jansen, 2013). As the raw data
from Unwin’s work have not been released, further renement is made impossible and the uncertainties
concerning this model have not been dissipated.
1.2 Bacterial and invertebrate homologues to the human nicotinic receptor
1.2.1 Why study channels from bacteria?
In 2004, Tasneem et al. searched for distant representatives of the Cys-loop family in organisms outside
the animal lineage, faced with the fact that ancestors of voltage-gated potassium and sodium channels have
been identied in non-animal eukaryotes, as well as numerous prokaryotes. Interestingly, this indicates
that these channels were used in other signaling contexts by a variety of organisms way before the origin
of the animal nervous system (Ito et al., 2004). As Tasneem et al. argue that the TMD is compositionally
biased and tends to recover false positives in iterative sequence searches, they used only the ECD for their1.2. Bacterial and invertebrate homologues to the human nicotinic receptor 13
A
membrane
B C
M1 M2 M4 M3
N-ter
C-ter
β9
β9'
β10
β5
β6
β2
β8
β7
β1 membrane
Figure 1.8 – GLIC: a bacterial homologue to the human nicotinic receptor. A) Side view of the GLIC
channel. Compared to the nAChR (see gure 1.7), GLIC’s structure lacks the intracellular domain, the
helices at the top of the ECD and the two cysteines that border the signature loop (not visible here). B)
Topology of one of GLIC’s ve identical subunits, which is the same as for ELICand GluCl. C) Organination
of the transmembrane domain. Each subunit (represented with dierent colors) contributes to four helices
named M1 to M4. M2 helices line the channel pore.
queries. ey used PSI-BLAST to search in all organisms with genomic sequence data available at that
time, with initial queries such as the human acetylcholine receptor α7 chain or the human GABA receptor
α4 chain. In addition to animal sequences, these searches recovered sequences from bacteria such as the
cyanobacteria Gloeobacter violaceus and the γ-proteobacteria Erwinia chrysanthemi4
, among others.
1.2.2 A conserved general receptor organization
e work by Tasneem et al. turned out to be a breakthrough in the study of pLGICs. Several groups started
focusing on bacterial members of the superfamily, despite the debate on the applicability of discoveries
from prokaryotes to eukaryotes. Intensive eorts lead to the crystallization of two bacterial pLGICs, namely
ELIC from Erwinia chrysanthemi (Hilf and Dutzler, 2008) and GLIC from Gloeobacter violaceus (Bocquet
et al., 2009; Hilf and Dutzler, 2009). e structure of the eukaryotic glutamate-gated chloride channel
GluCl, from Caenorhabditis elegans, has been solved few years later in complex with the positive allosteric
modulator ivermectin (Hibbs and Gouaux, 2011).
ese structures show an important similarity with the nAChR although being simpler (gure 1.8).
e ECD is structured in a β-sandwich fold stabilized through conserved hydrophobic residues (Corringer
et al., 2012) but lack the N-terminal helix and the two cysteines that border the signature loop. e TMD
of each protomer is made of four helices named M1 to M4 (gure 1.8B). e M2 helices form the pore of
the channel and are thus critical segments of the ion conduction pathway (gure 1.8C). In contrast to the
nAChR, they do not display a cytoplasmic domain.
Despite this conserved general organization, the structure and length of loops connecting β-sheets
in the ECD vary along pLGICs although they are critical for the quaternary assembly of the receptor
(the sequence similarity between those pLGICs is notably low, as shown in table 1.2). e evolutionary
4Recent taxonomic revisions have caused the bacteria Erwinia chrysanthemi to be renamed Dickeya dadantii (Samson et al.,
2005).14 Chapter 1. Biological Background
GLIC ELIC GluCl nAChR
GLIC – 45 (22) 36 (23) 41 (19)
ELIC – – 39 (21) 41 (23)
GluCl – – – 42 (26)
Table 1.2 – Sequence similarities of non-human pLGICs. Sequence similarities calculated with proteinprotein
BLAST. Percentages of identity are given between parentheses. Sequence accession ids are Q7NDN8,
P0C7B7, Q17328, and Q9UGM1 for GLIC, ELIC, GluCl, and nAChR respectively.
explanation for these dierences is that these loops are believed to play a crucial role in the binding of the
agonist and the transduction of the signal to the TMD. Similarly, connecting loops in the TMD play a
determinant role for the channel function, such as the M2-M3 loop that actively participates to the signal
transduction (Corringer et al., 2012).
1.2.3 Key features of an ion channel: opening and closing
e comprehension of an ion channel’s transition from open to closed state, named gating, is essential
for the understanding of the mechanics of signal transduction. Based on normal modes analysis, Taly
et al. suggested that nAChR gating involved a quaternary twist-motion rearrangement of the ECD and
the TMD (Taly et al., 2005). is analysis, later performed on the crystal structures of GLIC and ELIC,
suggested that this gating mechanism was applicable to both prokaryotic channels (Bocquet et al., 2009;
Cheng et al., 2009).
However, the detailed function of a channel’s gating mechanism can hardly be understood without
knowing how to activate and inactivate it. GluCl, by denition, is gated by glutamate. GLIC’s natural ligand
was known even before the resolution of its crystal structure: the proton, meaning that GLIC opens at
acidic pH and closes at neutral pH (Bocquet et al., 2007). On the other hand, ELIC’s detailed investigation
was slowed down by the fact that activating ligands were unknown until a list of several primary amines
that include GABA were found to activate the receptor (Zimmermann and Dutzler, 2011). Notably, GLIC
is a cation channel with similar permeabilities for Na+
and K+
(Bocquet et al., 2007). Its conductance is
8 pS. At −60 mV, GLIC permeates only 3 to 4 ions per microsecond, making this process very expensive
in terms of computational cost to study thanks to MD simulations (see sections 2.2 and 3.1.2).
A second prerequisite to understand atomic details of a channel’s gating mechanism is to obtain the
structures of both its open and resting state, the endpoints of the gating transition. Based on the calculation
of the channel pore radius, one can determine whether a channel is in a conducting conformation or not,
i.e. if ions can pass through the pore. GLIC and GluCl display very similar open conformations, while
ELIC displays a closed pore.
Several attempts have been made to model the gating transition from GLIC’s open state to ELIC’s
closed state, assuming that ELIC is a good model for GLIC’s resting form (Zhu and Hummer, 2009, 2010;
Nury et al., 2010; Calimet et al., 2013), an assumption that is still debated today considering the low
sequence identity between the two proteins (see table 1.2). Furthermore, it is not clear whether ELIC’s
crystal structure represents the resting state as channels may adopt dierent closed conformations, in their1.3. pLGICs are modulated by a variety of molecules 15
desensitized state for example (Gonzalez-Gutierrez and Grosman, 2010). However, the work by Nury
et al. is interesting from several points of view. First, as GLIC is sensitive to pH, they induced the channel
closure by modifying the protonation state of selected residues. Second, they simulated a fully atomistic
model of the GLIC system for one microsecond, leading to the closure on only two over ve subunits,
which suggests that at least another microsecond would be required to simulate GLIC’s full closure. Finally,
they proposed that GLIC’s closure starts by the formation of a hydrophobic gate between residues 9’ and
16’ in prime notation5
, with a twist motion of the top of M2 helices. ese ndings revealed particularly
consistent with crystal structures of open and nonconductive GLIC as discussed below.
Concerning GluCl’s gating, it turns out that, upon ivermectin removal, the channel closes at the
hundred nanosecond timescale (Calimet et al., 2013; Yoluk et al., 2013). is transition is probably too
swi to be biologically relevant, as a full gating event is assumed to take place on the millisecond timescale.
is swiness probably indicates a bias in the crystal structure and/or the simulation setup. However,
several observations made during the transition of GluCl from open to closed state are consistent with the
quaternary model proposed in the light of recent high resolution structures of GLIC.
Among all pLGICs, GLIC is currently probably the best structural model to study transitions from
open to closed state since it has been crystallized in three distinct conformations, rstly at acidic pH in an
open conformation (Bocquet et al., 2009; Hilf and Dutzler, 2009), later mutants have been crystallized
in a Locally Closed (LC) conformation (Prevost et al., 2012; Gonzalez-Gutierrez et al., 2013), and very
recently an X-ray structure of Wild-Type (WT) GLIC in its resting state has nally been released (Sauguet
et al., 2014). e LC form shares most structural features with the open state but displays a closed pore as
a result of the concerted bending of the extracellular part of its M2 helices. It was recently demonstrated
that WT GLIC can adopt the LC form and that the open and LC forms coexist at acidic pH (Sauguet et al.,
2014), consistently with the assumption that the LC form can represent a late intermediate in the course of
activation. ese structures allowed to conrm that GLIC’s gating involves a marked twist motion of the
ECD, coupled with an inward tilt motion. e structure of the resting state shows that the conformation
of M2 helices is remarkably dierent from that observed in ELIC: GLIC’s pore appears closed due to a
concerted bending of the upper part of its M2 helices (gure 1.9). is motion is independent of M3 helix
orientation, unchanged compared to the open form. In ELIC, the M2 helix axis appears straight and M2
and M3 helices seem strongly attached to each other.
1.3 pLGICs are modulated by a variety of molecules
Over decades of research, pLGICs turned out to be modulated by numerous compounds with very dierent
physico-chemical properties. I chose to present some of the most important related studies, sorting the
compounds by the localization of the binding site.
5e prime notation has been introduced decades ago and aims to number residues that line the channel pore. Hence, residues
with the same prime number have the same location on the M2 helix, residue 1’ being located on the intracellular end of M2.16 Chapter 1. Biological Background
M2 M3 M2
M3
GLIC
Open pore
GLIC
Closed pore
ELIC
Closed pore
M2 M3
Figure 1.9 – Comparing GLIC and ELIC closed state. Top: enlarged views of the pore. e solventaccessible
region is shown by a green mesh, the side chain of the pore lining residues are shown as
sticks with polar and hydrophobic residues colored in green and yellow, respectively. Bottom: schematic
representation of the M2 and M3 helix relative positions. Adapted from Sauguet et al. (submitted).1.3. pLGICs are modulated by a variety of molecules 17
1.3.1 Modulation through the sites in the ECD
pLGICs are modulated by benzodiazepines, a class of widely prescribed drugs that display anxiolitic,
anti-convulsive and sedative properties, targeting mainly GABA receptors. ey have been shown to bind
ELIC’s ECD in two distinct sites with associated opposite modulation eects (Spurny et al., 2012):
• activation through an intrasubunit site at low concentration,
• inhibition through an intersubunit site at high concentration.
Notably, the intersubunit site matches a site previously described on GABAAR (Ramerstorfer et al., 2011).
Divalent cations such as Ca2+ or Zn2+ have been suggested to play an important role in a biological
context. Ca2+ can potentiate nAChRs (Vernino et al., 1992; Mulle et al., 1992) and inhibit 5-HTRs (Peters
et al., 1988), while Zn2+ can have potentiating or inhibiting eects, depending on its concentration and
the type of pLGIC (Laube et al., 1995; Palma et al., 1998). Divalent ions have been shown to inhibit ELIC
(Zimmermann et al., 2012), with a binding site at the interface between two subunits.
A 2.4 Å structure of GLIC allowed to detect Br-
, Cs+
and Rb+
at several binding sites in the vestibule
edge region of the ECD (Sauguet et al., 2013b). In the same study, the authors suggest two binding sites for
acetate, one overlapping the benzodiazepine binding site identied in ELIC, the second at the interface
between two subunits.
A nal study should be mentioned here. Pan et al. (2012) proposed a binding site for the General
Anesthetic (GA) ketamine located at the interface between subunits in GLIC’s ECD. Interestingly, this
structure is, to my knowledge, the only crystal structure of a GA bound to a pLGIC extracellular domain.
However, further investigation in Marc Delarue’s group highlighted several structures with unattributed
densities at the same location, even in absence of ketamine. e same group used these data to try
to propose an inhibition mechanism of GLIC by ketamine, using the Perturbation-based Markovian
Transmission model (Mowrey et al., 2013a). is work has, in my opinion, two weaknesses: i) the doubts
that still exist on the structure of ketamine bound to GLIC and ii) the lack of dynamic analyses to conrm
the validity of the paths from ECD to TMD that would explain ketamine’s action.
Importantly, most of these binding sites, especially ion ones, are still largely unexplored, as most groups
focused on the modulating sites in the TMD. A summary of anesthetics and alcohol binding sites found
by X-ray crystallography in pLGICs is given in table 1.3.
1.3.2 Modulation through the sites in the TMD
e TMD is the target of general and local anesthetics, alcohols and several cations.
Modulation sites for alcohols and GAs have been characterized experimentally by combining photolabelling
(Hamouda et al., 2013), site-directed mutagenesis and electrophysiology (Olsen et al., 2013; Howard
et al., 2011b). ree principal binding sites for GAs and alcohols have been identied within the TMD: i)
an intrasubunit pocket located within the M1-4 helix bundle, ii) an intersubunit pocket located roughly
at the same height than the intrasubunit pocket and iii) a channel site located at the extracellular end of
the pore, between the M2 helices. pLGICs crystal structures have been solved in complex with GAs and18 Chapter 1. Biological Background
Protein Ligand Resolution (Å) Reference
GAs
GLIC propofol 3.3 Nury et al. (2011)
GLIC desurane 3.1 Nury et al. (2011)
GLIC (F238A) bromoform 3.1 Sauguet et al. (2013a)
GLIC bromoform 2.7 Sauguet et al. (2013a)
ELIC bromoform 3.7 Spurny et al. (2013)
Alcohols GLIC (F238A) ethanol 2.8 Sauguet et al. (2013a)
GLIC (F238A) 2-bromo-ethanol 3.1 Sauguet et al. (2013a)
Channel
blockers
GLIC bromo-lidocaine 3.5 Hilf et al. (2010)
GLIC tetra-ethyl-arsonium 3.5 Hilf et al. (2010)
GLIC tetra-methyl-arsonium 3.6 Hilf et al. (2010)
GLIC tetra-butyl-antimony 3.7 Hilf et al. (2010)
GLIC picrotoxine 3.4 Hibbs and Gouaux (2011)
Table 1.3 – Crystal structure of general anesthetics, alcohols and channel blockers bound to a member
of the pLGIC family. Adapted from Sauguet et al. (submitted).
A B
P1
B1
B2 W3
W1
W2
B1
W3
W1
W2
P1
B2
Figure 1.10 – Location of the anesthetic binding sites highlighted in pLGICs transmembrane domain.
Top (A) and side (B) views of one and a half subunit transmembrane domain showing the three intrasubunit
binding sites (W1 to W3), the intersubunit site (B1) present in the GlyR and in GLIC F238A mutant, Nury
et al.’s linking tunnel (B2) and the pore site (P1).1.3. pLGICs are modulated by a variety of molecules 19
alcohols, covering these three sites. For convenience, we introduce here a nomenclature for these binding
sites that will be consistently numbered as summarized in gure 1.10 and referred to by their number.
A brominated variant of the local anesthetic lidocaine, which is known for its pore blockage properties,
as well as several cations were co-crystallized with GLIC few years ago (Hilf et al., 2010). Docking based
data suggested GLIC’s pore blockage by propofol and isourane with a micromolar anity (Brannigan et al.,
2010; LeBard et al., 2012). More recently, the co-crystal structure of ELIC with bromoform provided another
experimental evidence that anesthetics can bind pLGIC’s pore (Spurny et al., 2013). Inhibition through
the pore can be understood intuitively and two distinct mechanisms probably coexist. Open-channel
blockers, such as lidocaine, are most oen charged molecules that carry the same charge as the permeating
ion and block the pore by mimicking ion permeation up to the point where they sterically prevent ion
conduction and jam the channel in an open conformation. On the other hand, general anesthetics such
as propofol, desurane or isourane are mostly believed to block the pore in an allosteric fashion, either
selecting or favoring, then stabilizing a closed conformation. However, from a mechanistic point of view,
the hypothesis that pore blockage/closing alone is at the origin of the anesthetic-induced eects is dicult
to reconcile with mutagenesis data indicating that mutations in the intrasubunit pocket region aect
anesthetic action (Nury et al., 2011). Binding sites in this region should therefore closely be examined, too.
Propofol, desurane and bromoform bind the intrasubunit pocket in GLIC (Nury et al., 2011; Sauguet
et al., 2013a; Chiara et al., 2014). While propofol and desurane binding poses are virtually the same,
bromoform adopted three distinct poses in the cavity: site W1 (the W standing for within the subunit)
overlaps the propofol and desurane binding site; site W2 lies closer to the M1 helix and partially overlaps
site W1; site W3 is deeper inserted in the cavity, between the M1 and M2 helices, at the interface between
the intra- and intersubunit regions. Ethanol, 2-bromo-ethanol and bromoform were found to bind an
intersubunit cavity in the structure of a GLIC ethanol sensitive variant, namely the mutant F238A. Ethanol,
2-bromo-ethanol and bromoform were shown to bind an ethanol-sensitive variant of GLIC, namely the
mutant F238A, by docking in an intersubunit cavity (Sauguet et al., 2013a) that will be referred to as
site B1 (the B standing for between the subunits). is site had been previously suggested for ethanol
binding to the glycine receptor by MD simulations (Murail et al., 2011). GAs and alcohols binding to
these sites produce opposite eects on channel function. In GLIC, the intersubunit site B1 is thought to be
potentiating (Sauguet et al., 2013a; Brömstrup et al., 2013; Murail et al., 2012; Howard et al., 2011a) while
the intrasubunit W1 site is inhibitory (Nury et al., 2011). Another intersubunit site has been suggested for
propofol binding to GABAAR by photolabelling at the ECD and the TMD interface (Yip et al., 2013), that
had been suggested for desurane based on MD data (Nury et al., 2011). is site will be referred to as site
B2.
A founding hypothesis of my work is that anesthetics modify the equilibrium between the channel
open and closed states, complying with the denition of an allosteric modulator (gure 1.11). However, it
should be mentioned that some experts believe that anesthetics block ion ow by sterically obstructing
the channel. A consensus exists for some anesthetics such as lidocaine which is believed to be an open
channel blocker. On the other hand, some anesthetics such as propofol for example have been proven to
bind to GLIC’s intrasubunit pocket (Nury et al., 2011) and suggested to bind the pore as well (LeBard et al.,
2012). Propofol is therefore believed by some to be a steric channel blocker and not an allosteric inhibitor.
e emerging picture is that modulation is the eect of competitive binding between the intersubunit20 Chapter 1. Biological Background
Resting state
Activation by agonist
Inbibition by anesthetic
(cationic channels)
Potentiation by anesthetic
(anionic channels)
Open channel Closed channel
Neurotransmitter
Anesthetic
Figure 1.11 – Hypothesis of anesthetic action on the function of ionotropic channels. Neurotransmitters
as well as anesthetics are believed to change the equilibrium between the channel conformations i.e. open
and closed. e neurotransmitter modies the equilibrium in favor of the open state. At excitatory
channels, anesthetics favor the closed state, preventing cations to enter the cell therefore the increase of the
membrane potential. At inhibitory channels, they favor the open state, allowing anions to enter the cell
which have the eect of decreasing the membrane potential. At excitatory as well as at inhibitory channels,
anesthetic action is therefore to inhibit the transmission of the action potential.
potentiating site and the intrasubunit inhibitory site, which is consistent when applied to mammalian
pLGICs since GAs and alcohols potentiate inhibitory channels GABAARs and GlyRs, while they inhibit
the excitatory nAChRs. Although, despite the accumulation of crystal structures of general anesthetics
bound to a member of the pLGIC family, the molecular mechanism of allosteric inhibition by anesthetics
binding to intra- and intersubunit pockets is still poorly understood. Regarding the probable existence of
general anesthetic binding sites in pLGICs pore, channel modulation is to be regarded as the combined
eect of binding to the intra, inter, and pore regions.
1.4 Context in October 2010
In the next few lines, I attempt to provide some context for the choices I made when I started to work on
the project, in October 2010.
A close collaboration was initiated in 2009 between Marc Delarue’s group at Institut Pasteur and my
PhD supervisor, Marc Baaden. In January 2011, Marc Delarue’s group released the rst structure of general
anesthetics bound to GLIC (Nury et al., 2011). His group co-crystallized propofol and desurane bound to1.4. Context in October 2010 21
GLIC’s intrasubunit pocket.
As electrophysiology measurement showed marked dierences in the modulation of several GLIC
mutants by these GAs, Marc Baaden was in charge of running MD simulations aiming to understand
this phenomena. ese simulations yielded interesting but incomplete data on anesthetic dynamics while
bound to the receptor, mainly suggesting that channel closure could be caused by the repetitive contacts
between GAs and the M2 helices.
We decided to center the start of my thesis on three principal aspects: i) the extensive characterization
of desurane and propofol dynamics bound to the crystallographic site; ii) understanding why propofol
inhibits more the T255A mutant than the WT GLIC; iii) understanding why desurane has an opposite
eect than propofol on this mutant, i.e. it is less eective on the mutant than on the WT.
In early 2013, our collaborators at Institut Pasteur came back to us with several structures of bromoform
bound to GLIC, displaying among other previously unseen sites, a bromoform molecule bound to the
pore of GLIC in LC conformation. As I had developed a suite of tools that allowed me to rapidly launch
MD simulations on a system of interest and eciently analyze the results, our collaborators asked us to
characterize GLIC’s inhibition by bromoform.
In the next two chapters, I will introduce the methods I used and developed during this project. e
characterization of GLIC’s inhibition by bromoform will be detailed in chapter 4. e following chapter
will be devoted to the study of propofol and desurane dynamics while bound to GLIC. Finally, I will end
the present manuscript with some concluding remarks.Molecular Modeling: Theory And
Practice 2
In this chapter, I introduce the principal method I have been using in this work: molecular modeling.
Molecular modeling includes a wide range of methods, from mixed experimental-theoretical to purely
theoretical ones.
As an example of a so-called mixed method, Nuclear Magnetic Resonance (NMR) and X-ray crystallography
are widely used to determine the three-dimensional structures of molecules. Both methods
have a strong in vitro component including protein expression, purication and raw data acquisition.
Since none of these techniques routinely allow to precisely determine the position of atoms from raw
data, in silico models are used to t atoms in the signal acquired from the machines (Trabuco et al., 2008;
Brünger et al., 1998). Pure in silico methods developed during the last decades faced with the lack of in
vitro methods able to describe molecule dynamics at the atomistic scale. MD simulations are a member of
the large family of pure in silico methods, further including Brownian Dynamics, Normal Modes Analysis,
or docking for example. ese methods belong to the family of molecular mechanics methods that require
the use of a force eld (see section 2.1) to describe the interactions between a system of particles. Despite
their empirical nature, these methods have proven their ability to reproduce data obtained from “wet lab”
experiments and are used to answer questions that in vitro and in vivo procedures cannot.
In 2013, the Nobel Prize in Chemistry was awarded jointly to Martin Karplus, Michael Levitt and Arieh
Warshel for the development of multiscale models for complex chemical systems, an acknowledgment that in
silico methods are to be considered as an essential tool that can, together with in vitro and in vivo methods,
address some of the most challenging questions of our time.
is chapter is divided into four sections. e rst three sections briey introduce respectively the
concepts of force eld, MD simulation and free energy calculations. Finally, the fourth section will be
devoted to challenges mostly related to the simulation of biological systems.
2.1 Force Fields
As opposed to quantum mechanical representations that aim to describe the dual particle-like and wavelike
behavior of energy and matter, molecular mechanics representations use classical mechanics to model
a molecular system. Molecular mechanics methods require the use of a force eld that describes the
interactions between a system of particles with contributions of processes such as the stretching of bonds,24 Chapter 2. Molecular Modeling: eory And Practice
Vpotential = ∑
bonds
ki
2
(li − li,0)
2+
∑
angles
ki
2
(θi − θi,0)
2+
∑
torsions
Vn
2
[1 + cos(nω − γ)]+
N−1
∑
i=1
N
∑
j=i
4εi j
⎡
⎢
⎢
⎢
⎢
⎣
(
σi j
ri j )
12
− (
σi j
ri j )
6⎤
⎥
⎥
⎥
⎥
⎦
+
N−1
∑
i=1
N
∑
j=i
qiqj
4πε0ri j
+ -
Figure 2.1 – Equation of potential energy and schematic representation of the various contributions.
e total potential energy is the sum of bonded (bonds, angles, torsions) and non-bonded (steric, electrostatic)
interactions.
the opening and closing of angles, the rotations about single bonds and non-bonded interactions between
particles.
It should be noted that some methods do not account for all these components. As an example, in rigid
docking bonded interactions are oen ignored while classical spring network models do not explicitly
account for electrostatic interactions (Tirion, 1996; Bahar et al., 1997; Hinsen, 1998).
e classical form of a molecule’s potential energy is shown in the illustrated equation of gure 2.1.
For each component, energy penalties are associated with the deviation from equilibrium values. e
resolution of these equilibrium values, even when based on experimental data, is oen adjusted to t a
molecule’s macroscopic properties that can be measured thanks to in vitro experiments. is process is
called parametrization. For example, during the parametrization of small molecules such as anesthetics, it
is common to use the density of a pure solution of this molecule and the solvation energy of this molecule
in water as target properties. As another example, lipids are oen parametrized in such a way that the
order parameter of each carbon atom ts in vitro data.
As a consequence and since force elds are parametrized to t a nite set of properties that can be
dierent from one force eld to another, it is not surprising that a given force eld may perform better
reproducing certain properties compared to another one (and conversely). It is then crucial to choose
with precaution which force eld is the most appropriate to reproduce the properties one wants to study.
For example, several studies highlight the fact that the Amber03 force eld overstabilizes helical structures
(Cino et al., 2012; Lindor-Larsen et al., 2012) while it has been suggested that the OPLS-AA force eld
may be biased in favor of bends over helices (Cao et al., 2011; Cino et al., 2012; Vamparys, 2013).2.2. Molecular Dynamics Simulations 25
Initialize ri and vi
Fi = −
∂V
∂ri
ai =
Fi
mi
Update ri and vi
repeat as long as
needed
Figure 2.2 – e algorithm underpinning molecular dynamics simulations. With ri the cartesian coordinates
of the atom i, vi
its velocity, Fi the net force acting on it, V the potential energy applied to it, ai the
acceleration applied to it and mi
its mass.
2.2 Molecular Dynamics Simulations
Molecular Dynamics (MD) is a computer simulation method that integrates Newton’s laws of motion to
calculate successive congurations of a system, resulting in a trajectory of atom coordinates and velocities
over time.
e second law of motion states that the acceleration of a body depends directly upon the net force acting
upon the body, and inversely upon the mass of the object. us F = ma, where F is the net force acting on
the object, m its mass and a its acceleration. anks to a force eld, F can be calculated for each particle of
a system. Since the particle mass is known, its acceleration can be calculated, therefore its position at the
next iteration can be deduced. is process, called integration of equations of motions can be performed
several times to obtain a trajectory for each particle in the system (gure 2.2).
e integration of motion equations can be done thanks to several integrators, each one having specic
properties. Next I will develop a few examples of such integrators.
Because MD is an in silico method, the soware used to run the calculations plays a central role in
the data acquisition. During my thesis these issues proved important. In this part I will introduce some
dierences that exist in the main two soware suites that I used for MD simulations, namely NAMD and
GROMACS.
2.2.1 Equation of motion integration algorithms
is part could lead us into the deepest pits of classical physics and mathematics. I chose to present only a
few key concepts in order to highlight some of the most important properties that should be considered
before running an MD simulation.
ere are a variety of algorithms that can be used to solve ordinary dierential equations. e most
basic methods are probably the Euler method, named aer Leonard Euler who proposed it in the late 17th
century, and its generalization by C. Runge and M. W. Kutta, called the Runge-Kutta method.26 Chapter 2. Molecular Modeling: eory And Practice
0 2 4 6 8 10 12 14 16 18 20
27.5
27
26.5
26
25.5
−
−
−
−
−
− 25
Velocity Verlet, ∆t =1 fs
Runge−Kutta 4, ∆t =1 fs
0 2 4 6 8 10 12 14 16 18 20
25.464
25.4635
25.463
25.4625
−
−
−
−
− 25.462
Velocity Verlet, ∆t =0.1 fs
Runge−Kutta 4, ∆t =0.1 fs
Time (ps)
Total Energy (Kcal/mol)
Figure 2.3 – Sympletic vs non-symplectic integrators. Energy evolution of a water tetramer simulated
by the symplectic Verlet scheme (solid line) versus the non-symplectic Runge-Kutta integrator (dashed
line) at two time steps (0.1 and 1 fs). From Schlick (2010).
ese methods are quite intuitive and easy to implement, but do not feature one of the most important
properties an integrator should have in MD: they are not symplectic integrators. Sympletic integrators
are integrators that preserve specic properties associated with the Hamiltonian system of dierential
equations, including its value i.e. its energy (Schlick 2010, section 14.2). In practice, the total energy is not
preserved exactly but the energy error remains contained over time, which is dierent from non-symplectic
integrators which display a systematic energy dri over time. Runge-Kutta or Euler integrators are therefore
not to be used in MD.
e most popular methods for integrating Newton’s laws of motions derives from the Verlet method
(Verlet, 1967) in which the positions are given by
r(t + ∆t) ≈ 2r(t) − r(t − ∆t) + F
m
∆t
2
(2.1)
with ∆t the time between two snapshots. e velocities are given by
v(t) = r(t + ∆t) − r(t − ∆t)
2∆t
+ O(∆t
2
) (2.2)
with O(∆t
2
) being the interpolation error. NAMD implements the velocity-Verlet algorithm (Phillips
et al., 2005) while GROMACS’ default MD integrator is leap-frog (Pronk et al., 2013). GROMACS also
implements a variety of integrators which are mostly variants of either leap-frog or velocity-Verlet, each
one aiming to either increase accuracy or eciency under certain circumstances.2.2. Molecular Dynamics Simulations 27
2.2.2 Integration time step
e upper limit for the integration time step ∆t in the integration scheme depends on the fastest motions
in the system. For biological systems under biological temperature and pressure conditions, these motions
are light-atom bond vibrations, which are on the order of 10 fs (Schlick 2010, section 14.2.3). It is usually
accepted that ∆t has to be one order of magnitude lower than the fastest motions in the system, i.e. 1 fs in
this case. As the amount of CPU-time1
a user can spend calculating an MD simulation is xed and since
the computation time of one time step is constant, it is therefore useful to be able to increase the value of
∆t to speed up the simulation: computing 1,000,000 simulation steps with ∆t = 1fs will output a 1 ns long
simulation trajectory, while, with ∆t = 2 fs, 2 ns can be calculated in the same amount of time.
e integration time step can be increased by treating bond stretching degrees of freedom as rigid.
e traditionnal algorithm to constrain bonds, implemented in NAMD, is SHAKE (Ryckaert et al., 1977).
e LINCS algorithm (Hess et al. 1997, a default in GROMACS), has proven of higher eciency and
presents better convergence properties. Both algorithms solve the same problem i.e. resetting coupled
constraints aer an unconstrained update. Interestingly, a third algorithm optimized for rigid water
molecules, named SETTLE (Miyamoto and Kollman, 1992), has been implemented in both soware
packages and is commonly used in the simulations of biological solutions.
An alternative scheme to treat high-frequency vibrational modes is to separate the calculation of the
force on a particle into two components: short-range and long-range forces, the underlying idea being
that long-range forces vary more slowly than short-range forces. is technique, known as multiple-timestepping,
allows to use dierent time steps for bonded and non-bonded interactions. NAMD implements
this idea separating bonded forces, Lennard-Jones and short-range electrostatic forces and nally longrange
electrostatic forces in three dierent loops. Typical multiple time step example values would be 2 fs,
2 fs and 6 fs. Multiple-time-stepping is not yet implemented in GROMACS.
2.2.3 Non-bonded interactions under periodic boundary conditions
Periodic boundary conditions
Without specic boundary conditions, the simulation of a molecular system would take place in vacuum:
particles at the system’s border are surrounded by nothing. At a moderately short time scale, this would lead
to serious artefacts because the whole system would diuse in the innite space of cartesian coordinates.
e solution to this issue is to circumscribe the system in a box just large enough to encompass every
particles of the system. But this would lead to other artefacts: border particles would repeatedly collide
with the box, which would strongly impact their behavior. Because the size of the systems that can be
currently simulated with MD is still so small, the abnormal behavior of border particles would nally
impact little by little every components of the system. A solution to this problem is to periodically repeat
the simulation cell, a technique known as Periodic Boundary Conditions (PBC). A particle exiting on one
side of the cell enters from the opposite face with the same velocity (gure 2.4). Besides, border particles
on one side of the cell interact with particles at the opposite side. is technique therefore simulates an
1Cost of a simulation, expressed as the amount of time for which a Central Processing Unit (CPU) was used processing
instructions of a computer program (denition from wikipedia.org). For example, a calculation that was run on 128 CPUs and
lasted 2 hours consumed t = 2 × 128 = 256 CPU-hours.28 Chapter 2. Molecular Modeling: eory And Practice
Figure 2.4 – Periodic boundary conditions. e initial cell (central) is replicated in each direction so
that border particles interact with particles from the neighboring cell. Particles that exit a cell on one side
enter the cell on the opposite side.
innite system, but interactions with contributions from an innite number of neighboring images have
to be calculated, with consequences on computational eciency.
Non-bonded interactions
e complexity of computing non-bonded interactions is O(N
2
) where N is the number of atoms. is
is because non-bonded interactions have to be computed between all pairs of atoms. Such a complexity
implies a huge computational cost: Schlick (2010) estimates to roughly 2 years the CPU-time required
to calculate a single nanosecond of a 10,000-atom system. Fortunately, techniques have been developed
to reduce the dramatic cost of computing non-bonded interactions without decreasing the accuracy of
simulations of biomolecules in solvent.
e rst technique is to use a spherical cuto scheme, which is easy to implement and cheaper than brute
calculation (O(N)). ere are three categories of cuto techniques, all of them setting the contribution of
atoms remote from each other of a distance r > b to 0. e dierence between the techniques are their
behavior when r <= b (gure 2.5):
• the truncation approach does not change the value of the energy when r <= b, therefore abruptly
sets the interaction energy to 0 when r > b,
• switching schemes smoothly change the energy value for a <= r <= b,
• shi functions alter the function for all r < b.
In simulations of biomolecules, spherical cuto schemes are mostly used for representing van der Waals
interactions, which are quite short-range interactions.
Electrostatic interactions are long-range interactions that play a critical role in biomolecules. e
Particle Mesh Ewald (PME) approach has revolutionized biomolecular simulations, reducing the computational
cost of calculating long-range interactions from O(N
2
) to O(N log N) (Darden et al., 1993). is
technique, which has been developed specically to be used under PBC, employs direct calculation for
short-range interactions while long-range interactions are calculated in reciprocal space thanks to Fast
Fourier Transforms (FFT).2.2. Molecular Dynamics Simulations 29
orig.
trunc.
switch
shift
7 8 9 10 11
x 10-3
0
-2
-4
-6
VdW potential (kcal/mol)
r (Å)
a b 0.00
-0.06
-0.04
-0.02
4 6 8 10
Figure 2.5 – Spherical cuto schemes for non-bonded interactions. Van der Waals potential for various
cuto schemes with buer region 6-10 Å. Example of a Cβ − Cβ interaction with parameters taken from
the CHARMM program. Adapted from Schlick (2010).
2.2.4 Statistical ensembles: thermostats and barostats
Biological organisms live under strict conditions of temperature and pressure. To mimic a biological
environment, it is fundamental to be able to reproduce the atomic vibrational movement associated with a
given temperature and pressure. It is therefore very common for simulations of biological interest to run
in the NPT ensemble, i.e. an ensemble where the Number of particles, the Pressure and the Temperature
are retained constant.
Temperature coupling
e temperature T of a system is related to its kinetic energy, which is given by:
Ekinetic =
1
2
N
∑
i=1
miv
2
i =
1
2
νkT (2.3)
where ν is the number of degrees of freedom, i.e. 3 per atom (velocities along x, y and z axes)2minus the
number of constraints applied to the system. For example, for a system of N atoms with xed bond length
and center of mass momentum removal, ν = 3N − Nbonds − 3. Controlling the temperature can therefore
be done by a simple scaling of the velocities at each time step. However, algorithms coupling to an external
bath are oen preferred because they allow the temperature to uctuate about the desired temperature.
e Berendsen weak-coupling scheme (Berendsen et al., 1984) is a widely used algorithm. It has
been implemented in several MD soware packages such as NAMD and GROMACS. However, while it
performs fast temperature equilibration, it does not generate rigorous canonical averages (Leach, 2001).
Dierent canonical algorithms are therefore oen used for the production phase, such as the Andersen
thermostat (Andersen, 1980) or the Nosé-Hoover scheme (Nosé, 1984; Hoover, 1985). GROMACS also
implements a velocity rescaling method which is very similar to a Berendsen thermostat with an additional
stochastic term that ensures a correct canonical ensemble (Bussi et al., 2007).
2ere are 6 degrees of freedom per atom in the system, 3 for its velocity components plus 3 for the positions. As the kinetic
energy does not depend on atomic positions, here each atom accounts for 3 degrees of freedom.30 Chapter 2. Molecular Modeling: eory And Practice
Pressure coupling
e instantaneous pressure p(t) is computed as the trace
p =
1
3
Trace P (2.4)
of the pressure tensor
P =
2
V
(
1
2
N
∑
i=1
mivi ⊗ vi − Ξ) (2.5)
from the virial tensor
Ξ = −
1
2
∑
i 100 mM). is process is depicted on gure 2.9 along with data for
alcohol partitioning (Murail et al., 2011).
Brannigan’s study implies that a long equilibration of the system may be necessary before concentrations
can be measured reliably in order to allow solute molecules to partition between aqueous and membrane
phases. It may be debated whether concentrations should be calculated with respect to the water phase
only, with respect to water and membrane or with respect to the entire simulation box.
2.5.3 Protonation state
Knowing the protonation state of ionizable residues is a key issue to reliably model a protein. e protonation
state depends on a residue’s local environment. Standard pKa values measured in bulk cannot be
applied to buried protein residues, in particular for membrane proteins with an environment that largely
diers from aqueous solution. GLIC is constituted of ve symmetric protomers and the location of its 81 ×
5 ionizable residues is shown in gure 2.10. We may consider that equivalent residues in each subunit bear
identical protonation states. is assumption leads to approximately 281 = 1019 possible combinations of
protonation states. Tang and coworkers suggest that the protonation state of some titratable groups may
be dierent from one protomer to another leading to up to 1098 dierent combinations (Cheng et al., 2010;
Willenbring et al., 2011), a gure exceeding the number of particles in the universe!
e development of methods for calculating pKa values of titratable groups in proteins was pioneered
by Tanford and Kirkwood (1957) who proposed to represent the protein as an impenetrable sphere, which
allows to analytically solve the Poisson-Boltzmann Equation (PBE). e increase in computing performances
has facilitated the development of many PBE solvers, including the widely used APBS soware
(Fogolari et al., 2002; Baker et al., 2001). Nielsen and coworkers showed that a Finite Dierence PoissonBoltzmann
method yields better results when adding an explicit step to optimize the hydrogen bond38 Chapter 2. Molecular Modeling: eory And Practice
1
10
100
1000
0
0.3
0.6
0.9
0 100 200 300 400
100
1000
ISO - nAChR
ISO - GLIC
Eth - GlyR
Fraction ISO/Eth
in membrane
[ISO]aq (mM)
[Eth]aq (mM)
Time (ns)
Figure 2.9 – Isourane and ethanol partitioning along ooding simulations. Isourane (black and red)
and ethanol (green) partition into the membrane during the equilibration of a GLIC, a nAChR and a
GlyR system, respectively. e aqueous concentration of isourane (top) decreases for the benet of the
fraction in the membrane (bottom). e same behavior is observed for the partitioning of ethanol during
the equilibration of a GlyR system (green) but to a lesser extent. Due to its more hydrophilic properties,
ethanol concentration decreased to half the initial one (≈ 300 mM) at the end of the simulation. is is in
contrast to isourane: its concentration drops to less than 10% of the starting one (≈ 10 mM).
network (Nielsen et al., 1999). Ideally, protein conformational exibility should be taken into consideration
for calculating pKa values. Specic terms have been included in some algorithms (Alexov and Gunner,
1997) and, more recently, methods based on the λ-dynamics approach using constant pH MD and Replica
Exchange Molecular Dynamics emerged (Donnini et al., 2011; Williams et al., 2011; Meng and Roitberg,
2010). ese latter methods are currently still under development and have so far only been tested on
small non-membrane peptides or proteins. PROPKA (Li et al., 2005; Bas et al., 2008) may be one of the
most commonly used empirical approaches because it is very fast.
In order to setup simulations of the GLIC system, we assessed the results of several widely used
programs and web services. ese pKa predictions yielded widely varying pKa shis as illustrated in
gure 2.11. We settled on the use of the Yasara soware (Krieger et al., 2002) mixing Ewald summation and
hydrogen bonding network optimization to determine if a titratable group should be protonated or not
(Krieger et al., 2006). e Yasara results remain in a reasonable pKa shi range, whereas some of the other
methods suggest huge shis (gure 2.11). We applied a consensus approach, only protonating residues that
were simultaneously found to change ionization state in all ve subunits. Subsequent Brownian Dynamics
simulations suggested that a neutral H11’ residue is most compatible with ion permeation (data courtesy of
Prof. Toby Allen; not shown) and the inuence of this protonation state has been tested in more recent
simulations. Many eorts in improving the crystallization protocol for GLIC recently lead to a higher
resolution structure in which ion binding can be predicted between residue D86 and D88. is is a strong
indication that these residues should not be protonated (Sauguet et al., 2013b). ese ndings allowed us
to iteratively improve our protonation state estimate for GLIC.2.5. Diculties 39
Figure 2.10 – Localization of ionizable residues shown in a cross-section of the GLIC ion channel
(grey). M2 helices, in cartoon representation, line the pore through which cations (pink) cross the membrane
(ochre).40 Chapter 2. Molecular Modeling: eory And Practice
Figure 2.11 – pKa shi predictions with respect to standard values for all ionizable residues in GLIC
obtained using dierent soware packages. Residues are ordered according to ∆pKa = (pKa solution −
pKa calc) with respect to the Yasara soware (A) or the PROPKA soware (B), respectively. e bottom
part of each panel indicates the amino acid type of each residue.2.5. Diculties 41
-20
-10
0
10
20
0 50 100 150 200 -20
-10
0
10
20
z (Å)
Time (ns)
A
B
Figure 2.12 – Hydration traces of GLIC’s pore during two representative simulations. Minor changes
in the simulation parameters can make a noticeable dierence between a fully hydrated channel (A)
and a channel that dehydrates spontaneously in the upper part of the M2 helix-lined pore (B). For both
simulations, the protonation states were identical (Bocquet et al., 2009), the only dierences were the
forceeld and the MD soware used (amber99 and Gromacs for simulation A, vs. Charmm22 and
NAMD2 for simulation B).
2.5.4 Solvation in special/unusual environments
e complex shapes of proteins may feature channels and cavities providing special, potentially solvated
nano-environments. Water in such hydrophobic nanoconnement may be particularly unstable, a phenomenon
known as capillary evaporation. Several groups have observed and characterized dewetting
transitions in MD simulations, for example in the context of nanopores (Beckstein and Sansom, 2003;
Beckstein et al., 2001) or in the bacterial mechanosensitive channels MscL and MscS (Anishkin et al., 2010;
Anishkin and Sukharev, 2004). Roth and coworkers suggest that capillary evaporation could constitute an
intrinsic property of some channels (Roth et al., 2008) and may be a widespread biological mechanism.
In the case of GLIC, extensive sampling lead us to observe an unexpected pore dewetting behavior (see
gure 2.12A), as did several other groups (LeBard et al., 2012; Willenbring et al., 2011). Yet we cannot
currently conclude whether GLIC belongs to a family of bubble gated ion channels, since ongoing studies
in our lab suggest that subtle changes in the simulation parameters may prevent dewetting to occur (see
gure 2.12B). Another very recent study is more armative (Zhu and Hummer, 2012b). It should be noted
that forceeld parameters generally have not been tuned to reproduce the behavior of water in such special
environments, which is in part due to the lack of experimental data.
2.5.5 Sampling, statistics, timescale
A fundamental question before starting any computational study is how to best spend the limited amount of
available computing time. Strategies may vary in between two extremes: a) running many short simulations
from several starting points or b) running an extended one-shot simulation. Shaw et al. recently showed
that the result of the second approach matches experimental data very well, when the MD simulations are
long enough (Shaw et al., 2010).
In 2010, my PhD host lab studied GLIC gating in a 1 microsecond MD simulation suggesting a domino
gating mechanism in which subunits sequentially switch from an open to a closed conformation (Nury
et al., 2010). Despite the large amount of computational resources (approx. 10 months of calculations on42 Chapter 2. Molecular Modeling: eory And Practice
Figure 2.13 – Sodium ion occupancy and related relative Boltzmann energy accumulated during a
one microsecond MD simulation. Ions are blocked in the upper part of the transmembrane domain.
a supercomputer in 2009, i.e. tens of years on a recent desktop machine), only two protomers had fully
undergone this transition to a closed state at the end of the simulation, suggesting that a much longer
simulation was required to achieve a complete gating transition in all ve protomers. Longer simulations
are also needed to characterize processes such as ion permeation. Since GLIC has a low conductivity
of 8 ps, one should observe an estimated passage of only 3 ions per microsecond at −65 mV. A cheaper
alternative is to map the anity of ions for a certain position along the channel pore. Such a graph was
determined previously from the 1 microsecond gating simulation for a non-conductive state with a central
barrier (gure 2.13). It is usually admitted that a simulation should be run at least 10 times longer than the
slowest timescale of interest (Zuckerman, 2011). is is oen impossible since many relevant biomolecular
timescales exceed 1 microsecond. Typically, the neuromuscular acetylcholine receptor’s gating is expected
to be in the range of 1 to 10 µs (Chakrapani and Auerbach, 2005) which implies MD simulations from 10
to 100 µs.
Running several short comparative simulations may be more appropriate for ligand binding studies,
for example involving drugs and anesthetics as illustrated in the results of this PhD thesis. An advantage of
such short simulations is to remain close to a well dened state, e.g. a crystal structure, rather than moving
away from the experimentally backed conformation to some transient intermediate state. Furthermore one
may reduce the number of unproductive runs where the drug may diuse out of the binding pocket into
the solvent. Many short simulations with slightly dierent ligand starting conformations improve statistics
and sampling. We employ such an approach to study two general anesthetics, propofol and desurane, that2.5. Diculties 43
have recently been co-crystallized with GLIC (Nury et al., 2011). is study revealed a binding site in the
upper part of the transmembrane domain of the protein. Other binding sites for general anesthetics and
alcohols, including transmembrane, extracellular and pore sites have been suggested (Cheng et al., 2010;
Chen et al., 2010; Brannigan et al., 2010; Howard et al., 2011a). Channel blocking by charged quaternary
ammonium compounds, divalent ions and lidocaine has been shown using electrophysiology and X-ray
crystallography (Hilf et al., 2010), also suggesting binding sites located in the pore of the channel. ese
observations pose the problem of sampling from a combinatorial point of view: multiplying the number
of sites by the number of ligands, then by the number of mutants one wishes to test quickly leads to an
intractable required total simulation time.
Lipids are crucial for the structure and function of membrane proteins. Bilayers with complex compositions
pose a particular sampling challenge (Soares and Straatsma, 2008). A misplaced lipid in a
simulation setup might have consequences on the whole trajectory, in particular if it were to play a specic
biological role. With a diusion coecient of the order of 10−8
cm2
/s, a lipid embedded in a membrane is
expected to have a mean-square displacement of 4 nm2
for a one microsecond long simulation. In our
GLIC simulations, convergence for this value sets on beyond 100 ns and fully stabilizes at about 500 ns.
Hence, the timescale of most current studies does not allow for an extensive reorganization of lipids
around membrane proteins. Parton et al. recently addressed this problem while simulating a whole vesicle,
demonstrating the importance of lipid diusion for protein aggregation (Parton et al., 2011). e authors
however highlight that the coarse grained models are highly simplied and inevitably approximate the
nature of the protein-lipid and protein-protein interactions. de Meyer et al. (2010) previously suggested
the role of cholesterol in protein clustering using dissipative particle dynamics Monte Carlo and a more
simplied model.
At last, the problem of simulation convergence should be raised briey. Methods for the quantication
of sampling have been proposed for several decades, yet none has been widely adopted. In 2000, Berk
Hess proposed a method based on principal component analysis (Hess, 2000) that has been used by other
groups to evaluate the convergence of a set of MD simulations (Faraldo-Gómez et al., 2004; Grosseld
et al., 2007). Faraldo-Gómez and coworkers focus on convergence of membrane protein simulations, and
although the timescale is relatively short by today’s standards, their main ndings are likely still valid.
eir work concludes that structured transmembrane domains converge relatively fast, even on a 10 ns
timescale, but more mobile parts are under-sampled. Grosseld et al. calculated 26 independent 100 ns
molecular dynamics runs of rhodopsin and found similar results (Grosseld et al., 2007). To date, despite
new method proposals (Grosseld and Zuckerman, 2009; Zhang et al., 2010; Zhu and Hummer, 2012a),
sampling quality is oen tentatively assessed based on several simple criteria. A single descriptor may be
monitored along a simulation until it reaches a stable value. e Root Mean Square Deviation (RMSD),
which is a descriptor for molecular deformation, is a common but controversial criterion. A variation
consists in stopping a simulation aer a descriptor reaches an experimental reference value and remains
close to it for a certain time. Another approach is to use several independent MD simulations with dierent
starting points. When these simulations converge to a similar state, sampling is considered sucient.44 Chapter 2. Molecular Modeling: eory And Practice
2.6 Setups and methods used in this work
In this subsection I rst describe the simulation setups that form the basis for this thesis, representing
a total of over 1600 nanoseconds sampling accumulated on the anesthetic-bound GLIC system. At the
end I highlight a few non-standard methods used to calculate condence intervals on these data sets,
characterize the location of the anesthetic in a given binding site and determine binding pocket volume.
is work reports MD simulations of three dierent anesthetics bound to GLIC. Molecular models
of propofol (PFL) and desurane (DSF) bound to GLIC were built using a pre-equilibrated system of
GLIC embedded in a fully hydrated lipid bilayer. GLIC’s initial conguration was based on PDB ID 3EAM,
in which protein conformation is virtually identical to the later released high resolution structure 4HFI
(RMSD on heavy atoms is 0.4 Å), and then equilibrated without restraints for several tens of nanoseconds.
GLIC’s conformation at the end of the equilibration phase displayed an RMSD relative to 3EAM of 2.5 Å
(calculated and tted on the protein Cα atoms).
For bromoform, molecular models of open GLIC were built from PDB ID 4HFI (wild-type) and 4HFD
(F238A). e system was equilibrated with harmonic constraints on the protein backbone for 200 ns.
Residue protonation state was assigned in the same fashion as in previous simulations (Nury et al.,
2011) on the basis of pKa calculations with the Yasara soware (Krieger et al., 2012) to represent the most
probable pattern at pH 4.6, with residues E26, E35, E67, E69, E75, E82, D86, D88, E177 and E243 being
protonated. All histidines were doubly protonated (unless stated otherwise). e models were inserted
in a fully hydrated palmitoyl-2-oleoyl-sn-glycerol-phosphatidylcholine (POPC) lipid bilayer. e net
charge of the system was neutralized with Na+
and Clcounter
ions. e NAMD (Phillips et al., 2005) and
GROMACS (Pronk et al., 2013) soware suites were used for short and long MD simulations, respectively.
2.6.1 Short 8 ns long MD simulations
Anesthetic initial poses
e ligand was inserted into a previously equilibrated system of GLIC embedded in a fully hydrated lipid
bilayer. Bromoform (MBR) poses have been generated by randomly moving and rotating bromoform
molecules around the crystallographic binding site. Propofol and desurane poses have been generated by
taking the largest clusters from a 30 ns long MD simulation of the GA bound to GLIC. Previous coordinates
were calculated using the GROMACS g_cluster program with the gromos algorithm. e cuto distance
for the clustering has been determined empirically to t the number of starting conformations we needed
i.e. approximately 125.
GA molecules were assigned dierent conformations in each of the ve GLIC subunits and in each of
the 25 systems that were simulated achieving a total of 125 dierent poses, which maximizes anesthetic
sampling in the binding pocket.
Each system was then minimized for 1000 steps and ran for 8 ns using the run parameters described
below.2.6. Setups and methods used in this work 45
Anesthetic GLIC variant Conformation* Binding site†
Sampling (ns) Total sampling (ns)
MBR WT Open W1 25 × 8 = 200 1000
MBR WT LC P1 10 × 8 = 80 80
MBR F238A Open B1 25 × 8 = 200 1000
DSF WT Open W1 25 × 8 = 200 1000
DSF WT LC W1 25 × 8 = 200 1000
DSF T255A Open W1 25 × 8 = 200 1000
DSF T255A LC W1 25 × 8 = 200 1000
PFL WT Open W1 25 × 8 = 200 1000
PFL WT LC W1 25 × 8 = 200 1000
PFL T255A Open W1 25 × 8 = 200 1000
PFL T255A LC W1 25 × 8 = 200 1000
Table 2.3 – Systems simulated by means of short MD simulations. Each GLIC protomer hosts a GA.
Considering that each GA molecule is independent from the ones in the neighboring subunits, an MD
simulation of 5 GAs bound to GLIC therefore provides 5 times the sampling.
*
LC conformation is dened in section 1.2.3. †
Site numbering is dened in section 1.3.2.
MD run parameters
MD simulations were performed using the CHARMM27 (MacKerell et al., 1998) force eld. Temperature
and pressure were maintained using Langevin dynamics (Kubo et al., 1992) and a Langevin Piston (Feller
et al., 1995), respectively, at 310 K and 1 bar. Short-range non-bonded interactions were computed using a
potential switching from 8.5 to 10 Å. Long-range interactions have been treated using PME (Darden et al.,
1993). e same protocol has been used for each system for which short MD simulations were calculated
(table 2.3).
2.6.2 Long MD simulations beyond the hundred nanoseconds timescale
e ooding simulation setup was carried out by my colleague Samuel Murail.
For long MD simulations a previously equilibrated system containing GLIC, 246 POPC lipids, 29141
water molecules, 170 Cland
135 Na+
ions (i.e. a total of 146,000 atoms) in an hexagonal box was used to
create the system with 200 bromoform molecules. It was equilibrated for 50 ns with position constraints
on GLIC Cα atoms with the 4HFI structure as a reference. en four iterations were used to add slowly the
bromoform and avoid aggregates due to its low solubility. In each iteration, 50 molecules of bromoform
were added by replacing random water molecules 10 Å away of protein and 4 Å away of the membrane. e
system was then minimized for 10,000 steps and equilibrated with position constraints on GLIC Cα atoms
with the 4HFI structure as a reference. In the two rst iterations, equilibrations were 50 ns long, and 100 ns
long in the two following. In a last step bromoform molecules which were bound in the intrasubunit cavity
were replaced in the water phase and the system was minimized for 10,000 steps. is equilibrated system
was then used as starting point for the three ooding simulations. For simulation of F238A, the phenyl46 Chapter 2. Molecular Modeling: eory And Practice
side chain was removed manually from the system and a minimization of 10,000 steps was run. In each
of the three simulations, a supplementary equilibration step was used consisting in a 10 ns equilibration
with position constraints on heavy atoms, and 20 ns with position constraints on Cα atoms. Reference
structures used were, for WT open, WT LC, and F238A open simulations, respectively, PDB:4HFI, the
structure presented in chapter 4 and PDB:4HFD. Production runs were nally carried out for 1 µs without
any constraints. Simulations were performed using GROMACS 4.6.3 using virtual interaction sites, 5 fs
time steps, and all bond lengths constrained with the LINCS algorithm (Hess et al., 1997). Electrostatics
interactions were computed using particle mesh ewald summation at every step. A 10 Å cuto was used
for non-bonded interactions and the neighbor list was updated every 5 steps. ree baths (protein, water
and ion, membrane) were coupled to a temperature of 310 K using the Bussi velocity rescaling thermostat
with a time constant of τ = 0.1 ps. e x/y dimensions were scaled isotropically with a Berendsen weak
barostat and the z dimension independently to reference pressures of 1 bar, τ = 5 ps and compressibility of
4.5 × 10−5
bar−1
. During equilibration position restraints of 1000 kJ/(mol nm) were used.
2.6.3 Free energy calculations
irdly, we calculated the bromoform anity for each of the 6 binding sites in WT, F238A, open and LC
variants of GLIC using alchemical free energy calculations (gure 2.14). e bromoform poses displayed in
the crystal structure were used when available. e bromoform pose in intersubunit site B2 was extracted
from a short MD simulation. Bromoform was inserted into a previously equilibrated system of GLIC
embedded in a fully hydrated lipid bilayer. MD simulations were performed using the CHARMM36
(Huang and MacKerell, 2013) force eld. e system was minimized for 10,000 steps. Two successive
equilibrations with constraints on a reference structure, typically a crystal structure, were performed:
5 ns constraining protein heavy atoms and bromoform, then 20 ns constraining protein Cα atoms and
bromoform. During these two equilibration steps, constraints were also applied on the dihedral angle
between Y197 C-Cα-Cβ
-Cγ atoms ensuring an angle of 173.5° in GLIC open form and 91.8° in the locally
closed conformation. ese values correspond to the two principal modes of the angle distribution
observed along short MD simulations. A thermodynamic cycle was then applied to calculate free energies
of binding of bromoform to GLIC using a similar protocol as that described in (Brömstrup et al., 2013),
however as a large number of such calculations was carried out, we optimized the protocol in terms of
number of windows and sampling times. Coulombic and van der Waals interactions were decoupled
using a decoupling parameter λ linearly increasing from 0 to 1. Coulombic interactions were decoupled
along 11 independent steps while 21 steps were necessary to decouple van der Waals interactions. At each
λ-point, the system was minimized for 5000 steps, equilibrated for 10 ps in the NVT ensemble, then
equilibrated for 100 ps in the NPT ensemble. Bromoform positions were harmonically constrained during
these two equilibration steps with a force constant of 1000 kJ/(mol nm2
). Production simulations were
run using the sd3
integrator with a time step of 2 fs. During the production phase, bromoform positions
were restrained using an umbrella potential with a force constant of 100 kJ/(mol nm2
). For coulombic
interaction decoupling, 2 ns were carried out. For van der Waals interactions, 3 ns were carried out for the
rst 14 λ-points (initial λ < 0.7) and 10 ns for the remaining 7 points (initial λ >= 0.7). e same protocol
was applied for decoupling bromoform in water. e calculation of the binding free energy was carried out2.6. Setups and methods used in this work 47
GLIC Variant
Pore state
Binding site
Locally-Closed Open
WT
B1 B2 P1 W1-2 W3 B1 B2 P1 W1-2 W3
Locally-Closed Open
F238A
B1 B2 P1 W1-2 W3 B2 P1 W1-2 W3 B1
Figure 2.14 – Extensive screening of bromform’s anity for GLIC. Bromoform’s free energy of binding
was calculated for 5 binding sites in GLIC wild-type, mutant F238A, in both open and locally closed
conformation.
using the BAR method (Bennett, 1976) as implemented in the g_bar program from the GROMACS suite.
2.6.4 Confidence interval on means calculation
Comparing two means extracted from MD simulations requires a robust methodology that is not well
established in the eld. A classical method such as the Shapiro-Wilk test is oen not applicable in MD
because this test, as well as most parametric tests, require the data to be normally distributed and have
equal variances, which is oen not the case in MD. Non parametric tests, such as the Kolmogorov-Smirnov
test, are therefore a better choice but, as well as the parametric tests by the way, are biased by the number
of observations: they will return signicant p-values if the number of observations is important, even if
the dierence between the distributions is minimal. In MD, it is very common to calculate a mean on
hundreds or thousands of steps of a simulation. Another approach has therefore to be used to calculate
robust means with condence intervals.
I chose to use the bootstrapping method. is method consists in calculating an estimator, typically
the mean, of a distribution using a random resampling of the distribution with replacement. Numerous
resamplings have to be done, to nally obtain as many estimators extracted from the slightly dierent
subsamples extracted from the original data set. is method has several advantages, especially to calculate
means with condence intervals. First, it can be used on non normally distributed data since the ensemble
of means that is calculated will most likely be normally distributed itself. Second, this method is sensitive
to variance in the initial distribution which means that two sets of data centered on the same value but
with dierent variances will yield dierent condence intervals.
In my case, I chose to use 1000 resamplings.
2.6.5 Binding site occupancies
Binding sites occupancies have been computed by calculating the distance between the anesthetic and
a reference position taken from relevant crystal structures. e occupancy of site B2, which is not a
crystallographic site, has been calculated with respect to a position extracted from a short MD reference
simulation. A site is dened as occupied at a time t if the distance between the center of mass of the
anesthetic molecule and the reference position are within a cuto. e cuto value I chose is 4 Å, which
is quite restrictive considering the volume of the intrasubunit pocket. It is therefore important to note
that the analysis may indicate that the anesthetic does not occupy any binding site strictly speaking while
3e sd integrator implemented in GROMACS is an accurate leap-frog stochastic integrator which also acts as a thermostat.48 Chapter 2. Molecular Modeling: eory And Practice
being inside the pocket.
Occupancy maps have been calculated with Visual Molecular Dynamics (VMD)’s volmap tool, using
a classical van der Waals radius, combining all frames and averaging the data.
2.6.6 Pocket volume calculation
Binding pocket volume calculations have been carried out using the Epock soware (see section 3.3).
To calculate the volume of the intrasubunit pocket, only frames with anesthetic molecules closer than
4 Å from sites W1, W2 or W3 have been taken into account.
e nal volume average value and corresponding condence interval have been calculated by bootstrapping
(see section 2.6.4.) considering the last 3 nanoseconds of simulation.
2.6.7 Contacts
Contacts between the anesthetic and the protein residues have been calculated with the VMD measure
contacts procedure. A contact with a residue is counted if any atom from the anesthetic is closer than
4 Å of any atom of the residue. e number of contacts with a residue at a time t is summed over the ve
subunits of the protein. e nal percentage of contacts between the anesthetic and a residue is dened as
the sum of the number of contacts at each frame divided by the number of frames in the simulation. is
percentage is therefore the probability that any of the ve anesthetic molecules present in a simulation
contacts the correspondind residue on any of the ve GLIC chains.3
High-Performance Computing And
Large Scale Data Analysis
e founding principle of statistical physics concerns ergodicity stating that the time average of one
sequence of events is the same as the ensemble average. Hence, as any statistical analysis, data obtained
from MD simulations can only be trusted if numerous uncorrelated events have been observed. As
discussed in section 2.5.5, there are basically two ways one can apply this principle to MD simulations: a)
running an extended one-shot simulation; b) running many short simulations from several starting points.
Depending on the study focus, the rst, second or both methodologies may apply. For example, a study
that aims to describe the process of binding of a ligand to a protein would most probably require long
simulations in which the ligand is not bound to the protein at the start as opposed to the description of the
interactions between a protein and a bound ligand, which would require many short simulations to avoid
the ligand unbinding. Nowadays, it is very common to run one to two long simulations since, as will be
justied in this chapter, it oen implies less work.
A major aspect of this work has been the description of the dynamics of GAs bound to GLIC. I chose
the second approach, i.e. the calculation of several short simulations to achieve extensive sampling of the
ligand dynamics while bound to the protein.
In this part, my goal is to introduce the main technical diculties I have been facing. e rst section
will be devoted to the specic hurdles related to the approach I used, while the following is related to the
system’s size.
3.1 Computing the simulations
3.1.1 The need for high-performance computers
As GLIC is a membrane protein, a minimum system for studying this channel at an all-atom resolution is
made of several molecule types, leading to a total number of approximately 200,000 atoms (see table 3.2).
e simulation of such a number of particles remains challenging and requires computational power that
is oen not accessible locally. Supercomputers are therefore required to produce data in a reasonable
time. As an example, using 184 cores on jade@cines.fr1
allows to run an MD simulation at a speed of
10 ns/24h. While computing 10 ns of simulation takes one day on jade, it would virtually take 46 days to50 Chapter 3. High-Performance Computing And Large Scale Data Analysis
get the same amount of data on a recent desktop computer.
I focused on 12 subsystems including dierent GLIC mutants in dierent conformations with dierent
GAs bound to it. Since 25 simulations of 8 ns each have been run for each system, I calculated the equivalent
of 9600 ns, which would have been done in a total of 960 days if they had been run one aer the other on
a super computer, and more than 120 years on a recent desktop computer, pointing out the essential need
for supercomputers in theoretical biophysics. e total amount of CPU-time2
spent on this aspect of the
project is estimated to 4,377,528 jade equivalent CPU-hours3
.
3.1.2 Optimizing the available resources
e number of CPU-hours available for a project is nite, obviously. To best spend the limited amount
of available computing time, it is necessary to run several benchmarks to avoid loosing time by running
a suboptimized simulation. e procedure to nd the set of parameters that gives the best computation
speed is well dened and should be carried out every time one starts to work on new machines or a new
system since this set of parameters depends both on the topology of the system and the architecture of the
machines.
e very rst step to optimize a simulation is to reduce to the minimum the number of particles that
compose a system. e size of the simulation box (see section 2.2.3) has therefore to be well chosen not
being too large, which will increase the number of lipids (in the case of a membrane protein) and solvent
molecules, but also not being too small to avoid contacts between protein periodic images or articial
structuring of the membrane.
e second step is to run several very short simulations (on the order of 100 ps) varying the number of
cores used that will allow to estimate the speed a simulation is computed at (i.e. number of nanoseconds
calculated per day), and the computing time consumed. e optimal number of processors and cores
(recent processors have up to 16 cores, and, sometimes, leaving one core available yields better results) can
then be dened according to the project needs. A number of processors which is a power of two usually
yields better performance. However, NAMD developers advise for a maximum speed to use a number of
cores proportional to the system’s size. For instance, it can be deduced from gure 3.1 that the maximum
speed (number of nanoseconds computed per day) is reached at 544 CPUs. It is then a waste of resources,
again for this particular system on this particular machine, to run a simulation using 1024 CPUs, as no
speed-up is achieved. e second element that will inuence the choice of the number of cores to use
is the number of nanoseconds that can be computed with a certain amount of CPU-hours, 300,000 for
instance. is amount is inversely proportional to the number of cores used. It is clear on gure 3.1, that, at
maximum speed (i.e. 512 CPUs), only 500 ns can be computed while more than 700 ns can be computed
with 128 CPUs. On the other hand, the 500 ns would be obtained in X days only with 512 CPUs, whereas
Y days are required with the more economical 128 CPUs for 700 ns.
Last but not least, the program options should be in their turn optimized. In NAMD, for instance,
1
jade is a supercomputer located at Centre Informatique National de l’Enseignement Supérieur (CINES, Montpellier).
2
See denition on page 27.
3e simulations were dispatched on jade@cines.fr, turing@idris.fr, babel@idris.fr, ada@idris.fr,
vargas@idris.fr and curie@tgcc.fr. is value is the number of CPU-hours that would have been consumed if all the
simulations had been carried out on jade@cines.fr.3.1. Computing the simulations 51
Total number of cores
Figure 3.1 – Benchmarking the speed of a simulation on a machine. e total number of cores is the
product of the number of CPUs and the number of cores on each CPU. Benchmark realized with NAMD
in 2011 on jade@cines.fr.
dividing patches4
in halves oen leads to better results. e PME calculation (electrostatic interactions)
can be optimized by dening the dimension of the grid for PME decomposition and dening the number
of processors on which PME should be computed and reserve them for PME only. Several other options
can be adjusted and will not be developed here.
Table 3.1 compares some French supercomputer performances. Although it may seem illogical, the
fastest machine is not necessarily the one to use for all purposes. For instance, curie@tgcc.fr’s cores are
slightly less ecient to run an MD than ada@idris.fr’s but, on the other hand, curie’s overall speed is
higher than ada’s since it has more cores: 80,640 cores vs 10,624 on ada. is reduces the waiting time
between jobs and may allow to run more jobs in parallel, depending on a given supercomputer’s policy.
Furthermore, more cores could be used on curie than on ada speeding-up the simulation (but increasing
the cost of a simulation in CPU-hours/ns). As as second example, turing@idris.fr is one order of
magnitude slower than every other supercomputer listed in table 3.1. However, this machine turned out to
be suitable to run short MD simulations (8 ns). e specic rules of the computer centers have to be taken
into account. At IDRIS, the number of jobs a user can run at the same time is limited to 3, and the number
of jobs the same user can have in queue is also restricted. is rule can strongly slow down a project’s
proceedings when numerous jobs have to be run. To compute 20 dierent free energies of binding of
bromoform to GLIC (see section 2.6.3), I had to run a total of 640 jobs. For the reason stated above, most
of these jobs (in the limit of the available CPU time) were run on curie to benet of the unrestricted
number of jobs a single user can run at the same time on this machine. e remaining jobs were run with
a special priority on the ada machine, thanks to the assistance of the IDRIS support team.
3.1.3 Data storage
e storage of these data has to be considered as a major concern, since more than 6 TB have been produced
carrying out this part of the project. Besides, safety demands storing at least two copies of the data in
4e patch is used by NAMD as the fundamental unit of spatial decomposition.52 Chapter 3. High-Performance Computing And Large Scale Data Analysis
Machine Number of cores Speed (ns/day) ns/100,000 CPU hours days/µs
turing@idris.fr 256 3.54 58 283
ada@idris.fr 256 57.66 938 17
curie@tgcc.fr 256 53.03 863 19
jade@cines.fr 256 43.61 710 23
hades@lbt.ibpc.fr 180 35.88 865 28
Table 3.1 – Comparing common supercomputers. Benchmark realized with GROMACS 4.6.3 on a system
made of 146,182 particles.
dierent places, allowing to recover data if one copy is damaged or deleted.
e original data have been stored on gaya@idris.fr, that oers a capacity of 6.6 PB of taped storage.
Copies had to be stored locally. However, the lab’s current storage setup imposes limits on the recurrent
backup of such large quantities of data. e solution I found is to switch from the original NAMD dcd
format to the GROMACS xtc format, which has been optimized for oating point numbers compression.
Hence, an xtc le is more than 3 times smaller than a dcd le and displays a negligible precision dri. It
therefore turns out a very good choice for original data backup and everyday analyses. Finally, xtc les
generated for this part of the project constitute a total of 1.9 TB of data.
From a more general point of view, I think that GROMACS’s xtc format should always be used to store
system trajectories for numerous reasons. e rst reason is the impressive gain of space detailed above.
e second reason is that GROMACS can perform a variety of operations on xtc les such as ltering,
tting, translating, etc. e third reason is that dealing with smaller les will signicantly impact the time
a program will require to run an analysis, even its capacity to run an analysis. As an example, the VMD
soware loads into memory the whole trajectory at start. Obviously, the larger the le, the longer the
loading, which can become critical if the le size exceeds 1 GB.
Finally, backup soware run time considerably depends on the number of les to save. Some MD
soware, such as OPEP (Chebaro et al., 2012), store the system trajectory as Protein Data Bank (PDB)
formatted les at a rate of one le per frame. One trajectory could therefore be stored as several thousands
(millions) of les which will take a considerable amount of time to backup. is may even be more critical
at supercomputer centers, as the number of available inodes on the le system may be limited.
Dealing with such a volume of data divided into 400 independent simulations is not trivial. Improving
the eciency and the scaling of the analysis processes turned out to be unavoidable.
3.2 Scaling and parallelization of the analysis processes
Handling several similar simulations at the same time can reveal itself time consuming and many mistakes
can slip into the process if some slight changes have to be made from one simulation to the other. Since
most recent studies favor the calculation of one to a handful (< 5) of long simulations upon the calculation
of many short ones, no soware has been developed to perform this kind of specic task.
A good knowledge of Unix tools combined with programming skills allowed me to handle 4003.3. Ecient Analysis Soware Need: e Epock Soware 53
Molecule type Number of molecules Number of atoms
Protein 1555 residues (5 chains of 311 residues) 25,385
Lipids 301 41,138
Water 43,882 131,646
Ions 143 143
Total – 198,312
Table 3.2 – Composition of a minimal GLIC system. minimal is to be understood as that contains the
minimum number of species to calculate an all-atom simulation. We estimate that the total number of atoms
can be further reduced by ≈ 25% by agressively optimizing the simulation box shape.
independent simulations very eciently considering both time concerns and risk minimization. As an
example, a script aiming to get each simulation ready to run on a supercomputer is shown in appendix C.1.
e script creates one directory per simulation with all the materials required to run the MD simulation
on a cluster. It implements the possibility of choosing on which cluster the simulations have to be ran and
adapts the submission scripts in consequence. Such kind of scripts are not major progresses in the eld
but have to be implemented when running tens (hundreds in my case) of similar simulations that may
vary by a handful parameters.
e same kind of approach had to be applied to the simulation analysis. I chose to write one specic
Makefile for each analysis which allowed me to take advantage of the multi-threaded nature of the make
program and to run up to 12 analyses at the same time, which became critical when analyses have to be
run on hundreds of simulations. Furthermore, by writing scripts as exible as possible, running a new
analysis turned out a matter of minutes, even on hundreds of simulations.
3.3 Efficient Analysis Software Need: The Epock Software
is part is adapted from Laurent et al. (submitted) and specically adresses the development of a pocket
volume analysis tool in the context of handling more and more massive amounts of MD data.
Owing to recent advances in hardware and soware, MD simulations enable the study of the evolution
of biomolecular systems of increasing size and complexity over time. Repeatedly D.E. Shaw showed the
possibility of breaking the millisecond barrier using the Anton supercomputer and the Desmond computer
program (Lindor-Larsen et al., 2011). e drawback of this progress is the generation of increasingly
large MD datasets (see section 3.1), with consequences for subsequent analysis. It is therefore crucial to
develop improved soware tools able to analyze these datasets in a reasonable time.
e volume of an internal protein pocket is of fundamental importance to ligand accessibility and
mobility inside the pocket. Along years, several programs and algorithms that aim to quantify the volume
of a protein cavity have been developed and, among them, only few are designed to eciently manage
dynamic data from MD. Limited performance oen prohibits their use on large datasets. To tackle this
issue, I developed Epock, a program that allows ecient measurement of the evolution of protein pocket
volume during MD trajectories.54 Chapter 3. High-Performance Computing And Large Scale Data Analysis
3.3.1 Program features
Epock is a command-line program that requires input in the form of a system topology and an MD
trajectory in GROMACS xtc format (Pronk et al., 2013), which can be either atomistic or coarse-grained.
An Epock conguration le species a set of parameters for each cavity to be characterized, including a
maximum encompassing region for the cavity (MER). e MER provides explicitly dened bounds for
each cavity by combining simple 3D objects (spheres, cylinders and cuboids) to create complex shapes (a
concept known as “solid constructive geometry”). is allows to unequivocally follow a priori determined
cavities over time, whereas Epock is not intended for cavity searches. My implementation extends the
method proposed by Durrant and coworkers in the POVME program (Durrant et al., 2011). e Epock
Tcl/Tk plugin for VMD (Humphrey et al., 1996) provides an intuitive way to choose and position shapes
to dene the MER (see gure 3.3A-B) 5
.
For each pocket, Epock calculates the space accessible to a probe, called “free space”, which is the set of
all grid points with a distance to protein exceeding the user-dened probe radius (typically, 1.4 Å). e
number of grid points that overlap each residue is stored and can be outputted as “residue contribution”.
e volume of the so-called free space is then calculated at higher precision using a ner grid.
Epock outputs pore proles by calculating the radius of the largest disc that can t the previously
detected free space along the Z axis. e results are similar to those obtained with the Hole soware (Smart
et al. 1993. see gure 3.2) 6
.
Epock produces several output les, including the computed trajectory of free space over time, a feature
inspired by the trj_cavity soware (Paramo et al., 2014). is trajectory is directly readable in VMD,
which makes the relationship between pocket volume and protein conformation highly intuitive. Epock
results for pocket volume, residue contribution and pore prole can be plotted directly in VMD using the
plugin, or by running the Python scripts that are freely distributed with Epock.
3.3.2 Application: the GLIC ion channel
e Gloeobacter violaceus Ion Channel (GLIC) previously introduced in this PhD manuscript features
numerous pockets, including a binding site for general anesthetics (Nury et al., 2011). It is a challenging
test case because of its size, 1555 residues, and the presence of multiple pockets that oen connect to each
other and/or to the central pore. e volume of a single pocket was computed over an 800-frame trajectory
of the protein (25385 atoms, 75 MB) on Mac OS 10.6.8 with 2 × 2.93 GHz Quad-Core Intel Xeon processors
and 8 GB 1066 MHz DDR3 memory.
Examples of Epock output are shown in gure 3.3. e chosen analysis example shows that the cavity
volume dramatically decreases aerc.a. 1500 ps, (see red curve in gure 3.3C). Epock’s residue contribution
analysis shows a particularly high variability for residue Y197 (see cyan curve in gure 3.3C, and gure 3.3D).
Simultaneous visualization of the protein trajectory alongside the pocket free space in VMD (gure 3.3E-F)
conrms that movement of the Y197 side chain is largely responsible for the volume decrease.
5e VMD plugin has been developed by Matthieu Chavent and Caroline Dahl from the Structural Bioinformatics and
Computational Biochemistry Unit, Department of Biochemistry, University of Oxford, UK
6e pore prole feature has been developped by Tristan Cragnolini, Laboratoire de Biochimie éorique, CNRS UPR 9080,
Univ. Paris Diderot, France3.3. Ecient Analysis Soware Need: e Epock Soware 55
60 50 40 30 20 1
0
2
4
6
8
10
12
14
Z
pore radius (Å)
A
B
Figure 3.2 – Calculation of a pore prole with Epock. A) GLIC transmembrane domain (protein backbone
is represented as white cartoon, Epock’s pore surface as red wireframe). e pore prole has been
calculated given a 14 Å-radius cylinder as include region and a superimposed 7 Å-radius cylinder as
contiguous seed (see Epock’s manual for more information). e surface has been calculated from Epock’s
output using the VMD Volmap tool. B) Comparison of the average prole of the GLIC pore of a 800-frame
trajectory. Epock (red) and Hole (blue) results are very similar.56 Chapter 3. High-Performance Computing And Large Scale Data Analysis
A
B
C E
D F Volume (Å
3)
0 1000 2000 3000 4000 5000 6000 7000 8000 200
300
400
500
600
700
0
200
400
600
800
1000
1200
1400
1600
Time (ps)
Y197 contribution
Contribution Standard deviation
TYR197
ILE201
TYR119
MET205
TYR254
THR255
VAL242
ILE202
ILE258
PHE121
PRO120
LEU206
ILE259
PHE238
ASN239
LEU241
LEU246
ILE262
ILE198
THR253
ASN245
HSP235
GLU243
GLY256
TYR194
ASN307
ALA257
ASN200
GLU243
PHE303
MET261
0
50
100
150
200
250
300
350
1500 ps
3500 ps
Figure 3.3 – From Epock setup to result analysis. A) Graphical interface for dening the MER using
the VMD Epock plugin. e MER consists of a combination of volumes to include (spheres in red) and
exclude (spheres in purple), giving rise to a custom complex geometric shape for analysis. B) Grid points
that compose the MER. C) Pocket volume (red) and residue contribution of Y197 (cyan) during an MD
simulation. D) Standard deviation of residue contribution ordered from highest to lowest. E-F) Protein
conformation and pocket (protein surface in grey mesh, backbone as white tube, Y197 as spheres colored
by atom type, pocket accessible space as red spheres) at t = 1500 ps (E) and t = 3500 ps (F).
We compared Epock execution speed to two existing programs: i) mdpocket (Schmidtke et al., 2011) that
uses Voronoi diagrams and has been specically designed to calculate pocket volume for MD simulations
and ii) POVME (Durrant et al., 2011) which implements an algorithm similar to Epock for free space
detection but with dierences in the free space volume calculation. e same input grid can be given for
all three programs, allowing for meaningful performance comparisons. Epock ran in 5 seconds. is is
a dramatically higher speed than both mdpocket and POVME, which feature computing times on the
hour timescale (5 and 3 hours, respectively). We hypothesize that POVME’s execution time is largely
related to its implementation in Python which is known for being slower than the corresponding C++
executable. e reason why Epock is faster than mdpocket may be due to the numerous additional analyses
that mdpocket performs during a run, and that can not be disabled.
3.3.3 Making Epock public
e source code distribution
A distributed soware requires protection against abusive use such as copy and distribution for commercial
use. I strongly believe in open-source projects, especially for science, as well as Epock co-developers. We
decided to make Epock’s source code accessible to anyone so that developers could enhance the program
over years or build a new program inspired by it. As it is crucial for us to assure the accessibility of the
source code of any program inspired by Epock, Epock source code is distributed under the CeCILL license,
a modied version (and still compatible with it) of the GNU General Public License (GPL).
To encourage developers to contribute to Epock, its source code is versioned with mercurial, a distributed
source control management system. is technology allows a developer to access all past code3.4. BioSpring: an Augmented Spring Network Simulation Engine 57
modications and keep track of new code modications while developing a new feature. If a developer
wants to contribute to Epock, his changes can be pulled into Epock’s mother repository so that the whole
history of the new feature development is then accessible from it.
Epock’ source code is hosted by bitbucket.org and is available at
http://bitbucket.org/epock/epock.
e soware distribution
Nowadays, besides the publication of an article or application note in a scientic journal, it is crucial for
a soware to be visible on the Internet, so that, in the case of Epock for example, anyone looking for a
program for pocket volume measurement in molecular dynamics can reach Epock. Part of the time I spent
on the Epock project was therefore naturally devoted to the creation of a website explaining the method
underlying Epock, its usage and a series of application examples.
As writing HTML code can be time consuming, I have been looking for a solution allowing me to
write text les with a simplied markup language and translate them to HTML. e best solution I found
is the Sphinx tool that was originally created for the new Python documentation, and, from a general
point of view, is particularly adapted to the code documentation. In the case of Epock, I did not want to
document the code itself but only to build a showcase allowing to download the package, access the online
manual and read more about Epock.
Sphinx inputs are, besides a conguration script, text les in reST format, a markup language that
allows high eciency during the writing process since reST les are much simpler to write than HTML
code. It can be guessed from gure 3.4 (that shows the reST input le and the corresponding webpage)
that reST is a very powerful language that can produce very rich content: this thesis manuscript could
perfectly have been written in reST and rendered into a PDF document thanks to Sphinx! A few more
hours were also required to customize the page layout and, more importantly, write the CSS les for a
stylized and original website.
Epock’s website is hosted by bitbucket.org and is available at
http://epock.bitbucket.org.
e methodological aspect of this project has now been covered. In the next two chapters, I will
focus on the results I obtained on the study of general anesthetic action at the atomic scale. e accurate
characterization of binding pocket volumes did play an important role in these investigations.
3.4 BioSpring: an Augmented Spring Network Simulation Engine
As has already been discussed, MD simulations of GLIC require consequent computational power and a
simulation may run for weeks, if not months. Here I will describe BioSpring, a computational tool for
much faster - but also more approximate - simulations of macromolecular systems. BioSpring is not an
alternative to MD simulations, but a useful complementary tool to characterize a molecular system.58 Chapter 3. High-Performance Computing And Large Scale Data Analysis
Figure 3.4 – Writing Epock’s website. e reST source code (le) that, aer processing by Sphinx, will
produce the HTML that can be rendered in any web browser (right).
3.4.1 Principle
BioSpring is a calculation engine allowing to run molecular simulations of spring network models. Spring
networks are a simplied representation in which the system structure is maintained by interactions
mimicking springs: harmonic potentials are created between neighbor particles so that the more the
distance di j between two particles i and j is distant from their equilibrium distance d
0
i j, the greater is the
associated energy. e equilibrium distance d
0
i j is dened as the distance between particles i and j at t0.
By denition, this force tends to drive the system back to its equilibrium state: the initial conguration of
the system.
Biospring has two major originalities. First, it takes into account non-bonded interactions between
particles which can allow the system to reach metastable states dierent from its initial conguration.
Second, Biospring implements an interface to Interactive Molecular Dynamics (IMD), a technique in
which a user can input forces to the system manually as the simulation is going on thanks to a dedicated
input device. is input device can be a simple mouse or a haptic device that allows to send back forces to
the user. IMD therefore allows to very intuitively dock a ligand on a receptor or fold a protein. Another
application has been demonstrated recently by Molza et al. (2014) in a study where the authors use a map
extracted from Small-Angle X-ray Scattering (SAXS) experiments to run a targeted folding thanks to
BioSpring.
3.4.2 My contribution
BioSpring development was initiated by Nicolas Férey in 2008. He implemented BioSpring’s core plus
several associated tools.
My initial thesis project included several BioSpring-IMD experiments on GLIC including docking of
anesthetics and studies of the channel gating. e current BioSpring force-elds turned out unsuitable to
reproduce hydrophobic interactions with sucient accuracy, so anesthetic docking tries were unfruitful3.4. BioSpring: an Augmented Spring Network Simulation Engine 59
as were tests on GLIC’s gating. In the latter case because the spring network revealed itself too rigid to
properly reproduce the motions of the M2 helices. To make these tests, I nevertheless regularly improved
BioSpring in dierent ways I will develop in this part.
Input/Output
BioSpring input les are
• the simulation conguration le (containing time step, number of steps...),
• the system topology.
e system topology le contains the parameters for all the particles of a system including coordinates,
radius, charge,etc. Reading and writing tabulated les can raise problems, especially forformat specication.
BioSpring lead developers chose to use the NetCDF format for topology les in which data are stored
as arrays (gure 3.5). I improved NetCDF reader and writer classes already existing in BioSpring by
performing numerous sanity checks to make sure the le format behaves as expected, a crucial step
to avoid unauthorized memory access, which can turn out very dicult to debug. I also implemented
methods to automatically write NetCDF binary les and implemented BioSpring support for the newest
versions of the NetCDF library.
Associated tools
Initially, BioSpring conversion tools from PDB format to NetCDF format oered limited exibility. In the
context of scientic experiments using BioSpring, it is very common that the spring stiness between two
particles or two groups of particles has to be adjusted, some springs have to be removed, others have to be
added, etc. Despite the diculty of the task, these operations had to be done manually, which was time
consuming and a potential source of errors. As an example, to add a single spring between two particles,
the user had to
1. nd the id number of the two particles (this part was usually done using VMD, making sure the
serial parameter of VMD corresponds to the actual particle id in BioSpring),
2. add 1 to the dimension spring_number,
3. add the two particle ids to the springs array
4. add the appropriate stiness for this spring to the springsstiffness array,
5. add the appropriate spring equilibrium distance to the springsequilibrium array (note that the
spring stiness and equilibrium parameters have to be inserted at the exact same position as the
spring is inserted in the springs array).
I developed three tools named pdb2spn, editspn and mergespn to deal with most use cases and
signicantly reduce both the time spent on the topology tuning and the probability of making mistakes
during the process.60 Chapter 3. High-Performance Computing And Large Scale Data Analysis
netcdf model {
dimensions:
spatialdim = 3 ;
particle_number = 2 ;
particlename_length = 4 ;
chainname_length = 4 ;
resname_length = 4 ;
springdim = 2 ;
spring_number = 1 ;
variables:
float coordinates(particle_number, spatialdim) ;
coordinates:units = "angstrom" ;
coordinates:long_name = "Particle coordinates" ;
float charges(particle_number) ;
charges:long_name = "Particle charge id" ;
charges:units = "electron" ;
float radii(particle_number) ;
radii:units = "A" ;
radii:long_name = "Particle radius" ;
float epsilon(particle_number) ;
epsilon:units = "kJ.mol 1" ;
epsilon:long_name = "Particle epsilon for Lennard Jones" ;
float mass(particle_number) ;
mass:units = "Da" ;
mass:long_name = "Particle mass" ;
...
int springs(spring_number, springdim) ;
springs:long_name = "Spring between particle referenced by 2 particle id
s" ;
float springsstiffness(spring_number) ;
springsstiffness:long_name = "Spring stiffness" ;
float springsequilibrium(spring_number) ;
springsequilibrium:long_name = "Spring distance equilibrium" ;
data:
coordinates = 0, 0, 0,
2, 0, 0 ;
particleids = 0, 1 ;
particlenames = "N", "N" ;
charges = 0.4157, 0.4157 ;
radii = 1.824, 1.824 ;
epsilon = 0.17, 0.17 ;
mass = 14.01, 14.01 ;
surfaceaccessibility = 0, 0 ;
hydrophobicityscale = 0.112, 0.112 ;
resnames = "VAL", "VAL" ;
resids = 1, 2 ;
chainnames = "A", "A" ;
dynamicstate = 0, 1 ;
springs = 0, 1 ;
springsstiffness = 1 ;
springsequilibrium = 2 ;
}
Figure 3.5 – e NetCDF array-oriented format. Example of a NetCDF text le for a system containing
two particles. BioSpring input is the binary version of this le that can be created thanks to the ncgen
program distributed along with the NetCDF library.3.4. BioSpring: an Augmented Spring Network Simulation Engine 61
pdb2spn is a utility that converts a PDB formatted le to a binary NetCDF formatted le. Prior to the
development of this tool, text les were generated. ey had to be converted to a binary in a second time,
thanks to a tool distributed with the NetCDF library. e creation of a binary le is the only new feature of
pdb2spn but it is incorporated within a framework in which BioSpring topology les should not be edited
by hand.
editspn allows to edit BioSpring binary topology les. It implements features such as spring creation
from a cuto, add or remove springs thanks to a selection language, modify particle positions...
mergespn aims to merge two BioSpring binary topology les. is is particularly useful for creating a
system in which several parts have dierent exibility levels. Two spring network models can be created
for two distinct molecules of a system, with dierent spring cutos and/or spring stiness thanks to two
calls to pdb2spn. ey are gathered together in a second time thanks to mergespn which can additionally
create springs between the two structures.
e compilation process
BioSpring soware is made of 98 source les representing a total exceeding 20,000 lines of C++ code.
It has several dependencies such as the NetCDF library and a few more libraries. e build process can
therefore not be managed by hand.
For decades, developers used the GNU build system known as Autotools, a suite of programs designed
to generate a configure script for the project. is script, to be executed by the user prior to compilation,
generates the Makefile that will produce the soware targets (programs, libraries, etc.) by invoking
the command make (gure 3.6). is system has proven both its robustness and diculty of use since
Autotools input les have a very particular syntax that makes writing them tough and improvement even
tougher since the whole le has to be read again and understood before being modied. e CMake
soware was developed in this context in the early 2000s, with a main objective to simplify the writing
of conguration les. e developer has to write basically a single input le and CMake generates the
appropriate Makefile. Notably, CMake conguration variables are very easy to modify, so the build
settings can be tuned very quickly. CMake is now used by thousands of developers to compile hundreds
of projects including very large projects such as KDE, a Unix desktop environment, MySQL, a database
management system and BioSpring!
BioSpring lead developers chose CMake as build process management system, facing the fact that the
less time is spent on the compilation, the more is spent on the actual code development. My contribution
to the build process has been to improve the CMake input le by adding several options to customize the
build process and make the input le clearer from a general point a view. A very interesting CMake feature
is the package search: CMake can search for libraries, programs or any kind of dependency a project has. I
wrote several CMake search scripts that were not already included in the CMake package, such as for the
NetCDF and the MDDriver libraries for example.62 Chapter 3. High-Performance Computing And Large Scale Data Analysis
configure.ac
aclocal
autoconf
autoheader
automake
autoscan
aclocal.m4 Makefile.am
configure
config.h.in
Makefile.in
config.status
config.h
make
Makefile input file
executable
process
influences
output file
creates
Figure 3.6 – GNU autoconf and automake process for generating makeles. From
http://www.wikipedia.org4
Probing pLGICs with bromoform
reveals many interconnected
anesthetic binding sites
is chapter is devoted to the characterization of general anesthetic bromoform binding sites described in
Sauguet et al. (2013a). I characterize the three sites and an additional pore site described in a new crystal
structure of GLIC in locally closed conformation. I combine several computational approaches to address
three key questions: (i) are the crystal binding sites spontaneously accessible? (ii) can bromoform travel
from one site to another? (iii) what is the bromoform anity for each binding site? Molecular dynamics
simulations of ooding the receptor with bromoform recover most of the experimentally observed sites,
with a modulated occupancy between the open and the locally closed conformations. Sixty short MD
simulations were carried out to extensively explore the binding pockets, providing data on possible routes
connecting them. ese simulations furthermore highlight residues such as Y197 that may play key roles in
controlling the interaction between anesthetic and receptor molecules. FEB calculations indicate signicant
anity for all crystallographic binding sites in open and locally-closed conformations, in some cases
modulated by pH. ey support the critical role of Y197 into anesthetic binding.
e chapter is largely inspired by a scientic article currently in preparation. I am the rst author
of this article. Furthermore this work features contributions from Ludovic Sauguet and Marc Delarue
(Institut Pasteur) who covered the X-ray crystallography part of this project, my colleague Samuel Murail
who carried out the setup of microsecond timescale MD simulations as well as the main part of their
analysis, and Marc Baaden who supervised the project. I was in charge of writing the article, managing the
dierent contributions, running and analyzing all short MD simulations, running and analyzing all FEB
calculations as well as partly analyzing long MD simulations.
4.1 Results
4.1.1 Bromoform-bound crystal structure of the GLIC channel in its locally-closed conformation
In order to study the properties of bromoform-binding to the GLIC receptor in its locally-closed conformation,
we grew crystals of the GLIC K33C L246C variant in the presence of bromoform. GLIC K33C
L246C variant is a particularly adapted model for this study as it is known to crystallize in a locally-closed64 Chapter 4. Probing pLGICs with bromoform reveals many interconnected anesthetic binding sites
E-2'
T2'
S6'
I9'
A13'
I16' intra-subunit
sites
pore site
Y197
N245 T244 T244
N245
Y197
Figure 4.1 – A bromoform-bound structure of GLIC in its locally closed conformation. A) Top view
of GLIC TMD. Bromoform densities, shown in ochre wireframe, are present in the intrasubunit site of
four over ve subunit, and in the new pore site. B) Location of bromoform (sticks) in the pore site. Two
M2 helix backbones of the LC and open conformations are represented in pink and white, respectively.
Water molecules detected in GLIC high resolution structure are represented as red spheres. C-D) Side
and top view of one intrasubunit site in open (pink) and locally closed (white) conformations. Residues
possibly responsible for decrease of site W3 accessibility are showed as sticks.
conformation but shares indistinguishable electrophysiological properties with WT GLIC (Prevost et al.,
2012). Bromoform is an analogue of chloroform containing three bromine atoms that produce a specic
anomalous signal that can be observed by crystallography using X-rays with tunable wavelengths. e
bromoform-bound structure was determined at a 2.95 Å resolution (gure 4.1).
It was completely superimposable with the apo-form of GLIC K33C L246C with a root mean square
deviation of 0.77 Å over the 1555 Cα atoms. In the pore, a bromoform-binding site is indicated by a Fo-Fc
electron density peak (7.0 σ) that overlaps with a bromine-specic anomalous peak (10.0 σ). Bromoform
binds in the middle part of the pore between the I240 (I9’) and S236 (S6’) rings of residues (gure 4.1B),
two critical rings of residues that are repectively involved in gating and ion permeation (Sauguet et al.,
2013b). is bromoform-binding site in GLIC is novel and is specically occupied when the channel pore
is closed. In contrast, when the channel pore is open, this location is lled of ordered water molecules
that were found to be critical for ion permeation. Interestingly, bromoform was found to occupy a similar
location in ELIC ’s closed pore (Spurny et al., 2013). A previous study revealed that bromoform occupies
alternatively three poses in the intrasubunit cavity of the GLIC open-channel structure (named W1 to
W3). In contrast, this intrasubunit cavity is remodelled in the GLIC locally-closed structure thus aecting
the previously described bromoform binding sites (gure 4.1C-D). Indeed, despite the presence of an
intrasubunit bromine anomalous signal in four out of ve subunits, the absence of interpretable Fo-Fc
dierence electron density supports the possibility that bromoform may also bind at positions W1 and W2,
but with too low occupancy or too high mobility to allow for condent model building. is is caused
by the side chain of residue Y197 that alternates between two conformations. e second one induces a
steric clash that prevents binding of bromoform at W1 and W2 sites (gure 4.2). In addition, the revolving
motion of the M2-M3 loop partly occludes the intrasubunit cavity and prevents bromoform-binding at
position W3. In summary, bromoform binding-sites are dierent in the locally-closed versus the open
GLIC structures: while a novel site is observed in the pore, binding to the intrasubunit cavity is discouraged
in the locally-closed form.4.1. Results 65
A B C
Figure 4.2 – Two distinct conformations of residue Y197. A) In open conformation (top), Y197 side chain
(space lling representation colored by atom type) does not overlap any of the 3 intrasubunit bromoform
binding sites (pink, purple and magenta spheres), while in down conformation (bottom) it partially overlaps
site W2 and W3. B-C) Inuence of Y197 side chain orientation on the intrasubunit pocket accessible
volume (represented with red spheres and calculated with the Epock soware, see section 3.3). e protein
surface is represented as a white wireframe, its backbone as a grey tube.
4.1.2 Molecular Dynamics simulations to explore and quantify anesthetics binding
I combine three complementary simulation strategies to explore bromoform binding to GLIC. Firstly, I
used data from several one microsecond long MD simulations of membrane inserted GLIC in an oversaturated
bromoform solution to assess the spontaneous exploration of the system by the anesthetic and
identify preferential bromoform binding sites. We subsequently refer to this type of simulations as ooding
experiments. ree forms of GLIC were used, WT GLIC in open and LC conformation and the GLIC
mutant F238A in the open conformation. Secondly, we ran 25 unconstrained 8-ns long MD simulations of
GLIC F238A in open conformation starting from anesthetic locations in sites W1-2 and site B1. Considering
that, at this timescale, the ve subunits are independent, we accumulated a total of 25 × 5 × 8 ns sampling
per system. is one microsecond dataset for each location yielded an extensive exploration of both the
intra- and the intersubunit binding pockets and allowed us to observe transitions between sites. Ten 8-ns
simulations were run for GLIC WT in the LC form starting with bromoform in the pore site P1. irdly,
we determined the bromoform anity for each of the 6 binding sites in WT and F238A mutant for both
open and LC variants of GLIC using alchemical free energy calculations. Sampling times are given in
table 4.1, full technical details of all the simulation approaches are provided in section 2.6.
4.1.3 Crystallographic sites are spontaneously reachable
Flooding experiments reveal that all binding sites (i.e. W1, W2 W3, B1, B2, and P1), are spontaneously
reachable in at least one of the three simulations. By design, the ion channel in the short MD simulations
remains very close to the crystal structure, which makes for straightforward comparison with experiment.
e observed occupancies for sites W1 and W2 are equivalent as was observed in the crystal (respectively
0.41 and 0.38, table 4.2). In contrast, the equilibrium is shied in favor of the membrane exposed W1
site in ooding simulations. In both short and long MD simulations, the occupancy of the W1-2 sites is66 Chapter 4. Probing pLGICs with bromoform reveals many interconnected anesthetic binding sites
Sequence Form Bromoform pore Sampling time
Long MD simulations
F238A Open Flooding 1 µs
WT LC Flooding 1 µs
WT Open Flooding 1 µs
Short MD simulations
F238A Open Site W1-2 25 × 8 = 200 ns
F238A Open Site B1 25 × 8 = 200 ns
WT LC Site P1 10 × 8 = 80 ns
FEB calculations
F238A Open
W1-2, W3, B1, B2, P1 32 windows sampled for
3 to 10 ns each
F238A LC
WT Open
WT LC
Table 4.1 – Sampling time and studied systems for bromoform characterization.
markedly higher than that of site W3, which is consistent with crystallographic data. During ooding
simulation of WT GLIC in LC conformation, site W3 occupancy was lower by one order-of-magnitude
compared to the simulation starting from the open form and displayed a particularly low residence time
(3.4 ns in average), consistently with crystallographic data. As the intersubunit cavity B1 does not exist
in WT GLIC because of the presence of the bulky F238 residue sidechain, this site has only been reached
in the simulation of the F238A mutant. Spontaneously, the pore site P1 has been reached in the ooding
simulation of WT open GLIC only.
Site W1 Site W2 Site W3 Site B1 Site B2 Site P1
F238A – O Site W1 0.41 0.38 0.03 0.01 0.00 0.01
F238A – O Site B1 0.00 0.00 0.00 0.94 0.00 0.00
WT – LC Site P1 0.00 0.00 0.00 0.00 0.00 1.00
WT – O Flooding 0.56 0.43 0.35 0.00 0.12 0.49
WT – LC Flooding 0.45 0.24 0.03 0.00 0.00 0.00
F238A – O Flooding 0.46 0.23 0.25 0.02 0.19 0.00
Table 4.2 – Bromoform binding site occupancy along MD simulations. e 3 rst rows correspond to
short MD simulations with bromoform being placed in site W1, B1 or P1, respectively. e 3 last rows refer
to ooding simulations4.1. Results 67
M1
M3
M4
Loop β6-β7
M2
Loop M2-M3
Figure 4.3 – Key residues of the intrasubunit pocket. Percentage frames in which a bromoform molecule
contacts a residue of the intrasubunit pocket along short MD simulations.
4.1.4 All sites are interconnected, with gates between them
Considering the close vicinity of the experimentally observed sites W1,2,3 and B1, we characterized the
dynamics of bromoform bound to each site. e simulations furthermore generate data to examine possible
paths between these sites.
Site W1-2 may act as an entrance to other sites
In the ooding simulations, site W1 was the most occupied site mainly because it is exposed to the
membrane. During the second half of the production run around 95 % of bromoform molecules were
located in the membrane, as a consequence the W1 sites were the easiest to access and the rst to be bound.
In short simulations bromoform did not oen penetrate much deeper into the intrasubunit pocket as
depicted by both the low site W3 occupancy and the relatively low number of contacts with M2 residues
(gure 4.3). Concerning site W3, its occupation in the ooding runs was signicantly higher compared to
the short simulations but only in the open form of GLIC. In the simulation of LC GLIC, the occupation
of sites W1 and W2 were close to GLIC in open form, however site W3 was weakly occupied. In the LC
form, the conformation of the M2-M3 loop and of the top part of the M2 helix prevent occupation of site
W3, in particular residue T245 is in close contact with this site, preventing any binding (gure 4.4). A key
observation is that, once site W3 has been reached, bromoform was able to enter the upper intersubunit
B2 pocket, as previously mentioned. e same behavior was observed in ooding simulations of open
GLIC (WT and F238A), which is reected by the high occupancy of site B2.
Y197: a gate to the inner channel
Interestingly, Y197 which is not in the immediate environment of bromoform in the crystal structure,
appears to dramatically modulate the volume of the intrasubunit pocket (gure 4.2), as proposed by
Mowrey et al. (2013b). erefore Y197 might control access to sites W3 and B2. In the crystal structure,
the Y197 side chain is oriented toward the extracellular domain, the dihedral angle θ between Y197 CCα-Cβ
-Cγ atoms being equal to (167.6 ± 0.5)°. Notably, in available crystal structures of open GLIC, all68 Chapter 4. Probing pLGICs with bromoform reveals many interconnected anesthetic binding sites
WT LC WT OPEN F14'A OPEN
Figure 4.4 – Bromoform exploration in ooding simulations. Top (top pannel) and side (bottom pannel)
views of a GLIC subunit in which bromoform occupancies are represented as yellow surfaces. Residues
Y197 and T244 are represented with sticks colored by atom type.
Y197 residues display this up conformation (θ = 165.6 ± 3.8°), while closed structures of subtypes I and
III respectively display four and two Y197 in down conformation, in which the Y197 side chain lies inside
the intrasubunit pocket (θ =60.4 ± 8.5°). During the MD simulations, θ oscillated around these values
with average orientations at 169.9° and 72.9° (gure 4.5). Notably, in down conformation, the Y197 side
chain plunges into the intrasubunit pocket and occupies a large volume there, overlapping sites W2 and
3, hindering bromoform entering the deeper intrasubunit pocket (gure 4.2), and therefore ultimately
prevents it from entering the intersubunit pocket. It is to be noted that the transition of the Y197 rotamer
is a rare event with an average of 10 ± 6 transitions per microsecond calculated on the ooding simulations
dataset.
Bromoform is conned within the intersubunit site
In the intersubunit cavity, bromoform mostly stays within 6.5 Å of the crystal structure location. roughout
the one-microsecond dataset provided by short MDs, a single transition from site B1 to site B2 was
observed. Two residues, L241i and E243i-1, restrain the available space in this region and therefore hinder
crossing from site B1 to B2 (either way). During the F238A ooding simulation, the same inverse transition
(B2 to B1) was observed once (gure 4.6). In that case, the molecule has been traveling from the membrane
to the W1-2 site to W3, to B2, to nally reach site B1. Another intersubunit site was occupied by one
molecule for more than 800 ns. is site is located 5 Å above B1 and slightly closer to the membrane. e
bromoform molecule reaches that site from site W2 and stays there for the rest of the simulation.4.1. Results 69
Figure 4.5 – Y197 side chain orientation along ooding simulations. Distribution of the Y197 side chain
orientation along ooding MD simulations for each system namely wild-type (WT) open (O) and locally
closed (LC) and the F14’A mutant in open conformation (F14A-O). Densities have been calculated over
the a microsecond period with a time step of 0.5 ns, leading to a total of 10,000 points per density (2000
points per Y197 × 5 subunits).
800-810 ns
811-836 ns
836-840 ns
840-860 ns
861-1000 ns
W1-W2
W3 B2
B1
B1
B2
W3
W1-W2
membrane
membrane
Figure 4.6 – Transition of a bromoform molecule from the membrane to the B1 site. Top (le) and side
(right) views of a GLIC subunit. Bromoform center of mass is represented as spheres colored according to
the time of the simulation. In 200 ns, this bromoform molecule could pass from the membrane to site
W1-2, W3, B2 and ultimately B1.70 Chapter 4. Probing pLGICs with bromoform reveals many interconnected anesthetic binding sites
Bromoform is stable in site P1
Short simulations of the locally closed form of GLIC with bromoform bound to the pore site P1 show that
the anesthetic molecule remains close to this site, never leaving the region delimited by residues T226
(T2’) and I233 (I9’), even in the absence of additional stabilizing bromoform molecules that were present
in the ooding simulations but not in the short runs. Flooding simulations of WT open GLIC showed
anesthetic molecules switching from the ECD vestibule to the pore site P1. As a result, the occupancy of
site P1 in that simulation reaches 0.49 (table 4.2), with a total of three bromoform molecules present in
the pore. One bound at the beginning of the simulation and stayed continuously in site P1 for more than
400 ns before binding an upper pore site (between I9’ and A13’) and coming back to site P1 twice for a
few nanoseconds. e two other molecules were observed binding the upper site in the pore, the rst one
came early (aer ∼ 100 ns) from the vestibule and stayed in the upper cavity for the rest of the simulation
with the exception of one 3 ns binding event in site P1 halfway through the simulation (∼ 500 ns). e
other molecule came from the intra subunit cavity (W1-2 for 205 ns then site W3 for 365 ns) at the very
end of the simulation (∼ 950 ns). In the LC form simulation, no anesthetics were shown to bind to the
pore site. During the F238A mutant simulation, no anesthetics were shown to bind in site P1, however one
molecule was binding the upper pore site in the second half of the simulation (∼ 550 ns). e molecule
came from the intra subunit cavity (W1-2 for 67 ns) and later an intermediate position between B2 and W3
for 63 ns. To be noted, none of the bromoform molecules, which bound in the pore, le the pore.
Bromoform binding anities are favorable for all binding sites
Bromoform anity for crystallographic binding sites ranges from −7.1 to −4.8 kcal/mol (gure 4.7). e
open form appears signicantly more favorable for sites W3, B1 and B2 with ∣∆∆G∣ ranging from 1.3 to
2.8 kcal/mol, while P1 displays a higher anity in the LC form than in the open form with ∣∆∆G∣ of 1.7
and 2.4 kcal/mol respectively for the WT and the F238A channel. It should be noted that the pore site P1
of both WT and F238A channels displays a favorable FEB, comparable to site W1-2 in open form and even
more favorable than W1-2 in the channel LC form.
Bromoform free energy of binding is sensitive to H235 protonation state.
e H235 residue is located on the pore-lining M2 helix (H11’ in prime notation), close to the B1 site
entrance. e protonation state of its side chain has been shown to be particularly dicult to determine
with condence (Laurent et al., 2013). To assess whether the protonation state of H235 modulates the
ligand binding anity, we compared bromoform free energy of binding for neutral and protonated H235
(table 4.3). When neutral, we observe a dierence of −1.9 kcal/mol between the WT intrasubunit site W1
(−6.3 ± 0.1 kcal/mol) and the F238A intersubunit site B1 (−8.2 ± 0.1 kcal/mol). When H235 is protonated,
the FEB to B1 reduces to (−6.1 ± 0.1) kcal/mol. No eect was observed on the more remote site W1.4.1. Results 71
F238A-LC
-8.0
-6.0
-4.0
-2.0
0
W1-2 W3 B1 B2 P1
WT-O WT-LC F238A-O
Figure 4.7 – Free energies of binding of bromoform to the ve binding sites. Energies are given in
kcal/mol. WT = “Wild-Type”; O = “Open”; LC = “Locally-Closed”. Error estimates are all below or equal
to 0.2 kcal/mol.
H235 + H235 n
Site W1 (intra) −6.6 −6.3
Site B1 (inter) −6.1 −8.2
∆ = W1 − B1 −0.5 +1.9
Table 4.3 – Free energy of binding of bromoform as a function of H235 protonation state Energies are
given in kcal/mol; “+” stands for double charged, “n” stands for neutral.72 Chapter 4. Probing pLGICs with bromoform reveals many interconnected anesthetic binding sites
4.2 Discussion
Globally, a picture of dynamically accessible and interconnected anesthetic binding sites emerges from
this computational study, in excellent agreement with the available crystallographic data. e calculations
reveal phenomena enriching the picture obtained from the experimental data such as the transitions
between sites or the possible modulation of anesthetic binding anities by pH.
4.2.1 Multi-site allosteric modulation, a delicate balance toward potentiation or inhibition
Evidence that anesthetics bind the intrasubunit site in the W1 region is strong. Crystal structures showed
that bromoform (Sauguet et al., 2013a), propofol and desurane bind to this pocket (Nury et al., 2011;
Chiara et al., 2014). e data collected in this work are in very good agreement, clearly showing that
intrasubunit sites are spontaneously accessible from the membrane and display favorable FEB, especially
for W1. Our data suggest that sites W1 and W2 should be considered as two marginally dierent poses of
the same site. e ligand may switch from one to another with equal probabilities as is the case in short
MD simulations. On a longer timescale, this equilibrium shis in favor of site W1, probably because of a
bias induced by its direct exposure to the membrane where most bromoform molecules accumulate.
In WT GLIC, site B1 does not exist since the presence of the bulky F238 side chain does not leave
enough room for an anesthetic molecule, as it leaves barely enough space for a single water molecule.
Interestingly the F238 residue is conserved in the human nicotinic acetylcholine receptor subunits α3,4,5
and β1,2 and 5-HTR subunits 3A,B. In the glycine and the GABAA receptors this residue is substituted by
less bulky residues, respectively Q and L/I. Howard and coworkers showed that this substitution creates
an intersubunit pocket (corresponding to the B1 binding site) in which ethanol can bind, explaining the
potentiating eect on the channel. We observe in this study that the articial intersubunit pocket created
in GLIC by the mutation F238A can be reached from intrasubunit site W1. Calculated free energies of
binding reect the high anity of bromoform for B1 in both open and locally closed forms of GLIC F238A.
is observation suggests that the anesthetics’ initial binding site could be site W1 for both inhibitory and
excitatory channels. e anesthetic would then migrate to B1 in inhibitory channels, in this way stabilizing
the open form, while remaining in the intrasubunit pocket in excitatory channels stabilizing the closed
form. Such a scenario would support hypotheses proposing that the dierence of action of anesthetics
(and alcohols) on inhibitory and activating Cys-loop receptors might be found in the accessibility of the
lower intersubunit pocket (Murail et al., 2012).
Besides transitions from site W1-2 to B1, our data show a high mobility of bromoform inside the
binding regions (see gure 4.8). Notably, we observe an important exchange rate between site W1-2 and
site W3 over the microsecond period. e average occupancy of site W3 appears signicantly lower than for
site W1-2 in both short and long MD simulations, which is in very good agreement with crystallographic
data. Importantly, we observe several transitions from site W3 to site B2, an intersubunit site described in
GLIC on the basis of MD simulations (Nury et al., 2011) and in GABAA by photolabeling (Yip et al., 2013)
with respectively desurane and ortho-propofol diazirine. As we observe bromoform occupying this site
on the microsecond timescale, we argue that site B2 is denitely occupied by antagonists at a timescale4.2. Discussion 73
Figure 4.8 – Bromoform exploration of the intra- and intersubunit binding pockets in short MD
simulations. Side view from the pore. e protein TMD backbone atoms are represented as cartoon
colored by subunits. e area explored by the bromoform along short MD simulations are represented
with meshes colored according to the bromoform starting location (purple and orange for intra- and
intersubunit pockets, respectively). Two residues that seem to occlude the route between B1 and B2
intersubunit sites are represented with space lling spheres colored by atom type.
relevant for anesthesia. Still, the anesthetic has to be able to access site B2 through a route passing by sites
W1-2 and W3, a route that can be occluded by Y197.
4.2.2 A residue gating the access to anesthetic allosteric binding sites
Our data strongly suggest that the orientation of the Y197 side chain is critical for anesthetic binding and
insertion depth; therefore their transition to intersubunit cavities may be controlled in this way. e up
conformation of Y197 as described above appears highly conserved in all GLIC open structures, while
the down conformation is found in the majority of the locally closed structures. In addition, the M2
helices bending in the locally closed conformation move residues from the top of M2 and from the M2-M3
loop inside the intrasubunit pocket and in particular residue T245. erefore, site W3 is not accessible
anymore from site W1 in the locally closed channel conformation, as shown in the crystal structure of
bromoform bound to LC GLIC presented here. Free energy calculations corroborate these data showing
that site W1 is clearly more favorable to bromoform than site W3 and B2 in the LC structures, while in
GLIC ’s open form, this dierence is less clear (gure 4.7). Importantly, structural alignments reveal
that Y197 is highly conserved in Cys-loop receptors, including, nicotinic acetylcholine, 5HT3 and glycine
receptors (Sauguet et al., 2013a). Interestingly, in GABAAR, the tyrosine is substituted by a phenylalanine,
two residues with very similar side chains, especially considering their volume. We argue this residue
might play a critical role in Cys-loop receptors’ sensitivity to anesthetics. Our simulations show that Y197
orientation aects the F195 rotamer distribution. In the down conformation the Y197 residue prevents F195
from being in the same conformation, and vice versa. e F195 residue, given its direct interaction with
the M2-M3 helix, may be a key residue to modulate GLIC gating. is residue is a glycine in all GABAA
Conception et commande d’un robot de comanipulation
pour l’assistance `a la biopsie de prostate.
Cecile Poquet
To cite this version:
Cecile Poquet. Conception et commande d’un robot de comanipulation pour l’assistance `a la
biopsie de prostate.. Robotics. Universit´e Pierre et Marie Curie - Paris VI, 2014. French.
.
HAL Id: tel-01081960
https://tel.archives-ouvertes.fr/tel-01081960
Submitted on 12 Nov 2014
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of scientific
research documents, whether they are published
or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est
destin´ee au d´epˆot et `a la diffusion de documents
scientifiques de niveau recherche, publi´es ou non,
´emanant des ´etablissements d’enseignement et de
recherche fran¸cais ou ´etrangers, des laboratoires
publics ou priv´es.
L’UNIVERSITÉ
Sciences Mécanique, Acoustique et Robotique
Conception et commande d'un robot de comanipulation pour l'assistance à
Directeur de recherche
Soutenue le 11 Septembre 2014
Devant la commission d’examen formée de
M. Gérard POISSON Professeur de l' Université d'Orléans
M. Pierre RENAUD Professeur
Mme. Jocelyne TROCCAZ Directrice de recherche à l'Université Joseph Fourier
M. Jean-Luc ZARADER Professeur de l'Université Pierre et Marie Curie
M. Guillaume MOREL Professeur de l'Université Pierre et Marie Curie
Mme. Marie-Aude VITRANI Maître de Conférence à l'Université Pierre et Marie Curie
M. Pierre MOZER Maître de Conférence à l'Université Pierre et Marie Curie
M. Antoine LEROY Président de la société Koelis
THÈSE
PRÉSENTÉE A
L’UNIVERSITÉ PIERRE ET MARIE CURIE
ÉCOLE DOCTORALE SMAER
Sciences Mécanique, Acoustique et Robotique
Par Cécile POQUET
POUR OBTENIR LE GRADE DE
DOCTEUR
SPÉCIALITÉ : Robotique
Conception et commande d'un robot de comanipulation pour l'assistance à
la biopsie de prostate
Directeur de recherche : Guillaume MOREL
’examen formée de :
Professeur de l' Université d'Orléans
Professeur d'Université à l'INSA Strasbourg
Directrice de recherche à l'Université Joseph Fourier
Professeur de l'Université Pierre et Marie Curie
Professeur de l'Université Pierre et Marie Curie
Maître de Conférence à l'Université Pierre et Marie Curie
Maître de Conférence à l'Université Pierre et Marie Curie
et urologue à l'hôpital de la Pitié Salpêtrière
Président de la société Koelis
PIERRE ET MARIE CURIE
Conception et commande d'un robot de comanipulation pour l'assistance à
Rapporteur
Rapporteur
Examinatrice
Examinateur
Directeur
Maître de Conférence à l'Université Pierre et Marie Curie Encadrante
Maître de Conférence à l'Université Pierre et Marie Curie Invité
Invité i
Résumé
Le cancer de la prostate est à l’heure actuelle le cancer le plus fréquent chez l’homme
en France. Sous cette appellation unique sont regroupés des pronostics très différents :
cancers asymptomatiques évoluant suffisamment lentement pour n’avoir aucune influence
sur l’espérance et la qualité de vie, mais aussi cancers agressifs pouvant causer le décès.
Or il est aujourd’hui très difficile d’analyser le cancer, d’en prévoir l’évolution et donc de
prendre une décision thérapeutique adaptée. C’est pourquoi il est capital de faire évoluer
les outils de diagnostic du cancer de la prostate, non pas pour détecter plus de cas mais
pour être capable de mieux les qualifier.
L’examen permettant de poser le diagnostic de cancer prostatique est la réalisation
de biopsies de prostate, c’est-à-dire le prélèvement d’échantillons qui seront ensuite
analysés. Or ce geste, effectué en routine clinique sous échographie bidimensionnelle sur
un patient anesthésié localement, s’avère particulièrement complexe à réaliser et fournit
très peu d’informations quantitatives sur les carottes de glande prélevées. C’est pourquoi
la robotisation des biopsies est aujourd’hui vue comme un medium intéressant pour
améliorer la qualité du diagnostic du cancer de la prostate.
Dans cette thèse, nous abordons la problématique de l’assistance robotique à la
réalisation de biopsies prostatiques. Le geste chirurgical et son impact sur le diagnostic
sont d’abord étudiés, il en ressort qu’un tel système robotique présente un réel intérêt. Une
analyse des dispositifs existants destinés à la biopsie et à la brachythérapie de prostate
permet ensuite, en tenant compte des contraintes économiques liées à l’examen, de poser
les grandes lignes de la conception de notre robot : utilisation de l’image échographique
comme seule source d’informations extrinsèques, passage par la voie transrectale,
cinématique à 6 degrés de liberté et exploitation du paradigme de la comanipulation.
Un robot répondant à ces critères est présenté : Apollo est un bras anthropomorphique à
actionnement hybride (trois freins et trois moteurs), une solution intéressante en matière
de performances, de coût mais aussi de sécurité pour le patient. Différentes fonctions
d’assistance peuvent être réalisées avec ce système.
Un mode libre permettant à l’urologue de maîtriser les mouvements de la sonde sans
influence aucune du robot est d’abord présenté. Une analyse du geste lors de la réalisation
d’une tâche de pointage permet de prouver que le mode libre présente une transparence
satisfaisante, grâce à des mesures matérielles et logicielles. Un mode verrouillé est ensuite
développé : celui-ci assure un maintien en position de la sonde échographique à la fois
souple et précis. Les performances de ce mode de commande, validées in vitro et in
cadavero, permettent de justifier a posteriori la conception d’Apollo. Des essais cliniquesii
portant sur les modes libre et verrouillé ont été autorisés par le Comité de Protection
des Personnes ainsi que par l’Agence Nationale de Sécurité du Médicament et devraient
débuter en Juillet 2014 à la Pitié-Salpêtrière.
L’anus pouvant se déplacer au cours de l’examen et le niveau limite acceptable des
efforts n’étant pas connu, la question du respect de cette contrainte anatomique se pose.
L’utilisation d’un robot similaire à Apollo mais présentant six degrés de liberté permet
de comparer une commande dite « déplacement de torseur » et une commande dite « bras
de levier ». Il est ainsi montré que la commande « bras de levier » permet de réaliser en
utilisant un robot tel qu’Apollo toute fonction d’assistance par retour d’effort exprimée
comme une force virtuelle appliquée sur la partie distale d’un outil comanipulé, tout
en respectant la contrainte anatomique. Un exemple d’une telle fonction d’assistance à
la biopsie prostatique est ensuite présenté : il s’agit d’une augmentation de la raideur
apparente de la prostate utilisant l’image échographique en temps réel dans l’élaboration
de sa commande. Cette fonction, mise en œuvre en tout début de thèse, a été testée sur
un prototype basique mais permet néanmoins de démontrer la faisabilité d’un tel retour
d’effort basé image.
Enfin, Apollo étant déjà pourvu de deux modes de base (libre et verrouillé) ainsi
que d’une méthodologie de réalisation de commande par retour d’effort respectueuse de
la contrainte anatomique exploitant le paradigme de la comanipulation, il est proposé
d’utiliser également ses capacités de fonctionnement automatique. Une assistance au
positionnement fin par bouclage sur l’image échographique est implémentée et testée in
vitro : elle permet d’approcher la ligne de visée de l’aiguille à biopsie d’une cible définie
dans la prostate avec une précision satisfaisante.
Plusieurs possibles perspectives de recherche sont présentées en conclusion de la
présentation de ces travaux.
Mots clés : robotique médicale, comanipulation, conception, commande, contrainte
anatomiqueiii
Abstract
Prostate cancer is nowadays the most common cancer among men in France. Very
different prognosis are brought together under this only one designation : asymptotical
cancers that evolve slowly enough as not to have any influence over the lifetime
expectancy and quality of life, but also aggressive cancers that can lead to death. Yet
to analyze cancer, to predict its outcome and thus to take an appropriate therapeutic
decision is still very difficult. That’s why making progress in the field of diagnostical
tools is crucial, not in order to detect more cancer cases but to be able to better qualify them.
The examination that can bring to diagnose prostate cancer is prostate biopsy, which
consists in taking out tissue samples that will later be analyzed. This gesture, which is
performed in clinical routine under 2D ultrasonic imaging on a patient who is under local
anesthesia, proves to be particularly complex to realize and provides very little quantitative
information about the samples taken out. Thus the robotization of biopsies appears to be
an interesting medium to improve the quality of the prostate cancer diagnostic.
In this thesis, we take up the problematic of robotic assistance to the realization of
prostate biopsies. The surgical gesture and its impact on the diagnostic are first studied.
From that it appears that such a robotic system could bring noticeable improvement to the
process. Thanks to an analysis of the existing devices destined for prostate biopsy and
prostate brachytherapy and taking in account the economic constraints attached to the
examination, guidelines are led out for our robot design : it will have to use the ultrasonic
image as the only source of extrinsic information, pass through transrectal access, exhibit
6 degrees of freedom and exploit the comanipulation paradigm. A robot satisfying these
criteria is presented : Apollo is an anthropomorphic arm exhibiting a hybrid actuation
(three brakes and three motors), an interesting solution as regards performances, cost and
patient safety. Different assistive functions can be performed with such a system.
A free mode allowing the urologist to control the probe movements without any
influence from the robot is first presented. An analysis of the gesture during a pointing
task proves that the free mode exhibits a satisfying transparency, thanks to material and
software design. A locked mode is then developed : it precisely locks the ultrasonic
probe in its position while exhibiting a low stiffness. The performances of this control
mode are tested both in vitro and in cadavero, which justify a posteriori Apollo’s design.
Clinical trials focusing on the free mode and the locked mode have been authorized byiv
the Comité de Protection des Personnes (french People Protection Committee) and the
Agence Nationale de Sécurité du Médicament (french Drug Security National Agency), it
should start in July 2014 in the Pitié-Salpêtrière hospital.
Given that the anus can move during the examination and that the acceptable limit
for the efforts applied on it is unknown, it is crucial to determine how to respect this
anatomical constraint. Thanks to a robot that is similar to Apollo but exhibits six motorized
degrees of freedom, two control laws are compared : a « wrench displacement » control
law and a « lever effect » control law. It is proved that any force feedback assisting
function can be realized with Apollo controled by a « lever effect » command and respect
the anatomical constraint, provided that this function can be expressed as a virtual force
applied on the distal part of a comanipulated tool. A example of such an assistance function
is then presented : an increase in the apparent stiffness of the prostate based on real time
ultrasonic imaging. This function as been implemented and tested at the beginning of the
thesis here presented on a basic prototype but it still demonstrates the feasibility of such
an image based force feedback.
Finally, Apollo being already fitted with two basic modes (free and locked) and
a methodology to compute a force feedback control law that respects the anatomical
constraint thanks to comanipulation, exploiting its automatic functioning capabilities is
proposed. An assistance to precise positionning featuring a loop on the ultrasonic image is
implemented and tested in vitro : it allows to bring the line of sight of the biopsy needle
near a target defined in the prostate with a satisfying precision.
As a conclusion, possible future research axis arising from these work are presented.
Keywords : medical robotics, comanipulation, design, control, anatomical constraintRemerciements
Je souhaite tout d’abord remercier Guillaume Morel, Marie-Aude Vitrani et Pierre
Mozer, pour leur accueil et tout ce qu’ils m’ont appris. Guillaume, merci de m’avoir
amenée jusqu’au bout malgré nos caractères très différents. Marie-Aude, merci de m’avoir
permis de m’investir autant dans l’enseignement. Pierre, merci de m’avoir ouvert les portes
de la Pitié, plus jamais je ne pourrai dire « bonjour monsieur » sans arrière-pensée.
Merci à Mrs. Renaud et Poisson, qui ont accepté d’être rapporteurs de cette thèse. Vos
avis m’ont beaucoup aidée à clarifier mes idées et à réorganiser le contenu de cette thèse
en vue de sa soutenance. Je remercie également Mme. Troccaz ainsi que Mrs. Zarader et
Leroy, qui ont bien voulu être membres du jury.
Je tiens aussi à remercier la société Koélis, et en particulier Michael Baumann que j’ai
beaucoup sollicité. Je vous souhaite longue vie et j’espère que vous prendrez bien soin
d’Apollo. Plus généralement, merci à tous les partenaires du projet PROSBOT, qui m’ont
permis de voir plus loin que le bout de mon end-effecteur.
J’adresse de chaleureux mercis aux membres de l’équipe Agathe, passés et actuels,
avec qui j’ai pris beaucoup de plaisir à travailler (ou pas ;-)). Je ne me risquerai pas à les
nommer un par un, de peur d’en oublier, mais j’ai néanmoins une pensée particulière pour
le J08 historique, Juan et les Vincent. Mes remerciements particuliers vont également à
David, Sébastien et Florian, ingénieurs dans l’équipe Agathe, qui m’ont énormément aidée.
Merci à mes amis. Alsaciens, parisiens, suisses, fournisseurs de chats, couturières et
tricoteuses, connus depuis le lycée ou plus récemment rencontrés, vous avez toujours été
présents et avez grandement contribué à mon équilibre ces dernières années. Votre amitié
m’est précieuse.
Un grand merci à ma famille pour son soutien et surtout à mes parents, qui ont su me
donner le goût des études puis m’ont encouragée quand j’ai voulu faire à mon tour une
« foutue thèse ».
Enfin, merci à toi Christophe. Je ne saurais écrire correctement tout ce que je te dois.
Alors tout simplement : je t’aime, et je suis heureuse de me lancer dans un nouveau projet
à (très) long terme avec toi.Table des matières
1 La robotique dans le diagnostic du cancer de la prostate 5
1.1 Le cancer de la prostate . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.1 Du dépistage au diagnostic . . . . . . . . . . . . . . . . . . . . . . 6
1.1.2 Options thérapeutiques . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 La biopsie prostatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.1 Anatomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.2 Routine clinique . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.3 Problématiques inhérentes à l’examen . . . . . . . . . . . . . . . . 13
1.3 L’UroStation, un dispositif informatif . . . . . . . . . . . . . . . . . . . . 15
1.4 Analyse du geste chirurgical . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.4.1 Influence sur le geste de biopsie . . . . . . . . . . . . . . . . . . . 17
1.4.2 Étude géométrique du geste . . . . . . . . . . . . . . . . . . . . . 18
1.4.3 Conséquences sur le diagnostic . . . . . . . . . . . . . . . . . . . 21
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2 Conception d’un système robotique d’assistance à la biopsie de prostate :
Apollo 25
2.1 Analyse des dispositifs existants . . . . . . . . . . . . . . . . . . . . . . . 25
2.1.1 Imagerie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.1.2 Voie d’abord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.1.3 Cinématique du robot . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.4 Degré d’autonomie du robot . . . . . . . . . . . . . . . . . . . . . 30
2.2 Cinématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3 Distribution des actionneurs . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.4 Différentes fonctions d’assistance . . . . . . . . . . . . . . . . . . . . . . 40
2.4.1 Mode libre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.4.2 Mode verrouillé . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.4.3 Assistance par retour d’effort . . . . . . . . . . . . . . . . . . . . . 41
2.4.4 Déplacement fin par retour échographique . . . . . . . . . . . . . . 42
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42viii Table des matières
3 Modes libre et verrouillé 45
3.1 Mode libre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.1.1 Une caractéristique essentielle : la transparence . . . . . . . . . . . 46
3.1.2 Commande bas niveau . . . . . . . . . . . . . . . . . . . . . . . . 46
3.1.3 Commande du mode libre . . . . . . . . . . . . . . . . . . . . . . 49
3.2 Validation expérimentale du mode libre . . . . . . . . . . . . . . . . . . . 49
3.2.1 Analyse de la transparence d’Apollo in vitro . . . . . . . . . . . . 49
3.2.2 Essais in cadavero . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.3 Mode verrouillé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.3.1 Souplesse et précision, deux contraintes antagonistes . . . . . . . . 58
3.3.2 Commandes développées . . . . . . . . . . . . . . . . . . . . . . . 60
3.4 Validation expérimentale du mode verrouillé . . . . . . . . . . . . . . . . . 69
3.4.1 Validation in vitro . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.4.2 Validation in cadavero . . . . . . . . . . . . . . . . . . . . . . . . 73
3.5 Essais cliniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
4 Assistance au positionnement comanipulé par retour d’efforts 77
4.1 Transmission d’efforts respectueuse d’un point de passage . . . . . . . . . 79
4.1.1 Contrainte anatomique . . . . . . . . . . . . . . . . . . . . . . . . 79
4.1.2 Différentes stratégies de commande possibles . . . . . . . . . . . . 80
4.1.3 Comparaison expérimentale . . . . . . . . . . . . . . . . . . . . . 83
4.2 Augmentation de raideur apparente basée image . . . . . . . . . . . . . . . 94
4.2.1 Mise à l’échelle de force . . . . . . . . . . . . . . . . . . . . . . . 94
4.2.2 Commande basée image . . . . . . . . . . . . . . . . . . . . . . . 96
4.2.3 Validation expérimentale . . . . . . . . . . . . . . . . . . . . . . . 100
4.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5 Ajustement automatique lors d’une tâche de pointage 109
5.1 Réalisation d’un ajustement de visée . . . . . . . . . . . . . . . . . . . . . 109
5.2 Déplacements fins automatiques unitaires . . . . . . . . . . . . . . . . . . 111
5.2.1 Définition de la matrice d’interaction . . . . . . . . . . . . . . . . 111
5.2.2 Protocole d’identification de la matrice d’interaction . . . . . . . . 112
5.2.3 Déplacements automatiques, freins serrés . . . . . . . . . . . . . . 113
5.2.4 Déplacements automatiques freins déserrés . . . . . . . . . . . . . 116
5.3 Asservissement sur l’image de déplacements fins . . . . . . . . . . . . . . 118
5.3.1 Processus de bouclage . . . . . . . . . . . . . . . . . . . . . . . . 118
5.3.2 Expérience mise en place . . . . . . . . . . . . . . . . . . . . . . . 119
5.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
6 Conclusions et perspectives 125
A Résumé du protocole expérimental des essais cliniques 131
Bibliographie 135Notations et définitions
Rb = (O,
−→xb ,
−→yb ,
−→zb ) ... repère lié à la base du robot
Rs = (E,
−→xs
,
−→ys
,
−→zs ) ... repère lié à la sonde échographique endorectale
Ri = (E,
−→xi
,
−→yi
,
−→zi ) ... repère lié à l’image échographique 3D
Ri2 = (E,
−→xi2,
−→yi2) ... repère lié à l’image échographique 2D
P ... centre du poignet du robot
T ... point cible par lequel on souhaite faire passer la biopsie
E ... extrémité de la sonde
−→xA ... vecteur position du point A
a ... coordonnées du vecteur −→a dans le repère RbIntroduction
Contexte clinique
Le cancer de la prostate est à l’heure actuelle le cancer le plus fréquent chez l’homme
en France. Sous cette appellation unique sont regroupés des pronostics très différents :
certains patients présentent des cancers asymptomatiques évoluant suffisamment lentement
pour n’avoir aucune influence sur leur espérance et leur qualité de vie, tandis que d’autres
sont atteints par des cancers agressifs pouvant causer leur décès. Traiter tous les patients de
la même manière n’est donc pas envisageable, les différents types de cancer prostatiques
appelant différentes solutions thérapeutiques.
Or ces dernières années ont vu augmenter le nombre de dépistages systématiques du
cancer de la prostate effectués dans la population des hommes de plus de 50 ans. Cette
tendance crée la polémique car elle peut mener à un sur-diagnostic et à un sur-traitement
des patients atteints : du fait des outils aujourd’hui disponibles pour réaliser le diagnostic
il est très difficile d’analyser le cancer, d’en prévoir l’évolution et donc de prendre une
décision thérapeutique adaptée. Il est donc capital de faire évoluer les outils de diagnostic
du cancer de la prostate, non pas pour détecter plus de cas mais pour être capable de mieux
les qualifier.
L’examen permettant de poser le diagnostic de cancer prostatique est la réalisation de
biopsies de prostate, c’est-à-dire le prélèvement d’échantillons qui seront ensuite analysés
par l’anatomopathologiste. Or ce geste, effectué en routine clinique sous échographie
bidimensionnelle sur un patient anesthésié localement, s’avère particulièrement complexe
à réaliser et fournit très peu d’informations quantitatives sur les carottes de glande
prélevés. C’est pourquoi la robotisation des biopsies est aujourd’hui vue comme un
medium intéressant pour améliorer la qualité du diagnostic du cancer de la prostate.
Problématique et objectifs
Les travaux menés au cours de cette thèse portent sur le développement d’un robot
d’assistance aux biopsies prostatiques et de sa commande, le système exploitant le
paradigme de la comanipulation pour s’affranchir des limites rencontrés par les dispositifs2 Table des matières
existants. Il doit assurer la sécurité du patient et assister l’urologue sans le contraindre ou
l’éloigner du premier.
Dans le chapitre 1 nous analysons le geste chirurgical effectué par l’urologue et son
impact sur la détection de tumeurs. Cette étude nous permet de mettre en évidence l’intérêt
d’un robot tel que celui que nous allons développer.
Dans le chapitre 2 un état de l’art des dispositifs d’assistance à la biopsie et à la
brachythérapie de prostate existants est présenté. L’analyse de ces systèmes et du contexte
médico-économique nous amène à faire de premiers choix de conception, à partir desquels
est développé le robot Apollo. Sa cinématique et son actionnement sont présentés.
Plusieurs modes d’assistance à l’urologue qu’il est susceptible d’offrir sont évoqués.
Dans le chapitre 3 nous nous concentrons sur deux de ces modes : le mode libre et le
mode verrouillé. Le premier doit permettre à l’urologue de maîtriser les mouvements de la
sonde sans influence aucune du robot, nous chercherons donc à améliorer la transparence
d’Apollo et à la quantifier. Le second doit assurer un maintien en position de la sonde
échographique qui soit à la fois souple, pour ne pas blesser le patient, et précis. Plusieurs
commandes, exploitant différents composants d’Apollo, sont proposées puis testées, in
vitro et in cadavero.
Dans le chapitre 4 la question de l’exploitation du paradigme de comanipulation pour
l’assistance au geste par retour d’effort est posée. Deux points clés apparaissent dans ce
contexte : la prise en compte de la contrainte constituée par le point d’insertion de la sonde
dans le patient et la gestion des échelles de temps dans une commande en effort basée
image. Pour répondre à chacun de ces problèmes, plusieurs commandes sont présentées et
évaluées.
Dans le chapitre 5 les capacités de manipulation automatiques de la sonde
échographique par Apollo sont exploitées. Une commande permettant le positionnement
fin automatique basé image de la ligne de visée de l’aiguille à biopsie vers une cible est
détaillée. Une preuve de concept expérimentale est ensuite présentée.
Dans le chapitre 6 nous concluons sur ces études et présentons plusieurs pistes de
prolongement de ces travaux.
Contexte partenarial
Cette thèse s’inscrit dans le cadre du projet PROSBOT, qui a été lancé en Novembre
2011. Il est financé par l’ANR TECSAN. Ce projet, qui regroupe à la fois des partenaires
académiques, hospitaliers et industriels, a pour but le développement d’un système
robotisé d’assistance aux biopsies prostatiques.Table des matières 3
Les partenaires académiques sont l’Institut des Systèmes Intelligents et de Robotique
(Université Pierre et Marie Curie, Paris) et le laboratoire Techniques de l’Ingénierie
Médicale et de la Complexité (Université Joseph Fourier, Grenoble). TIMC s’intéresse
plus particulièrement au suivi d’organe par imagerie, à la prédiction de bougés par modèle
bio-mécanique et au couplage image-modèle, tandis que l’ISIR travaille au développement
d’un robot comanipulé, à l’analyse des bougés pour la commande et à la mesure de la
position de la sonde échographique.
Les partenaires hospitaliers, l’APHP-Pitié Salpêtrière (Paris) et le Centre
d’Investigation Clinique - Innovation Technologique de Grenoble, sont en charge de
l’analyse de risque, des évaluation cliniques et des aspects réglementaires de ces essais.
Le partenaire industriel est Koelis, une entreprise basée à Grenoble spécialisée dans
le développement de systèmes de GMCAO (Gestes Médico-Chirurgicaux Assistés par
Ordinateur) dans le domaine de l’urologie. Cette société produit l’UroStation, un dispositif
d’assistance aux biopsies prostatiques qui sera présenté en section 1.3.Chapitre 1
La robotique dans le diagnostic du
cancer de la prostate
Sommaire
1.1 Le cancer de la prostate . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.1.1 Du dépistage au diagnostic . . . . . . . . . . . . . . . . . . . . . . 6
1.1.2 Options thérapeutiques . . . . . . . . . . . . . . . . . . . . . . . . 6
1.2 La biopsie prostatique . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.1 Anatomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.2 Routine clinique . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.2.3 Problématiques inhérentes à l’examen . . . . . . . . . . . . . . . . 13
1.3 L’UroStation, un dispositif informatif . . . . . . . . . . . . . . . . . . . 15
1.4 Analyse du geste chirurgical . . . . . . . . . . . . . . . . . . . . . . . . 16
1.4.1 Influence sur le geste de biopsie . . . . . . . . . . . . . . . . . . . 17
1.4.2 Étude géométrique du geste . . . . . . . . . . . . . . . . . . . . . 18
1.4.3 Conséquences sur le diagnostic . . . . . . . . . . . . . . . . . . . 21
1.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.1 Le cancer de la prostate
Le cancer de la prostate est à l’heure actuelle très répandu : en 2013 240000
nouveaux cas ont été dépistés et presque 24000 décès sont survenus aux États-Unis
d’après [Siegel 2013]. Néanmoins, si le cancer prostatique est le plus fréquent chez
l’homme en France (taux d’incidence de 99,4 pour 100000) il n’est que le cinquième pour
le taux de mortalité (11,3 pour 100000) [Rébillard 2013]. Les taux relatifs de survie sont
donc très importants : quasiment 100% à 5 ans, 98% à 10 ans et 91% à 15 ans [ACS ].
L’âge moyen de diagnostic se situe autour de 69 ans, tandis que l’âge médian de décès se
situe après 80 ans.6 Chapitre 1. La robotique dans le diagnostic du cancer de la prostate
Du fait de l’étendue de cette pathologie, l’examen permettant de la diagnostiquer est
un acte médical courant : des centaines de milliers de biopsies sont réalisées chaque année
aux États-Unis [ACS ] afin d’identifier les patients atteints d’un cancer de la prostate et
d’estimer le pronostic.
1.1.1 Du dépistage au diagnostic
À un stade précoce, le cancer de la prostate est généralement asymptomatique.
Néanmoins la présence de cellules cancéreuses dans la prostate entraîne l’augmentation du
taux sanguin d’antigène prostatique spécifique (PSA), ce qui trahit la présence d’un cancer
avant qu’il ne génère le moindre symptôme. Mais le dosage du PSA n’est pas suffisant
pour diagnostiquer à lui seul un cancer car il s’agit d’un marqueur de la prostate et non
du cancer, ce qui signifie qu’une augmentation du taux de PSA n’est pas nécessairement
due à un cancer prostatique. D’autres examens existent (toucher rectal, IRM...) mais
ils permettent uniquement d’évoquer le diagnostic. En effet, tout zone dure dans la
prostate n’est pas forcément cancéreuse et l’IRM peut uniquement montrer des « zones
suspectes » sans pour autant permettre de conclure sur leur nature. La plupart du temps,
c’est l’augmentation du taux de PSA qui va conduire le médecin à prescrire au patient une
série de biopsies prostatiques, qui est le seul examen permettant d’établir le diagnostic.
Les biopsies prostatiques se déroulent en chirurgie ambulatoire, sous anesthésie locale.
L’urologue utilise une sonde échographique endorectale afin de visualiser la prostate
et de choisir les lieux de biopsie. En règle générale, une aiguille à biopsie est utilisée
pour réaliser une douzaine de ponctions aussi équi-réparties que possible dans le volume
de la glande, auxquelles des biopsies ciblées dans les zones suspectes peuvent ensuite
être ajoutées selon les résultats de l’imagerie. Les carottes de prostate ainsi prélevées
sont confiées à l’anatomopathologiste pour analyse. Celui-ci informe l’urologue de la
longueur de tissu cancéreux présente dans chaque prélèvement ainsi que de leur stade de
développement (score de Gleason). Il revient à ce dernier de poser le diagnostic puis, en
accord avec le patient, de prendre des décisions thérapeutiques.
1.1.2 Options thérapeutiques
Si la présence de cellules cancéreuses au sein de la prostate est avérée, une décision
thérapeutique doit être prise. Celle-ci doit offrir au patient les meilleures perspectives
possibles, en terme de d’espérance mais aussi de qualité de vie. Différents choix sont
possibles, en fonction notamment du stade d’évolution des cellules cancéreuses et de l’âge
du patient. Du fait de la systématisation des examens de dépistage (l’Association Française
d’Urologie préconise un dosage annuel du taux de PSA dès 50 ans, 45 ans en cas de risque
familial ou ethnique, et jusqu’à 75 ans [Salomon 2010]), les cancers de la prostate sont
généralement dépistés à un stade très précoce. Nous nous intéresserons ici aux options
thérapeutiques généralement envisagées pour des cancers de stade II (cancers de taille1.1. Le cancer de la prostate 7
importante et ayant un haut score de Gleason mais localisés dans la prostate), c’est-à-dire
les cas les plus souvent rencontrés.
La première option possible est de ne pas traiter le patient et de le placer sous
surveillance. En effet, de nombreux cancers prostatiques évoluent très lentement. Certains
évoluent tellement peu qu’ils n’ont aucun effet sur la santé du patient, et ce jusqu’à leur
mort (due à une autre cause). Dans ce cas, le patient sera placé sous surveillance : son
taux de PSA sera suivi et il passera régulièrement des biopsies prostatiques et des IRMs
afin de contrôler l’évolution de la zone cancéreuse. Les résultats des biopsies faites d’une
année sur l’autre sont malheureusement parfois difficiles à expliquer. En effet, étant donné
que les urologues utilisent uniquement l’image échographique 2D pour cibler les zones
de biopsie et sachant que la taille de la prostate peut varier considérablement au cours du
temps (et de l’évolution de la maladie), il est impossible de prélever précisément au même
endroit d’une année sur l’autre. Ainsi, l’urologue ne peut connaître de façon certaine et
quantitative l’évolution de l’étendue de la tumeur.
FIGURE 1.1 – Illustrations tirées de [Gross 2011]. A gauche : accélérateur linéaire de
particules classiquement utilisé en radiothérapie de la prostate. A droite : segmentation
d’une image obtenue par scanner pour établir le planning de dosimétrie ; en orange la
vessie, en vert le rectum, en bleu la prostate.
Si le cancer est plus agressif et/ou plus étendu ou si le patient est jeune, il peut être
décidé de le traiter par irradiation. Cette irradiation peut être faite soit par radiothérapie
externe [Gross 2011], soit par brachythérapie. Dans le premier cas, un accélérateur de
particules couplé à un logiciel de planning permet d’irradier le volume prostatique défini
au préalable grâce à la segmentation d’un scanner, voir figure 1.1. Il s’agit dans le
deuxième cas d’insérer des grains radioactifs dans la prostate à l’aide d’une aiguille en
suivant un planning établi par un logiciel de dosimétrie, ceci afin d’assurer une irradiation
suffisante et uniforme de la prostate. Cette opération se fait en s’aidant d’un « template ».
Le template est une plaque percée, chaque trou correspondant à un point d’entrée pouvant
être imposé par le logiciel de dosimétrie. Il est placé contre le périnée du patient qui est
alors sous anesthésie générale. Un moyen d’imagerie médicale (sonde échographique
endorectale, scanner ou IRM) est utilisé pour contrôler visuellement le geste au cours
de son exécution et connaître a posteriori la répartition des grains dans la prostate (voir8 Chapitre 1. La robotique dans le diagnostic du cancer de la prostate
FIGURE 1.2 – Illustrations tirées de ❤tt♣✿✴✴✇✇✇✳✉r♦♣❛❣❡✳❝♦♠✴. A gauche :
schématisation de la brachythérapie. A droite : visualisation échographique des grains
insérés dans la prostate.
figure 1.2). Quelle que soit la méthode d’irradiation de la prostate choisie, si la glande n’a
pas été suffisamment traitée alors des cellules cancéreuses peuvent résister et continuer à
se développer. A l’inverse, une irradiation trop importante de la prostate peut conduire à
une irradiation des tissus environnants sains, ce qui peut avoir un impact sur les fonctions
digestives notamment [Alivizatos 2005].
FIGURE 1.3 – Illustration tirée de [Bastide 2009]. Schématisation de la prostatectomie
radicale.
Il est également possible de pratiquer une prostatectomie radicale, c’est-à-dire une
ablation de la glande dans sa totalité sous anesthésie générale, voir figure 1.3. A l’issue
de l’opération, le patient est stérile mais toutes ses autres fonctions corporelles sont
normalement intactes. Cependant la prostate est très proche à la fois des nerfs érectiles et
du sphincter. Si ces structures anatomiques sont touchées lors de l’opération, le patient peut
devenir impuissant et/ou incontinent. A l’heure actuelle, on constate que 2 à 3% des patients
ayant subi une prostatectomie radicale souffrent par la suite d’incontinence permanente,
5 à 20% présentent une incontinence d’effort et 14 à 87% une dysfonction érectile selon
les études (donc les définitions des complications post-opératoires considérées), les
techniques chirurgicales employées, le stade tumoral, etc [Bastide 2009, Richard 1993].
Il est important de noter que les taux de complications sont particulièrement liés à l’âge1.2. La biopsie prostatique 9
du patient et à l’expérience du chirurgien [Alivizatos 2005]. La prostatectomie radicale est
donc un geste chirurgical présentant des risques non négligeables et nécessitant un long
apprentissage ; il convient de n’y recourir que lorsque c’est nécessaire.
On note ainsi que, à l’heure actuelle, seuls des traitements globaux sont disponibles.
En effet, qu’il s’agisse de l’irradiation ou de la chirurgie, la glande va être traitée dans
sa totalité alors que le cancer peut être localisé dans une partie seulement de la prostate.
De ce fait, des tissus sains sont impactés par les traitements proposés aux patients atteints
d’un cancer prostatique. La décision thérapeutique est ainsi lourde de conséquences alors
qu’elle repose sur des outils diagnostiques imprécis. Améliorer la qualité du diagnostic
ne veut donc pas dire uniquement augmenter les capacités de détection des cellules
cancéreuses, mais aussi et surtout augmenter sa précision. Un « bon » diagnostic est un
diagnostic apportant des informations fiables et précises (si possible chiffrées) sur la
répartition des tumeurs dans la prostate. Connaître la localisation précise des biopsies
présentant des cellules cancéreuses permettrait à l’urologue de prendre une décision
adaptée au cas particulier de son patient, sans sur-traitement ou opération inutile, et de se
diriger vers des traitements focalisés sur les zones tumorales, ayant des effets secondaires
moins importants.
1.2 La biopsie prostatique
Comme nous l’avons vu précédemment, améliorer la qualité de l’examen menant au
diagnostic du cancer de la prostate permettrait aux praticiens de prendre des décisions
thérapeutiques en ayant une vision claire et juste du stade de développement de la maladie.
Nous allons donc nous intéresser à la réalisation proprement dite des biopsies prostatiques,
afin de déterminer les éléments de l’examen sur lesquels il est possible d’agir.
1.2.1 Anatomie
La prostate est une glande qui fait partie du système reproducteur masculin. Elle se
situe en avant du rectum, juste sous la vessie (figure 1.4). Elle a la forme d’une châtaigne
et mesure 3 à 5 cm dans toutes les directions. Cependant sa taille peut varier du simple au
quadruple selon le patient et son âge. Lorsque le sujet est debout, la zone basse est appelée
apex, la zone haute est appelée base. Des cellules cancéreuses peuvent se développer dans
la prostate, principalement près de sa périphérie, et l’on cherche à les détecter le plus tôt
possible.
1.2.2 Routine clinique
Bien que chaque urologue ait sa propre façon de procéder, des recommandations
existent [Ouzzane 2011]. Les biopsies prostatiques se font généralement sans10 Chapitre 1. La robotique dans le diagnostic du cancer de la prostate
FIGURE 1.4 – Appareil génital masculin. 1. Vessie 2. Pubis (os) 3. Pénis 4. Corps caverneux
5. Gland 6. Prépuce 7. Méat urétral 8. Côlon sigmoïde 9. Rectum 10. Vésicule séminale
11. Canal éjaculateur 12. Prostate 13. Glande de Cowper 14. Anus 15. Canal déférent 16.
Épididyme 17. Testicule 18. Scrotum.
hospitalisation, en chirurgie ambulatoire. Le patient est placé en décubitus latéral
gauche (couché en chien de fusil sur le côté gauche) comme on peut le voir sur la
figure 1.5. Une sonde échographique endorectale munie d’un guide-aiguille est introduite
dans le rectum. Une injection permet de réaliser une anesthésie locale de la paroi du rectum.
FIGURE 1.5 – Installation pour la réalisation d’une série de biopsies prostatiques en routine
clinique.
En s’aidant de l’image échographique, le chirurgien dirige l’aiguille vers la zone
désirée. Les tumeurs prostatiques, souvent des adénocarcinomes, n’étant généralement pas
visibles sur l’image échographique, le chirurgien n’utilise celle-ci que pour se repérer au
sein de la prostate et cibler les zones qu’il souhaite biopsier. Lorsqu’il est en face d’une1.2. La biopsie prostatique 11
de celles-ci, il perce la paroi du rectum pour placer l’extrémité de l’aiguille au contact
de la capsule prostatique puis il actionne le pistolet à biopsie. Celui-ci va pousser très
rapidement l’aiguille sur une distance maximale de 22 mm, pour une ponction nette et
moins douloureuse (figure 1.6).
FIGURE 1.6 – Réalisation d’une biopsie de prostate. A gauche : vue en coupe sagittale
(❤tt♣✿✴✴✇✇✇✳✉r♦♣❛❣❡✳❝♦♠). A droite : gros plan sur la zone de ponction (❤tt♣✿✴✴✇✇✇✳
✈✐❞❛❧❣r❛♥❞♣✉❜❧✐❝✳❝♦♠).
Le schéma le plus couramment utilisé pour le placement des biopsies est le schéma
en sextant : on réalise 12 biopsies, 6 dans chaque lobe (droite et gauche), également
réparties entre la base, le milieu et l’apex (figure 1.8). Ces biopsies se font dans un ordre
prédéterminé, afin de faciliter la navigation au sein de la prostate pour l’urologue. Il est
éventuellement possible de réaliser des biopsies supplémentaires, par exemple dans des
zones suspectes détectées à l’IRM (voir figure 1.7). Dans ce cas, la plupart du temps, le
chirurgien réalise une mise en correspondance mentale entre les images IRM et l’image
échographique.
Il est possible de réaliser les biopsies par voie transpérinéale mais cela rend la
procédure plus longue, coûteuse et délicate. En effet, il faut dans ce cas que le patient
soit placé sous anesthésie générale, ce qui implique une hospitalisation. Or cela n’est pas
compatible avec les contraintes médico-économiques actuelles : les biopsies prostatiques
constituent certes un examen diagnostic et non pas un dépistage, néanmoins une part
importante de la population masculine doit passer cet examen chaque année. Il faut donc
qu’il reste peu onéreux et rapide (une séance typique dure une vingtaine de minutes). De
plus, pratiquer une anesthésie générale plutôt qu’une anesthésie locale accroît les risques
de complications pour le patient. Ainsi la voie d’abord transpérinéale n’est indiquée que12 Chapitre 1. La robotique dans le diagnostic du cancer de la prostate
FIGURE 1.7 – L’IRM permet de détecter des zones suspectées d’être concéreuses. A
gauche, une image d’une prostate saine, à droite une prostate contenant un carcinome
( ).
FIGURE 1.8 – Schéma de biopsies en sextant.1.2. La biopsie prostatique 13
dans de rares cas et la voie transrectale sera préférée en routine.
Une autre raison pour laquelle l’urologue utilise l’échographie plutôt qu’une autre
modalité d’imagerie est le contexte médico-économique. En effet, l’utilisation d’une
machine telle que l’IRM est trop coûteuse en routine, sans compter la rareté de cette
ressource qui la rend difficile d’accès et interdit de l’immobiliser une vingtaine de minutes
pour chaque patient.
1.2.3 Problématiques inhérentes à l’examen
Si la réalisation d’une biopsie prostatique peut paraître simple au premier abord,
il n’en est rien. Tout d’abord, l’urologue ne bénéficie quasiment d’aucune information
tactile sur le geste qu’il est en train de réaliser. En effet, les efforts exercés par le rectum
sur la sonde peuvent être très importants et sont variables au cours du temps puisqu’ils
dépendent notamment de l’activation musculaire (consciente ou non) du patient. Or il est
important que le chirurgien maintienne un effort stable entre l’extrémité de la sonde et la
paroi rectale. Un effort trop grand causerait une déformation et un déplacement importants
de la prostate et pourrait occasionner de la douleur pour le patient. Un effort trop faible
pourrait permettre à une bulle d’air de se glisser entre le transducteur et la paroi rectale,
ce qui ferait perdre l’image échographique. Ainsi l’urologue doit garder les yeux rivés sur
l’écran de l’échographe en permanence, afin d’estimer les efforts qu’il exerce sur la paroi
rectale via la sonde en observant les déformations des structures anatomiques visibles à
l’image échographique.
Tout au long de l’examen, le chirurgien doit également se construire une image mentale
de la prostate dans laquelle il se représente et suit la position de la sonde échographique,
du plan de coupe affiché sur l’écran de l’échographe, et de l’aiguille. Cette opération
demande une grande concentration au chirurgien. De plus il est impossible de connaître la
localisation des biopsies effectuées avec précision, ce qui limite actuellement la qualité du
diagnostic et du suivi de l’évolution des cellules cancéreuses et empêche le développement
de traitements localisés des tumeurs.
L’urologue ne pouvant se guider qu’à l’aide de l’image échographique et de sa
reconstruction mentale de la prostate, il est difficile pour lui d’obtenir une répartition
homogène des ponctions dans le volume prostatique et impossible de vérifier a posteriori
la qualité de son échantillonnage. C’est pour cette raison notamment que l’échantillonnage
systématique suivant le schéma en sextant a été retenu, puisqu’il permet d’obtenir un taux
de détection des cellules cancéreuses satisfaisant malgré les imprécisions de réalisation
du geste chirurgical [Villers 2004]. Il a été montré que, si l’on était capable d’obtenir une
précision parfaite dans le placement des biopsies, on pourrait n’en réaliser que six ou sept,
dont le placement a été défini grâce à une analyse statistique, tout en obtenant un taux de
détection du cancer de l’ordre de 95%, tandis que le schéma en sextant offre un taux de
détection de l’ordre de 70% [Zhan 2007]. Or il a été montré par [Rodriguez 1998] que, si14 Chapitre 1. La robotique dans le diagnostic du cancer de la prostate
les biopsies prostatiques par voie transrectale ne présentent pas de risque de complication
majeure, les complications mineures sont courantes : hématurie (présence de sang dans
les urines), saignement du rectum, douleur persistante, présence de sang dans le sperme,
dysurie (difficulté à uriner)... Il serait donc intéressant de pouvoir guider le geste du
chirurgien afin que les biopsies soient correctement réparties et moins nombreuses, ce qui
réduirait le risque de complications post-opératoires.
Enfin, lors de l’examen la prostate bouge sous les effets combinés de plusieurs
mécanismes :
– mouvements physiologiques (respiration, mais aussi remplissage de la vessie),
– déplacements du patient (volontaires et réflexes),
– pression exercée par le chirurgien sur la paroi rectale via la sonde échographique
endorectale,
– efforts générés par l’aiguille lors de sa pénétration dans la paroi rectale puis dans la
prostate.
Il a été montré dans [Stone 2002] que l’insertion d’une aiguille dans la glande peut
occasionner des déplacements d’amplitude pouvant atteindre le centimètre (moyenne
observée : 2,3 mm) et des déformations (définies ici comme la variation de la dimension
maximale de la prostate dans la direction considérée) pouvant atteindre 2 cm (moyenne
observée : 4,2 mm). L’insertion d’aiguilles peut également faire pivoter la prostate
d’un angle pouvant atteindre 13,8
◦ d’après [Lagerburg 2005]. Un état de l’art de la
littérature disponible sur le déplacement de la prostate durant des séances de biopsie et de
brachythérapie a été réalisé par [Marchal 2006] et aboutit à une conclusion similaire : des
déplacements de la prostate de l’ordre de 5 mm sont couramment observés, ils dépassent
même régulièrement le centimètre. L’importante mobilité et la déformabilité de la prostate,
qui sont liées aux actions du chirurgien mais aussi à des éléments que le praticien ne peut
contrôler, compliquent la tâche de reconstruction mentale de la prostate pour l’urologue et
limitent encore sa maîtrise de l’échantillonnage de la glande.
A cela il faut ajouter enfin que, lorsque la sonde est orientée de telle façon que le
guide-aiguille se retrouve en-dessous, le chirurgien peut se retrouver obligé d’adopter une
position inconfortable pour pouvoir à la fois maintenir la sonde en position et insérer le
pistolet à biopsie dans le guide-aiguille. Or cette configuration de la sonde correspond
généralement à sa position moyenne lors des ponctions dans le lobe gauche, donc à la
moitié de l’examen.
En résumé, la réalisation de biopsies prostatiques impose à l’urologue une lourde
charge cognitive ainsi qu’une charge physique. Les mobilités de la prostate et le fait que
le patient ne soit pas sous anesthésie générale compliquent encore le geste. Devant ce
constat, différents systèmes d’assistance à la réalisation de biopsies prostatiques ont été
proposés.1.3. L’UroStation, un dispositif informatif 15
1.3 L’UroStation, un dispositif informatif
Afin d’assister l’urologue lors de la réalisation de biopsies prostatiques, différents
systèmes lui apportant des informations supplémentaires sur le champ opératoire et le
geste qu’il réalise ont été proposés. Parmi eux figure l’UroStation, un produit de la société
Koelis ([Koe ], Grenoble, France), partenaire du projet ANR PROSBOT avec qui nous
avons travaillé dans le cadre de cette recherche.
L’UroStation est un système d’assistance aux biopsies prostatiques sous imagerie
échographique. Elle permet de visualiser les biopsies dans une image tridimensionnelle de
la prostate, mais aussi d’effectuer une fusion IRM-échographie.
FIGURE 1.9 – L’Urostation, mise en œuvre et capture d’écran.
L’UroStation est composée d’un échographe 3D « classique » en liaison avec un
ordinateur portable. Sur cet ordinateur tourne un logiciel qui récupère les images
échographiques tridimensionnelles au fur et à mesure de l’examen (la dernière image
3D arrivée est appelée peropératoire) et qui, en utilisant des techniques avancées
de recalage élastique d’images tridimensionnelles présentées dans [Baumann 2009]
et [Baumann 2012], calcule la position de l’aiguille dans une image de référence de la
prostate (une image tridimensionnelle qui a été prise en tout début d’examen, appelée
panorama). Cette information est présentée au chirurgien sous la forme d’un cylindre
positionné dans une image échographique 3D de la prostate. Le praticien peut alors
naviguer dans cette image et analyser le geste qu’il vient d’effectuer. Il est important de
noter que ce recalage se fait sans segmentation de la prostate, en traitant l’image 3D dans
sa globalité.
Après chaque déclenchement du pistolet à biopsie, le praticien lance une acquisition
3D durant laquelle il cherche à maintenir la sonde immobile. En effet l’image
tridimensionnelle est obtenue en assemblant une série d’images bidimensionnelles
correspondant à différentes orientations de la barrette d’éléments piézoélectriques, qu’un
moteur permet de faire pivoter à l’intérieur de la sonde (le volume échographique ainsi16 Chapitre 1. La robotique dans le diagnostic du cancer de la prostate
visualisé est représenté à gauche de la figure 1.9). Le logiciel permet d’afficher la position
et l’orientation de la biopsie sur le panorama puisque, le guide-aiguille étant fixé à la sonde
échographique endorectale, la « ligne de visée » de l’aiguille est fixe par rapport à l’image
peropératoire. Le chirurgien peut ainsi savoir où est la zone biopsiée, à la fois par rapport
aux autres biopsies et par rapport à la prostate. De plus si l’acquisition est lancée en mode
simulation, c’est-à-dire avant le déclenchement du pistolet à biopsie, le logiciel indique à
l’urologue quelle serait la position de la biopsie s’il avait inséré l’aiguille dans la capsule
prostatique dans cette configuration.
Malheureusement, l’acquisition d’une image 3D n’est pas instantanée puisqu’elle
nécessite un balayage du transducteur. Or les mouvements du patient et du chirurgien
intervenant durant la phase d’acquisition nuisent à la qualité de l’image 3D obtenue donc
à la précision du placement de la biopsie. Ainsi l’UroStation fournit une information
précieuse au chirurgien sur l’échantillonnage de la prostate mais a posteriori et sous réserve
d’un maintien en position de la sonde qui soit satisfaisant durant l’acquisition des images
échographiques tridimensionnelles. Les biopsies virtuelles ne sont elles qu’indicatives
puisque, pour que le chirurgien cible effectivement la zone indiquée par l’UroStation suite
à une biopsie virtuelle, il faudrait que l’urologue et le patient soient totalement immobiles
à partir du moment où la biopsie virtuelle est demandée et jusqu’au moment où la biopsie
réelle est faite.
Il a été déjà montré par [Mozer 2009] que l’UroStation permet à l’urologue d’améliorer
la précision de son geste (c’est-à-dire de limiter la distance entre la biopsie réalisée et la
cible visée), mais nous nous sommes posé deux questions supplémentaires :
– l’UroStation induit-elle une modification dans la façon même de procéder à des
biopsies prostatiques ?
– en vue du développement d’une assistance robotique, les données issues des
recalages effectués par l’UroStation permettent-elles de mettre en évidence certaines
caractéristiques du geste chirurgical ?
1.4 Analyse du geste chirurgical
Nous avons pu utiliser une base de données comportant les examens de 78 patients
qui ont passé des biopsies prostatiques entre Janvier et Septembre 2009 à l’APHP
Pitié-Salpêtrière, et pour lesquels le docteur Pierre Mozer et deux de ses collègues ont
utilisé l’UroStation. Les algorithmes de recalage élastique implémentés dans l’UroStation
permettent l’enregistrement de nombreuses données géométriques lors de l’examen.
Toutes ces données sont exprimées dans un repère lié à la prostate (panorama initial) et
peuvent être extraites à l’aide d’un exécutable écrit par M. Baumann (Koelis). Grâce à un
traitement mathématique puis à une étude statistique des données, nous avons pu étudier
l’influence de l’UroStation sur le geste médical réel, les caractéristiques géométriques de
ce dernier et leur influence sur le diagnostic.1.4. Analyse du geste chirurgical 17
1.4.1 Influence sur le geste de biopsie
Les données issues de l’UroStation ont été d’abord exploitées pour calculer la position
dans le repère lié à l’image de référence du point d’entrée de l’aiguille dans la capsule
prostatique lors de chaque biopsie, pour chaque lobe. Connaissant l’ordre de réalisation
des biopsies, on peut alors les relier en les parcourant dans le sens des aiguilles d’une
montre pour dessiner la surface ponctionnée dans chaque lobe (biopsies reliées dans
l’ordre 1-2-4-6-5-3 pour le lobe droit, 8-7-9-11-12-10 pour le lobe gauche, voir figure 1.8).
La figure 1.10 présente deux exemples de graphiques obtenus.
FIGURE 1.10 – Position du transducteur pour chaque biopsie du lobe droit dans un repère
lié à la prostate pour deux patients différents. A gauche : schéma en sextant respecté. A
droite : biopsies n
◦ 5 et 6 du schéma en sextant inversées.
Les surfaces ponctionnées lors de certains examens apparaissent « croisées », comme
dans l’exemple présenté à droite de la figure 1.10. Cela signifie que l’urologue n’a pas
exécuté les biopsies dans l’ordre prévu par le schéma en sextant, pourtant globalement
suivi (on retrouve bien une biopsie dans chaque zone du sextant). Il s’agit d’un effet direct
de l’utilisation de l’UroStation : l’urologue constate en temps réel ses imprécisions et
les corrige. Supposons par exemple que le chirurgien souhaite réaliser la biopsie n
◦3. Il
vise sa cible en s’appuyant sur l’image échographique 2D, fait pénétrer l’aiguille dans la
capsule prostatique, actionne le pistolet à biopsie, puis lance l’acquisition d’une image 3D.
L’UroStation l’informe que la troisième biopsie, qui vient d’être réalisée, est en réalité là
où devrait se trouver la biopsie n
◦4 du schéma en sextant. L’urologue va alors déplacer la
sonde de manière à réaliser sa quatrième biopsie dans la zone où aurait dû se trouver la
troisième. Ainsi, tout en conservant le même nombre de biopsies et les mêmes zones cible,
l’urologue effectue un échantillonnage de la prostate de meilleure qualité et plus conforme18 Chapitre 1. La robotique dans le diagnostic du cancer de la prostate
au schéma en sextant recommandé (seul l’ordre des biopsies a changé).
L’UroStation, qui est un système informatif, permet donc d’améliorer l’examen
puisqu’il aide l’urologue à échantillonner équitablement les différentes zones de la
prostate en lui permettant de visualiser les éventuelles erreurs de placement de biopsie.
1.4.2 Étude géométrique du geste
1.4.2.1 Apparition de faisceaux
Les données issues de l’UroStation permettent également de connaître la position et
l’orientation de l’aiguille à biopsie, ainsi que la position du transducteur dans le repère lié
à l’image de référence lors de chaque biopsie. Ainsi, pour chaque patient, l’ensemble des
positions et orientations de l’aiguille par rapport à la prostate lors d’une séance est connue.
Nous avons utilisé les données issues d’examens de routine pour analyser la géométrie du
geste.
Deux situations, présentées sur la figure 1.11 , peuvent être observées selon les
patients :
– 1er cas : les positions successives de l’aiguille à biopsie dans le repère lié à la prostate
forment un faisceau en forme de sablier, tous les axes ainsi obtenus traversant une
unique « zone de passage » correspondant logiquement à l’anus,
– 2ieme cas : les positions successives de l’aiguille à biopsie dans le repère lié à la
prostate se séparent en deux faisceaux ou plus, chaque faisceau présentant une « zone
de passage » distincte.
Le deuxième cas correspond à un examen au cours duquel, à un moment donné, la
prostate s’est déplacée de façon importante et a glissé d’un côté ou de l’autre de la sonde
échographique tout en tournant. Ainsi dans le repère lié à la prostate l’anus a effectivement
changé de position, ce qui explique la présence de plusieurs faisceaux d’aiguilles (biopsies
faites avant ou après le glissement).
1.4.2.2 Espace de travail de la sonde
Pour chaque biopsie, il est également possible de calculer la position de la sonde
échographique endorectale dans le repère lié à la prostate connaissant la position du
transducteur (qui est situé à l’extrémité distale de la sonde) et l’orientation de l’aiguille
(qui est la même que celle de la sonde puisque le guide-aiguille est rigidement lié à cette
dernière). Ainsi, une position moyenne de la sonde dans le repère lié à la prostate a pu être
déterminée pour chaque patient et les écarts à cette position moyenne ont pu être analysés.
Les caractéristiques statistiques de ces écarts sont présentés en table 1.4.2.2.
Si l’espace de travail de la sonde échographique endorectale varie beaucoup d’un
patient à l’autre, il est néanmoins contenu dans un cône de demi-angle au sommet de 30◦
.1.4. Analyse du geste chirurgical 19
FIGURE 1.11 – Axe de la sonde lors de biopsies successives dans un repère lié à la prostate
pour deux patients. En haut : 1er cas, un seul faisceau. En bas : 2ieme cas, deux faisceaux.20 Chapitre 1. La robotique dans le diagnostic du cancer de la prostate
Écart de position Écart d’orientation
du transducteur (mm) de la sonde (◦)
Minimum 5,0 12,2
Premier décile 7,1 16,7
Médiane 9,0 21,7
Neuvième décile 12,2 26,1
Maximum 20,6 30,2
Moyenne 9,2 21,4
TABLEAU 1.1 – Écart de position et d’orientation de la sonde par rapport à sa position
moyenne dans le repère lié à la prostate.
1.4.2.3 Surface de la capsule prostatique ponctionnée
Nous avons également utilisé les données issues de l’UroStation pour calculer la
surface ponctionnée dans chaque lobe prostatique. Cette surface est définie de la façon
schématisée en figure 1.12 . Le barycentre Ebar des points d’entrée Ei de l’aiguille
dans le lobe prostatique est déterminé, ainsi que la position du plan PE qui minimise
la distance au carré des points Ei au plan PE. Le point Ebar est ensuite déplacé
perpendiculairement au plan PE vers l’extérieur de la prostate, de la distance entre le
plan PE et le point Ei qui en est le plus en avant, de façon à tenir compte au moins en
partie du bombé de la prostate. Ensuite, la surface de chaque triangle formé par Ebar et
deux points Ei consécutifs est calculée. La somme de ces surfaces est une estimation de la
surface ponctionnée dans le lobe considéré. Les valeurs obtenues pour chaque patient et
chaque lobe sont présentées sur la figure 1.13 en fonction du volume prostatique du patient.
FIGURE 1.12 – Définition de la surface percée dans un lobe.
Il apparaît que les surfaces de ponction sont variables d’un patient à l’autre mais
semblent être corrélées avec le volume prostatique, ce qui est logique. La surface de
ponction moyenne est de l’ordre de 1 cm2 seulement. On observe également que la surface1.4. Analyse du geste chirurgical 21
FIGURE 1.13 – Surface percée dans chacun des lobes prostatiques en fonction du volume
de la glande. Gris foncé : lobe droit. Gris clair : lobe gauche.
ponctionnée dans le lobe gauche est en moyenne plus importante que celle percée dans le
lobe droit.
Or il existe effectivement une dissymétrie du geste médical : durant la réalisation
des biopsies dans le lobe droit le guide-aiguille se situe sur le dessus de la sonde
échographique, tandis qu’il se trouve en-dessous de la sonde échographique lorsque le
chirurgien travaille sur le lobe gauche. Il en résulte une position moins confortable pour
l’urologue lorsqu’il biopsie le lobe gauche. On pourrait s’attendre à ce que cet inconfort
se traduise par une surface de ponction moins importante dans le lobe gauche que dans le
lobe droit puisque les mouvements semblent gênés. Mais il semblerait que cette mauvaise
position lors des ponctions dans le lobe gauche conduise à une sous-estimation par le
chirurgien de ses propres mouvements et donc à une surface de ponction plus grande dans
le lobe gauche que dans le lobe droit.
1.4.3 Conséquences sur le diagnostic
Une variabilité non négligeable de la surface prostatique ponctionnée selon le patient et
le lobe biopsié (gauche ou droit) est apparue. Une étude a alors été menée pour déterminer,
en combinant ces données avec les résultats des analyses anatomopathologiques, si ces
différences de géométrie ont un impact sur le diagnostic final posé par l’urologue. Elle
a porté sur 158 patients, âgés de 64 ans en moyenne, chez qui un cancer de la prostate
a été diagnostiqué grâce à un examen sous UroStation durant lequel six biopsies ont été
réalisées dans chaque lobe.
L’histogramme présenté en figure 1.14 montre pour chaque lobe l’évolution du taux de22 Chapitre 1. La robotique dans le diagnostic du cancer de la prostate
FIGURE 1.14 – Taux de détection de cancer et surface biopsiée pour chacun des lobes en
fonction du volume prostatique.
détection de cancer (pourcentage de patients dont au moins l’un des échantillons biopsiés
dans ce lobe présente des cellules cancéreuses) et de la surface biopsiée (comme définie
précédemment) en fonction du volume prostatique. On constate tout d’abord que le taux
de détection chute lorsque le volume prostatique augmente, ce qui est logique puisque le
volume de tissu prélevé est constant donc la proportion de volume prélevé évolue de façon
inversement proportionnelle à la taille de la prostate.
On note également qu’au moins une des biopsies effectuées dans le lobe droit
présentait des cellules cancéreuses pour 29,1% des patients inclus dans l’étude (tous
volumes prostatiques confondus), tandis que pour le lobe gauche ce taux est de 40,5%.
Or il n’y a aucune raison anatomique connue pouvant expliquer une dissymétrie de la
répartition des tumeurs prostatiques à l’échelle d’une telle cohorte de sujets. Cette disparité
dans le taux de détection de cancer entre le lobe droit et le lobe gauche est donc bien liée à
l’examen. Cela pourrait être dû à la dissymétrie du geste de ponction entre les lobes droit
et gauche, ou encore à la fatigue puisque les urologues qui ont réalisé les biopsies prises
en compte dans cette étude ponctionnent toujours le lobe droit en premier, puis le lobe
gauche. Le diagnostic posé par l’urologue à l’issue d’une séance de biopsies prostatiques
classique est donc biaisé.
Nous avons ainsi montré que la dissymétrie des surfaces ponctionnées dans chacun
des lobes prostatiques conduisait à une erreur, ou tout du moins une imprécision, sur1.5. Conclusion 23
le diagnostic posé : les tumeurs localisées dans le lobe gauche sont statistiquement
plus souvent détectées que celles situées dans le lobe droit. Ainsi, une séance « type »
de biopsies prostatiques fournit à l’urologue une information biaisée ; les décisions
thérapeutiques prises à la suite de cet examen seront basées sur une vision faussée de la
présence et de la répartition de cellules cancéreuses dans les deux lobes prostatiques. Outre
le fait que cette dissymétrie dans la détection des tumeurs puisse mener à des décisions
thérapeutiques n’étant pas les plus appropriées, elle empêche de plus d’avancer vers des
traitements locaux du cancer prostatique pourtant plus intéressants en terme de sauvegarde
des tissus sains et de réduction des effets secondaires.
1.5 Conclusion
La qualité de réalisation des biopsies prostatiques est d’une importance capitale en
terme de santé publique puisque cet examen débouche sur un diagnostic et sert de base
à la prise de décisions thérapeutiques. Or il s’agit d’un geste complexe et contraignant,
du fait des nombreux phénomènes perturbateurs qui interviennent (mouvements de la
prostate, mouvements du patient, positions inconfortables pour le praticien) et de la basse
qualité des informations fournies à l’urologue (pas d’information tactile, image temps
réel ne permettant pas de visualiser les lésions, qualité de l’image 3D dégradée par les
mouvements cités précédemment). De plus nous avons montré que, malgré l’utilisation
d’un outil d’aide à la visualisation des biopsies, l’examen présente une dissymétrie
géométrique. Celle-ci coïncide avec une différence statistique dans les taux de détections
de cellules cancéreuses en fonction du lobe dans lequel elles sont situées, ce qui crée un
biais dans le diagnostic sur lequel sont ensuite basées les décisions thérapeutiques.
Il apparait donc qu’une assistance robotique pourrait améliorer la réalisation de
biopsies prostatiques, en ce sens qu’elle pourrait permettre de mieux maîtriser la
répartition des biopsies mais aussi de faciliter la navigation dans la prostate et même
de soulager physiquement le praticien. En effet si la sonde échographique est liée à
l’organe terminal d’un robot alors il est possible d’exploiter les atouts classiques d’un tel
système : force, endurance, répétabilité, précision, navigation, enregistrement de données
quantitatives.
Dans le prochain chapitre, nous allons détailler la conception d’un tel robot qui est
forcément impactée par son cadre de travail particulier : au contact direct avec deux
humains. Nous déterminerons également les types d’assistance que le système ainsi conçu
est susceptible d’offrir au praticien, avec les problématiques robotiques que cela implique
d’adresser.Chapitre 2
Conception d’un système robotique
d’assistance à la biopsie de prostate :
Apollo
Sommaire
2.1 Analyse des dispositifs existants . . . . . . . . . . . . . . . . . . . . . . 25
2.1.1 Imagerie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.1.2 Voie d’abord . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.1.3 Cinématique du robot . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.1.4 Degré d’autonomie du robot . . . . . . . . . . . . . . . . . . . . . 30
2.2 Cinématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3 Distribution des actionneurs . . . . . . . . . . . . . . . . . . . . . . . . 36
2.4 Différentes fonctions d’assistance . . . . . . . . . . . . . . . . . . . . . . 40
2.4.1 Mode libre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.4.2 Mode verrouillé . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.4.3 Assistance par retour d’effort . . . . . . . . . . . . . . . . . . . . . 41
2.4.4 Déplacement fin par retour échographique . . . . . . . . . . . . . . 42
2.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.1 Analyse des dispositifs existants
La robotique pourrait constituer un apport intéressant et à fort impact pour l’assistance
à la biopsie prostatique. De plus, la brachythérapie présente des problématiques similaires
pour la robotisation puisqu’il s’agit également de maîtriser l’insertion d’une aiguille dans
la prostate d’un patient.26
Chapitre 2. Conception d’un système robotique d’assistance à la biopsie de
prostate : Apollo
En plus d’améliorer la qualité du diagnostic, connaître précisément la géométrie des
biopsies permettrait en cas de cancer prostatique avéré de se tourner vers des traitements
locaux : seuls les sites où des cellules cancéreuses ont été détectées seraient traités,
épargnant ainsi les tissus sains. Ce geste thérapeutique local pourrait prendre différentes
formes : irradiation localisée à l’aide de grains radioactifs, destruction des cellules par
laser amené via une fibre optique logée dans une aiguille, apport de molécules capables
d’attaquer les cellules cancéreuses, cryothérapie... Ces techniques locales ont comme point
commun de nécessiter elles aussi le placement précis d’une aiguille dans la prostate, elles
pourraient donc être mises en œuvre avec le même système que les biopsies. Ainsi, si dans
nos travaux nous nous sommes placés plus spécifiquement dans le cadre du diagnostic du
cancer de la prostate, l’extension à la thérapie reste possible.
Du fait du grand intérêt et de l’important potentiel d’un système d’assistance à la
biopsie et/ou à la brachythérapie et/ou au traitement focal du cancer de la prostate, plusieurs
équipes de recherche se sont penchées sur la question. Un état de l’art exhaustif concernant
la biopsie et la brachythérapie est présenté dans [Hungr 2012]. Les systèmes robotiques qui
ont été proposés à ce jour diffèrent sur quatre critères principaux :
– la modalité d’imagerie,
– la voie d’abord,
– la cinématique du robot,
– le degré d’autonomie du robot.
2.1.1 Imagerie
Le premier critère permettant de classifier les systèmes robotiques proposés
dans la littérature est la modalité d’imagerie utilisée. En effet, la prostate n’étant ni
rigide ni fixe dans le corps du patient, il est nécessaire de contrôler sa géométrie
et sa position en temps réel. Pour cela, différents moyens d’imagerie peuvent être
utilisés : l’échographie [Bassan 2007, Bax 2011, Davies 2004, Fichtinger 2006,
Fichtinger 2008, Ho 2009, Hungr 2012, Phee 2005, Salcudean 2008, Schneider 2004,
Wei 2005, Yu 2007], le scanner [Fichtinger 2002] et l’imagerie par résonance
magnétique [Abdelaziz 2011, Chinzei 2000, Fischer 2008, Krieger 2011, Patriciu 2007,
Song 2010, van den Bosch 2010]. Comme on peut le voir sur la figure 2.1, les trois
modalités fournissent des images ayant des caractéristiques différentes : précision,
structures observables, durée d’acquisition, exposition aux rayonnements pour le patient et
le personnel hospitalier à proximité.
L’échographie permet d’obtenir soit des images bidimensionnelles en temps
réel (plan de coupe), soit des images tridimensionnelles à une fréquence de
l’ordre du dixième de Hertz, la scène observée devant être au maximum immobile
par rapport à la sonde échographique. Cette image 3D peut être obtenue soit à
l’aide d’une sonde 3D [Hungr 2012] (dans ce cas, c’est la barrette d’éléments
piézoélectriques située dans l’extrémité de la sonde qui pivote, le mouvement
étant géré par l’échographe), soit à l’aide d’une sonde 2D déplacée de façon2.1. Analyse des dispositifs existants 27
FIGURE 2.1 – Prostate vue sous différentes modalités d’imagerie : échographie à gauche,
IRM au milieu, scanner à droite (✇✇✇✳♦♥❝♦♣r♦❢✳♥❡t et ✇✇✇✳✉r♦❢r❛♥❝❡✳♦r❣).
incrémentale [Bassan 2007, Bax 2011, Davies 2004, Fichtinger 2006, Fichtinger 2008,
Ho 2009, Phee 2005, Salcudean 2008, Wei 2005, Yu 2007]. Dans les deux cas, une image
2D est enregistrée à chaque position (de la barrette d’éléments piézoélectriques dans la
sonde ou de la sonde dans le rectum du patient) puis un volume 3D est reconstruit à partir
de l’ensemble des images ainsi obtenues. L’avantage principal de l’échographie est que
les appareils sont déjà présents dans les cabinets d’urologie, puisqu’ils sont utilisés pour
les biopsies prostatiques en routine clinique, et relativement peu coûteux. Il est cependant
important de noter que les tumeurs ne sont pas visibles à l’échographie, puisque leur
échogénécité est généralement la même que celle du reste de la prostate. De plus l’image
échographique est de très mauvaise qualité : elle est très bruitée, de ce fait les structures
anatomiques peuvent être difficiles à distinguer.
L’IRM et le scanner permettent d’avoir des images plus nettes et plus précises, mais
à un coût bien plus élevé et une fréquence plus basse. Cela implique que le patient
doive rester le plus immobile possible durant l’acquisition, cette condition étant bien
plus complexe à remplir lorsque le patient est réveillé que lorsqu’il est placé sous
anesthésie générale. De plus, le scanner a un effet irradiant sur le patient comme sur le
praticien, ce qui limite son temps d’utilisation, tandis que pour sa part l’IRM impose
de prendre en compte la compatibilité magnétique, ce qui donne des contraintes lourdes
à prendre en compte lors de la conception de robots destinés à être utilisés dans son
enceinte [Fischer 2008, Song 2010].
Une autre faiblesse de l’IRM et du scanner en vue de la robotisation est que,
contrairement au cas de l’échographie, la ligne de visée de l’aiguille à biopsie n’est pas
connue dans le repère Ri
lié à l’image mais uniquement dans le repère Rb lié à la base
du robot. Ainsi, une phase de calibration est nécessaire pour déterminer la transformation
Tib permettant de passer du repère Ri au repère Rb. Le site à biopsier étant choisi dans
l’image, ses coordonnées dans le repère Ri sont connues et ses coordonnées dans le
repère Rb peuvent être calculées. Le robot a alors pour tâche de placer l’aiguille à cette
position. Or la prostate bouge et se déforme au cours de la procédure, sous l’influence de
nombreux paramètres : respiration, remplissage de la vessie, pression d’une éventuelle
sonde échographique (parfois utilisée en complément du scanner ou de l’IRM, afin d’avoir28
Chapitre 2. Conception d’un système robotique d’assistance à la biopsie de
prostate : Apollo
un retour visuel en temps réel), insertion de l’aiguille... Ainsi, la prostate a bougé durant
le temps qu’a mis le robot pour atteindre les coordonnées cibles dans le repère Rb et ces
dernières ne correspondent plus à la même zone physique de la prostate. Ainsi, il a été
montré par [Xu 2010] que le robot initialement présenté dans [Krieger 2005] ne pouvait
pas atteindre une précision satisfaisante de positionnement de l’aiguille à biopsie dans la
prostate si les mouvements par rapport à la base du robot et les déformations de la glande
n’étaient pas pris en compte.
Outres les avantages et inconvénients déjà présentés pour chacune des modalités
d’imagerie, il est important de prendre en compte le contexte médico-économique dans
lequel devra évoluer un robot d’assistance aux biopsies prostatiques. En effet l’échographe
est un appareil utilisé dans la pratique clinique actuelle, les cabinets d’urologie en sont
donc d’ors et déjà équipés. A l’inverse, le scanner et l’IRM sont des ressources coûteuses
et rares, souvent partagées entre plusieurs services hospitaliers et qui ne sont donc pas
aisément accessibles.
Pour toutes ces raisons, nous avons choisi de baser notre système sur une imagerie par
ultrasons.
2.1.2 Voie d’abord
La voie d’abord par laquelle on cherchera à atteindre la prostate avec une aiguille
constitue un deuxième critère de classification des systèmes robotiques proposés
dans la littérature : il est possible d’utiliser la voie transpérinéale [Abdelaziz 2011,
Bax 2011, Bassan 2007, Chinzei 2000, Davies 2004, Fichtinger 2002, Fichtinger 2006,
Fichtinger 2008, Fischer 2008, Heikkilä 2008, Ho 2009, Hungr 2012, Patriciu 2007,
Phee 2005, Podder 2007, Salcudean 2008, Song 2010, van den Bosch 2010, Yu 2007,
Wei 2005] ou la voie transrectale [Krieger 2011, Schneider 2004], comme illustré par la
figure 2.2.
Comme nous l’avons vu au chapitre 1, lors d’une série de biopsies prostatiques
classique (c’est-à-dire non robotisée) la voie transrectale est généralement préférée. Seule
une anesthésie locale de la paroi du rectum est réalisée en début d’examen. Ainsi, le
patient est réveillé et peut bouger. Dans ce cas, l’urologue utilise généralement une sonde
échographique endorectale sur laquelle est fixée un guide-aiguille, l’aiguille à biopsie
étant glissée dans ce dernier. L’aiguille est non biseautée et de diamètre important (18
gauges, soit environ 1 mm). Sa déformation lors de la biopsie peut ainsi être considérée
comme négligeable et sa ligne de visée correspond à l’axe du guide-aiguille. Elle est fixe
dans l’image échographique, ce qui permet à l’urologue de cibler le site de ponction de
son choix en positionnant la sonde.
En revanche, lors d’une séance de brachythérapie, la voie transpérinéale est
préférée. Certains auteurs proposent d’utiliser cet abord pour la réalisation des biopsies2.1. Analyse des dispositifs existants 29
FIGURE 2.2 – Voies d’abord possibles pour la biopsie de prostate : voie transrectale et voie
transpérinéale.
prostatiques [Song 2010], mais cela pose plusieurs problèmes : la procédure est plus
longue et le patient doit être placé sous anesthésie générale. Cette dernière condition n’est
pas compatible avec les contraintes médico-économiques que nous avons déjà évoquées au
chapitre 1 et accroit les risques pour le patient. En revanche, cet abord permet l’insertion
simultanée de plusieurs aiguilles.
Notre système d’assistance aux biopsies prostatiques devra donc utiliser la voie
transrectale, le guide-aiguille étant fixé sur la sonde échographique endorectale, car cela
est non seulement compatible avec la pratique clinique actuelle mais permet également
de limiter la complexité du système à développer puisque imageur (sonde échographique)
et instrument effecteur (ligne de visée de l’aiguille à biopsie, matérialisée par le guideaiguille)
sont rigidement liés.
2.1.3 Cinématique du robot
Pour placer l’extrémité d’une aiguille à une position et dans une orientation données
seuls 5 degrés de liberté (ddl) sont nécessaires, puisque la rotation de l’aiguille autour
de son axe n’a pas d’impact sur la tâche de positionnement. Néanmoins, certains auteurs
choisissent de motoriser la rotation de l’aiguille autour de son axe afin d’améliorer sa
pénétration à travers le périnée [Bassan 2007, Hungr 2012, Podder 2007, Yu 2007] (la
pénétration d’une aiguille dans la paroi rectale étant plus aisée).
Lorsque la voie transrectale est choisie, l’anus joue le rôle d’une contrainte cinématique
à 2 degrés de liberté type linéaire-annulaire : la sonde (à laquelle le guide-aiguille donc
la ligne de visée de l’aiguille à biopsie sont rigidement liés) peut pivoter dans toutes les
directions et translater selon son axe. La tâche présente alors 4 degrés de liberté.
Ceci a poussé plusieurs auteurs à concevoir des systèmes présentant un centre de30
Chapitre 2. Conception d’un système robotique d’assistance à la biopsie de
prostate : Apollo
rotation déporté, ou « remote center of motion » (RCM) [Wei 2005] : du fait de la
géométrie du robot son effecteur, ici la sonde, passe forcément par un point fixe dans
le repère Rb lié à sa base. Le principal intérêt d’une telle approche est que le robot ne
doit posséder que 4 degrés de liberté, ce qui réduit son coût total. En contrepartie, toute
intervention devra commencer par une phase de mise en place pour faire coïncider l’anus
du patient et le RCM du robot. Celle-ci peut être longue, fastidieuse et peut poser problème
dans le cas où le patient est sous anesthésie locale uniquement : en effet, celui-ci peut alors
se déplacer consciemment ou non par rapport à la base du robot, ce qui non seulement
impose de recommencer l’étape d’installation mais surtout peut occasionner des blessures
pour le patient.
De plus il apparait en pratique clinique que les chirurgiens utilisent parfois l’élasticité
de l’anus pour atteindre certaines cibles de biopsies avec ce qu’ils jugent être la bonne
orientation de la sonde [Torterotot 2010]. Dans ce cas, formellement, la contrainte
cinématique n’est plus respectée. Ainsi, utiliser un RCM limite l’espace de travail de
la sonde échographique par rapport à une manipulation humaine, ce qui peut empêcher
d’atteindre avec le robot certaines configurations de biopsie voulues par le praticien.
Ainsi il nous parait intéressant de développer un robot présentant 6 degrés de liberté.
Outre le fait qu’un tel système n’impose pas de suivre une procédure lourde de mise en
place, cela permettra à l’urologue de bénéficier de sa liberté de mouvement habituelle
lorsque cela s’avère nécessaire mais également d’assurer la sécurité du patient en
n’imposant aucune contrainte de coïncidence géométrique.
2.1.4 Degré d’autonomie du robot
Les systèmes proposés dans la littérature diffèrent également par leur degré
d’autonomie. Certains systèmes sont entièrement autonomes : ils positionnent le guideaiguille
de façon à ce que la ligne de visée de l’aiguille à biopsie soit celle qui est
désirée, puis insèrent eux-même l’aiguille dans la prostate [Davies 2004, Bassan 2007,
Fichtinger 2006, Hungr 2012, Patriciu 2007, Yu 2007]. Ce mode de robotisation s’avère
intéressant dans le cas où le système est basé sur un scanner, puisque cela permet à
l’urologue de se tenir loin de l’appareil et donc de limiter son exposition aux radiations.
D’autres robots sont des comanipulateurs, qui partagent la réalisation du geste avec le
chirurgien. La répartition des tâches est généralement séquentielle : le robot place le guideaiguille
à la position désirée, puis le chirurgien réalise l’acte médical proprement dit en
manipulant l’aiguille à la main [Abdelaziz 2011, Bax 2011, Chinzei 2000, Fichtinger 2002,
Fichtinger 2008, Fischer 2008, Schneider 2004, Salcudean 2008, Song 2010, Wei 2005].
Sur certains systèmes, le robot limite néanmoins la manipulation manuelle de l’aiguille
en bloquant cette dernière lorsque la profondeur d’insertion prévue par le logiciel de
commande est atteinte [Ho 2009, Phee 2005].2.1. Analyse des dispositifs existants 31
La première limitation de ces systèmes vient de leur commande. Elle peut être calculée
soit en temps réel, soit une fois pour toute sous forme de trajectoire donnée dans le repère
Rb lié à la base du robot. La première solution impose d’être capable de traiter des images
à très haute vitesse, en supposant que celles-ci sont fournies à une cadence suffisante. A
l’heure actuelle, aucun système ne présente ces capacités. Dans le deuxième cas, le calcul
des déplacements du robot doit se faire à partir d’une unique image puis d’un modèle qui
devrait idéalement prendre en compte de très nombreux paramètres pouvant varier dans le
temps même si le patient est sous anesthésie générale : anatomie (géométrie) du patient,
raideur des différents organes entrant en jeu, déplacements et déformations cycliques
dûs à la respiration, contraintes géométriques liées au point d’insertion de l’aiguille
et/ou de l’imageur dans le corps du patient, etc. Or de telles données sont difficiles voire
impossibles à obtenir à l’heure actuelle et, sans au moins une partie d’entre elles, la
précision requise pour que le positionnement de l’aiguille soit acceptable peut ne pas être
atteinte [Xu 2010].
De plus ces deux types de systèmes ne sont pas utilisables sur un patient qui n’est pas
endormi, pour des raisons évidentes de sécurité mais aussi d’acceptabilité pour le patient
(voir figure 2.3). Or, comme nous l’avons vu au chapitre précédent, l’anesthésie générale
est pour la majorité des patients à la fois inutilement risquée et incompatible avec les
contraintes médico-économiques liées aux biopsies prostatiques.
FIGURE 2.3 – Dessin issu de « Quino-thérapie » par Quino (ISBN : 2.7234.0520.6, éditions
Glénat).
Nous avons donc choisi de développer un robot comanipulé ou « cobot » qui ne
fonctionnera en mode « automatique » que dans certaines conditions dans lesquelles
le système est capable d’assurer la sécurité du patient, à savoir maintien en position
de la sonde vers une cible et petits déplacements. Il est à noter que le fait de limiter32
Chapitre 2. Conception d’un système robotique d’assistance à la biopsie de
prostate : Apollo
les mouvements automatiques à ces deux seuls cas nous permettra de choisir des
actionneurs moins nombreux et/ou moins compliqués que si le robot avait dû être
totalement automatique et capable de générer seul de grands déplacements. Le reste du
temps, l’urologue et le robot tiendront tous les deux la sonde échographique endorectale
et travailleront ensemble. Une combinaison particulière de choix de conception et de
réglages de commande permettront d’assurer à tout moment la sécurité du patient.
2.2 Cinématique
Comme nous l’avons vu dans la section 2.1, nous cherchons à concevoir
un robot présentant 6 degrés de liberté capable de comanipuler une sonde
échographique endorectale fixée à son effecteur. De nombreuses cinématiques sont
alors envisageables [Smith-Guerin 2008], le choix devant être fait en fonction de l’espace
de travail voulu, de l’encombrement acceptable, des efforts en jeu ainsi que de la précision
attendue.
Nous avons montré dans la section 1.4.2.2 que l’espace de travail de la sonde est un
cône de demi-angle au sommet de 30◦
, représenté sur la figure 2.4. La rotation de la sonde
autour de son axe doit être possible sur un angle de l’ordre de 300◦
environ, la position
moyenne du guide-aiguille durant les biopsies du lobe gauche étant diamétralement
opposée à sa position moyenne durant les biopsies du lobe droit (au-dessus ou en-dessous
de la sonde).
FIGURE 2.4 – Espace de travail de la sonde montée sur Apollo.
Un robot, appelé Apollo, a été conçu de façon à autoriser cet espace de travail lorsque
sa base est placée sur le lit d’examen, à une quarantaine de centimètres environ du point
d’insertion de la sonde dans le patient (par exemple dans le creux des genoux du patient2.2. Cinématique 33
FIGURE 2.5 – Exemple de positionnement du robot Apollo pour la réalisation de biopsies
prostatiques
FIGURE 2.6 – Apollo34
Chapitre 2. Conception d’un système robotique d’assistance à la biopsie de
prostate : Apollo
placé en décubitus latéral, comme on peut le voir sur la figure 2.5). Comme on peut
le voir sur la figure 2.6, il est composé de six pivots assemblés selon une géométrie
anthropomorphique :
– les deux premiers pivots, l’axe du premier étant vertical et celui du suivant étant
horizontal, constituent une épaule ;
– le troisième pivot, dont l’axe est parallèle à celui du deuxième, correspond au coude
du robot ;
– les trois derniers pivots, dont les axes sont concourants en un unique point P, forment
le poignet du robot.
La géométrie d’Apollo est décrite en suivant la convention de Denavit et
Hartenberg [Denavit 1955], les paramètres sont résumés dans la table 2.2 et les liaisons
correspondantes sont représentées sur la figure 2.7.
i αi−1 ai−1 di θi
1 0 0 0 θ1
2 −π/2 0 0 θ2
3 0 0,25 m 0 θ3
4 π/2 0 0,30 m θ4
5 −π/4 0 0 θ5
6 π/2 0 0 θ6
TABLEAU 2.1 – Paramètres de Denavit et Hartenberg du cobot Apollo.
FIGURE 2.7 – Schéma cinématique d’Apollo.
Il est à noter que les variables θ2 et θ3 ne sont pas directement accessibles par
les capteurs du robot. Les axes 2 et 3 sont en réalité deux sommets opposés d’un
parallélogramme déformable que l’on peut voir sortir du capot sur la figure 2.6, les
moteurs étant montés sur deux articulations successives du parallélogramme (celles qui
sont situées au plus proche de la base, cachées par le capot). Les codeurs montés sur les
axes moteurs donnent donc les angles moteurs θm2 et θm3, qui permettent de calculer les2.2. Cinématique 35
angles articulaires θ2 et θ3 comme suit :
θ2 = θm2 (2.1)
θ3 = π −θm3 (2.2)
Le dernier segment est conçu de manière à présenter un trou cylindrique de 8 cm de
diamètre dont l’axe coïncide avec celui de la dernière liaison. Ainsi, n’importe quelle
sonde échographique peut être connectée à l’extrémité d’Apollo à l’aide d’une pièce
d’interface propre à la sonde. La fixation de la pièce d’interface au robot se fait à l’aide de
couples trous/picots métalliques (pour la mise en position) et d’aimants (pour le maintien
en contact) visibles sur la figure 2.8. Grâce à ce système, Apollo peut être utilisé avec
différentes sondes échographiques sans devoir être entièrement reconçu.
FIGURE 2.8 – Système de fixation de la sonde échographique endorectale sur le robot
Apollo, avec la première version des pièces d’interface.
Nous disposons d’une sonde échographique endorectale 4DEC9-5/10STI de la société
Ultrasonix, pour laquelle nous avons conçu une pièce d’interface qui a été fabriquée en
prototypage rapide. Comme on peut le voir sur la figure 2.8, cette interface est constituée
de deux pièces comprenant chacune une demi-empreinte de la sonde. Ces deux pièces sont
fixées autour de la sonde grâce à deux vis de serrage. Dans une première version, un trou a
été ménagé face à l’entrée du guide-aiguille, afin de permettre l’insertion de l’aiguille. Une
deuxième version de cette pièce, que l’on peut voir sur la figure 2.9, a été dessinée par la36
Chapitre 2. Conception d’un système robotique d’assistance à la biopsie de
prostate : Apollo
FIGURE 2.9 – Deuxième version des pièces d’interface montée sur la sonde échographique
endorectale.
suite pour permettre une protection efficace lors d’un futur essai clinique : cette nouvelle
pièce d’interface permet en effet de placer une protection type préservatif entre la sonde
échographique endorectale et le guide-aiguille.
2.3 Distribution des actionneurs
Nous appellerons mode libre le mode dans lequel le robot est « suiveur », c’est-à-
dire qu’il laisse entièrement le contrôle des mouvements de la sonde à l’utilisateur. Ce
mode pourrait être réalisable sans actionneur, mais Apollo doit également être capable
d’appliquer sur la sonde échographique endorectale des efforts afin de la maintenir à une
position décidée par l’urologue (la position de la sonde au moment où l’urologue déclenche
ce mode, que nous appellerons mode verrouillé). En robotique, il existe classiquement deux
façons d’atteindre un tel but :
– utiliser un moteur électrique asservi en position avec un fort gain (ce qui génère une
raideur importante),
– utiliser des freins électromagnétiques (dont la raideur est infinie tant qu’il n’y a pas
de glissement).
Les freins électromagnétiques présentent un rapport couple résistant/masse plus
important que les moteurs électriques. Ils sont également moins chers et leur commande
est plus facile à mettre en œuvre. Ils présentent néanmoins un inconvénient majeur :
ils n’offrent que très peu de possibilités de commande. En effet ils fonctionnent sur un
mode « tout ou rien » : les freins sont soit bloqués (ils présentent alors une raideur infinie
tant que le couple résisitif maximal n’est pas atteint) soit libres (ce qui correspond à une
raideur nulle), aucun intermédiaire n’est possible. Ainsi, si tous les axes d’Apollo étaient
équipés de freins, il ne serait pas possible d’exercer des efforts contrôlés sur la sonde
échographique endorectale.2.3. Distribution des actionneurs 37
De plus, une fois que l’urologue a positionné la sonde comme il le souhaitait et
actionné le mode verrouillé, il relâche la sonde. Toutes les forces externes que l’urologue
compensait jusque là en mode libre, à savoir le poids de la sonde et les efforts de contact
exercés par le patient sur la sonde, agissent alors comme des perturbations pour le robot.
Si la raideur du robot pourvu de freins n’est pas infinie, cela va conduire à un déplacement
de la ligne de visée de l’aiguille à biopsie. Or augmenter la raideur de la structure du
robot et des freins signifie limiter la déformation des pièces mécaniques et augmenter
la puissance des freins, ce qui implique d’augmenter la masse du système. Ceci va à
l’encontre du besoin de transparence, qui est crucial en mode libre (nous reviendrons en
détail sur ce point dans le chapitre suivant, section 3.1). À cela il faut ajouter qu’un robot
qui présenterait une raideur importante serait dangereux pour le patient : si ce dernier
bouge tandis que le robot présente une raideur élevée, alors il peut être blessé.
Pour choisir les actionneurs équipant les six axes d’Apollo, plusieurs éléments ont donc
dû être pris en considération :
– la masse du robot doit être minimisée afin de faciliter sa manipulation en mode libre,
– le prix du robot doit rester le plus bas possible afin de permettre son transfert vers un
usage clinique,
– la raideur du robot doit pouvoir être modulée durant les phases de verrouillage afin
de ne pas blesser le patient, qui est sous anesthésie locale uniquement et peut donc
bouger pendant que le robot maintient la sonde en position.
Si les deux premières contraintes vont dans le sens des freins, la troisième impose
l’utilisation de moteurs. Afin d’obtenir le meilleur compromis possible, un mode
d’actionnement hybride a finalement été choisi.
Les trois premiers pivots sont équipés de moteurs électriques Maxon RE35, afin de
pouvoir générer un comportement élastique de raideur contrôlable au centre P du poignet.
Pour assurer une bonne maniabilité en mode libre, les forces d’inerties et les forces
résistives doivent être minimisées. Les moteurs sont donc placés au plus près de la base
du robot. Ainsi, non seulement ils génèrent moins d’effets inertiels, mais ils n’auront
pas à être portés par les segments du robot (le « bras » situé entre les axes 2 et 3 et
l’« avant-bras » qui lie les axes 3 et 4). De ce fait, le bras et l’avant-bras pourront être plus
légers, ce qui participera aussi à la réduction de l’inertie du robot. C’est pour cette raison
que le bras est en réalité un parallélogramme, comme nous l’avons vu précédemment. Les
moteurs étant déportés près de la base du robot, il est nécessaire d’utiliser une transmission
pour exercer les couples voulus au niveau des axes ; le choix d’un système à câble limite
les frottements. Chaque moteur est équipé d’un codeur optique, ce qui permet de mesurer
la position articulaire de chacun des trois premiers axes.
Les trois axes du poignet sont en revanche équipés de freins Kebco 01.P1.300, ce qui
restreint la masse et le coût du robot. Un potentiomètre est monté sur l’axe de chacun
des freins, donnant ainsi accès aux positions articulaires des axes correspondants. Si
la conception des axes 4 et 5 ne pose pas de problème particulier (les freins, qui sont38
Chapitre 2. Conception d’un système robotique d’assistance à la biopsie de
prostate : Apollo
traversants, peuvent être montés directement sur les axes), il n’en va pas de même pour
l’axe 6. En effet, celui-ci devant comporter un trou cylindrique de 8 cm centré sur l’axe
de la liaison pour permettre le montage de la sonde sur le robot, le frein ne peut être
placé directement sur cet axe. Il a été choisi d’utiliser une transmission par engrenage :
une couronne dentée a été fixée sur l’anneau dans lequel viendra se monter la pièce
d’interface sonde/robot tandis que le corps du frein est monté sur le segment liant les
axes 5 et 6 et une deuxième roue dentée est fixée sur l’axe traversant le frein. Le ratio
des nombres de dents étant de 4,5, un potentiomètre multitours a été choisi pour équiper
l’axe 6, permettant de couvrir la plage de rotation autorisée par les butées (environ
350◦
). Les freins sont commandés de façon binaire : ils sont soit alimentés, auquel
cas il sont libres et n’empêchent pas la rotation de l’axe sur lequel ils sont montés ; soit
non alimentés, auquel cas il sont bloqués. Tous ces éléments sont visibles sur la figure 2.10.
FIGURE 2.10 – Gros plan sur le poignet d’Apollo.
La présence de ces freins constitue une sécurité supplémentaire pour le patient. En
effet, lorsque les freins sont relâchés, Apollo peut uniquement exercer sur la sonde une
force au centre P du poignet, point autour duquel la sonde pivote librement. Ainsi le robot,
ne pouvant exercer de couple sur la sonde au point P, ne peut générer d’effort sur l’anus du
patient via la sonde. Les risques d’occasionner des blessures en cas de dysfonctionnement
sont donc réduits.
Le robot a été fabriqué par la société Haption [Hap ], spécialisée dans la conception
d’interfaces haptiques puissantes (utilisant notamment des transmissions à câbles).
Les trois premiers axes d’Apollo sont identiques à ceux du Virtuose3D, tandis que
les 3 derniers axes ont été fabriqués à partir de notre conception. Les caractéristiques
d’actionnement axe par axe sont résumées dans la table 2.3. Les moteurs des trois premiers
axes permettent de générer au centre P du poignet un effort continu de 5 N et un effort pic
de 15 N.2.3. Distribution des actionneurs 39
Axe Actionneur Transmission Rapport Couple maximal
1 moteur câble 21,6 3,4 Nm
2 moteur câble 14,9 2,4 Nm
3 moteur câble 14,8 2,3 Nm
4 frein directe 1 0,4 Nm
5 frein directe 1 0,4 Nm
6 frein engrenage 4,5 1,8 Nm
TABLEAU 2.2 – Caractéristiques d’actionnement d’Apollo axe par axe.
FIGURE 2.11 – Éléments mécaniques améliorant la transparence du robot Apollo.40
Chapitre 2. Conception d’un système robotique d’assistance à la biopsie de
prostate : Apollo
Les masses des différentes pièces ont été réparties de façon à ce que la gravité ne génère
pas de moment sur les axes. Pour cela, deux stratégies ont été utilisées :
– un contrepoids a été monté sur l’axe 4 d’Apollo, voir figure 2.11, cette solution
présentant néanmoins l’inconvénient d’ajouter à la masse embarquée du système ;
– des ressorts ont été montés sur les axes 2 et 3 d’Apollo, voir figure 2.11.
Notons que les ressorts montés sur les axes 2 et 3 compensent une part constante des effets
de la gravité correspondant à peu près au poids des pièces non-démontables (ni la sonde ni
sa pièce d’interface ne sont concernées). Cela permet d’éviter les soucis au démontage de
la sonde : si le poids de la sonde et de son interface était compensé par les ressorts, lors de
leur décrochage le poignet du robot monterait brusquement et risquerait de venir frapper
l’utilisateur au visage.
Notons que les couples articulaires que peut générer Apollo sont relativement faibles,
ce qui constitue une sécurité intéressante pour un robot travaillant au contact de deux
humains : en cas de problème, il sera aisé pour l’urologue de forcer (à la main) les
mouvements du robot.
Les moteurs électriques sont contrôlés au bas niveau par une boucle de courant. Grâce
à cette dernière, il est possible de commander les moteurs directement en effort.
2.4 Différentes fonctions d’assistance
Nous disposons donc d’un robot capable de bloquer l’orientation de la sonde
échographique endorectale par rapport à son avant-bras ou, au contraire, de la laisser libre
de pivoter selon les trois directions autour du centre P de son poignet. Apollo est également
capable d’exercer une force contrôlée en ce point P. Ces capacités vont nous permettre de
nous intéresser à trois tâches ou types de tâches :
– laisser l’urologue libre de manipuler la sonde comme il le souhaite, sans qu’il ne
ressente la présence du robot ;
– verrouiller la positon de la sonde, c’est-à-dire maintenir la sonde en position tout en
garantissant la sécurité du patient, sans l’aide de l’urologue ;
– assister l’urologue dans le positionnement de la sonde par rapport à la prostate en
mode libre en y ajoutant un retour d’effort.
2.4.1 Mode libre
Comme nous l’avons vu précédemment à la section 2.1.4, planifier une trajectoire de
la sonde échographique endorectale que devra générer le robot est très complexe si l’on
doit prendre en compte les déformations et déplacements de la prostate, les mouvements
éventuels du patient, les contraintes anatomiques liées au rectum et à l’anus, la possibilité
de s’appuyer sur ces contraintes anatomiques sans atteindre le seuil de douleur du patient,
etc. En revanche, un urologue est lui capable d’intégrer toutes ces informations lorsqu’il
manipule la sonde. De plus, il possède un sens du toucher fin ainsi que des connaissances et2.4. Différentes fonctions d’assistance 41
compétences cognitives qui ne peuvent être mises en équation : connaissances médicales,
réactivité, adaptabilité, etc.
C’est pourquoi Apollo doit offrir un « mode libre », dans lequel il laisse la sonde
« aussi libre que possible », l’urologue contrôlant les mouvements de cette dernière. Nous
présenterons ce mode plus en détails dans le chapitre 3, section 3.1.
2.4.2 Mode verrouillé
Lorsque le système est en mode libre, l’urologue peut positionner manuellement la
sonde à l’endroit qui lui parait être adapté pour faire une biopsie. Comme nous l’avons vu
plus tôt, le chirurgien cherche alors à rester le plus immobile possible au moins le temps
d’effectuer la biopsie proprement dite. Il peut également, s’il dispose d’une UroStation
(voir section 1.3), faire une biopsie test puis soit effectuer la biopsie réelle si la localisation
simulée lui convient, soit corriger sa position si nécessaire. Dans les deux cas, il est
important que la sonde soit immobile dès le lancement de l’acquisition 3D (qui permettra
de calculer l’emplacement de la biopsie virtuelle dans un repère lié à la prostate) et jusqu’à
la biopsie ou la réalisation d’un petit déplacement de la sonde. Or un maintien en position
parfait est très difficile à obtenir à la main.
C’est pourquoi Apollo doit pouvoir présenter un « mode verrouillé », durant lequel
le robot maintient précisément la sonde en position tandis que l’urologue a les mains
libres pour effectuer d’autres tâches (manipulation de l’échographe, de l’UroStation et du
pistolet à biopsie notamment). Cette tâche est double : le robot doit à la fois assurer un
positionnement précis de la sonde échographique endorectale et garantir la sécurité du
patient, qui n’est pas endormi. Il doit donc être à la fois précis et souple, deux contraintes
classiquement antagonistes en robotique. Nous avons vu dans la section 2.3 comment le
choix des actionneurs d’Apollo permet de prendre en compte en partie ce problème, nous
verrons dans le chapitre 3, section 3.3 la commande qui a été développée pour le résoudre
complètement.
2.4.3 Assistance par retour d’effort
Si les modes précédents constituent déjà une amélioration potentiellement significative
de l’examen, aussi bien en terme de gestion de la répartition des biopsies qu’en terme de
confort pour le praticien, un système tel qu’Apollo pourrait être utilisé pour développer de
nombreuses autres fonctions d’assistance.
Il est notamment envisageable d’utiliser Apollo pour fournir à l’urologue un retour
d’effort via l’application de forces sur la sonde en mode libre, comme nous le verrons
au chapitre 4. Nous verrons dans un premier temps en section 4.1 que la génération d’un
retour d’effort à travers une contrainte anatomique peut avantageusement exploiter les
capacités de l’humain manipulant la sonde pour arriver à une commande nécessitant peu42
Chapitre 2. Conception d’un système robotique d’assistance à la biopsie de
prostate : Apollo
de ressources et présentant un haut niveau de sécurité pour le patient. Cette capacité
de génération d’un retour d’effort peut permettre de réaliser plusieurs fonctions, par
exemple un guidage virtuel ou une augmentation de la raideur apparente de la prostate. Le
développement de cette dernière fonction sera détaillé dans la section 4.2.
2.4.4 Déplacement fin par retour échographique
La fonction de verrouillage présentée précédemment souffre d’une faiblesse : ce mode
n’utilise que les capteurs du robot pour élaborer sa commande, ce qui signifie qu’Apollo
maintient la sonde fixe dans un repère Rb lié à sa propre base. Or la prostate n’est pas fixe
dans ce repère et la cible de biopsie est quant à elle fixe par rapport à la prostate. Ainsi, il
est possible que la précision du maintien de la ligne de visée de l’aiguille en direction de
la cible à biopsier en mode verrouillé ne soit pas satisfaisante dans le repère de la tâche.
Ainsi, si la réalisation de grands mouvements par le robot en autonomie est à proscrire
pour les raisons détaillées dans la section 2.1, il est possible d’utiliser Apollo pour
générer à partir du mode verrouillé de petits déplacements correctifs de la sonde calculés
à partir d’informations tirées de l’échographie. Ainsi, l’urologue pourrait effectuer un
positionnement aussi précis qu’il est humainement possible de le faire, puis le robot
pourrait effectuer une correction fine en se basant sur les données géométriques issues de
l’image. Ce mode de fonctionnement sera détaillé dans le chapitre 5.
2.5 Conclusion
Dans ce chapitre, nous avons analysé les différents robots dédiés au diagnostic et au
traitement du cancer de la prostate qui existent dans la littérature. Nous avons ensuite
présenté le robot Apollo, un comanipulateur de sonde échographique endorectale à 6
degrés de liberté présentant un actionnement hybride, et les raisons qui ont motivé les
différents choix de conception. Différentes fonctions que notre système pourrait offrir ont
été présentées dans la section 2.4, elles seront détaillées dans la suite de ce document.
Dans le chapitre 3, nous détaillerons les deux fonctions de base que sont le mode
libre (section 3.1) et le mode verrouillé (section 3.3) : le premier doit permettre une
manipulation de la sonde par l’urologue sans que le mouvement ne soit impacté par le
robot, tandis que le deuxième doit permettre un maintien en position de la sonde à la fois
précis et souple par le robot seul.
Le fait que notre système soit équipé de trois moteurs et capable d’exercer une force
maîtrisée au centre de son poignet nous permet de nous intéresser à différents types
d’assistance par comanipulation, que nous détaillerons dans le chapitre 4. Nous nous
intéresserons particulièrement à la méthodologie de génération de guides haptiques à2.5. Conclusion 43
travers une contrainte anatomique et à un exemple de retour haptique basé image.
Nous nous pencherons ensuite, dans le chapitre 5, sur la génération de déplacements
fins basés sur des informations issues de l’image échographique. Cette possibilité d’ajuster
la position de maintien de la sonde viendra renforcer le mode verrouillé pour aider
l’urologue à atteindre les cibles de son choix.Chapitre 3
Modes libre et verrouillé
Sommaire
3.1 Mode libre . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
3.1.1 Une caractéristique essentielle : la transparence . . . . . . . . . . . 46
3.1.2 Commande bas niveau . . . . . . . . . . . . . . . . . . . . . . . . 46
3.1.3 Commande du mode libre . . . . . . . . . . . . . . . . . . . . . . 49
3.2 Validation expérimentale du mode libre . . . . . . . . . . . . . . . . . . 49
3.2.1 Analyse de la transparence d’Apollo in vitro . . . . . . . . . . . . 49
3.2.2 Essais in cadavero . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.3 Mode verrouillé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.3.1 Souplesse et précision, deux contraintes antagonistes . . . . . . . . 58
3.3.2 Commandes développées . . . . . . . . . . . . . . . . . . . . . . . 60
3.4 Validation expérimentale du mode verrouillé . . . . . . . . . . . . . . . 69
3.4.1 Validation in vitro . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.4.2 Validation in cadavero . . . . . . . . . . . . . . . . . . . . . . . . 73
3.5 Essais cliniques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
3.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Nous avons présenté dans le chapitre précédent les raisons qui ont présidé à la
conception d’Apollo, un cobot d’assistance aux biospies prostatiques, dont nous avons
également défini les principaux modes de fonctionnement. Nous allons dans ce chapitre
détailler l’élaboration et la validation expérimentale des modes libre (ou « mode L ») et
verrouillé (ou « mode V »).
3.1 Mode libre
La première capacité que doit présenter notre système est de permettre une
manipulation de la sonde par le chirurgien qui soit naturelle. C’est cette aptitude que l’on46 Chapitre 3. Modes libre et verrouillé
appelle « transparence ».
3.1.1 Une caractéristique essentielle : la transparence
La transparence d’un robot est sa faculté à ne pas perturber le mouvement d’un
utilisateur qui manipule son effecteur [Troccaz 2012]. Ainsi une tâche à réaliser à l’aide
d’un outil sera effectuée de la même manière que l’utilisateur seul tienne l’outil ou que
ce dernier soit également fixé à l’extrémité distale d’un robot présentant une transparence
parfaite. Cela signifie que tous les paramètres de la tâche seront les mêmes, qu’ils soient
objectifs ou subjectifs : temps de réalisation de la tâche, qualité de réalisation de la tâche,
trajectoire de l’outil, efforts exercés par l’utilisateur sur l’outil, efforts exercés par l’outil
sur son environnement, etc, voir [Jarrasse 2008].
Pour offrir une transparence satisfaisante, un robot doit donc présenter plusieurs
caractéristiques qu’il convient de prendre en compte dès sa conception. Tout d’abord la
masse en mouvement doit être la plus faible possible, afin de limiter les effets d’inertie.
C’est pour cette raison que les bras d’Apollo ont été réalisés en carbone et que les
moteurs ont été déportés au niveau de sa base. Ajoutons au passage que réduire les masses
embarquées permet de limiter les efforts à générer en mode verrouillé et donc de diminuer
les efforts demandés aux moteurs. Comme on l’a vu à la section 2.3, Apollo a de plus été
conçu de façon à ce que la gravité ne génère pas de moment sur ses axes.
Un robot transparent doit également présenter une grande réversibilité, c’est-à-dire
qu’il doit être aisé de déplacer l’extrémité distale du robot à la main lorsqu’une commande
nulle est envoyée aux actionneurs. Les systèmes type vis-écrou ou engrenages multi-étages
ne présentent généralement pas cette caractéristique, c’est pourquoi la transmission entre
les moteurs et les axes d’Apollo est assurée par un système de câbles visibles sur la
figure 2.11.
3.1.2 Commande bas niveau
3.1.2.1 Transmission des vitesses et des efforts
Déterminer la commande d’Apollo revient à définir la force que le robot doit exercer
au centre P de son poignet. Afin de pouvoir effectivement contrôler le robot, il faut faire le
lien entre cet effort et les couples articulaires.
Le lien entre couples articulaires et effort généré au point P découle du modèle
cinématique du robot :
VP,s/b
ωs/b
=
Jv1,P 0
Jω1 Jω2
| {z }
JP
q˙ , (3.1)3.1. Mode libre 47
avec ˙q =
θ˙
1 ··· θ˙
6
T
le vecteur des vitesses articulaires, JP la matrice jacobienne
6×6 du robot au point P et Jv1,P, Jω1 et Jω2 des sous-matrices jacobiennes 3×3 exprimées
dans le repère Rb, VP,s/b
les composantes de la vitesse du point P par rapport à la base du
robot dans le repère Rb, ωs/b
les composantes du vecteur rotation de la sonde par rapport à
la base du robot dans le repère Rb. La sous-matrice supérieure droite nulle indique que les
vitesses articulaires des axes 4 à 6 n’ont aucun effet sur la vitesse du point P lié à la sonde
par rapport à la base du robot. Ceci découle du fait que ce point soit situé à l’intersection
des trois pivots constituant le poignet. Le robot étant équipé de butées, les singularités
cinématiques se situent en-dehors de son espace de travail. De ce fait, on peut considérer
que la matrice jacobienne JP est de rang plein.
Grâce à la dualité cinémato-statique, la matrice jacobienne définie dans l’équation 3.1
permet également de relier le torseur d’effort exercé par le robot sur la sonde au point P
aux couples articulaires τ =
τ1 ··· τ6
T
:
τ =
[τ1 τ2 τ3]
T
[τ4 τ5 τ6]
T
!
=
J
T
v1,P
J
T
ω1
0 J
T
ω2
| {z }
J
T
P
Fr→s
MP,r→s
, (3.2)
avec Fr→s
les composantes dans Rb de la force et MP,r→s
les composantes dans Rb du
moment appliqués par le robot sur la sonde au point P. Les axes 4 à 6 étant équipés
de freins, les couples articulaires τ4 à τ6 ne peuvent être modulés. Seuls pourront être
commandés les couples moteurs τmoteurs = [τ1 τ2 τ3]
T
.
On cherchera généralement à exprimer la commande sous la forme d’une somme :
τmoteurs = [τ1 τ2 τ3]
T = τcomp +τf onc , (3.3)
avec τcomp les couples articulaires des trois premiers axes compensant les effets de la gravité
et τf onc les couples articulaires des trois premiers axes permettant de réaliser la fonction
voulue (par exemple le maintien en position de la sonde).
3.1.2.2 Compensation du poids de la sonde
Réaliser la compensation des effets de la gravité n’est a priori pas absolument
nécessaire : l’urologue est habitué à manipuler la sonde à la main, donc à ressentir
son poids et son inertie. Néanmoins, il pourrait être intéressant de soulager le praticien
des effets de la pesanteur sur la sonde. Cela pourrait contribuer à son confort, et nous
chercherons à évaluer l’impact de cette compensation sur le geste proprement dit. Nous
allons donc dans un premier temps exprimer τcomp les couples articulaires des trois
premiers axes compensant les effets de la gravité sur la sonde échographique endorectale.
Freins libres
Une approche math´ematique pour la forme
architecturale
Ahmed Elshafei
To cite this version:
Ahmed Elshafei. Une approche math´ematique pour la forme architecturale. Hardware Architecture.
Universit´e Paris-Est; Laboratoire G´eom´etrie, structure, architecture (Paris), 2014.
French. .
HAL Id: tel-01061095
https://tel.archives-ouvertes.fr/tel-01061095
Submitted on 5 Sep 2014
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of scientific
research documents, whether they are published
or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est
destin´ee au d´epˆot et `a la diffusion de documents
scientifiques de niveau recherche, publi´es ou non,
´emanant des ´etablissements d’enseignement et de
recherche fran¸cais ou ´etrangers, des laboratoires
publics ou priv´es.Université Paris-Est
L’école doctorale VTT: ville, transport et territoires
L’école nationale supérieure d’architecture Paris-Malaquais
Laboratoire GSA: géométrie, structure et architecture
Thèse de doctorat
UNE APPROCHE MATHÉMATIQUE POUR LA FORME ARCHITECTURALE
Doctorant: Ahmed ELSHAFEI
Directeur de thèse de doctorat: Maurizio BROCATO
| 12 | Pour ceux qui ne connaissent pas les mathématiques, il est difficile d’avoir un réel sentiment pour la beauté,
la plus profonde beauté, de la nature ... Si vous voulez en apprendre davantage sur la nature, pour apprécier
la nature, il est nécessaire de comprendre la langue qu’elle parle.
R. Feynman
| 3Résumé
Au cours des deux dernières décennies avec la montée des ordinateurs et des logiciels de CAO dans l’architecture,
il a été une fois de plus un intérêt croissant pour les mathématiques. Toutefois, cet intérêt a de nombreuses
conséquences paradoxales. C’est parce qu’au cours des deux derniers siècles ces deux disciplines ont
augmenté dans des directions presque opposées sur la compréhension de l’espace et des objets en elle. Cette
recherche examine ces conséquences paradoxales, il part de l’hypothèse que les mathématiques modernes
peuvent une fois de plus être la base de la compréhension de l’espace dans l’architecture. Cela signifie que
toutes les constructions abstraites de la géométrie moderne serait l’outil pour comprendre, concevoir et
manipuler l’espace architectural et les objets qu’elle contient. En prenant cette position de nombreuses questions
se posent. Questions de technicité en termes de connaissances mathématiques à acquérir et questions de
nature philosophique en termes de ce que cela signifie pour l’architecture de comprendre l’espace mathématiquement.
Cette recherche examine ces deux dimensions de cette position, à savoir que d’une part il y a une
construction mathématique complète des espaces et des objets en elle, couplés avec des réflexions
philosophiques sur le sens de ces constructions dans l’architecture. À côté du formalisme mathématique, ces
constructions sont également traduits en une série de programmes courts qui alors peuvent effectivement être
utilisés comme outils de calcul et de visualisation. La recherche tente d’assembler divers fragments de différentes
branches mathématiques en un seul corps du savoir mathématique qui est pertinente d’un point de vue
de la conception architecturale, comprise dans huit chapitres. Le premier chapitre traite principalement les
conséquences philosophiques de cette prise de position entre l’architecture et les mathématiques; expliquant le
contexte de leur relation et éclairer la nature esthétique de la recherche. Dans le chapitre deux, nous essayons
de préparer la fondation pour les constructions mathématiques, à savoir examiner la relation entre la géométrie
et de la perception. Nous expliquons aussi la différence entre les espaces formels et physiques, et nous définissons
formellement les notions de base de la spatialité en utilisant la topologie et enfin nous construisons le
principal objet géométrique de la recherche, qui est la variété différentiable (en particulier à deux dimensions à
savoir la surface). La logique de structuration des constructions mathématiques dans la recherche provient
essentiellement de l’approche intuitive de la conception architecturale de définir d’abord une forme de base,
puis appliquer des modifications. Par conséquent, nous avons deux parties générales des constructions mathé-
matiques la première est la définition des formes et la deuxième partie est les opérations sur les formes. Dans
le chapitre trois, nous donnons une explication de la différence entre nos deux types principaux de définitions
de formes à savoir la définition paramétrique et la définition algébrique. Dans le chapitre quatre, nous donnons
une explication sur les deux principales techniques de définitions de forme utilisés par les logiciels de CAO à
savoir les meshes et les splines (en particulier les NURBS). Ceci est couplé avec une réflexion philosophique
sur l’utilisation de logiciels de CAO et de sa relation à la connaissance géométrique, et sur une perspective
plus large, la relation entre cette recherche et l’architecture numérique. Dans les trois chapitres suivants, nous
définissons trois types d’opérations différentes qui peuvent être appliquées à des formes que nous avons
définies, à savoir les opérations algébriques, analytiques et algorithmiques. Comme il ressort de leurs noms,
ces opérations correspondent aux différentes branches de la géométrie: la géométrie affine (en particulier
euclidienne) et la géométrie projective, puis la géométrie différentielle et enfin la géométrie combinatoire et
computationnelle. Dans le chapitre cinq, l’accent est sur les opérations algébriques, nous commençons par
expliquer les différents espaces en question et de passer ensuite la notion de la symétrie par lesquels ces
différents types de géométrie sont constitués une dans l’autre (cf. programme d’Erlangen). Dans le chapitre
six, nous nous concentrons sur la géométrie différentielle (en particulier des courbes et surfaces), avec une
variété de résultats analytiques qui permet un large éventail d’outils et techniques de conception. Tous ces
résultats sont couplés avec des exemples des conceptions architecturales élaborées à l’aide de ces calculs.
Dans le chapitre sept nous déplaçons vers des opérations algorithmiques, qui sont divisés en deux parties: la
première partie traite de géométrie combinatoire et computationnelle et la seconde porte sur les méthodes
d’optimisation tels que les algorithmes génétiques. Nous concluons finalement la recherche au chapitre huit,
dans lequel nous revenons une fois de plus à nos réflexions philosophiques. Nous prenons trois grandes
idéologies en architecture à savoir, le fonctionnalisme, la sémiotique et la phénoménologie et essayer de voir
comment cette recherche se rapporte aux leurs points de vue.
4 | Table des matières
1.Introduction
1.1. Objectif
1.2. Objectif et sa double nature
1.3. Changement de paradigme dans l’esthétique
1.4. Changement de paradigme en mathématiques
1.5. Disciplinarité, indisciplinarité et interdisciplinarité
1.6. Références
2. Géométrie et espace
2.1. Géométrie, la perception et l’expérience
2.2. Les espaces formels et variétés
2.2.1 Notions topologiques de base
2.2.2. Construction d’une variété
2.3. Références
3. Définition de la forme
3.1. Définition paramétrique de courbes et de surfaces
3.2. Familles de surfaces
3.3. Définition algébrique (non paramétriques) des courbes et des surfaces
3.3.1. Paramétrage de la surface algébrique
3.5. Références
4. L’ordinateur et la conception
4.1. Bref historique de la conception assistée par ordinateur
4.2. Modélisation de maillage polygonal
4.2.1. «Box modeling» et «winged edge data structure»
4.2.2. Conception en utilisant «box modeling»
4.2.3. La conception et la manipulation de la structure de données
4.3. Modélisation par interpolation
4.3.1. Interpolation polynomiale
4.3.2. Splines cubique et bicubique
4.3.3. Bézier et NURBS
4.3.4. Concevoir utilisant NURBS
4.4. Critique de la conception assistée par ordinateur
4.5. Concernant l’architecture numérique
4.6. Références
| 55. Opérations algébriques
5.1. Construction des espaces vectoriel et affine
5.2. Symétrie et géométrie
5.3. La géométrie euclidienne vs l'arithmétique pythagoricienne en architecture
5.4. Géométrie affine et euclidienne
5.4.1. Définition du groupe
5.4.2. Transformations affines isométriques (i.e. transformation euclidienne)
5.4.3. Transformation affine non-isométrique
5.4.4. Projections orthogonales
5.4.5 Conception en utilisant la géométrie affine
5.5. Géométrie projective
5.5.1. Espace projectif et groupe projectif
5.5.2. Bref historique de la perspective
5.5.3. Points à l'infini
5.5.4. Construction de la perspective
5.6. Conception utilisant la géométrie affine et la géométrie projective
5.7. Références
6. Opérations analytiques
6.1. Bases de calcul différentiel
6.2. Géométrie différentielle des courbes
6.2.1. Définition d'une courbe régulière
6.2.2. Analyse d'une courbe régulière
6.2.3. Conception en utilisant l'analyse d'une courbe régulière
6.2.4. Tubes le long des courbes
6.2.5. Conception utilisant des tubes
6.3. Géométrie différentielle des surfaces
6.3.1. Calcul vectoriel
6.3.2. Définition d'une surface régulière
6.3.3. Analyse d'une surface régulière
6.3.3.1. Champs de vecteurs
6.3.3.2. Conception en utilisant des champs de vecteurs
6.3.3.3. Courbes intégrales et systèmes dynamiques
6.3.3.4. Conception en utilisant des courbes intégrales
6.3.3.5. Métrique riemannienne sur une surface régulière
6.3.3.6. Conception en utilisant la métrique riemannienne
6.3.3.7. Volume contenu par une surface régulière
6.3.3.8. Courbure d'une surface régulière
6.3.3.9. Conception en utilisant la courbure
6.3.3.10. Asymptotes dans une surface régulière
6.3.3.12. Courbes géodésiques dans une surface régulière
6.3.3.13. Courbes d'intersection entre les surfaces régulières
6.3.3.14. Conception en utilisant l'intersection entre les surfaces régulières
6.3.4. Surfaces spéciales
6.3.4.1. Surfaces non orientables
6.3.4.2. Conception en utilisant des surfaces non orientables
6.3.4.3. Surfaces réglées et développables
6.3.4.4. Conception en utilisant les surfaces réglées
6.3.4.5. Surfaces de révolution
6.3.4.6. Surfaces à courbure constante
6.3.4.7. Surfaces minimales
6.4. Références
6 | 7. Opérations algorithmiques
7.1. Dessin automatisé
7.1.1. Organisation interne
7.1.1.1. Circulation verticale
7.1.1.2. Séparation et la division de l'espace
7.1.1.3. Renflement et transition douce
7.1.2. Tâches répétitives
7.1.2.1. Opération géométrique répétée
7.1.2.2. Elément architectural répété
7.1.2.3. Génération des variants
7.1.3. Géométrie computationnelle
7.1.3.1. Problèmes de géométrie computationnelle (le paire la plus proche)
7.1.3.2. Motif computationnelle
7.1.4. Problèmes de géométrie combinatoire (pavage)
7.1.4.1. Pavage et l'architecture
7.1.4.2. Groupes ponctuels discrets et groupes de «wallpaper»
7.1.4.3. Conception en utilisant le groupe de «wallpaper»
7.2. Optimisation (méthode de recherche)
7.2.1. Problème d'optimisation
7.2.2. Conception et la science
7.2.3. Notions de base de la biologie évolutive
7.2.4. Optimisation en utilisant un algorithme génétique
7.2.5. Optimisation en utilisant la méthode de Monte-Carlo
7.3. Références
8. Qu'est-ce que l'architecture
8.1. Architecture
8.2. Idéologies architecturales dominantes
8.2.1. L'architecture comme fonction
8.2.2. L'architecture comme communication
8.2.3. L'architecture comme une expérience vécue
8.3. Références
| 71.Introduction
ü
1.1. Objectif
Tout au long de l'histoire, l'architecture et les mathématiques ont été profondément liées, et même dans
certaines périodes les deux disciplines étaient indiscernables, à savoir les architectes étaient aussi des mathé-
maticiens et vice-versa. Cela était dû au fait que l'architecture offerts les mathématiques (qui, dans le monde
antique était plein de symbolisme et de mysticisme) un moyen d'exprimer, visualiser et de manifester ces
relations divines dans la pierre. Ceci peut être vu dans le monde antique de l'Egypte, la Grèce et Rome, les
cathédrales médiévales de l'Europe et les grandes mosquées du monde islamique et tout le chemin à la Renaissance
italienne. Tout au long de toutes ces périodes une relation intime entre la spiritualité et les mathématiques
a été exprimé dans la relation entre la beauté et de l'architecture. Nous trouvons dans la Grèce antique,
la philosophie pythagoricienne dont les adeptes (les pythagoriciens) comprenaient les mathématiques comme
la base de toutes les choses physiques et métaphysiques, avec les nombres en son coeur. Au moyen âge, nous
pouvons voir dans l'architecture de la cathédrale comment les mathématiques a été écrit dans la pierre; symbolisme
provenant de relations géométriques divins sont dans presque tous les aspects de sa conception. Le
nombre de piliers, la proportion de l'aménagement de la façade, jusqu'aux détails de la division de la rosace,
tous expriment les relations géométriques divines avec d'importantes signification métaphysique que la
personne médiévale comprise et appréciée. Dans la renaissance de la relation de l'architecture aux mathématiques
a atteint son apogée avec la montée de l'humanisme et de la figure de l'homme de la Renaissance,
hommes comme Léonard de Vinci et Albrecht Durer, qui a donné des représentations détaillées du corps
humain et de sa relation à des proportions géométriques, en particulier le nombre d'or. D'autres, comme le
maître de la Renaissance Andrea Palladio qui a proposé l'utilisation de séquences dans les dimensions des
pièces dans ses célèbres Les Quatre Livres de l'architecture, et le polymathe Leon Battista Alberti qui consid-
érait les mathématiques comme un fondement commun de l'art et de la science. Cependant, avec la montée du
modernisme dans la culture occidentale à la fin du XVIIIe siècle, un changement de paradigme commençait
un changement fondamental dans la pensée occidentale dans la philosophie, l'art et la science; à tel point que,
pour comprendre toute discipline contemporaine nous devons extrapoler revenir à ce changement de
paradigme [1]. En ce qui concerne la relation entre l'architecture et les mathématiques qui est au cœur de cette
recherche, nous trouvons deux aspects importants de ce changement de paradigme est nécessaire de comprendre.
Le premier est le changement de paradigme dans l'esthétique qui a conduit à une esthétique plus kantienne
qui a porté sur l'œuvre d'art elle-même à la place de l'esthétique classique qui a été porté sur la nature. Le
deuxième est le changement de paradigme en mathématiques qui a conduit à l'interprétation moderne de la
géométrie avec l'accent uniquement sur le formel-logique à la place de l'ancienne interprétation de la
géométrie qui nécessitait une connaissance a priori de ses objets (tels que des points, des lignes et des surfaces).
Avec ce bref aperçu du contexte dans lequel nous nous trouvons aujourd'hui concernant l'architecture
et les mathématiques, nous allons formuler l'objectif de la recherche montrant sa double nature et ses limites.
L'objectif de cette recherche:
Application de la géométrie moderne en architecture dans le sens de fournir une approche mathématique
formelle pour la conception de formes architecturales et à la compréhension de l'espace.
Avec ce dit, nous allons maintenant montrer quelques points importants concernant la nature de cet objectif,
ses limites et les difficultés qu'elle implique, après que nous nous concentrerons sur le contexte dans lequel
nous nous trouvons lorsque vous faites une telle recherche. Cette idée contextuelle serait donné par faire la
lumière sur la relation entre l'architecture contemporaine et les mathématiques, une relation qui a été défini
principalement par le changement de paradigmes dans l'esthétique et les mathématiques.
8 | ü
1.2. Objectif et sa double nature
Cet objectif a par définition une nature double et presque paradoxal: d'un côté, il est tout à fait pratique
d'apporter une base mathématique à la génération de forme dans l'architecture, ce qui permettra un meilleur
contrôle et une compréhension des formes, pour ne pas mentionner un terrain commun mieux adapté pour la
correspondance avec les ingénieurs et les conseillers techniques. D'autre part la géométrie moderne est assez
loin dans son abstraction et son formalisme de la géométrie descriptive traditionnelle que les architectes
connaissent, avec des notions comme des variétés, et la topologie qu'il serait presque absurde du point de vue
de l'architecture d'avoir un tel niveau d'abstraction qui n'est pas nécessaire; ici nous rencontrons l'autre côté
fondamental de la recherche qui est le côté esthétique. En un mot, l'objectif de la recherche du début à la fin
contient deux motivations adverses: une motivation pratique et une esthétique. Avec ce dit, nous nous trouvons
dans une position particulière en soulevant de nouveau la question de l'architecture et les mathématiques
dans nos temps modernes. Cette particularité vient du fait que, même si l'intérêt de l'architecture en mathématiques
reste encore tout à fait clair, il n'y a pas de cadre contextuel approprié pour héberger une telle question
de manière scientifique; ceci est l'une des premières limites de la recherche. Il n'est pas un corps important des
recherches en combinant les deux disciplines à partir de laquelle nous pouvons avoir assez de ressources ou de
points de départ, les deux disciplines ont été assez séparés depuis au moins deux siècles. Il existe bien sûr de
la recherche en architecture orientée vers la géométrie mais l'objectif principal est la génération de forme et
beaucoup moins concentrer sur la construction formelle abstraite, et il y a la recherche en mathématiques qui
ne se rapporte pas beaucoup aux disciplines artistiques comme l'architecture. Ainsi, afin de surmonter cette
limitation, nous devions aller et extraire les constructions formelles issus des mathématiques et puis essayer de
les assembler de la manière la plus cohérente possible du point de vue de l'architecture. Ceci peut être vu dans
la structure de la recherche qui est divisé en définitions des formes, puis les opérations (algébriques, analytiques
et algorithmique) sur ces formes, cette logique ne vient pas de mathématiques, mais plus de l'architecture;
car, dans l'architecture, nous commençons naturellement par une forme de base, puis nous modifions et
développons avec le processus de conception. Une autre limitation qui nous avons rencontré dans cette
recherche est que les notions géométriques qui sont d'intérêt contemporain dans la conception architecturale, à
savoir les sujets concernant courbure, géodésiques entre autres, sont assez intuitive du point de vue de l'architecture
architectural; mais ils sont des sujets assez avancés dans la géométrie moderne. Cela signifie que leur
construction formelle nécessiterait un niveau avancé de connaissances mathématiques et un nombre important
de constructions mathématiques qui y mènent. Encore une fois cette limitation a été surmontée par l'extraction
de ces concepts et toutes leurs constructions issus des mathématiques et de les assembler de manière cohérente
qui peut être pédagogique du point de vue architectural; mais cela est venu au coût que le niveau mathématique
de la recherche a également été soulevée. Ces deux limitations et en particulier la première nous offre un
aperçu du contexte problématique de la recherche et nous montre que cette recherche combinant géométrie et
l'architecture ne peut jamais être simplement une recherche scientifique dans le sens de l'ingénierie ou les
sciences naturelles, car une grande partie de sa motivation est l'appréciation esthétique. Cela conduit à la
conclusion que faire une telle recherche est un acte esthétique, le mot esthétique est ici essentiel et nous
expliquer son importance plus tard. Le produit final est donc un objet esthétique sur trois niveaux différents
d'appréciation esthétique. Nous avons d'abord l'esthétique austère des constructions mathématiques formelles;
deuxièmement les conceptions architecturales avec leur esthétique plus accessible et enfin l'acte de utiliser ces
constructions mathématiques dans la conception architecturale avec sa dimension poétique. En plus des
constructions mathématiques formelles, il y a le codage numérique de ces constructions qui nous permettent
de calculer et d'analyser des informations sur les formes; ce qui donne la recherche sa dimension intrinsèquement
pratique. Cette dualité entre la motivation esthétique et une pratique est une caractéristique fondamentale
non seulement de cette recherche, mais de la discipline architecturale en général. Maintenant que nous avons
mentionné l'importance de cette dualité entre l'esthétique et la pratique dans cette recherche, nous avons
besoin de comprendre précisément ce que nous entendons par un objet esthétique; et ce qui fait que l'utilisation
des construction mathématiques dans la conception architecturale avoir une dimension poétique. Donc,
nous allons donner deux brefs récits sur ces changements de paradigme, ce qui nous permettra d'expliquer la
dimension poétique de travailler entre disciplines.
| 9ü
1.3. Changement de paradigme dans l'esthétique
Bien sûr, nous n’allons pas donner un exposé complet sur l’esthétique moderne qui pourraient faire l’objet
d’une recherche complète par elle-même, à la place, nous allons nous concentrer ici sur quelques idées clés de
l’esthétique moderne qui pourraient être utiles pour nous plus tard, quand nous parlons de la poétique de la
connaissance. En résumé, l’esthétique moderne commence autour du XVIIIe siècle avec les travaux de
penseurs allemands et britanniques qui ont souligné la beauté comme l’élément clé de l’art et celui de l’expérience
esthétique et vu l’art comme nécessairement visant à la beauté absolue. Le premier à utiliser le terme
«esthétique» dans son sens moderne était le philosophe allemand A.G.Baumgarten pour qui, l’esthétique est la
science de l’expérience des sens, plus proche de la logique et de la beauté est donc la forme la plus parfaite de
la connaissance que l’expérience de sens peut avoir. Un des récits les plus cruciales et les plus influents sur
l’esthétique est celle de Kant dans son livre Critique du jugement, à savoir sa formulation du jugement esthé-
tique et sa conception du sublime; qui, selon Jean-François Lyotard est essentiel pour l’art moderne. Kant se
trouve en plein milieu d’un changement historique complet dans le point central de l’esthétique; avant Kant,
l’esthétique a pris ses principaux exemples de la beauté et de la sublimité de la nature, après Kant l’accent est
porté sur l’œuvre d’art elle-même. Ceci est crucial pour nous, car c’est précisément à partir de ce point que les
mathématiques et l’art démarrer leurs trajectoires divergentes modernes; qui donne toute tentative de les réunir
une position presque paria. Avec le déplacement de la valeur esthétique d’une œuvre d’art de la nature
(comme la manifestation de l’harmonie divine) à l’œuvre elle-même, les artistes ont perdu leur intérêt pour les
mathématiques qui a toujours été considéré comme la langue dans laquelle le divin a créé la nature. Et ils se
sont concentrés davantage sur leur propre vision du monde, leur psychologie et perceptions; menant vers l’art
contemporain, où il n’y a absolument pas de cadre de référence objectif pour juger la valeur du travail. Malgré
cette position apparemment non universel en ce qui concerne la valeur esthétique d’une œuvre, Kant considère
l’expérience esthétique de la beauté comme un jugement de la vérité subjective, mais encore universel;
puisque tous les gens devraient conviennent qu’un certain rose est belle mais la beauté ne peut pas être réduit
à un ensemble de base des caractéristiques de cette rose. Cette notion de «subjective pourtant universel” est
également essentielle, car elle nous sauve de l’attitude réductrice de dire «tout est permis» et nous donne une
compréhension de la notion kantienne du jugement esthétique. Dans le cadre de cette recherche, nous avons
deux motivations pour comprendre le compte de Kant du jugement esthétique, Tout d’abord, le jugement
esthétique est au cœur du processus de conception architecturale, même lorsque les architectes utilisent un
raisonnement pratique derrière leur préférence d’une certaine forme sur une autre, il reste dans le domaine du
jugement esthétique. La deuxième motivation vient de la nature de indisciplinaire de cette recherche
(indisciplinaire ici est dans le sens du concept de Jacques Rancière de la poétique de la connaissance), qui
repose principalement sur le compte kantienne du jugement esthétique. Maintenant, nous allons donner une
brève explication du jugement esthétique de Kant. Dans la Critique du jugement, Kant définit jugement
comme la subsomption d’un particulier sous un universel. Si l’universel est la faculté de comprendre, qui
fournissent des concepts. et la raison est celle qui tire des conclusions, alors le jugement sert d’intermédiaire
entre l’entendement et la raison en permettant des actes individuels de subsomption. Cela conduit à une
distinction entre les jugements déterminés et réflexifs. Cependant, dans les jugements réflexifs, le jugement
doit procéder sans concept, parfois dans le but de former un nouveau concept; Kant met le jugement esthé-
tique dans la catégorie de jugement réflexifs [2]. Ici, nous pouvons voir clairement que l’opposition entre les
arts et les mathématiques ne sont pas simplement une distinction entre les jugements universels et particuliers.
Mais plutôt, que dans l’art les concepts universels ne peuvent pas déterminer un jugement sur le cas particulier
d’une manière directe comme ils le font dans les mathématiques et les sciences en général. Bien sûr, cela est
dû au déplacement de la valeur de l’art de la nature à l’œuvre elle-même. L’architecture a une place particulière
dans cette distinction des jugements déterminés et réflexifs, car dans certains domaines, l’architecture
peut fonctionner en utilisant un jugement déterminant, par exemple sur les aspects techniques. Néanmoins, le
jugement global en architecture est réflexive, car il ne peut pas être obtenue directement à partir de concepts
universels. Que notre contexte est artistique ou scientifique, presque immédiatement une question se pose
sujet de la convenance de la nature au notre jugement, Kant soutient ce principe de convenance et il l’appelle
la finalité ou la détermination de la nature au notre jugement. Il ajoute que sans ce principe, la science ne
serait pas possible, comme toutes les sciences doivent assumer la disponibilité de ses objets pour notre jugement.
De même, sans un tel principe nos jugements sur la beauté ne serait pas exposer la communicabilité, ou
10 | serait pas possible, comme toutes les sciences doivent assumer la disponibilité de ses objets pour notre jugement.
De même, sans un tel principe nos jugements sur la beauté ne serait pas exposer la communicabilité, ou
la tendance à l’universalité même en l’absence d’un concept, ce qu’ils font. Le problème de le jugement est
d’une grande importance, puisque, pour Kant, le jugement sert d’intermédiaire entre deux branches de la
philosophie, la philosophie théorique mettant l’accent sur la connaissance de la nature sensible et la philosophie
pratique mettant l’accent sur la possibilité d’une action morale et sur la nature sensible. Kant constate un
problème dans notre faculté de raisonner contre elle-même, puisque dans son emploi théorique, la raison exige
absolument la soumission de tous les objets à la loi, mais dans son utilisation pratique, raison exige également
la possibilité de la liberté. Kant résout ce problème en utilisant l’idéalisme, à savoir chaque objet doit être
conçu de manière double: d’abord comme une apparition, sous réserve de la compétence nécessaire de certains
concepts de base et les formes de l’espace et le temps, d’autre part, comme une chose en lui-même, dont
plus rien ne peut être dit. Nous allons utiliser cet idéalisme kantien dans cette recherche quand nous allons
décrire les objets géométriques. À savoir qu’il y a effectivement deux façons de concevoir une forme
géométrique, son apparence physique que ce soit représentée graphiquement ou construit comme un objet du
monde physique et sa description mathématique qui nous allons considérer que l’objet en lui-même. Nous
allons traiter cette question dans le chapitre suivant sur l’espace et la géométrie, pour l’instant nous revenons à
la définition de Kant du jugement esthétique, et montrer comment la position de cette recherche se rapporte à
elle. Kant affirme que les jugements esthétiques (ou jugements de goût) doivent avoir quatre principales
caractéristiques distinctives. D’abord, ils sont désintéressés, ce qui signifie que nous prenons plaisir à quelque
chose parce que nous jugeons que c’est beau, plutôt que de juger que c’est beau, parce que nous trouvons
agréable. Deuxièmement, ils sont universels, ce qui signifie en gros que c’est une partie intrinsèque de l’activité
d’un tel jugement d’attendre que les autres sont d’accord avec nous. Troisièmement, elles sont nécessaires,
la beauté se comporte comme si elle était une propriété réelle d’un objet, comme son poids ou sa composition
chimique. Enfin, de beaux objets semblent être utile sans but (parfois traduit comme définitive sans fin) [3].
Nous expliquons maintenant que ces quatre caractéristiques du jugement esthétique de Kant pourrait être
trouvée dans la position de cette recherche; tout d’abord il est désintéressé, car il prend plaisir à l’emploi des
constructions mathématiques dans la conception simplement parce qu’il juge que c’est beau, et pas dans
l’autre sens. Deuxièmement, il prend une position universelle de la beauté de cet emploi, et ne dit pas qu’il est
seulement belle personnellement. Troisièmement, il a un caractère nécessaire, et enfin le résultat final de cette
recherche ne semble utile sans but. Après avoir défini les quatre critères de du jugement esthétique, Kant porte
à décrire l’expérience esthétique. Il affirme que, comme l’expérience naturelle, l’expérience esthétique qui
conduit à un jugement déterminant est explicable que à l’aide d’une dimension intuitive et conceptuelle qui
signifie que la beauté est cognitive. Le deuxième type de base de l’expérience esthétique de Kant est le
sublime, le sublime décrit des expériences qui nous accablent et nous donnent le sentiment que nous ne
pouvons pas les saisir pleinement. Le deuxième type de base de l’expérience esthétique pour Kant est le
sublime, le sublime décrit des expériences qui nous accablent et nous donnent le sentiment que nous ne
pouvons pas nous saisir pleinement. Le sublime est un concept essentiel dans la compréhension de l’art
moderne où il y a eu un changement clair de la beauté au sens classique de la beauté qui a vient de l’effet
écrasant. La plupart de l’art contemporain, vise à assurer sous une forme ou une autre un sentiment être
bouleversé par le travail au lieu de pleasured par sa beauté harmonieuse. Ce sentiment d’être bouleversé par le
travail est la caractéristique récurrent dans presque tout l’art contemporain, son but est de choquer l’observateur.
La question de savoir si c’est légitime ou pas est un autre débat. Nous nous intéressons ici au compte de
Kant sur le sublime, puisque l’architecture contemporaine tombe ainsi dans cette tendance pour le choquant et
l’écrasante. Ceci peut être vu en particulier dans le nouveau mouvement de l’architecture numérique et son
appétit croissant pour les conceptions de plus en plus choquantes. Kant divise le sublime en deux types: la
mathématique et de la dynamique. Si notre capacité de l’intuition est accablé par taille, comme un immense
bâtiment, ce serait une expérience sublime mathématique et si notre capacité de vouloir ou de résister est
accablé par la force, comme une énorme tempête, ce serait une expérience sublime dynamique. Kant soutient
que ce qui est sublime n’est pas du tout l’objet, mais nos idées de la raison: à savoir les idées de la totalité
absolue dans le sublime mathématique et la liberté absolue dans le sublime dynamique. Toutefois énorme est
le bâtiment, ou puissante est la tempête, ils ne sont rien par rapport à la totalité absolue et la liberté absolue, le
sentiment sublime est donc une alternance rapide entre la crainte de l’écrasante et le plaisir particulier de voir
ce écrasante accablé [4]. Maintenant, nous allons diriger notre attention vers une autre notion kantienne
important que l’idée esthétique; ce qui est crucial pour nous dans cette recherche en raison de sa position entre
| 11ce écrasante accablé [4]. Maintenant, nous allons diriger notre attention vers une autre notion kantienne
important que l’idée esthétique; ce qui est crucial pour nous dans cette recherche en raison de sa position entre
l’art et la science et la dualité de l’esthétique et le pratique. Après avoir défini l’esthétique et la sublime Kant
se tourne vers la définition de l’art et sa relation avec ses concepts de l’idée esthétique et le génie. Kant croit
que le cognition part à l’évaluation des beaux-arts est similaire à la cognition part à l’évaluation beauté
naturelle et que ce qui donne âme aux beaux-arts est l’idée esthétique et que le talent du génie est de produire
des idées esthétiques. Une idée esthétique est une contrepartie à l’idée rationnelle: si celui-ci est un concept
qui ne pourrait jamais être exposé de manière adéquate sensiblement, le premier est un ensemble de présentations
sensibles à laquelle aucun concept est suffisante [5]. Ainsi l’art pour Kant se réfère à l’activité de
fabrication selon une notion qui précède, si je fais une chaise, je dois savoir à l’avance ce une chaise est, qui le
rend différent de la nature; étant donné qu’une ouverture de la fleur se passe sans notion préalable de l’ouverture
par la fleur. Il différencie aussi l’art de la science, l’art est une compétence distingué d’une connaissance
de type, une capacité pratique irréductible à des concepts déterminés, qui se distingue d’une simple compréhension
de quelque chose. La science peut être enseignée, tandis que l’art bien que soumis à la formation, il
s’appuie sur le talent natif. Ainsi, pour Kant, il n’y a aucune telle chose comme un génie scientifique, parce
qu’un esprit scientifique ne peut jamais être radicalement originale, c’est-à-dire que les icônes scientifiques
comme Isaac Newton et Albert Einstein sont des génies artistiques dans le domaine de la physique. Nous
pouvons accord ou en désaccord avec l’affirmation de Kant, mais ce qui est important de comprendre ici, c’est
le sentiment qu’il vise, à savoir qu’il essaie de montrer que l’esthétique n’est pas seulement limitée aux
disciplines de l’art comme dans le sens classique du terme. Mais il s’agit plutôt d’un concept plus large et
générale plus liée à l’originalité et la créativité dans notre pensée quelle que soit notre domaine de travail. Ceci
est encore pertinente dans le contexte de cette recherche puisque, par définition, nous essayons de faire des
objets esthétiques en utilisant le langage de la science à savoir les mathématiques; et nous n’avons pas à notre
disposition la dimension mystique harmonieux global unifiant art et la science comme à l’époque classique.
Kant ici est en quelque sorte rassurant pour nous une valeur esthétique à l’œuvre sur la base de son concept de
l’idée esthétique à la place de l’esthétique classique. Cette esthétique kantienne et le rapport de l’art à la
science marque le début du changement de paradigme moderniste de l’esthétique (de la nature à l’œuvre d’art
elle-même). Qui d’une part signale la disparition des figures des polymathes de la Renaissance et le divorce
entre l’art et la science, mais d’autre part ouvre une nouvelle façon de penser entre les disciplines, notamment
scientifiques et des disciplines artistiques. Le passage de l’esthétique antique et médiévale où l’harmonie des
proportions et la symétrie sont fondamentales et où les mathématiques avec ses pouvoirs mystiques ont trouvé
une maison naturelle en architecture à l’esthétique moderne kantienne, signifiait que le rapprochement de l’art
et de la science aurait besoin d’un nouveau cadre de travail conceptuel : indisciplinarité. Ce concept n’est pas
un concept kantien par défaut, mais un concept développé par le philosophe français Jacques Rancière, qui
sera essentiel pour nous de comprendre davantage l’esthétique de la position de la recherche entre l’art et la
science. Nous allons faire face à cette situation lorsque nous allons expliquer la poétique du travail entre
disciplines, à savoir, dans ce contexte les mathématiques et l’architecture. Pour le moment, après avoir décrit
le changement de paradigme dans l’esthétique de la perspective kantienne, nous allons décrire un également
important changement de paradigme, c’est le changement de paradigme en mathématiques.
12 | ü
1.4. Changement de paradigme en mathématiques
Il semble maintenant que ce sont les artistes qui ont perdu l’intérêt pour les mathématiques avec le changement
de la valeur esthétique de la nature à l’œuvre d’art elle-même, mais ce n’est qu’un côté de l’histoire. Il y
a eu une perte égale mutuelle d’intérêt de la part des scientifiques et surtout les mathématiciens en métaphysique
ou plus précisément l’ontologie de la science. On peut dire que la science moderne et les mathématiques
modernes comme nous les connaissons ont commencé aussi à ce moment-là, où le sens et le symbolisme
ont été purgés de leurs domaines, ne laissant que la logique formelle et les expériences positivistes que
leurs seuls sujets. Cela permettra également de jouer un rôle également crucial que le changement de l’esthé-
tique dans l’histoire de l’art et de la science, et par conséquent toute tentative moderne de les réunir. Après
avoir discuté le changement de paradigme dans l’esthétique, nous allons maintenant discuter du changement
de paradigme en mathématiques à savoir l’interprétation ancienne et moderne de la géométrie. Avant d’entrer
dans les détails de cette ancienne et moderne distinction, nous allons montrer intuitivement quel est le problème
et comment il se rapporte à l’architecture. Quand on pense à des mathématiques en architecture immédiatement
on pense à des applications pratiques, par exemple, des calculs de structure, qui est tout à fait justifié
mais ce n’est pas la principale contribution des mathématiques à l’architecture ou de l’intellect humain en
général pour cette question. Ce que se passe avec les mathématiques est quelque chose de vraiment remarquable
d’un point de vue philosophique, à savoir, que c’est seulement par l’utilisation d’un système de symboles
et de relations logiques que nous sommes en mesure de créer des représentations de phénomènes
physiques. Cela semble tout à fait naturel pour nous, car nous sommes habitués au fait que les mathématiques
peuvent décrire le monde physique, mais si nous prenons un peu de recul et de penser, ce n’est pas du tout
évident que ces deux mondes des phénomènes et l’esprit humain peuvent être liés si étroitement. Dans les
temps pré-modernes, il a été tout simplement compris que les mathématiques avaient une signification mystique
et par le savoir nous se rapprochent de la divine. Cela a fonctionné parfaitement pour l’art et l’architecture
depuis les mathématiques et la géométrie en particulier leur a donné la langue par laquelle l’artiste
pourrait manifester l’esthétique classiques basés sur la nature. Mais avec la modernité, cette harmonie globale
est détruite et comme nous avons décrit dans le changement de paradigme dans l’esthétique, l’art et les
mathématiques n’étaient plus compatibles. Cela a laissé la question de savoir comment les mathématiques
décrits si parfaitement le monde physique grande ouverte. En fait, ce problème est tout à fait un vieux problème
et il ne se limite pas à l’architecture, mais à la physique et les sciences exactes et naturelles en général;
cette question sur la géométrie et l’expérience a été soulevée par Albert Einstein dans sa conférence devant
l’Académie des sciences de Prusse en 1921. Ce problème est bien sûr un problème métaphysique car du point
de vue scientifique moderne, la question de savoir pourquoi les mathématiques décrit la réalité est moins
important que comment nous pouvons utiliser les mathématiques pour décrire la réalité. Ayant fait ce constat,
nous n’allons pas tenter de répondre à cette question, qui peut faire l’objet d’une thèse par lui-même. Mais
nous allons diriger notre attention sur comment en soulevant cette question Albert Einstein montre l’évolution
des mathématiques de l’ancienne à la nouvelle interprétation de la géométrie. C’est en quelque sorte encore
plus important dans notre contexte que la question elle-même, puisque dans plusieurs façons l’un des principaux
obstacles entre l’architecture et les mathématiques aujourd’hui est due à la différence entre l’ancienne et
la nouvelle interprétation de la géométrie. Einstein a demandé comment se pourrait-il que les mathématiques,
étant après tout un produit de la pensée humaine qui est indépendante de l’expérience, est admirablement
adapté aux objets de la réalité? Est la raison humaine, alors, sans expérience, simplement en prenant la pensée,
capable de sonder les propriétés des choses réelles? Sa réponse a été très bref: En ce qui concerne les propositions
des mathématiques se réfèrent à la réalité, ils ne sont pas certains, et dans la mesure où elles sont certaines,
elles ne se réfèrent pas à la réalité [6]. Einstein a ensuite continué à clarifier sa réponse en faisant
référence à la montée de l’axiomatique comme une branche des mathématiques, ses progrès dans la séparation
de la logique formelle de mathématiques de son contenu intuitif ou objectif. Cela a été en parallèle avec
l’essor de la science positiviste qui est venu à être compris comme la seule interprétation légitime de la réalité,
éliminant tout besoin pour la métaphysique et de provoquer le divorce entre la foi et la raison et par conséquent
l’art et la science. Les mathématiques qui a été considéré par les anciens philosophes jusqu’à ce que
les polymathes de la Renaissance comme Alberti la base pour les arts et les sciences ont dû subir une transformation
fondamentale. Une transformation à faire être capable d’être le langage de la science positiviste
moderne, elle devait être purgé de tout symbolisme métaphysique, devenant ainsi une discipline purement
| 13mation fondamentale. Une transformation à faire être capable d’être le langage de la science positiviste
moderne, elle devait être purgé de tout symbolisme métaphysique, devenant ainsi une discipline purement
formelle dépourvue de sens mystique. Comme précisé Einstein, selon axiomatique, que la logique formelle
constitue l’objet des mathématiques, qui n’est pas concerné par l’intuitif ou tout autre contenu non associé.
Cette nouvelle interprétation des mathématiques et de l’émergence de la géométrie moderne ont eu un impact
fondamental sur l’architecture et sa relation avec le reste des beaux-arts. Alberto Perez Gomez explique dans
son livre Architecture et la crise de la science moderne que la purge des mathématiques de tous les sens
externe ou valeur a forcé l’architecture à une situation difficile, une existence de scission entre le couple
science et l’art moderne, récemment divorcé. C’était parce que la géométrie, qui est l’outil fondamental pour
la conception architecturale, a dû abandonner son “caractère sacré” et tout le bagage symbolique, il portait
avec lui, afin d’évoluer dans une discipline scientifique moderne appropriée. Cette géométrie moderne purgé
de toute signification est précisément la géométrie que nous allons utiliser dans cette recherche; construit à
partir de la logique purement formelle sans nécessairement de rapport avec les mondes physiques ou symboliques.
Nous allons montrer en détail plus loin comment cette constructions formelles de l’objet géométrique et
de les utiliser dans des conceptions architecturales a une dimension poétique, ce qui n’est pas basée sur le
symbolisme mystique comme ce fut le cas dans les périodes pré-modernes. Mais nous devons d’abord revenir
à l’explication d’Albert Einstein de l’ancienne et la nouvelle interprétation de la géométrie. Albert Einstein a
expliqué la différence entre l’interprétation ancienne et moderne de la géométrie en donnant un exemple de
l’axiome: par deux points dans l’espace, il passe toujours un et un seul ligne droite. Dans l’ancienne interprétation
cela sera considéré comme vrai en raison de son évidence, ce qui signifie qu’il fait partie d’une connaissance
a priori ce qui est une ligne et ce qui est un point. Dans l’interprétation moderne, que la validité de
l’axiome est supposé sans avoir besoin d’une connaissance a priori sur les objets: la ligne et les points (i.e.
axiomes sont considérés comme des définitions implicites, Schlick: épistémologie). Cependant la géométrie
est née de la nécessité d’étudier le comportement d’objets réels et cela ne peut être fait en utilisant uniquement
le système de la géométrie axiomatique, comme il ne peut pas faire des affirmations sur le comportement des
corps réels. Pour être capable de faire cela, nous devons ajouter la proposition: les corps solides sont liés par
rapport leurs dispositions possibles, de même que les organismes dans la géométrie euclidienne à trois dimensions.
Einstein appelle cela: la géométrie pratique complété par opposition à la géométrie purement axiomatique
et il ajoute que toutes les mesures de longueur en physique, y compris les mesures de longueur
géodésiques et astronomiques constituent la géométrie pratique en ce sens, si l’on utilise la loi empirique que
la lumière se propage en ligne droite , et même en ligne droite dans le sens de la géométrie pratique [6]. Il est
clair que tandis que les physiciens et les ingénieurs ont adopté l’interprétation moderne de la géométrie
purement axiomatique, qui est ensuite complété dans la géométrie pratique. Les architectes s’approprient
l’ancienne interprétation de la géométrie, ce qui a donc conduit à une compréhension des formes basées sur
nos sens et de la perception. Dans un sens, cela est tout à fait compréhensible puisque, après tout pourquoi un
architecte va passer du temps sur la compréhension des espaces abstraits qui sont dans la plupart des cas pas
possible de visualiser, tandis que le seul espace qui est en fait un intérêt architectural est l’espace euclidien à
trois dimensions. Et cet espace euclidien et sa géométrie euclidienne peuvent être totalement compris en
utilisant l’ancienne interprétation de la géométrie, à savoir que tous les objets sont comprises aussi comme des
objets physiques qui peuvent être soit dessinés ou construits. Cependant il y avait un prix, l’architecture a dû
payer pour s’en tenir à la simplicité de l’ancienne interprétation, à savoir que l’écart entre l’architecture et les
mathématiques a augmenté au point les architectes d’aujourd’hui ont près de zéro idées de ce que la géométrie
moderne est. Encore une fois ce ne serait pas du tout un problème si les architectes ont juste rester avec leur
ambition de conception dans la tradition euclidienne, ce qui n’est pas le cas. Si quoi que ce soit il y a un
appétit toujours croissante dans l’architecture contemporaine pour les constructions géométriques complexes,
et pour des concepts abstraits qui ont développé au cours des trois cents ans en mathématiques. Et dont
l’architecture n’a pas de n’importe quelle manière exhaustive intégrée dans son discours, qui est resté fondamentalement
fidèle à l’ancienne interprétation de la géométrie.Dans cette recherche, nous allons tenter une
nouvelle fois de mettre à jour l’architecture avec la géométrie moderne, à savoir d’accueillir ces constructions
provenant des mathématiques modernes dans la conception architecturale. Et d’une façon essayer de voir
quelles pourraient être les possibilités pour l’interprétation moderne de la géométrie dans l’architecture.
14 | ü
1.5. Disciplinarité, indisciplinarité et interdisciplinarité
Nous verrons par la suite que, pour comprendre cette dimension poétique nous nous appuierons sur le compte
de Kant sur l’esthétique que nous avons mentionné ci-dessus. Pour cela, nous allons maintenant remettre en
question la distinction entre la disciplinaire, indisciplinaire et interdisciplinaire, à travers le travail de Rancière
sur la poétique de la connaissance. Cette recherche envisage les possibilités et les conséquences de l’adoption
de l’interprétation moderne de la géométrie dans la conception architecturale comme un acte esthétique; il
demande quel est-il de concevoir l’aide de la connaissance de l’espace tel qu’il est compris par les mathématiques
modernes? Quel type d’un objet esthétique peut sortir de cet acte? Le mot esthétique est ici crucial, car
le produit n’est pas une conception architecturale, ni un article mathématique ou philosophique, il n’est pas
non plus simplement une boîte à outils d’ingénierie ni un aperçu historique sur l’architecture et la géométrie,
et pourtant il touche l’ensemble de ces territoires, d’où son caractère esthétique. Cette attouchements entre ces
différents territoires, n’est pas simplement de les mélanger dans une sorte de mélange interdisciplinaire, mais
cette recherche pourrait être considérée comme une famille de ponts (pour utiliser la métaphore de Rancière)
qui relient ces territoires distincts ensemble. Il est important de comprendre que ce travail ne vise pas en tout
cas de créer une discipline hybride entre l’architecture et les mathématiques, ou à déterritorialiser des concepts
géométriques dans l’architecture et de leur donner une nouvelle signification. En fait cet acte de déterritorialisation
des concepts est l’une des principales critiques que nous avons contre l’architecture numérique, sur lequel
nous aurons une analyse plus approfondie plus loin dans la recherche. Au contraire, nous insistons sur la
présentation des concepts mathématiques en utilisant leur langage propre à aucune tentative pour abus de
langage; avec certains schémas et textes pour les expliquer au lecteur non mathématiquement qualifié. En
d’autres termes cette recherche peut être considérée comme ce que le philosophe français Jacques Rancière
appelle un travail indisciplinaire, une esthétique de connaissances résultant de la pensée entre les disciplines.
Selon Rancière de parler d’une dimension esthétique de la connaissance est de parler d’une dimension de
l’ignorance qui divise l’idée et la pratique de la connaissance eux-mêmes [7]. Rancière affirme que la multiplicité
est essentielle pour la construction de ces ponts entre les disciplines. Cette notion d’ignorance est aussi
d’une grande importance dans ce contexte, car au contraire de ce que nous pensons intuitivement que la
maîtrise de deux disciplines mène à la maîtrise de leur somme, la réalité est plus subtile; à savoir en allant plus
profondément dans deux territoires déconnectés le résultat est la maîtrise d’aucun d’eux. C’est parce que
d’une certaine manière en creusant dans le nouveau territoire une certaine ignorance de l’autre territoire
grandit avec elle, en d’autres termes, si l’on peut être bien formés dans deux disciplines, on a aussi deux
ignorances sur ces deux disciplines qui viennent avec cette formation. Dans la partie qui suit, nous allons
montrer comment Rancière explique cette notion d’ignorance et les ponts entre les disciplines. Selon Rancière
les disciplines forment une orthodoxie d’un côté de l’eau sans avoir à ouvrir la possibilité pour d’autres
connaissances de l’autre côté, néanmoins, quand on est le pont, on touche les deux côtés sans appartenir à l’un
d’eux. Il ajoute que, avec ce pont, les deux parties deviennent égaux et peuvent être atteints et que indisciplinarité
est l’espace signifiant textuel dans lequel le pont d’un mythe à l’autre est visible et pensable, contrairement
à l’interdisciplinarité, qui est tout simplement intensifie d’une discipline pour un autre. La valeur esthétique
d’une œuvre indisciplinarité n’est pas simplement la somme des valeurs de chacune des disciplines comme
c’est le cas de l’interdisciplinarité, mais plutôt l’esthétique de la création d’un pont entre les disciplines. Cette
valeur esthétique est créé par la double négation que le travail n’est pas limitée dans le territoire de l’une des
disciplines, d’où il évite les orthodoxes dogmatiques, les frontières que les disciplines tentent de défendre.
Dans la Critique du jugement, Kant explique que la double négation constitue l’expérience esthétique l’aide
d’un certain déconnexion des conditions habituelles de l’expérience sensible [7]. Ainsi, dans un sens kantien,
cette recherche est présentée comme un objet d’appréhension esthétique qui est caractérisée comme ce qui
n’est ni un objet de connaissance, ni un objet de désir et apprécié comme une forme sans concept. Tout cela
semble un peu abstrait, mais au fond il est une idée simple, à savoir que l’architecture et les mathématiques
comme toute autre discipline forment une certaine défense contre les autres à l’aide de l’orthodoxie pour
protéger son mythe. Ce mythe n’est pas visible de l’intérieur de la discipline, il n’est visible que lorsque l’on
s’engager entièrement dans une autre discipline, en gagnant un point de vue depuis le pont entre les disciplines
qui est essentiellement poétique, car il expose ces mythes. En mythe ici on n’entend pas faux, mais ce que les
gens dans une certaine discipline, se soucient profondément. Ce serait la même si cette sphère a été construit à
partir d’acier ou de béton, serait d’une grande importance pour l’architecte et presque pas d’importance pour
| 15gens dans une certaine discipline, se soucient profondément. Ce serait la même si cette sphère a été construit à
partir d’acier ou de béton, serait d’une grande importance pour l’architecte et presque pas d’importance pour
le mathématicien, même si dans les deux exemples les deux ont travaillé sur la même forme géométrique: la
sphère. Cela peut nous donner une meilleure compréhension de ce que nous entendons par le mythe créé par
une discipline, et que lorsque nous sortons de la discipline sommes nous capable d’apprécier la dimension
poétique de soins mathématicien de la construction abstraite et l’architecte se soucier de la construction
matériel. Ce cours entre les disciplines a une double négation qui est liée à l’expérience esthétique kantienne
que nous l’avons mentionné plus tôt, parce qu’il regarde la forme seule, sans les frontières sociales. Cette
double négation n’est pas seulement définie par les nouvelles conditions d’appréciation des œuvres d’art, elle
définit également un certain suspension des conditions normales d’expériences sociales. Voilà ce que Kant
illustre avec l’exemple du palais, dont le jugement esthétique isole la forme seulement pour être esthétiquement
apprécié, désintéressé à savoir si le palais sert la vanité des riches oisifs et pour qui la sueur des travailleurs
a été passé afin de construire. Il est important de clarifier cette nature esthétique de la recherche afin
d’éviter toute confusion, une confusion qui est caractéristique de toute recherche effectuée dans la discipline
de l’architecture; c’est parce que contrairement à ce qu’il semble être, l’architecture est l’une des disciplines
moins clairement défini. C’est pourquoi, lorsque l’on fait la recherche en architecture on se retrouve immédiatement
dans le territoire d’une autre discipline que ce soit les mathématiques, l’ingénierie, de la philosophie, de
la sociologie ou de l’histoire, d’où l’importance de indisciplinarité et l’esthétique de la connaissance. Cela
soulève naturellement des questions sur le sens de la connaissance et de sa relation à l’ignorance, la manifestation
la plus simple de cette sensibilité, est comment certains mots comme «espace» ont une existence et une
structure complète dans des disciplines différentes. Maintenant, chaque discipline voit «l’espace», selon sa
propre structure qui ne s’oppose pas à celle des autres disciplines, mais plutôt ignorer. C’est-à-dire que chaque
connaissance vient avec une forme d’ignorance qui lui est intrinsèque. Cela va contre l’idée générale commun
de connaissances (détenus par des sociologues comme Pierre Bourdieu) qui est tout simplement: il existe la
vraie connaissance qui est conscient et libère et fausse connaissance qui ignore et opprime. Maintenant, la
neutralisation esthétique de la connaissance suggère qu’il n’y a pas une seule connaissance, mais que la
connaissance est toujours double: il est l’ensemble des connaissances (le savoir-faire) et une distribution
organisée de positions et que chacun de ces connaissances a ignorance comme son inverse. Par conséquent, il
est aussi des connaissances qui réprime et l’ignorance qui libère [7]. Nous pouvons voir que dans l’exemple
des pratiquants des disciplines utilisant le concept «espace»; chacun d’eux a une double connaissance, le
savoir faire en fonction de chaque discipline et la connaissance de leur état disciplinaire sociale. Par exemple,
comme un architecte ou un mathématicien, vous êtes censé regarder l’espace de la manière dictée par votre
discipline et pas en d’autres façons provenant d’autres disciplines, ce qui est une forme d’ignorance. Nous
pouvons voir que encore dans l’exemple de Kant du palais: les constructeurs de possession du palais connaissances
techniques et de leur condition de travailleurs qui ne possèdent le palais. Chacune de ces deux savoirs a
une ignorance comme son inverse: ceux qui savent comment travailler avec leurs mains sont censés être
ignorants en ce qui concerne l’appréciation de l’adéquation de leur travail à une fin supérieure. Platon dit que
c’est suffisant pour eux d’agir sur une base quotidienne, comme si c’était le cas: il suffit que leur jugement
font leur savoir-faire accord avec leur connaissance de leur état. Il dit que c’est une question de croyance qui
déterminent le rapport des deux savoirs et les deux ignorances. Un autre exemple parallèle à celle des travailleurs
du palais est que la présence des ingénieurs et mathématiciens dans des cabinets d’architectes pour la
résolution des problèmes structurels et géométriques; à cause de leur capacité technique, ils sont censés être
ignorant de la motivation artistique de l’œuvre. Qui vient précisément de leur connaissance de leur état
disciplinaire sociale, à savoir en tant que professionnel technique, vous êtes présumé ignorants des significations
artistiques. Le même pour les architectes, avoir la connaissance de comment concevoir et de créer est
livré avec une connaissance de leur condition sociale d’être artistique, qui suppose qu’ils soient ignorants des
connaissances techniques géométrique impliqué. Cette recherche prend la position de Rancière et Kant, à
savoir une position indisciplineaire esthétiquement neutre, où les conditions sociales disciplinaires sont
simplement suspendus ou ignorées toutes ensemble permettant une appréciation désintéressée. Rancière suit
Kant dans faisant valoir que les travailleurs sont en mesure de prendre une position désintéressée et apprécier
la beauté du palais sans tenir compte de leur position sociale comme les travailleurs, tandis que les sociologues
font valoir que cela est réservé uniquement pour ceux qui ne sont ni les propriétaires ou les travailleurs
de la palais. L’expérience esthétique dérègle cette disposition, il est donc bien plus qu’une façon d’apprécier
des œuvres d’art, il neutralise la relation circulaire entre la connaissance que le savoir faire et les connais-
16 | de la palais. L’expérience esthétique dérègle cette disposition, il est donc bien plus qu’une façon d’apprécier
des œuvres d’art, il neutralise la relation circulaire entre la connaissance que le savoir faire et les connaissances
que la distribution des rôles. Ceci explique l’importance de l’expérience esthétique dans cette recherche
car elle nous permet d’échapper à la répartition sensée des rôles: architecte, mathématicien, ingénieur et
philosophe et leurs compétences et d’apprécier le résultat d’une position neutre désintéressé. Maintenant que
nous avons montré l’importance de l’esthétique de Kant dans la compréhension des concepts de Rancière sur
la poétique de la connaissance et de travail entre les deux disciplines, ce qui est essentiel pour la compréhension
de la dimension esthétique de cette recherche, nous allons maintenant analyser plus en détail la notion de
“discipline “. Selon Rancière une discipline n’est pas simplement la définition d’un ensemble de méthodes
appropriées pour un certain domaine ou un certain type d’objet, mais c’est la constitution même de cet objet
comme un objet de pensée, une certaine idée de la relation entre la connaissance et une distribution de positions.
En d’autres termes, une discipline est une manifestation d’une idée de la connaissance, où une idée de la
connaissance doit être comprise comme le rapport entre les deux savoirs et deux ignorances. C’est toujours
plus qu’un ensemble de procédures qui permettent la pensée d’un territoire donné d’objets, c’est la constitution
de ce territoire lui-même et donc la création d’une certaine répartition du pensable. En tant que tel, il
suppose une coupure dans le tissu commun de manifestations de la pensée et de la langue. Pensée disciplinaire
dit: nous avons notre territoire, nos objets et nos méthodes qui leur correspondent. Disciplines sont donc en
guerre avec la allodoxie de jugement, mais ce qu’ils appellent allodoxie est en fait dissensus esthétique, la
déhiscence entre le corps et ce qu’il sait dans le double sens de la connaissance, la pensée indisciplinaire est
donc une pensée qui rappelle le contexte de la guerre. Pour ce faire, il doit pratiquer une certaine ignorance, il
faut ignorer les frontières disciplinaires pour restaurer ainsi leur statut comme des armes dans un conflit [7].
C’est exactement ce que nous essayons de faire dans cette recherche, de l’idée de base de l’application de la
géométrie moderne dans la conception architecturale tout au long dans les moindres détails; notions fondamentales
de mathématiques, les sciences et la philosophie mettre dans le contexte, comme s’ils pouvaient être
utilisés comme outils de conception architecturale. Cette mise de concepts d’une discipline dans leur forme
brute et les mettre dans un nouveau contexte d’une autre discipline avec toutes leurs structures rigoureuses
intactes, c’est ce que révèle cette confrontation violente des orthodoxies de disciplines. Par exemple, les
notions mathématiques sont effectuées sur le territoire de la conception architecturale avec tout leur bagage
mathématique structurale sans les privant de leur contenu ou les vulgariser afin d’être adapté dans le nouveau
contexte. Cela montre les deux savoirs et les deux ignorances en jeu; la connaissance du savoir-faire permet
l’écriture de ces notions, alors que la connaissance du rôle d’un mathématicien ignore les valeurs de ces
notions pour la conception architecturale. Dans le même temps la connaissance de la conception architecturale
permet l’utilisation créative de ces notions mathématiques tandis que la connaissance du rôle de l’architecte ne
tient pas compte de la valeur d’acquisition de ces connaissances techniques. Cela, réinvente efficacement la
relation entre une situation donnée et les formes de visibilité et les capacités de la pensée qui y sont attachés;
la pensée indisciplinaire créer le texte et l’espace signifiant dans lequel cette relation du mythe au mythe est
visible et pensable. Ceci est un rôle important de indisciplinarité en général et dans cette recherche en particulier,
il est un rappel constant que la fondation de la fondation est une histoire, un mythe, un beau mensonge
qui est la réalité de la vie pour la majorité des gens. Cela ne veut pas dire de toute façon que ces histoires sont
nulle ou sans effet, cela signifie simplement que ce sont des armes dans une guerre, ils ne sont pas les armes
qui facilitent simplement l’examen d’un territoire, mais des armes qui servent à établir les limites incertaines.
Il n’ya pas de limite assurée entre les disciplines, et de retracer ce limites est de tracer la frontière entre ceux
qui ont pensé à cette question et ceux qui n’ont pas. La poétique de la connaissance ainsi, ne prétendent pas
que les disciplines sont fausses connaissances, mais plutôt les moyens d’intervenir dans la guerre entre les
raisons de l’égalité et ceux de l’inégalité. Avec cela, nous terminons notre explication de la dimension esthé-
tique de cette recherche et dans la partie qui suit, nous allons commencer la prepration pour la construction de
l’espace formel.
| 17ü
1.6. Références
[1] Sacred, profane and geometrical symbolism in architecture, Antonio Caperna, 2007
[2] Internet encyclopedia of philosophy / Kant’s aesthetics / The central problems of the critique of judgment
[3] Internet encyclopedia of philosophy / Kant’s aesthetics / The judgment of the beautiful
[4] Internet encyclopedia of philosophy / Kant’s aesthetics / The sublime
[5] Internet encyclopedia of philosophy / Kant’s aesthetics / Fine art and genius
[6] Geometry and experience, Albert Einstein, Springler, Berlin 1921
[7] Thinking between disciplines: an aesthetics of knowledge, Jacques Ranciére, Parrhesia, Paris 2006
18 | 2. Géométrie et espace
ü
2.1. Géométrie, la perception et l’expérience
Dans le chapitre dernier nous nous sommes concentrés sur le contexte général de cette recherche, portant
principalement sur sa position entre les deux disciplines de l’architecture et les mathématiques. Nous avons
également mis l’accent sur affichant la double nature de la recherche motivée par des raisons esthétiques et
pratiqueset, et puis nous avons donné un bref compte rendu de l’esthétique de Kant qui a servi dans la compréhension
de la dimension esthétique de l’œuvre. Enfin, nous avons utilisé le concept de Jacques Rancière
pour montrer la dimension poétique de travail entre disciplines. Dans ce chapitre, nous allons laisser la
situation générale et commencer à se concentrer sur l’objet de la recherche à savoir l’utilisation de la
géométrie moderne en architecture. Bien sûr, cela nécessite une certaine préparation avant de plonger dans les
formules et les constructions abstraites, cette préparation est essentiellement de comprendre quelques différences
fondamentales importantes entre la vision de l’espace et de la géométrie des architectes et des
mathématiciens. We have already hinted at this distinction when we explained the paradigm shift in mathematics
resulting in the old and new interpretation of geometry. Cependant, maintenant nous allons lier cette
distinction à deux points dominants de vue de l’espace dans l’architecture: les cartésiennes et
phénoménologiques, avec plus d’emphase sur le point de vue phénoménologique dans les dernières décennies.
Nous allons de nouveau utiliser certaines notions de l’ontologie Kant quand nous expliquons cette distinction.
Le thème de l’espace et de la géométrie est un vaste sujet dans la philosophie et en particulier l’ontologie de
l’espace et du temps; dans cette recherche, nous allons mettre l’accent sur certaines notions spécifiques qui
sont pertinentes à notre contexte. Des notions telles que la distinction entre l’espace formel et l’espace
physique, qui sont liés à l’ancienne et la nouvelle interprétation de la géométrie. Autres notions importantes
sont liées à la perception et la compréhension espace à travers nos sens et d’autres notions phénoménologiques
tels que l’expérience corporelle. Cela nous aidera à obtenir une meilleure compréhension de la relation entre
l’espace, la géométrie et de notre perception. Il y a eu un grand nombre d’ouvrages philosophiques consacrés à
l’étude de l’espace et de la perception, surtout depuis le début de la phénoménologie comme un mouvement
philosophique et jusqu’à mouvements ultérieurs comme l’existentialisme, le structuralisme et le post-structuralisme
qui ont été très influencés par cette ligne de pensé. Ces travaux ont eu une influence considérable pour l’
compréhension de l’espace dans l’architecture, ce qui contribue d’une certaine manière à la problématique de
l’application de la géométrie moderne à la conception architecturale en particulier et au divorce entre la
science et l’art moderne en général. L’idée de base de la problématique est dans l’opposition entre deux points
de vue fondamentaux: l’ontologie cartésienne sur la base du cogito et l’ontologie phénoménologique par
exemple, que des corps-sujet de Merleau-Ponty. Il y a beaucoup de comptes ontologiques phénoménologiques
anti-cartésiens, mais nous tenons à mentionner en particulier celle de Merleau-Ponty en raison de son attitude
douteuse explicite en ce qui concerne les connaissances scientifiques comme le vrai compte de la réalité.
Merleau-Ponty utilise référence à la technique anti-perspective de Cézanne à la peinture, la considérant
comme une manière plus profonde pour capturer l’expérience humaine de l’espace [1]. Ce point de vue ne
pouvait pas être plus loin du point de vue de la renaissance où la perspective était censé être un moyen de
capturer l’espace réaliste humaniste. Nous pouvons déjà voir l’hostilité entre l’ontologie cartésienne adoptée
largement par la science et les mathématiques modernes avec leur compréhension abstraite de l’espace et
l’ontologie phénoménologique qui met l’accent sur l’expérience. Cela donne plus d’explications pourquoi les
mathématiques jouent un rôle important dans les arts de la Renaissance, alors qu’elle est totalement absente si
pas en position opposée aux arts dans les temps modernes. Merleau-Ponty poursuit en expliquant cette opposition
entre les mathématiques modernes et la science en général et l’art moderne. Selon Merleau-Ponty, la
science est à l’opposé de l’art, où l’art de capturer la perception individuelle, la science est fondamentalement
anti-individualiste, à savoir positiviste. Dans son livre (la phénoménologie de la perception) Merleau-Ponty
décrit la science comme une abstraction ex post facto, et qu’il néglige la profondeur des phénomènes qu’il
cherche à expliquer [2]. En d’autres termes, cette géométrie moderne (également de la géométrie pratique
complété de la physique) avec toute sa rigueur, en quelque sorte ne peut pas saisir pleinement la profondeur
du phénomène de l’expérience des objets réels. La position de Merleau-Ponty en ce qui concerne la compréhension
de l’espace et des objets dedans, est la position générale d’architectes que ce soit par conviction ou
| 19du phénomène de l’expérience des objets réels. La position de Merleau-Ponty en ce qui concerne la compréhension
de l’espace et des objets dedans, est la position générale d’architectes que ce soit par conviction ou
simplement en suivant la convention de la discipline. Nous n’allons pas ici plaider en faveur ou contre cette
position, nous mentionnons simplement comme partie de notre préparation du terrain pour la construction de
l’espace formel. Principalement pour donner une idée du contexte actuel de la compréhension de l’espace en
architecture avant de commencer à importer la compréhension de l’espace des mathématiques dans ce territoire.
Nous pouvons être d’accord ou en désaccord avec la position de Merleau-Ponty, le fait est qu’il est vrai
que les formules ne peuvent pas saisir pleinement l’expérience humaine, mais ce n’est pas ce qu’ils sont faits
pour. Cependant, ils capturent certain type de connaissances sur l’objet réel qui n’est pas accessible aux sens.
Pour rendre cette idée plus claire, nous prenons un exemple concret de représentant une forme connue, par
exemple le cercle. Il s’agit d’une forme que nous connaissons tous, parce que nous avons vécu dans la réalité,
par exemple en regardant la pleine lune. Alors, où un cercle tracé à la main plutôt déformé par un artiste
représente mieux la perception individuelle du cercle, il ne parvient pas à nous dire ses propriétés intrinsèques,
quelque chose que l’équation du cercle peut dire avec beaucoup de détails. Cela peut sembler une observation
triviale mais c’est précisément la position problématique de l’architecture depuis un côté, nous devons être
capables de dire des informations précises sur les formes que nous concevons, tout en exprimant une vision
individuelle artistique d’eux. Ce problème n’existerait pas dans l’ingénierie puisque ce qui est important est
l’information intrinsèque, et il n’apparaît pas dans la peinture ou la sculpture parce que c’est la vision individuelle
est ce qui compte. Au 18ème siècle, le mathématicien français Gaspard Monge a développé une méthode
de représentation intermédiaire: la géométrie descriptive, portant le processus rigoureux de construction
mathématique en utilisant le dessin au lieu de formules. Géométrie descriptive a été très adapté à l’architecture
et le dessin technique, qu’il est resté jusqu’au l’essor de dessin à l’ordinateur et des logiciels de CAO, la
dominante et parfois la seule géométrie enseignée dans les écoles d’architecture. Cependant, malgré les
fondements mathématiques de la géométrie descriptive, son processus est entièrement phénoménologique à
savoir que les constructions sont basées sur notre vision. Pour cette raison, nous ne pouvons pas considérer
son application en architecture d’une application de la géométrie moderne et son espace n’est pas un espace
formel. Contrairement aux dessin à la main ou à l’aide de la géométrie descriptive, l’écriture d’une équation
pour le cercle crée un saut que le dessin ne peut pas faire, c’est parce que, après tout, le dessin est une tentative
de recréer l’expérience de voir le contour (par exemple de la pleine lune ) en utilisant une autre expérience
qui, est de voir le cercle graphique dessinée. Maintenant ce que nous obtenons avec une équation en termes de
perception n’a rien à voir avec le cercle puisque visuellement tout ce que nous voyons sont des symboles
mathématiques, donc le lien à la forme du cercle n’est pas un visuel, mais un lien mental. C’est comme donner
le cercle une double existence, l’un comme une forme phénoménologique et l’autre comme une relation
logique entre les symboles, c’est remarquable, car il est équivalent à avoir un autre moyen de comprendre et
d’apprécier les formes uniquement à travers nos esprits. Toutes les informations sur la forme peut être comprise
de cette manière, par exemple, où elle se courbe ou où il n’est pas lisse, et puis peuvent être observés
phénoménologiquement et ont trouvé être parfaitement assorti. Cela nous amène au problème d’Einstein du
chapitre précédent lorsque nous avons soulevé la question de savoir comment les mathématiques décrivent le
monde physique avec une précision étonnante. Cette distinction entre les propriétés d’un objet qui peut être
compris que par l’esprit et ceux observés par les sens, peut être retracée aux idées et formes de Platon, mais
mises de l’avant dans les temps modernes par Emmanuel Kant dans son livre Critique de la pure raison
comme noumène et phénomènes. Cette distinction pourrait être compris comme des choses en soi et les
choses comme elles apparaissent. Ces notions sont des notions importantes de la philosophie transcendantale
de Kant qui ont besoin profonde étude de la philosophie de Kant à comprendre pleinement. Dans le cadre de
cette recherche, nous allons tenter d’interpréter ces concepts afin de les intégrer dans notre discours sur
l’ancienne et la nouvelle interprétation de la géométrie, ce qui est important pour nous, en montrant la différence
entre l’espace du point de vue de l’architecture et du point de vue des mathématiques modernes. Nous
allons mener cette tentative en utilisant à nouveau l’exemple de la représentation du cercle par le dessin et par
l’équation mathématique. Simplement, en considérant la représentation mathématique comme noumène et la
représentation graphique dessiné comme phénomène, tant représenté sur la figure ci-dessous.
20 | Noumena (la chose en soi)
Un objet posé ou de l’événement, qui est connu sans l’utilisation des sens
G = 9x œ !2
f HxL = x1
2 + x2
2 = 1= , ici f représente une propriété intrinsèque du cercle comme noumène
à savoir que chaque point sur le cercle vérifie cette relation.
Phénomènes (la chose telle qu’elle apparaît)
Un objet posé ou de l’événement, qui apparaît aux sens
Représentation du cercle ici comme un phénomène visible (un cercle de rayon = 1).
Le point de vue de Kant est la suivante: lorsque nous utilisons un concept de décrire ou de classer noumènes
nous sommes en fait en employant des méthodes pour décrire ses manifestations ou des phénomènes observables
[3]. Il continue de classer les méthodes par lesquelles les humains tentent de comprendre le monde tel
qu’il est, qu’il a appelé, catégories de l’entendement: l’esthétique transcendantale, analytique transcendantale,
la logique transcendantale, et déduction transcendantale. Selon Kant, afin de transcender une observation
directe ou une expérience, les humains utilisent la raison et classifications, pour corréler entre les interrelations
entre les phénomènes que l’on observe, cependant, ils ne peuvent jamais connaître les choses en elles-mêmes
directement. Plutôt, nous devons déduire la mesure dans laquelle les pensées correspondent avec les choses en
elles-mêmes par nos observations des manifestations de ces choses qui peuvent être détectés, c’est des
phénomènes [3]. Aussi abstrait que cela puisse paraître, nous pouvons voir des éléments de cette théorie en
mathématiques et en géométrie, en particulier, à savoir que par l’usage de formules, nous sommes en mesure
de puiser dans certaines informations sur la forme (par exemple le cercle), mais ces informations comme la
courbure en un point, peuvent être observés seulement si la forme est dessinée ou trouvé dans un objet
physique, mais ce qui est le cercle en soi est inconnaissable. Ces idées de la distinction kantienne entre
noumène et phénomènes sont très importants dans notre contexte, car ils peuvent nous montrer les origines de
la suite à venir: ontologie phénoménologique de l’espace. Cela commence par le travail d’Edmund Husserl
père de la phénoménologie transcendantale et mathématicien qui a pris les idées de Kant et les a développé
davantage. Dans ce qui suit nous allons continuer plus loin, en mettant l’accent sur les notions d’espaces
physiques et formelles et la perception, à travers de brefs comptes rendus des travaux de Husserl, Rudolf
Carnap et Martin Heidegger. Husserl était préoccupé par les phénomènes de notre perception de l’espace. Il se
demandait en quoi consistent la spatialité de notre perception, en d’autres termes comment pouvons-nous
appréhender l’espace et comment pouvons-nous décrire. Dans son livre (Idées I), il définit le concept de
épochè comme processus impliqués dans le blocage des préjugés et des hypothèses pour expliquer un
phénomène en termes de son propre système inhérent de signification. Et bracketing comme un processus de
mise systématiquement sur le côté, nos diverses hypothèses et nos croyances sur un phénomène, afin d’examiner
comment le phénomène se présente dans le monde du participant. Bracketing implique donc mettre de
côté la question de l’existence réelle d’un objet envisagé, ainsi que toutes les autres questions sur la nature
physique ou objectif de l’objet; ces questions sont laissées aux sciences naturelles [4]. Par exemple, le fait de
voir un cheval est considéré comme une expérience mentale, que l’on voit le cheval en personne, dans un rêve,
ou dans une hallucination. Bracketing le cheval suspend tout jugement sur le cheval comme noumène et à la
place, analyse le phénomène du cheval dans le mental humain. Cela signifie que pour Husserl perception est
notre principale forme de savoir et n’existe pas en dehors de l’a priori de la structure de l’organisme et de son
engagement dans le monde. Dans ces exemples, nous pouvons voir déjà la distinction entre les notions d’es-
| 21notre principale forme de savoir et n’existe pas en dehors de l’a priori de la structure de l’organisme et de son
engagement dans le monde. Dans ces exemples, nous pouvons voir déjà la distinction entre les notions d’espace
formel et physique, et la première formulation de Husserl de la compréhension phénoménologique de
l’espace qui cherche à devenir sans présupposés au moyen de la réduction phénoménologique. Husserl, étant
un mathématicien naturellement favorisé une version transcendantale de la phénoménologie où l’accent de
notre compréhension de l’espace et des objets dedans, se fonde sur notre perception ignorant leur existence
physique, laissant cette question aux sciences naturelles. Nous verrons tout à fait un point de vue
phénoménologique différente plus tard avec Heidegger, où l’accent est mis beaucoup plus sur la présupposition
que nous avons sur le monde, conditionné par le fait que la personne est jeté dans le monde. Nous verrons
plus loin, un point de vue phénoménologique tout à fait différente avec Heidegger, où l’accent est mis beaucoup
plus sur la présupposition que nous avons sur le monde, conditionné par le fait que la personne est jeté
dans le monde. En Logique formelle et transcendantale Husserl tente de géométriser la perception. À savoir,
qu’il corrèle les concepts géométriques avec le sens phénoménologique pure et il donne une utilisation intradescriptive
aux outils de la géométrie; traitant ainsi les concepts et les outils opérationnellement et non
objectivement. Il décrit le corps comme le lieu de toutes les formulations sur le monde; non seulement il
occupe l’espace et le temps mais comporte également de la spatialité et la temporalité, et il a une dimension
[5]. Ce que Husserl appelle la géométrie de l’expérience pourrait être comprise comme les significations que
nous recevons quand nos corps se déplacent dans l’espace polarisant la réalité extérieure. Pour lui la conception
architecturale est une extension de cette géométrie de l’expérience au-delà du corps [6]. Husserl conçoit la
constitution de ce qu’on appelle l’espace objectif à la fois des aspects statiques / dynamiques et mono / intersubjectives.
D’un côté, il constitue un espace objectif comme le corrélat de la transformation intentionnelle
mono-subjective de la variété de champs dits sensuels que nous faisons lors de notre activité mobile corporels.
De l’autre côté comme le corrélat de la transformation intentionnelle inter-subjective de structures d’espaces
ressentis subjectivement, (c’est à dire empathie transcendantale) au sein de notre communauté de sujets
transcendantaux qui communiquent entre eux. Le travail de Husserl a influencé de nombreux philosophes,
logiciens et mathématiciens, l’un d’eux était le philosophe allemand Rudolf Carnap, qui était membre du
cercle de Vienne et un protagoniste du positivisme logique. Le travail de Rudolf Carnap couvre de nombreux
domaines, en se concentrant principalement sur les fondements de disciplines, telles que la logique, les
mathématiques et la physique, comme un élève de Husserl, il utilise certaines de ses idées, mais il les pousse
d’une manière tout à fait différente. Carnap comme nous l’avons mentionné est un positiviste logique, et ainsi
sa position est beaucoup plus anti métaphysique, mais nous devons donner un bref compte rendu des idées de
Rudolf sur les espaces formels et physiques dans le cadre de notre préparation générale pour les constructions
formelles qui suit. Rudolf Carnap a développé sa théorie philosophique de l’espace dans son ouvrage sur les
fondements de la géométrie, il distingue trois types d’espace: formels, physiques et perceptives. Selon Carnap,
les espaces formels sont les espaces mathématiques, limitée seulement par ne pas être contradictoire en soi
d’un point de vue logico-déductive, tandis que l’étude des inter-relations entre les objets déterminés de
manière empirique constitue espaces physiques. Enfin, les espaces perceptuels sont le domaine d’expériences
sensorielles immédiates aussi connu comme Anschauungen (ou espace visuel). La distinction de Carnap des
trois espaces est assez directe et claire par rapport à la phénoménologie transcendantale de Husserl, où le
formel et le perceptif sont plus liés; dans le cadre de cette recherche lorsque nous utilisons le terme: espace
formel, nous serions alors parlons de des espaces mathématiques de Carnap. Qui sont évidemment basée ce
que Einstein distingue comme la nouvelle interprétation de la géométrie, sous la seule réserve formelle et
indépendante de toute présupposition a priori sur ses objets ou de toute existence physique logique. Cette
position a une saveur beaucoup plus scientifique qui est sûr, naturel pour le cercle de Vienne avec leur rejet de
la métaphysique; cette position dans la compréhension d’espace, est la position classique de l’ingénierie et des
sciences naturelles, mais l’architecture ne partage pas cette position. Compréhension architecturale de l’espace
est plus liée à l’autre école de pensée engendré par la phénoménologie transcendantale de Husserl, mais a pris
une direction philosophique plus continental avec l’influence de Heidegger, par opposition à la direction
philosophique analytique de Carnap et la logique positiviste. Martin Heidegger qui a également été influencé
par Husserl, néanmoins développé une position philosophique très différentes de celles de Husserl et Carnap.
Heidegger est aussi un philosophe très influent avec un grand corps de travail, mais nous allons nous concentrer
ici uniquement sur son travail concernant l’espace. Nous allons remarquer immédiatement la différence de
la langue et de la pensée de Heidegger par rapport à ce que nous avons vu jusqu’à présent chez Husserl et
Carnap dans le sens où Heidegger en revanche à Husserl et Carnap n’est pas orienté vers les mathématiques et
22 | la langue et de la pensée de Heidegger par rapport à ce que nous avons vu jusqu’à présent chez Husserl et
Carnap dans le sens où Heidegger en revanche à Husserl et Carnap n’est pas orienté vers les mathématiques et
sa version de la phénoménologie est fondée dans les présupposés que les humains ont de l’espace. Ces présupposés
que Husserl essayait de bracket, Heidegger creuse profond en eux et développe son concept d’être jeté
dans le monde, aussi sa langue est beaucoup plus orienté vers les conditions de vie de tous les jours avec
l’humeur et l’anxiété. Sa position concernant la science est naturellement opposé aux philosophes analytiques
et positivistes logiques, qui considèrent les connaissances scientifiques pour être le plus proche de la réalité,
en revanche Heidegger trouve autant de vérité dans la poésie et les arts sur la réalité comme dans les enquêtes
scientifiques. Cela nous donnerait une idée de pourquoi la phénoménologie de Heidegger était beaucoup plus
répandue en architecture, qui, vers le 20ème siècle est devenu de moins en moins liée aux mathématiques.
Dans ce qui suit, nous allons présenter le concept de Heidegger de ce que nous appelions jusqu’ici espace
formel ou de l’espace mathématique, et comment il contraste avec la notion de lieu, on remarque immédiatement
la différence de la langue et de l’intérêt par rapport à la langue sèche de Carnap, qui se concentre uniquement
sur les constructions formelles et logiques. Pour la première fois, nous rencontrons une compréhension
différente de l’espace qui est fondamentalement liée à la perception, mais pas de la manière anti-présuppositionnelle
comme chez Husserl, mais bien au contraire en se concentrant sur le sens de la place de l’homme.
Heidegger, il est très clair que l’espace dans la tradition mathématique cartésienne où le calcul peut être fait à
propos de ses fonctions, n’a rien à voir avec la place qui est l’environnement dans lequel nous vivons. Heidegger
est très clair que l’espace dans la tradition mathématique cartésienne où le calcul peut être fait à propos de
ses fonctions, n’a rien à voir avec la place qui est l’environnement dans lequel nous vivons. Dans son essai
(bâtiment, le logement, la pensée), Heidegger explique espace phénoménologique, par les notions de distance
ou de spatium en latin et l’extension ou extensio. Il continue alors de définir d’abord, la distance de la manière
suivante: une distance est un espace intermédiaire ou un intervalle, donc la proximité ou l’éloignement entre
les hommes et les choses peuvent devenir de simples intervalles d’espaces intermédiaires. Il ajoute ensuite que
dans un espace qui est représenté à titre purement spatium, toute entité apparaît comme une simple chose à
une position qui peut être occupé à tout moment par quelque chose d’autre, ou remplacé par un simple marqueur.
Ce qui est plus, les simples dimensions de la hauteur, la largeur et la profondeur peuvent être extraites
de l’espace sous forme d’intervalles. Ce qui est si abstraite, nous représentons comme une variété pure de trois
dimensions [7]. Cette définition de la distance est essentiellement la définition de la distance dans la tradition
cartésienne où les entités sont représentées par des coordonnées en trois dimensions d’espace homogène, mais
Heidegger explique que cette distance peut être prélevée encore plus loin pour devenir une extension. Il
raconte ce à la construction de variétés qui sont en quelque sorte, une nouvelle abstraction de l’espace
cartésien euclidienne. Il explique ensuite qu’une pièce fait par cette variété est également plus déterminée par
la distance, il n’est plus un spatium, mais maintenant pas plus que extensio, encore plus, il y a même encore
un autre niveau d’abstraction de l’espace comme extensio qui sont: variétés purement mathématiques. Il leur
explique comme des constructions purement mathématiques de dimensions arbitraires prises que par des
relations algébriques abstraites analytiques. L’espace prévu pour cette manière mathématique peut être appelé
l’espace, une espace en tant que tel, mais dans ce sens l’espace contient pas de lieux [7]. Ici, il fait clairement
la distinction entre l’espace et le lieu qui d’une manière subtile est différente de la distinction formelle et
physique de l’espace de Carnap et de la vieille et la nouvelle interprétation de la géométrie d’Einstein. Cette
distinction heideggerienne est le plus proche pour expliquer la différence entre l’espace compris en architecture
et l’espace compris par les mathématiques et la science, ce n’est pas seulement que les architectes comprennent
l’espace à travers la vieille interprétation de la géométrie et de l’espace physique, ils comprennent
l’espace surtout que le lieu. Par contraste aux scientifiques en particulier des physiciens et ingénieurs qui sont,
par définition, concernés par l’espace physique avec la géométrie pratique complété d’Einstein; leur espace
physique contient également pas de lieux. En bref, ce qui fait l’espace en architecture n’est pas seulement sa
construction formelle comme en mathématiques, ni ses propriétés matérielles comme en physique, ni la façon
dont il est perçu psychologiquement par nos sens, mais qu’il est toujours fondamentalement constituée
d’endroits. Heidegger manifeste alors de sa position poétique concernant la réalité de l’espace, en disant que
l’espace formel avec sa géométrie formelle ne peut jamais saisir la profondeur de ce que un lieu est. Il dit que
spatium et extensio permettre à tout moment la possibilité de mesurer les choses en termes de distances,
portées et les directions, et de calculer ces grandeur. Mais le fait qu’ils sont universellement applicables à tout
ce qui a une extension, ne peut en aucun cas faire les grandeurs numériques la base de la nature des lieux et
des espaces qui sont mesurables à l’aide des mathématiques [7]. La phénoménologie de Heidegger était très
| 23ce qui a une extension, ne peut en aucun cas faire les grandeurs numériques la base de la nature des lieux et
des espaces qui sont mesurables à l’aide des mathématiques [7]. La phénoménologie de Heidegger était très
influent à l’intérieur et à l’extérieur de la philosophie, en particulier dans la théorie architecturale, fournissant
un moyen de comprendre l’espace non pas comme un espace neutre abstraite (espace mathématique formelle),
mais plutôt comme l’espace d’expériences vécues. Les phénoménologues essaient de récupérer une dimension
ontologique à l’environnement bâti, une dimension qu’ils croient a été érodée progressivement depuis l’invention
de la perspective linéaire, il y a eu une tendance à percevoir l’espace comme de plus en plus abstraite et
éloignée du corps et ses sensations. Ils prétendent que les sens doivent être traitées, et l’espace doit être perçu
avec toutes les associations phénoménologiques autant que ce soit par des moyens visuels de représentation,
par exemple la visualisation de formules mathématiques. Puisque cette recherche est centrée autour de l’application
de la géométrie moderne dans la conception architecturale, à savoir le traitement de l’espace dans sa
forme la plus abstraite, nous sommes enclins à penser qu’il s’agit d’une approche anti-phénoménologique,
cependant, ce ne serait pas un jugement tout à fait correcte. C’est parce que, malgré le fait que tous les espaces
et les formes qui vont être définis ici sont purement formelles, sans aucun lien avec des expériences monde
physique, ils ne sont pas considérés comme une architecture au sens plein, nous pourrions les considérer
comme des candidats virtuels ou proto-architecture qui pourraient être développées davantage en objets
architecturaux. Avec ces brefs comptes rendus, nous avons une idée du contexte dans lequel nous nous
trouvons en tenter d’apporter l’espace formel et la géométrie moderne dans la conception architecturale; avec
cela, nous procédons maintenant à nos constructions mathématiques.
24 | ü
2.2. Les espaces formels et variétés
ü
2.2.1 Notions topologiques de base
Puisque la majorité des travaux dans cette recherche utilisent la géométrie moderne et l’espace formel, nous
devons comprendre quelques concepts fondamentaux qui sont essentiels à sa construction, le premier d’entre
eux sera la topologie. La topologie est l’étude mathématique concerné avec les propriétés qualitatives les plus
élémentaires de formes et d’espaces, tels que la connectivité, de la continuité et de la limite, les propriétés qui
sont conservées sous déformations continues, y compris étirement et de flexion, mais pas déchirer ou collage.
Topologie a de nombreux sous-champs: la topologie générale, qui établit les aspects fondamentaux de la
topologie et examine les concepts inhérents aux espaces topologiques (exemples incluent la compacité et la
connectivité). Topologie algébrique, qui tente de mesurer le degré de connectivité en utilisant des constructions
algébriques tels que les groupes d’homotopie et homologie, et la topologie différentielle principalement
des études de variétés différentiables et leurs plongements dans d’autres variétés.
Espace topologique [11]
Soit X un ensemble, !HXL l' ensemble de parties de X,
" Õ !HXL alors " est une topologie si « œ " et X œ "
" eststable par intersections finies : Ai œ " , " i œ 81, .., n< ï›i=1
n Ai œ "
" eststable par réunions quelconques : Ai œ " , " i œ I ï‹iœI Ai œ "
ï le couple HX, "Ls' appelle espace topologique
U est un sous ensemble de X inclus dans ", U est un ouvert de X
" est une topologie séparée ó " x, y œ X distincts, $ U, V œ " x œ U, y œ V and U › V = f
Le diagramme suivant explique la topologie d ' un ensemble X = 8a, b, c<
Le bas à gauche n' est pas une topologie parce que la réunion 8b< ‹ 8c< = 8b, c< Ã " = 8f, X, 8b<, 8c<<
En bas à droite n' est pas une topologie car l' ntersection 8a, b< › 8b, c< = 8b< Ã " = 8f, X, 8a, b<, 8b, c<<
La relation de la topologie à la conception architecturale n’semble pas tout à fait clair, compte tenu de la
nature abstraite de la topologie, par contraste à la relation de la géométrie à l’architecture qui est un peu
évident. D’un point de vue quantitatif c’est vrai; la géométrie a beaucoup plus à offrir, mais il y a un parallèle
fondamental sous-jacent entre la topologie et l’architecture, à savoir l’analyse qualitative des formes et des
espaces. L’architecture n’est pas seulement concerné par la nature quantitative des formes mais aussi leurs
propriétés qualitatives par exemple compacité et la connectivité. Des termes comme voisinage, ouvert, fermé,
intérieur, extérieur, frontière, densité entre autres apparaissent simultanément entre l’architecture et la topologie,
mais il n’a jamais été une recherche importante sur la corrélation entre ces analogies. Cette recherche
porte sur l’application de la géométrie moderne à l’architecture, ce qui signifie que les questions de la topologie
seraient naturellement adressées puisque la géométrie moderne est intrinsèquement liée à la topologie,
mais ces questions topologiques ne constituent pas l’objet principal du travail.
| 25Espace métrique [8]
d : X ä Xö!+ , d s' appelle une métrique sur l' espace topologique X, if " x, y, z œ X
séparabilité : dHx, yL = 0 óx = y
positivité : dHx, yL r 0
inégalité triangulaire : dHx, zL b dHx, yL + dHy, zL
ï le couple HX, dL s' appelle un espace métrique
" x, y œ !n
, dpHx, yL = H⁄i=1
n
†xi - yi
§
p
L
1
p
d2 est la distance euclidienne et H!n
, d2L est l' espace euclidien de dimension n
Le premier de ces concept sera le voisinage. Le voisinage est l’un des concepts fondamentaux de la la topologie
et donc fondamentale pour la géométrie en particulier la géométrie différentielle, intuitivement un voisinage
d’un point dans un espace topologique est un ensemble contenant ce point, où l’on peut déplacer ce point
une certaine quantité sans quitter l’ensemble. Le voisinage est étroitement liée à la notion d’ un ouvert et de
l’intérieur.
Voisinage et ouvert [8]
HX, "L est un espace topologique, p œ X et V œ !HXL
V est un voisinage de p ó $ U œ " p œ U Õ V , nous notons #p l' ensemble des voisinages de p
HX, dL est un espace métrique, p œ X et V œ !HXL et BHp, rL = 8y œ X dHp, yL < r< est une boule ouverte
V est un voisinage de p ó BHp, rL Õ V
HX, "L est un espace topologique, U Õ X est un ouvert ó " x œ U, U œ #x
HX, dL est un espace métrique, U Õ X est un ouvertsi " p œ U $ e > 0 " x œ X , dHx, pL < e ï x œ U
Représentation de V comme un voisinage de p , V ! U un ouvert
Après avoir défini le voisinage, nous allons maintenant définir l’intérieur d’un espace, son extérieur et sa
limite. Intuitivement, l’intérieur d’un sous ensemble A d’un espace topologique X est l’ensemble des points de
A qui n’appartiennent pas à sa limite, et, naturellement, à l’extérieur de A est à l’intérieur de son complémentaire
ou en d’autres termes le complément de son adhérence. La frontière de A est naturellement l’ensemble
des points de l’adhérence de A qui ne sont pas à l’intérieur de A, et l’adhérence de A est sa frontière plus son
intérieur.
Intérieur [8]
HX, "L est un espace topologique, S œ !HXL, x œ X est un point intérieur de S ó S œ #x
S
Î = 8x œ X x point intérieur de S< s' appelle l' intérieur de S Hle plus grand ouvert contenant SL
HX, dL est un espace métrique, x œ S
Îó $ r > 0 BHx, rL Õ S
26 | Adhérence [8]
HX, "L est un espace topologique, S œ !HXL, x œ X est un point adhérent à S ó " V œ #x
, V › S " f
S = 8x œ X x point adhérent à S< s' appelle l' adhérence de S Hle plus petit fermé contenant SL
S
c
est le complémentaire de S ï HSL
c = HS
c
L
Î
et #S est la frontière de S ï #S = S îS
Î
S est un fermé ó S
c
est ouvert et S est dense dans X ó S = X
S est un fermé si S = S Hi.e. " x œ S ïx est un point de accumilation ou un point isoléL
x œ X un point de accumilation de S is " V œ #x
, V › S î 8x< " f
x œ X un point isolé de S ó $ V œ #x
, V › S î 8x< = f
HX, dL est un espace métrique, x œ Só " r > 0 BHx, rL › S " f
Représentation de x comme un point intérieur de S et y comme un point d ' adhérence Hde la frontière L de S
En outre, nous allons définir la compacité et la connexité d’un espace, mais avant, nous devons définir une
propriété fondamentale de la topologie, à savoir la continuité d’une application entre deux espaces
topologiques (ie les transformations continues). Intuitivement une application continue est une application
pour laquelle petits changements dans l’entrée provoque de petits changements dans la sortie.
Continuité (topologique) [8]
HX, "X L, HY, "Y Lsont des espaces topologiques
f : X Ø Y, est continue en xó " V œ #y $ U œ #x
f HUL Õ V
f est une application continue ó f est continue en tout x œ X
Continuité (métrique) [8]
HX, dX L, HY, dY Lsont des espaces métriques, x, x' œ X
f : X Ø Y, est continue en xó " e > 0 $ d > 0 dX Hx, x'L < e ï dY H f HxL, f Hx'LL < d
et f est k - Lipschitz continueódY H f HxL, f Hx'LL b k dX Hx, x'L
continuité (topologique) continuité (métrique)
| 27Avec la définition de la continuité, nous allons définir la notion de homéomorphisme, ce qui est essentiel dans
l’étude de la topologie; essentiellement un homéomorphisme est une application continue entre deux espaces
topologiques qui a une application inverse continue. Deux espaces avec un homéomorphisme entre eux sont
appelés homéomorphe, et si ces espaces sont des espaces métriques alors ce homéomorphisme s’appelle un
isomorphisme. Ces notions sont importantes pour comprendre la catégorisation des familles de formes qui
vont être mis en place plus tard dans la recherche. Dans les figures ci-dessous, nous pouvons voir comment
cette compréhension topologique des homéomorphismes d’objets et d’espaces peut être d’une grande utilité
dans le processus de conception, par exemple ici, nous allons concevoir une maison flottante qui est homéomorphe
à tore T
2
. Toutes les transformations utilisées dans l’élaboration de la conception sont continue et
réversible, à savoir qu’ils sont des transformations topologiques; ne conservant que les informations
topologiques sur la forme. Dans ce qui suit nous allons donner des explications précises sur ce que sont ces
informations topologiques, par exemple compacité et la connectivité.
Homéomorphisme @8D
HX, "X L, HY, "Y Lsont des espaces topologiques
f : X Ø Y, est un homéomorphisme ó f est continue, bijective etson inverse f
-1
est continue
Isomorphisme @8D
HX, dX L, HY, dY Lsont des espaces métriques, x, x' œ X
f : X Ø Y, est un isomorphismeódY H f HxL, f Hx'LL = dX Hx, x'L
Homotopie @9D
HX, "X L, HY, "Y Lsont des espaces topologiques, f , g : Xö Y continue
H : X ä@0, 1Dö Y " x œ X, HHx, 0L = f HxL et HHx, 1L = gHxLï H est une homotopie entre f , g
Représentation des transformations homéomorphiques dans un processus de conception architecturale
Maintenant nous arrivons à la caractérisation des espaces topologiques et métriques, en d’autres termes les
propriétés qualitatives de ces espaces, les propriétés comme la compacité et la connectivité. Chacune de ces
propriétés est intuitivement connu pour les architectes car ils pourraient être comprises phénoménologiquement
sur les objets de l’espace physique tridimensionnel, mais depuis notre travail est dans l’espace mathématique
formelle, nous allons fournir une description formelle de ces propriétés. Intuitivement un espace complet
est un espace métrique sans points manquants, par exemple l’espace euclidien de nombres réels avec la
métrique de distance habituelle est un espace complet. La compacité est plus intuitive du point de vue architectural,
puisque la plupart des conceptions architecturales impliquent un enclos de quelque sorte; géométriquement
ces enclos sont sous-ensembles compacts de l’espace euclidien, ce qui en soi n’est pas compact, car il
n’est pas borné. Semblable à la compacité, la connexité est assez intuitive, un espace topologique connexe ne
peut être représentée comme étant l’union d’ouverts non vides disjoints; une notion plus forte, qui est plus
proche de notre notion de connexité dans le monde physique est celui de connexité par arc. Un espace connexe
par arc, est un espace dans lequel deux points quelconques peuvent être reliés par un chemin continu, par
exemple l’espace euclidien est connexe et connexe par arc mais pas compact.
28 | Espace complet [8]
HX, dL est un espace métrique, HxnLn œ ! est une suite de X
xn est une suite de Cauchy ó " e > 0 $ n œ " " p, q œ " avec p, q r n , dIxp, xqM < e
HX, dL est complet ó " HxnLn œ ! une suite de Cauchy X , HxnLn œ ! est convergent
HX, dL est complet HX, dL n’est pas complet
Espace compact [8]
HX, "L espace topologique, HAiLi œ I une famille de recouvrements ouverts de X ó X = ‹Ai
i œ I
si J Õ I et X = ‹Ai
i œ J
ï HAiLi œ J est une famille finie de recouvrementsHla propriété de Borel - LebègueL
HX, "L estséparé et vérifie la propriété de Borel - Lebègue ï HX, "L compact
HX, dL espace métrique , HxnLn œ ! est une suite de X
x est une valeur de adhérence de HxnLn œ ! ó " r > 0 , " N œ " $ n r N dHx, xnL < r
HX, dL est compactsi toute suite de X contient au moins une valeur d ' adhérence
HX, dL est compacts' il est fermé et borné
X = ‹Ai
i œ I
famille de recouvrements ouverts X = ‹Ai
i œ J
famille finie de recouvrements
Espace connexe [8]
HX, "L espace topologique, O1, O2 ouverts de X et F1, F2 fermés de X
HX, "L est connexeó lesseules parties de X qui sont à la fois ouvertes et fermées sont f et X
HX, "L est connexe ó si X = F1 ‹ F2 avec F1 › F2 = f ï soit F1 ou F2 = f
HX, "L est connexe ó si X = O1 ‹O2 with O1 ›O2 = f ï soit O1 ou O2 = f
HX, "L est connexe ó si f : X Ø 80, 1< continue ï f constante
Connexité par arc [8]
HX, dL espace métrique, x, y œ X
f : @a, bD Ø X continue, f est un chemin de x à y, si f HaL = x et f HbL = y
HX, dL est connexe par arc ó " x, y œ X $ f œ CH@a, bD, XL chemin de x à y
| 29Composante connexe [8]
HX, dL espace métrique, x œ X , $x = 8A œ !HXL A est connexe, x œ A<
Cx = ‹A
A œ !x
est la composante connexe de x Hla plus grande partie connexe de X contenant xL
Dx = 8y œ X $ f œ CH@a, bD, XL chemin de x à y< est la composante connexe par arc de x
si x, y œ X x " y ï Cx = Cy or Cx › Cy = f et Dx Õ Cx
C est simplement connexe D est connexe par arc
Poursuivant dans nos définitions d’espaces, nous arrivons à la définition de l’espace vectoriel normé, c’est un
type fondamental de l’espace, puisque l’espace euclidien du monde physique appartiennent à cette catégorie.
Fondamentalement, un espace vectoriel normé est un espace vectoriel accompagnée d’une norme; plus tard,
nous allons donner une définition détaillée de l’espace vectoriel lorsque nous aurons affaire à des opérations
algébriques. Pour le moment, nous allons donner une définition générale des espaces vectoriels normés du
point de vue de la topologie, pour cela, nous aurons besoin de définir la notion de norme et des applications
linéaires.
Espace vectoriel normé [8]
E est un espace vectoriel sur un corps # H = ! ou $L
N : Eö!+ , N est une norme sur E qui vérifie, " x, y œ E , " l œ #
séparabilité : NHxL = 0 óx = 0E Hvecteur nulL
homogénéité positif : NHl xL = †l§ NHxL
inégalité triangulaire : NHx + yL b NHxL + NHyL
ïHE, NL est un espace vectoriel normé
si E = !n
et N = °.¥ ï HE, NL = H!n
, °.¥L est l' espace euclidien
un espace vectoriel normé complet est appelé un
espace de Banach ï l' espace euclidien est un espace de Banach
Applications linéaires (caractérisation topologique) [8]
HE, NEL, HF, NFL espaces vectoriels normés, x œ E, et f : EöF linéaire, alors f est continue
ó f est continue en 0E , Lipschitz continue Hi.e. $ k > 0 NFH f HxLL b k NEHxLL
ó f est bornée : un ouvert O de E, BEH0, 1L , BEH0, 1L et #BEH0, 1L
Représentation de l’espace euclidien de dimension 3 comme I!3
, °.¥M
30 | ü
2.2.2. Construction d’une variété
Avec ces constructions précédentes, nous sommes maintenant en mesure de définir la variété. Intuitivement,
variétés en particulier de une et deux dimensions peuvent être considérées comme des généralisations des
notions de courbes et de surfaces, qui sont les deux objets mathématiques de base pour la conception architecturale.
Ainsi, afin d’étudier la conception architecturale du point de vue de la géométrie moderne, il faut
comprendre des courbes et des surfaces non comme des objets physiques, mais comme des cas particuliers de
leurs généralisations abstraites, nommément des variétés des une et deux dimensions. Les variétés sont des
objets essentiels des mathématiques modernes, en plus de leur généralisation des notions de courbes et de
surfaces, elles utilisent les idées de l’algèbre linéaire, la topologie et l’analyse, en outre, certaines catégories
spéciales de variétés ont également une structure algébrique, ils peuvent se comporter comme des groupes, ils
sont appelés groupes de Lie. Historiquement, la notion de variété est liée à la découverte de ce qu’on appelle
géométries non euclidiennes, les enquêtes sur ce sujet ont commencé presque immédiatement après Euclide a
écrit son livre Les éléments, interrogeant précisément le cinquième postulat également connu sous le postulat
des parallèles. Le cinquième postulat dit que si une droite tombant sur deux droites fait les angles intérieurs du
même côté plus petits que deux droits, ces droites, prolongées à l’infini, se rencontreront du côté où les angles
sont plus petits que deux droits. Beaucoup de mathématiciens ont essayé de trouver une contradiction à ce
postulat, à partir des mathématiciens musulmans de the11th, 12e et 13e siècles comme Ibn Al-Haytham, Omar
Al-Khayam et Nasr El-Din al-Tusi, jusqu’à les mathématiciens européens du 18e siècle comme Giovanni
Saccheri et Johann Lambert. Mais il n’était pas jusqu’au 19ème siècle avec les travaux des mathématiciens:
Janos Bolyai, Nikolaï Lobatchevski, Carl Friedrich Gauss et Bernhard Riemann que les premiers traités de
géométries hyperboliques et elliptiques ont été écrites, et il était Gauss qui a inventé le terme de géométrie
non-euclidienne. Dans la théorie moderne, ces deux notions d’espaces elliptiques et hyperboliques correspondent
aux variétés de courbure constante positive et négative; plus loin dans cette recherche, nous allons définir
ces notions formellement.
Hyperbolique Euclidien Elliptique
Une variété est un espace topologique que près de chaque point ressemble à l’espace euclidien. Plus précisé-
ment, chaque point d’une variété à n dimensions a un voisinage qui est homéomorphe à l’espace euclidien à n
dimensions; dans cette recherche, nous allons nous concentrer uniquement sur variété différentiable. Variétés
différentiables sont également variétés topologiques, mais avec une structure différentiable globale supplémentaire
et qu’ils sont localement difféomorphe à l’espace euclidien. Nous allons définir la notion de difféomorphismes
locaux / mondiaux avec la notion générale de différentiabilité plus tard, lorsque nous commençons la
définition des opérations différentielles sur nos formes et espaces; pour le moment, nous allons donner des
définitions générales des courbes et des surfaces comme variétés. Afin de définir des courbes et des surfaces
les collecteurs, nous aurons besoin de définir la notion de sous-variétés en particulier, les sous-variétés de
l’espace euclidien. Cette définition de nos courbes et surfaces en tant que sous variétés peut être effectué par
divers façons; dans cette recherche, nous allons nous concentrer principalement sur deux façons: la submersion
et l’immersion ou en d’autres termes des équations algébriques et paramétriques. Ensuite, nous allons
montrer que ces sous-variétés de l’espace euclidien sont en eux-mêmes variétés, en choisissant des atlas dont
les cartes sont des restrictions de la forme normale. Nous verrons aussi que l’immersion ou la définition
paramétrique de nos formes est beaucoup plus pratique, du point de vue de la conception architecturale. Afin
de définir la submersion et l’immersion nous aurons besoin de deux théorèmes importants de calcul différentiel:
la théorème d’inversion locale et théorème des fonctions implicites (ces deux théorèmes seront définies
avec la notion de différentiabilité plus loin dans la recherche).
| 31Submersion @10D
f : U Õ !pö !q C
k
submersion if " x œ U, f ' HxL estsurjective
Immersion @10D
f : U Õ !pö !q C
k
immersion if " x œ U, f ' HxL est injective
Sous-variétés de !n
[13]
M Õ !n
, si " x œ M $ U œ #x et V œ #0!n voisinages ouverts et une forme normale f
f : U Õ !nö V Õ !n
f HU › ML = V › !k ä80"n-k <
ïM est une sous - variété de !n de k dimensions
Représentation de la construction d’une sous-variété de !n
de k dimensions
Variété topologique [10]
M est une variété topologique de n dimensionssi Mest un espace topologique séparé telle que
" x œ M $ U Õ M ouvert , x œ U et V Õ !n h : UöV est un homéomorphisme
Maintenant que nous avons défini la sous-variété nous allons maintenant définir formellement la variété
différentiable, et pour ce faire, nous devrons définir quelques notions importantes: celle d’une carte, d’un atlas
et celle de l’application de changement des cartes. Ce vocabulaire est assez familier à tout le monde, c’est tout
simplement parce que les cartes et les atlas du globe sont des bons exemples de ce que nous essayons de faire.
Carte d’une variété [10]
M est une variété topologique, le couple HU, jL est une carte de M
si U Õ M ouvert Hest appelé le domaine de jL et j : U Õ MöV Õ !n
est un homéomorphisme
HU1, j1L, HU2, j2L deux cartes de M, alorssi U1 › U2 " f
etsi l' application de changement des cartes
j2 Îj1
-1
: j1HU1 › U2Lö j2HU1 › U2L C
k
est un difféomorphisme
ï HU1, j1L, HU2, j2L sont compatibles
Atlas d’une variété [10]
M est une variété topologique, HUi
, jiLiœI une famille de cartes dont les domainesHUiLiœI
recouvrent M
ï $ = HUi
, jiLiœI est un atlas de M
$ est de classe C
k
si " i, j œ I, les cartesHUi
, jiL, IUj
, jj
Msont compatibles
$ est maximale si elle contient toutesles cartes compatibles avec ses propres cartes
ï un atlas maximal $ de classe C
k
est appelé une structure différentielle de classe C
k
ïune variété différentiable de classe C
k
est une
variété topologique avec une structure différentielle de classe C
k
ïune variété lisse est une variété différentiable de classe C
¶ Hle seul type que nous allons utiliserL
32 | Les courbes et les surfaces en tant que sous variétés de l’espace euclidien sont en eux-mêmes variétés en
choisissant des atlas dont les cartes sont des restrictions de forme normale, à partir de maintenant, les termes
courbe et la surface se réfèrent à variétés différentiables des une et deux dimensions.
Sous-variété comme une variété [10]
S Õ !n
est une sous - variété de l' espace euclidien !n
j : U Õ !n ö V Õ !n jHU › SL = V › !k ä80"n-k < est une forme normale
la restriction de j à S ï HU, j SL est une carte de S
ï$ = IUi
, ji S
M
iœI
est un atlas maximal de S dont les cartesHformes normales restreintesLsont compatibles
ïS est une variété différentiable dont l' atlasHstructure différentielleL est $
Sous-variété S (défini par des équations) [10]
S Õ !n
, si " x œ S $ U Õ !n
, x œ U et une submersion f
f : U Õ !nö !n-k U › S = f
-1
H80"n-k < L ïS est une sous - variété de !n de k dimensions
pour n = 3 ï si k = 1, S est une courbe, etsi k = 2, S est une surface Hhypersurface etsi n - k = 1L
Sous-variété S (défini par le paramétrage local) [10]
S Õ !n
, si " p œ S $ V Õ !n
, p œ V et $ U Õ !k
, 0"k œ U et une immersion
c : U Õ !kö !n cHUL = V › S homéomorphisme
ïS est une sous - variété de !n de k dimensions
pour n = 3 ï si k = 1, S est une courbe, etsi k = 2, S est une surface Hhypersurface etsi n - k = 1L
Représentation de la définition paramétrique de la surface S dans !3
Ces constructions sont les bases fondamentales dont nous avons besoin avant de commencer toute opération
de géométrie différentielle sur la variété, même si ces constructions d’espaces formels (ou variétés) semblent
tout à fait abstrait, Intuitivement, tous tournent autour d’une idée simple. Qui est: une variété cependant
courbée ou de forme complexe, il est traité localement comme espace vectoriel plat, ce “traité” localement
signifie qu’il est difféomorphe à un espace vectoriel plat qui est tout à fait familier et où nous pouvons faire
toutes nos opérations de l’algèbre et l’analyse. Nous allons étudier cela en détail, lorsque nous allons travailler
sur les opérations analytiques, et là nous allons montrer une famille de techniques pour extraire des informations
à partir d’une variété en les amenant localement dans les cartes à un espace vectoriel plat. En fait, quand
les architectes ont une surface courbe, ils l’appellent un objet en trois dimensions, alors qu’en fait, il est un
objet de deux dimensions plongé ou immergé (selon la surface) dans l’espace euclidien habituel de trois
dimensions.
| 33ü
2.3. Références
[1] Cézanne’s doubt, Maurice Merleau-Ponty, 1945
[2] Phenomenology of perception, Maurice Merleau-Ponty, 1945
[3] Critique of pure reason, Immanuel Kant, 1781
[4] Ideas I, Edmund Husserl, 1913
[5] Formal and trancendental logic, Edmund Husserl, 1929
[6] Architecture and the crisis of modern science, Alberto Perez-Gomez, MIT press, Cambridge, Massachussets,
1985
[7] Building, dwelling, thinking, Martin Heidegger, trans. A.Hofstadter, New York, 1971
[8] Cours de Topologie generale, Sylvain Durand, Université Paris Descartes, Paris, 2011
[9] Cours de Topologie algébrique, Julien Marché, Université Pierre et Marie Curie, Paris, 2012
[10] Cours de Géométrie Différentielle, Laurent Charles, Université Pierre et Marie Curie, Paris, 2012
34 | 3. Définition de la forme
ü
3.1. Définition paramétrique de courbes et de surfaces
Jusqu’à ce point, nous étions occupés à préparer le terrain pour la constructions mathématiques qui formeront
l’essentiel de cette recherche; ces constructions mathématiques peuvent être considérés comme de deux
familles: les définitions de la forme et des opérations sur la forme, et maintenant nous allons commencer avec
la première famille: la définition de la forme. La distinction entre les définitions et des opérations n’est pas
une distinction mathématique, mais elle découle de la vision de cette recherche du processus de la conception.
À savoir, nous commençons par définir une forme initiale, puis appliquer des opérations à elle afin de la
rapprocher de la forme finale souhaitée. Dans ce qui suit, nous allons montrer deux types principaux de la
définition de la forme mathématiquement, à savoir paramétriquement et algébriquement venant de la définition
des variétés par paramétrisation locale et par une équation algébrique. Toutefois, le but est d’amener
toutes les définitions à une définition paramétrique qui est la forme la plus adéquate pour les opérations telles
qu’elles sont définies dans cette recherche. Avant de passer à notre premier type de définitions: la définition
paramétrique de courbes et de surfaces, il convient de mentionner que même si le mot paramétrique nous
rappelle immédiatement à l’expression: l’architecture paramétrique; il faut distinguer la définition
paramétrique de formes architecturales (courbes et surfaces) du terme: l’architecture paramétrique. Bien
entendu, la définition paramétrique des courbes et des surfaces est comprise dans la notion générale de
l’architecture paramétrique, mais ce n’est pas la seule interprétation de celui-ci. Le terme: l’architecture
paramétrique est sans doute le mot plus abusé dans l’architecture contemporaine, et, naturellement, il est très
difficile de trouver une définition unifiée pour elle. Le terme: l’architecture paramétrique est sans doute
l’expression la plus abusé dans l’architecture contemporaine, et, naturellement, il est très difficile de trouver
une définition unifiée pour. Le terme est aussi synonyme à d’autres termes tels que: conception numérique,
conception computationnelle, de modélisation associative et la fabrication numérique, il existe un grand
nombre d’œuvres de la théorie architecturale développées autour de ce terme, chacun essayant de le définir et
de le transformer en une forme ou d’une autre. En tout cas, cette recherche ne cherche pas à faire la même
chose, au lieu de l’utilisation du mot: paramétrique ici est strictement dans son sens mathématique. Avec ce
dit que nous commençons par montrer les bases de définitions paramétriques de formes, à savoir quel est un
paramètre et quels sont ses avantages et ses inconvénients. Dans une fonction mathématique, par exemple
f HxL = a x2 + b x + c, f est définie par la variable x et les constantes a, b, c où la variable x est dans la liste
des arguments, alors que les constantes a, b, c ne soient pas, mais leur présence définit toute une famille de
fonctions une pour chaque ensemble de valeurs de ces constantes. Ces constantes sont appelés paramètres
mais dans la définition paramétrique de courbes et surface, nous renvoyons également aux variables indépendantes
comme paramètres, qui découle de la notion de l’équation paramétrique d’une courbe ou d’une surface.
La définition paramétrique des courbes et des surfaces est l’une des plus directe et facile à manipuler; ceci lui
fait une des définitions les plus adaptés pour l’utilisation dans la production de la forme architecturale. La
définition paramétrique est une méthode de définition d’une relation à l’aide des paramètres, pour l’essentiel,
il définit la relation comme un ensemble d’équations; par conséquent, il est défini plus précisément comme
une représentation paramétrique. Cette façon d’exprimer des courbes et des surfaces est pratique ainsi que
l’efficacité, par exemple, on peut intégrer et dériver les courbes et surfaces terme à terme, en outre, la représentation
paramétrique de courbes, a tendance à être inappropriés à l’utilisation dans des applications de CAO. Et
il n’est pas de s’adapter facilement aux transformations géométriques, comme des rotations, des translations et
mise à l’échelle. En outre, la représentation implicite est gênant pour produire des points sur une courbe ou sur
une surface, parce que les valeurs de x peuvent être choisis de telle manière que le point ne se trouve pas sur la
courbe ou de la surface. Ces problèmes sont éliminés par la réécriture des équations sous forme paramétrique,
pour ces raisons, les opérations définies plus tard sont adaptées aux définitions paramétriques de courbes et de
surface, le seul problème est que les définitions paramétriques a ses limites.
| 35Exemple de base de la variation de forme basée sur le changement des paramètres
Le cercle unité est définie par a : @0, 2 pD Õ !ö!2
, aHtL = HCosHtL, Sin HtLL
L' ellipse est définie par b : @0, 2 pD Õ !ö!2
, bHtL = H4 CosHtL, 2 Sin HtLL
Il est clair que l’équation du cercle est une forme spécifique de l’équation de l’ellipse où les fonctions coordonnées
Hx, yLsont H1 CosHtL, 1 SinHtLL au lieu de H4 CosHtL, 2 SinHtLL. Là, nous définissons une équation générale
où 2 et 4 ne sont pas fixes mais les valeurs sont des paramètres a, b et aboutissant à l’équation:
f : @0, 2 pD Õ !ö!2
, f HtL Ha, bL = Ha CosHtL, b Sin HtLL
Représentation de la génération d’un cercle et d’une ellipse en changeant les paramètres
La même analogie peut être faite avec des surfaces qui peuvent être vus comme une généralisation des courbes
à savoir une application f : !2ö!3
(une définition plus élaborée de courbes et de surfaces paramétrées sera
montré plus tard). Cette idée semble si simple, est très important dans cette recherche, il montre simplement
comment les variations de la forme peuvent être produites.Variation qui sont utilisés pour tester le potentiel de
la forme en termes d’esthétique, de la structure, etc. Avant de montrer la puissance et l’étendue de cette
méthode pour générer des formes architecturales, nous allons d’abord sur les définitions formelles de courbes
et surfaces paramétriques, ces définitions nécessite certaines notions importantes que nous allons définir plus
tard dans la section des opérations analytiques. Donc, pour le moment, nous allons donner une formalisation
générale pour une courbe régulière et pour une surface régulière.
Courbe régulière [1]
g : Ha, bL ö!2
, gHtL = HxHtL, yHtLL est une courbe régulière H°g' HtL¥ " 0L et différentiables par morceaux
a : Ha, bL Õ ! ö!3
est une courbe régulière if " t œ Ha, bL , a est différentiable et °a' HtL¥ " 0"I","3
M
si " t œ Ha, bL , °a' HtL¥ = 1 alors a a une vitesse unité
Surface régulière [1]
% Õ !2 open, q œ % and p = cHqL
c : %ö& Õ !3
, cHu, vL = Hx1Hu, vL, x2Hu, vL, x3Hu, vLL is a regular injective patch Ha regular surfaceL
Il est vrai que ce n’est pas intuitif concevoir en utilisant des formules. Cela découle de notre notion de dessin à
la main qui se sent comme interpolation travers des points invisibles. C’est pour cela que l’interpolation est la
méthode la plus populaire pour le dessin parmi les architectes et il n’est pas surprenant que tous les logiciels
de CAO est basé sur une forme ou une autre de points l’interpolation, que ce soit splines cubiques ou nurbs.
Nous allons montrer prochain, que la conception en utilisant des formules peut être intuitif après un certain
temps et très manipulatrice comme les interpolations. Le point de départ naturel pour une telle tâche est
d’examiner certaines des courbes et des surfaces classiques en !3
, comprendre comment elles fonctionnent et
ensuite commencer à construire de nouvelles formules sur elles. Il existe des exemples fondamentaux, que les
comprendre constitue la base de la création de formules pour de nouvelles courbes et des surfaces. Les exemples
suivants de courbes sont très utiles dans la conception, en particulier l’épicycloïde qui est la plus élaborée.
36 | Quelques courbes de base [1]
Nous allons maintenant donner les formules de base pour les paramétrages de quelques courbes classiques,
l’idée est simplement que par la compréhension de la façon dont leurs traces se rapportent à leur paramétrage,
nous serons en mesure de construire nos propres courbes d’une certaine forme conçue.
L' ellipse
g : U Õ @0, 2 pD Õ !ö!2
, gHtL = Ha CosHtL, b Sin HtLL , avec U ouvert
La spirale d ' or
g : U Õ @0, 2 pD Õ !ö!2
, gHtL = Ia ‰
b t CosHtL, a ‰
b t SinHtLM , avec U ouvert
L' épicycloïde
g : U Õ @0, 2 pD Õ !ö!2
, avec U ouvert
gHtL = Ha Hb + 1L CosHtL - a CosHHb + 1L tL, a Hb + 1L SinHtL - a SinHHb + 1L tLL
L' hélice
a : U Õ @0, 4 pD Õ !ö!3
, aHtL = Ha CosHtL, a SinHtL, b tL , avec U ouvert
Le noeud de tore
a : U Õ @0, 2 pD Õ !ö!3
, avec U ouvert
aHtL = HH8 + 3 CosH5 tLL CosH2 tL, H8 + 3 CosH5 tLL SinH2 tL, 5 SinH5 tLL
| 37Quelques surfaces de base [1]
Même que nous n’avons pour les courbes, nous allons faire pour les surfaces, les surfaces montrent ci-dessous
seront les traces d’une des surfaces locales injectives réguliers, en d’autres termes chacun d’eux est
paramétrée par une seule carte, et & = c(%) une surface régulière. Encore une fois l’idée est simplement que
par la compréhension de la façon dont ces traces se rapportent à leur paramétrage, nous serons en mesure de
construire nos propres surfaces d’une certaine forme conçue.
Le plan !2
Hi.e. Graphe d ' une fonction hL
h : % Õ @0, 2 pD
2ö! fonction réelle différentiable de deux variables
c : % Õ @0, 2 pD
2ö& Õ !3
est une surface locale régulière, où % ouvert
hHu, vL = SinHuL SinHvL
cHu, vL = Hu, v, a hHu, vLL
Le cylindre IS
1 ä !M
c : % Õ @0, 2 pD
2ö& Õ !3
est une surface locale régulière, où % ouvert
cHu, vL = Ha CosHuL, b SinHuL, c vL
La sphère S
2
c : % Õ @0, 2 pD
2ö& Õ !3
est une surface locale régulière, où % ouvert
cHu, vL = Ia CosHuL SinI
v
2
M, b SinHuL SinI
v
2
M, c CosI
v
2
MM
Le tore T
2
c : % Õ @0, 2 pD
2ö& Õ !3
est une surface locale régulière, où % ouvert
cHu, vL = HCosHuL Ha + b CosHvLL, SinHuL Ha + b CosHvLL, c SinHvLL
38 | Modification d’une courbe standard
Ces courbes et surfaces classiques peuvent être utilisés comme base pour les construction de formules
décrivant les formes souhaitées. Ceci est fait par des adaptations de ces courbes et des surfaces classiques, ces
adaptations peuvent être modification de leurs formules ou par des combinaisons de différents types. Premier
exemple de ces adaptation serait que de passer de l’hélice spirale à une courbe horizontale allongée. Ceci peut
également être considéré comme une fusion entre la spirale et l’hélice. Un autre exemple plus élaboré est
l’adaptation de l’épicycloïde (avec une cuspide i.e. cardioïde) à une courbe en forme de coeur. Ici, la modification
de la formule est plus fondamental, mais l’esprit de l’épicycle reste présent dans la courbe en forme de
coeur.
Spiral hélice à la courbe en spirale allongée
L’équation de l’hélice spirale est donnée par
b : U Õ @0, 4 pD Õ !ö!2
, aHtL = Kt, 2 ‰
-2
25
t
SinHtL, 2 ‰
-2
25
t CosHtLO
et est ensuite modifié pour
j : U Õ @0, 4 pD Õ !ö!3
, jHtL = It + SinI
t
2
M -
1
100 SinHtL, SinI
t
2
M, 1 - CosHtL + SinI
t
2
MM
Représentation de la modification de l’hélice spirale
Épicycloïde (avec une cuspide i.e. cardioïde) à une courbe en forme de coeur
L’équation de l’épicycloïde est donnée par
b : U Õ @0, 2 pD Õ !ö!2
, aHtL = H2 SinHtL - SinH2 tL, 2 CosHtL - CosH2 tLL
et est ensuite modifiée pour l’équation de la courbe en forme de coeur
a : U Õ @0, 2 pD Õ !ö!2
, aHtL = ISinHtL
3
, I
5
3
+ CosHtLM HCosHtL H1 - CostHtLLLM
Représentation de la modification de cardioïde
| 39Modification d’une surface standard
La même maintenant peut être fait pour les surfaces, nous pouvons commencer à partir d’une forme générale
classique d’un ellipsoïde et l’adapter à une surface en forme de coeur.
Sphère à une surface en forme de coeur
L’équation de la sphère est donnée par
b : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3
, bHu, vL = ISinI
v
2
M CosHuL, SinI
v
2
M SinHuL, I1 - CosI
v
2
MMM
et est ensuite modifiée pour l’équation de la surface en forme de coeur
c : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3
,
cHu, vL = I
2
3
CosHuL SinI
v
2
M
5
,
1
2
SinHuL SinI
v
2
M
5
,
2
3
I
5
3
+ CosI
v
2
MM CosI
v
2
M I1 - CosI
v
2
MM + 1M
Représentation de la modification de la sphère
Ces exemples donnent une idée de la façon dont certaines formes en général peuvent être dérivées des formes
géométriques classiques (comme l’ellipse et l’ellipsoïde), mais dans le but de prendre ce au niveau de la
conception architecturale, nous avons besoin d’une technique beaucoup plus manipulable. Nous allons montrer
que les formes que nous allons concevoir, sont des variantes de la sphère S
2
, le tore T
2
, le cylindre
IS
1 ä !M et le plan !2
. Si nous sommes en mesure de contrôler la révolution d’une certaine courbe de profil,
nous pouvons parvenir à une assez grande variété de formes précisément conçus. Dans la sphère S
2
, la courbe
de profil est un demi-cercle et la courbe de révolution est un cercle. Dans le tore T
2
, la courbe de profil et la
courbe de révolution sont tous les deux cercles. Dans le cylindre IS
1 ä !M, la courbe de profil est une ligne et la
courbe de révolution est un cercle. Dans le plan !2
, les deux courbes de paramétrage sont des lignes. L’ensemble
des exemples suivant montrent comment nous pouvons être très élaboré dans le travail sur les deux
courbes de paramétrage dans les directions u et v, et arriver à des formes qui peuvent facilement être utiles
dans l’architecture. Les quatre familles de surfaces que nous serons concernés par sont: la sphère S
2
, le tore
T
2
, le cylindre IS
1 ä !M et le plan !2
, les deux premiers sont compact, le cylindre et le plan !2
sont noncompact.
Il est important de savoir que nous pouvons construire des surfaces continues paramétrés par une
seule carte seulement jusqu’au degré 1 (du genre topologique). Pour la construction de formes qui ont deux ou
plusieurs trous, soit nous utilisons plusieurs surfaces paramétriques locales ou de définir la forme algébriquement
à savoir comme un ensemble de zéros d’une fonction de trois variables.
40 | ü
3.2. Familles de surfaces
Afin que nous construisons une recherche concluante, nous devons nous limiter à quelques familles de surfaces
qui couvrent une grande variété de types de bâtiments architecturaux et alors nous pouvons bien les
modifier et de les analyser. Pour cette tâche, nous allons limiter nous-mêmes sur des surfaces qui peuvent être
paramétrées par une seule surface locale.
Homéomorphe au plan !2
(graphe hHu, vL)
Ce type de surfaces est très utile pour la conception de bâtiments de faible hauteur, couvrant d’une parcelle
rectangulaire. La surface n’est que le graphique de la fonction h : Hu, vL œ !2ö!, il est relativement facile à
comprendre que les autres types et il est adapté pour des conceptions architecturales des grands espaces
comme des ateliers, des salles de sport et de petites usines. Ici, les deux courbes de paramétrage sont des
courbes ouvertes.
nous commençons par construire l' équation h
h : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!,
hHu, vL = I 1 -
1
2
Sin HuL SinHvL - SinI
v
2
M
45
+ CosHvL
2
M I1 - CosI
u
2
M
90M I1 - CosI
v
2
M
90M
puis nous mettrons h dansl' équation finale de la surface
c : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3
, cHu, vL = Hu, v, hHu, vLL
cHu, vL = Iu, v, I 1 -
1
2
Sin HuL SinHvL - SinI
v
2
M
45
+ CosHvL
2
M I1 - CosI
u
2
M
90M I1 - CosI
v
2
M
90MM
Représentation d’une courbe de paramétrage dans la direction u
Représentation de la famille de surfaces homéomorphes au plan !2
(graphe hHu, vL)
| 41Application architecturale
Maintenant que nous avons défini cette famille de surfaces, nous allons montrer un exemple concret de la
façon dont cette surface peut être utilisé comme forme architecturale. Dans cet exemple, une fois que nous
fixons les famille de surfaces, nous commençons à rechercher des variations en faisant simplement varier les
paramètres de l’équation de base ci-dessus jusqu’à ce que nous allons faire un choix de la surface qui va être
l’enveloppe du bâtiment en fonction de certains critères.
Représentation de l’exploration de différentes surfaces de cette famille
Représentation d’une conception architecturale choisie de cette famille de surfaces
42 | Homéomorphe au plan !2
(non graphe)
Ce type de surfaces est également très utile pour la conception de bâtiments de faible hauteur, couvrant d’une
parcelle non rectangulaire. Bien que cette famille de surfaces est également homéomorphes au plan !2
ce
n’est pas un graphe hHu, vL cela signifie que le terrain que nous couvrons peut également prendre diverses
formes.
on commence par la construction de l’équation de la courbe u
f0 : U Õ @0, 2 pD Õ !ö!, f0HuL = u +
4
5
SinHuL
f1 : U Õ @0, 2 pD Õ !ö!, f1HuL = 2 + CosI
3
2
u + pM
f2 : U Õ @0, 2 pD Õ !ö!, f2HuL = 1 +
1
5
Sin
3
2
u +p
2
20
f3 : U Õ @0, 2 pD Õ !ö!, f3HuL =
1
2
I1 - CosI
u
2
M
20M
f : U Õ @0, 2 pD Õ !ö!2
, f HuL = H f0HuL, f1HuL f2HuL f3HuLL
puis nous construisons la courbe v
g0 : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!, g0Hu, vL = H2 + CosHn u + pLL I Hv - pL +
1
10 SinH2 vLM
g1 : U Õ @0, 2 pD Õ !ö!, g1HvL = 2 - CosH2 vL
g2 : U Õ @0, 2 pD Õ !ö!, g2HvL = 1 +
1
10 CosI2
v
2
M
20
g3 : U Õ @0, 2 pD Õ !ö!, g3HvL =
1
2
I1 - CosI
v
2
M
20M
g : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!2
, gHu, vL = Hg0Hu, vL, g1HvL g2HvL g3HvLL
et enfin nous composons les deux applications dans l’équation finale de la surface
c : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3
, cHu, vL = I f0HuL,
1
4
g0Hu, vL,
1
2
g1HvL g2HvL g3HvL f1HuL f2HuL f3HuLM
cHu, vL = Ju +
4 SinHuL
5
,
1
4
I2 - CosI
3 u
2
MM IHv - pL +
1
10 SinH2 vLM,
1
8
I1 - CosI
u
2
M
20M I2 - CosI
3 u
2
MM J1 +
CosHvL
20
10 N I1 - CosI
v
2
M
20M H2 - CosH2 vLL J1 +
1
5
SinI
1
2
Ip +
3 u
2
MM20NN
Représentation de la courbe u
Représentation de la famille de surfaces homéomorphes au plan !2
(non graph)
| 43Application architecturale
Comme dans l’exemple précédent, nous allons fixer une famille de surfaces et commence alors à rechercher
les variations de la surface de base de cette famille qui seraient appropriés pour la conception de l’enveloppe
du bâtiment. Il ressort clairement de ces variantes sélectionnées de la surface que l’espace de recherche de
surfaces de la même famille peut être très grande, ce qui permet une grande quantité d’options à choisir et
adapté à de nombreuses applications architecturales.
Représentation de l’exploration de différentes surfaces de cette famille
Représentation d’une conception architecturale en utilisant cette famille de surfaces
44 | Homéomorphe au cylindre IS
1 ä !M
Ce type de surfaces construction est très utile pour la conception des tours, intuitivement la peau de tours et
immeubles de grande hauteur sont homéomorphes au cylindre IS
1 ä !M. La même méthode de la courbe de
révolution u et la courbe de profil v est utilisé ici, mais avec plus de précisions sur la courbe de révolution u.
On peut voir cette courbe comme la base du plan de l’étage à un niveau donné, et en changeant le niveau, la
forme de la courbe de révolution (i.e. de plan de l’étage) seront également changer. Comme nous le savons le
niveau est rien que la valeur de la courbe de profil v à une v fixée En d’autres termes, nous pouvons voir la
courbe de la révolution en termes de Hu, vL au lieu de seulement u. L’exemple suivant illustre cette construction.
on commence par la construction de l’équation de la courbe de révolution u
f1 : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!, f1Hu, vL = CosHuL 1 -
J
9
10
v-pN
p
SinH2 uL
4
f2 : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!, f2Hu, vL = SinHuL 1 -
J
9
10
v-pN
p
SinH2 uL
4
f : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!2
, f Hu, vL = H f1Hu, vL, f2Hu, vLL
puis nous construisons la courbe de profil v
g1 : U Õ @0, 2 pD Õ !ö!, g1HvL = 1 + SinHvL
2
g2 : U Õ @0, 2 pD Õ !ö!, g2HvL = 2 Hv - SinHvLL
g : U Õ @0, 2 pD Õ !ö!2
, gHvL = Hg1HvL, g2HvLL
et enfin nous composons les deux applications dans l’équation finale de la surface
c : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3
, cHu, vL = H f1Hu, vL g1HvL, f2Hu, vL g1HvL, g2HvLL
cHu, vL = CosHuL 1 -
J
9
10
v-pN SinH2 uL
4
p
I1 + SinHvL
2
M, SinHuL 1 -
J
9
10
v-pN SinH2 uL
4
p
I1 + SinHvL
2
M, 2 Hv - SinHvLL
Représentation de la courbe de profil et les famille de surfaces homéomorphes au cylindre IS
1 ä !M
| 45Homéomorphe au disque unité ID1
M
Ce type de surfaces appartiennent à la famille surface homéomorphe au disque unité ID1
M, ils peuvent être
considérés comme graphes sur des domaines non rectangulaires. Ils sont utiles dans la conception de bâtiments
de faible hauteur, on distingue deux cas: homéomorphes au disque unité et homéomorphes à une
Couronne.
on commence par la construction de l’équation de la courbe de révolution u
f1 : U Õ @0, 2 pD Õ !ö!, f1HuL = I1 + I
1
2
SinH2 uL
3
MM I 13
10 + CosHuL
5
M CosHuL
f2 : U Õ @0, 2 pD Õ !ö!, f2HuL = I1 + I
1
2
SinH2 uL
3
MM I 13
10 + CosHuL
5
M SinHuL
f : U Õ @0, 2 pD Õ !ö!2
, f HuL = H f1HuL, f2HuLL
puis nous construisons la courbe de profil v
g1 : U Õ @0, 2 pD Õ !ö!, g1HvL = v
g2 : U Õ @0, 2 pD Õ !ö!, g2HvL = 3 SinI
v
2
M
g : U Õ @0, 2 pD Õ !ö!2
, gHvL = Hg1HvL, g2HvLL
et enfin nous composons les deux applications dans l’équation finale de la surface
c : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3
, cHu, vL = H f1HuL g1HvL, f2HuL g1HvL, g2HvLL
cHu, vL = Iv CosHuL I 13
10 + CosHuL
5
M I1 +
1
2
SinH2 uL
3
M, v SinHuL I 13
10+ CosHuL
5
M I1 +
1
2
SinH2 uL
3
M, 3 SinI
v
2
MM
Représentation de la courbe u
Représentation de la famille de surfaces homéomorphes au disque unité ID1
M
46 | Application architecturale
Encore une fois le même procédé est appliqué, à savoir une famille de surfaces est fixe et ensuite une
recherche de variantes est réglée en modifiant les paramètres de l’équation de base de la paramétrisation, et à
nouveau comme dans les exemples précédents l’espace des variations est assez grande, ce qui permettra une
riche variété de choix. Ces sélections peuvent être simplement basés sur les choix esthétiques ou comme nous
allons voir plus tard dans la recherche basée sur des modèles de recherche algorithmiques.
Représentation de l’exploration de différentes surfaces de cette famille
Représentation d’une conception architecturale en utilisant cette famille de surfaces
| 47Homéomorphe à la sphère (S
2
)
Ce type de surface est tout à fait utile pour la conception de l’enveloppe du bâtiment continu (i.e. la façade
continuant sur le toit). Cette famille de formes est devenu très populaire dans l’architecture dans les deux
dernières décennies en raison de l’intérêt des architectes dans la «continuité» comme caractéristique de la
forme. Pour cette raison, la construction des équations qui génère des formes qui sont homéomorphe à la
sphère S
2
est très utile du point de vue de la conception architecturale contemporaine.
on commence par la construction de l’équation de la courbe de révolution u
f1 : U Õ @0, 2 pD Õ !ö!, f1HuL = CosHuL +
5
2
CosI
u
2
M
8
f2 : U Õ @0, 2 pD Õ !ö!, f2HuL = 2 SinHuL
f : U Õ @0, 2 pD Õ !ö!2
, f HuL = H f1HuL, f2HuLL
puis nous construisons la courbe de profil v
g1 : U Õ @0, 2 pD Õ !ö!, g1HvL =
3
2
I2 +
35
100 CosI
v
2
MM I1 - CosI
v
2
M
6
+ SinI
v
2
MM
g2 : U Õ @0, 2 pD Õ !ö!, g2HvL = v - SinHvL
g : U Õ @0, 2 pD Õ !ö!2
, gHvL = Hg1HvL, g2HvLL
et enfin nous composons les deux applications dans l’équation finale de la surface
c : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3
, cHu, vL = H f1HuL g1HvL, f2HuL g1HvL, g2HvLL
cHu, vL = I
3
2
ICosHuL +
5
2
CosI
u
2
M
8
M I2 +
35
100 CosI
v
2
MM I1 - CosI
v
2
M
6
+ SinI
v
2
MM,
3 SinHuL I2 +
35
100 CosI
v
2
MM I1 - CosI
v
2
M
6
+ SinI
v
2
MM, v - SinHvLM
Représentation de la courbe u
Représentation de la famille de surfaces homéomorphes à la sphère S
2
48 | Homéomorphe au tore (T
2
)
Ce type de surfaces est très utile pour la conception de bâtiments de faible hauteur, qui a un atrium ou d’une
cour. Dans cette construction, on définit des équations pour les surfaces avec une courbe de révolution u fermé.
on commence par la construction de l’équation de la courbe de révolution u
f1 : U Õ @0, 2 pD Õ !ö!, f1HuL = I3 CosHuL -
1
5
CosH3 uLM J1 +
7
10 SinI
3
2
uM
3
N I1 +
1
2
SinIu -
p
4
M
2
M
f2 : U Õ @0, 2 pD Õ !ö!, f1HuL =
3
2
I3 SinHuL -
1
5
SinH3 uLM J1 +
7
10 SinI
3
2
uM
3
N I1 +
1
2
SinIu -
p
4
M
2
M
f : U Õ @0, 2 pD Õ !ö!2
, f HuL = H f1HuL, f2HuLL
puis nous construisons la courbe de profil v
g1 : U Õ @0, 2 pDä@0, 2 pD Õ !2ö!, g1Hu, vL =
3
2
+ CosHvL
g2 : U Õ @0, 2 pDä@0, 2 pD Õ !2ö!, g2Hu, vL = 2 SinHvL J1 +
6
5
SinI
3
2
uM
2
N
g : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!2
, gHu, vL = Hg1Hu, vL, g2Hu, vLL
et enfin nous composons les deux applications dans l’équation finale de la surface
c : % Õ @0, 2 pDä@0, 2 pDö!3
, cHu, vL = H f1HuL g1Hu, vL, f2HuL g1Hu, vL, g2Hu, vLL
cHu, vL = JI3 CosHuL -
1
5
CosH3 uLM I 3
2
+ CosHvLM J1 +
7
10 SinI
3
2
uM
3
N J1 +
1
2
SinIu -
p
4
M
2
,
3
2
I
3
2
+ CosHvLM I3 SinHuL -
1
5
SinH3 uLM J1 +
7
10 SinI
3
2
uM
3
N I1 +
1
2
SinIu -
p
4
M
2
M,
2 SinHvL J1 +
6
5
SinI
3
2
uM
2
NN
Représentation de la courbe u
Représentation de la famille de surfaces homéomorphe au tore T
2
| 49Application architecturale
Dans ce dernier exemple, on voit à nouveau le même processus de génération de variations basées sur la
modification des paramètres de l’équation de paramétrisation de base, suivie d’une sélection d’une variante
qui va être utilisé comme l’enveloppe du bâtiment. Cependant, nous voyons dans cet exemple, le panneautage
de la surface choisie par un composant architectural, ce processus, nous allons expliquer en détail plus tard
avec les opérations algorithmiques.
Représentation de l’exploration de différentes surfaces de cette famille
Représentation d’une conception architecturale en utilisant cette famille de surfaces
50 | ü
3.3. Définition algébrique (non paramétriques) des courbes et des surfaces
Maintenant que nous avons défini nos familles de surfaces paramétriquement, nous allons maintenant explorer
la définition des courbes et des surfaces par des équations polynomiales, nous avons déjà vu cette définition
quand nous avons défini les variétés par des équations. Comme nous l’avons mentionné avant la définition
algébrique des courbes et des surfaces n’est pas aussi simple que la définition paramétrique, mais il peut
s’avérer plus efficace dans la conception des formes plus complexes. Il s’agit d’une définition beaucoup plus
généralisée des courbes et des surfaces et avec elle, nous sommes capables d’atteindre des formes plus complexes
et élaboré, le problème est qu’il est théoriquement plus complexe et moins pratique en termes de
manipulations par des opérations. Cependant, il est important de donner une idée de définitions algébriques,
car dans la conception architecturale bien sûr nous devons explorer les conceptions de l’enveloppe des bâtiments
qui vont au-delà d’un seul paramétrage d’une surface locale. Par exemple, les formes qui ont plus d’un
trou, comme le tore à n-trous, qui pourrait être utile dans la conception des bâtiments à plusieurs cours, ici il
est clair que nous aurons besoin de plus qu’une seule surface locale pour couvrir cette surface. Dans ces cas, la
stratégie est de trouver une équation polynomiale, puis de décrire la surface comme l’ensemble des zéros de
cette équation, puis de trouver des surfaces locales (traités comme des graphes) sur ces surfaces en utilisant les
théorème des fonctions implicites. Avec cette technique, nous pouvons appliquer toutes les opérations
algébriques, analytiques et algorithmiques nécessaires afin de manipuler et de transformer la forme selon la
conception désirée. Avant de commencer, nous aurons besoin de quelques notion importante de la géométrie
algébrique, la première serait l’hyper-plan et ensuite l’hyper-surface, puis nous allons commencer par définir
les plus élémentaires de définitions algébriques de courbes et de surfaces à savoir les coniques et les
quadriques. Après cela, nous allons explorer certaines des surfaces algébriques plus complexes et belles et
essayer de trouver des paramétrages pour eux.
Représentation de la surface de genre avec deux trous (paramétrage en deux surfaces locales)
| 51Hyper plan de !n
[2]
L œ H!n
L
*
l' espace dual de !n
L : !nö !, L Hx1, ..., xnL = a1 x1 + ... + an xn + a0, $ i œ 81, ..., n< ai " 0
H = 8Hx1, ..., xnL œ !n LHx1, ..., xnL = 0< = ker L est un hyper plan
Hyper surface de !n
[2]
P œ QkH!L est un polynôme de degré k à n variables
G = 8Hx1, ..., xnL œ !n PHx1, ..., xnL = 0< = ker P est une hyper surface
Les formes non linéaires les plus simples seraient ceux du degré 2, dans le cas des courbes, elle est appelée
coniques et dans le cas des surfaces, elle est appelée quadriques
Quadriques de !n
[2]
P œ Q2H!L est un polynôme de degré 2 en n variables
G = 9Hx1, ..., xnL œ !n PHx1, ..., xnL = ⁄i=1
n aii xi + ⁄i, j=1
n bij xi x j + c = A
t
x + x B t
x + c = 0= ,
avec A, B œ MnH!L et c œ !
n = 2 ï G est une conique et n = 3 ï G est une quadrique
Les coniques de !3
[2]
Les plus basiques des courbes algébriques sont les coniques, leur importance dans l’architecture est très
significatif, à savoir ils sont largement utilisés en raison de leurs capacités structurelles. Nous avons déjà
paramétrages de ces courbes, maintenant, nous allons donner leurs définitions implicites.
L' ellipse
f : !2ö !, f Hx, yL =
x
2
a
2 +
y
2
b
2 - 1
G = 9Hx, yL œ !2
f Hx, yL = 0= = ker f
La parabole
f : !2ö !, f Hx, yL = y - a x2
G = 9Hx, yL œ !2
f Hx, yL = 0= = ker f
L' hyperbole
f : !2ö !, f Hx, yL =
x
2
a
2 -
y
2
b
2 - 1
G = 9Hx, yL œ !2
f Hx, yL = 0= = ker f
52 | Les quadriques de !3
[2]
Après avoir défini les coniques nous allons maintenant définir leurs équivalents en deux dimensions à savoir
les surfaces quadriques, leur nom, bien sûr vient du fait que leurs polynômes sont tous de second degré
(équation quadratique).e all of second degree (quadratic equation). Tout comme les coniques nous avons des
paramétrisations de ces quadriques, mais nous allons maintenant les définir comme l’ensemble des zéros de
leurs polynômes. Dans la suite, nous allons présenter quelques exemples classiques importants de quadriques
non dégénérée / dégénérés de !3
.
L' ellipsoid
f : !3ö !, f Hx, y, zL =
x
2
a
2 +
y
2
b
2 +
z
2
c
2 - 1
G = 9Hx, y, zL œ !3
f Hx, y, zL = 0= = ker f
Le paraboloïde elliptique
f : !3ö !, f Hx, y, zL =
x
2
a
2 +
y
2
b
2 - z
G = 9Hx, y, zL œ !3
f Hx, y, zL = 0= = ker f
Le paraboloïde hyperbolique
f : !3ö !, f Hx, y, zL =
x
2
a
2 -
y
2
b
2 - z
G = 9Hx, y, zL œ !3
f Hx, y, zL = 0= = ker f
| 53Encore de Quadrics de !3
[2]
Le cône elliptique
f : !3ö !, f Hx, y, zL =
x
2
a
2 +
y
2
b
2 -
z
2
c
2
G = 9Hx, y, zL œ !3
f Hx, y, zL = 0= = ker f
Le cylindre elliptique
f : !3ö !, f Hx, y, zL =
x
2
a
2 +
y
2
b
2 - 1
G = 9Hx, y, zL œ !3
f Hx, y, zL = 0= = ker f
L’hyperboloïde
f : !3ö !, f Hx, y, zL =
x
2
a
2 +
y
2
b
2 -
z
2
c
2 - 1 , G = 9Hx, y, zL œ !3
f Hx, y, zL = 0= = ker f Hune nappeL
f : !3ö !, f Hx, y, zL =
x
2
a
2 +
y
2
b
2 -
z
2
c
2 + 1 , G = 9Hx, y, zL œ !3
f Hx, y, zL = 0= = ker f Hdeux nappesL
Hyperboloïde une nappe Hyperboloïde deux nappes
54 | ü
3.3.1. Paramétrage de la surface algébrique
Maintenant on va prendre quelques exemples de surfaces ne pouvant pas être paramétrées en utilisant une
seule surface locale et essayer de les paramétrer en utilisant plusieurs cartes, comme nous l’avons mentionné
plus tôt que cela est possible en utilisant le théorème des fonctions implicites. L’idée est de trouver des
voisinages ouverts V Õ !3
, W Õ !2
et une fonction h : Wö!2
de classe C
1de telle sorte que chaque point
Hx, y, zL œ V avec f Hx, y, zL = 0 (i.e. se trouvant sur la surface) si et seulement si la coordonnée z peut être
exprimée comme la fonction réelle hHx, yL = z, où les coordonnées Hx, yL œ W et #z
f Hx, y, zL est inversible.
Cette méthode peut être vu dans les exemples suivants où la paramétrisation est donnée par les surfaces
locales (graphes) sous la forme cHx, yL = f Hx, y, hHx, yLL . Dans cet exemple nous avons une surface définie
par un polynôme de degré six, qui sont capables de paramétrer l’aide de deux cartes (surfaces locales).
Le Distel [3]
f : !3ö !, f Hx, y, zL = x
2 + y
2 + z
2 + 3000 Ix
2 + y
2
M Ix
2 + z
2
M Iy
2 + z
2
M - 3 ,
G = 9Hx, y, zL œ !3
f Hx, y, zL = 0= = ker f
ï f Hx, y, zL = f Hx, y, hHx, yLL h : !2ö !, hHx, yL = z
la surface peut être paramétré par deux carte Hsurfaces localesL
cHu, vL =
Ku, v, -
+-K-
1
6000 Ix
2+y
2
M
-
x
4
2 Ix
2+y
2
M
-
x
2
y
2
x
2+y
2 -
y
4
2 Ix
2+y
2
M
+
1
6000 Ix
2+y
2
M
I
,I1 + 36 000 x
2 - 6000 x
4 + 9 000 000 x
8 +
36 000 y
2 - 12 000 x
2
y
2 - 6000 y
4 - 18 000 000 x
4
y
4 + 9 000 000 y
8
MMO
Représentation de la surface donnée par ses ensemble de zéros et par paramétrage par deux surfaces locales
| 55Plus d’exemples de paramétrisation des surfaces algébriques [3]
Les Chubs
f : !3ö !, f Hx, y, zL = x
4 - x
2 + y
4 - y
2 + z
4 - z
2 +
2
5
, G = 9Hx, y, zL œ !3
f Hx, y, zL = 0= = ker f
ï f Hx, y, zL = f Hx, y, hHx, yLL h : !2ö !, hHx, yL = z ï cHu, vL = Hu, v, hHu, vLL
la surface peut être paramétré par quatre cartes cHu, vL = u, v, -
+
5 -
+
5 -3+20 x
2-20 x
4+20 y
2-20 y
4
10
Représentation de la surface donnée par ses ensemble de zéros et par paramétrage par quatre surfaces locales
La Q1
f : !3ö !, f Hx, y, zL = Ix
4 + y
4 + z
4
M - 4 Ix
2 + y
2
z
2 + y
2 + z
2
x
2 + z
2 + x
2
y
2
M + 21 x y z +
3
2
,
G = 9Hx, y, zL œ !3
f Hx, y, zL = 0= = ker f
ï f Hx, y, zL = f Hx, y, hHx, yLL h : !2ö !, hHx, yL = z ï cHu, vL = Hu, v, hHu, vLL
Représentation de la surface donnée par ses ensemble de zéros et par paramétrage par quatre surfaces locales
56 | ü
3.5. Références
[1] Modern differential geometry of curves and surfaces, Alfred Gray, CRC Press, 1993
[2] Cours d’ Algébre géométrique, Daniel Bertrand, Université Pierre et Marie Curie, Paris, 2012
[3] Gallery of Algebraic surfaces, http://www-sop.inria.fr/galaad/surface/
| 574. L’ordinateur et la conception
ü
4.1. Bref historique de la conception assistée par ordinateur
L’introduction des ordinateurs dans les domaines de la conception «action-centrée» comme l’architecture
n’était pas simplement une transition en douceur naturelle à partir de la planche à dessin à l’ordinateur, cela
est dû au fait que les ordinateurs sont essentiellement des machines rationnelles qui suivent des algorithmes et
la conception architecturale est fondamentalement intuitive. Contrairement à cela, nous constatons que dans la
conception «raison-centrée» comme l’ingénierie, l’introduction des ordinateurs étaient un plus naturel et ils
sont devenus intrinsèque à la conception de l’ingénierie moderne. Le problème pour la conception architecturale
est qu’il s’appuie sur le jugement esthétique qui est au sens kantien un jugement réflexif, à savoir qu’il
ne vient pas comme une simple détermination partir du concept universelle à une instance particulière par la
raison. En d’autres termes, il n’existe pas de formule universelle ou étapes prédéterminées, qui peuvent être
suivies pour produire une conception qui peut être jugé comme ayant une cohérence interne. En conséquence,
peu d’approches différentes ont été prises dans l’introduction de l’informatique dans la processus de conception
architecturale, mais surtout il y a deux tendances fondamentales. Le premier était de simplement consid-
érer la conception architecturale comme une conception «raison-centrée» semblable à la conception technique,
l’autre était d’utiliser déductivement l’ordinateur comme une planche à dessin électronique, en d’autres termes
pas de processus de calcul, que le dessin en utilisant l’ordinateur. Cette seconde approche est également connu
comme conception assistée par ordinateur ou CAO (et notamment à la conception architecturale: modélisation
3d). CAO est essentiellement l’utilisation de systèmes informatiques pour aider à la création, la modification,
l’analyse ou l’optimisation d’une conception, il décrit essentiellement le processus de création d’un dessin
technique en utilisant l’ordinateur. CAO a également été la force motrice majeure pour la recherche en
géométrie algorithmique, infographie et la géométrie différentielle discrète; la conception de modèles
géométriques des objets, en particulier, est parfois appelé conception géométrique assistée par ordinateur. Le
terme CAO, a été inventé par l’informaticien Douglas T. Ross, qui a été inspiré par les opérateurs de radar de
début des années 50. Les concepteurs de ces tout premiers ordinateurs ont découvert qu’ils pouvaient créer des
symboles électroniques et des figures géométriques à être utilisé pour créer les schémas de circuit et les
organigrammes. Ils ont réalisé que l’objet une fois établi, il pourrait être reproduit à volonté, son orientation,
ses liens et son ampleur, mais il a fallu dix ans avant le précurseur de logiciels de CAO: Sketchpad a été
développé par l’informaticien Ivan Sutherland dans les années 60. Sketchpad a permis au concepteur d’interagir
avec son ordinateur graphique, cela signifie que la conception a été alimenté dans l’ordinateur, en s’appuyant
sur un écran cathodique avec un crayon optique. D’autres travaux importants qui ont influencé le
développement de logiciels de CAO, ont été les travaux sur les courbes et les surfaces polynomiales par les
ingénieurs Pierre Bézier et Paul de Casteljau à savoir le développement de courbes splines. Ensemble avec les
développement de la 3D dans les années 70, la modélisation solide dans les années 80 et les noyaux de la
modélisation solides B-rep dans les années 90; une application plus souple et pratiquement omniprésent de
l’ordinateur dans la conception architecturale a été créé. Une caractéristique fondamentale et importante d’un
système de CAO est la modélisation 3D, qui est le processus d’élaboration d’une représentation mathématique
d’une surface d’un objet en trois dimensions, le produit est appelé un modèle 3D et est divisé en deux caté-
gories: les modèles volumiques et surfaciques. Les modèles solides définissent le volume de l’objet qu’ils
représentent (comme une pierre), ces modèles sont principalement utilisés pour la simulation non visuels tels
que la simulation médicale et de l’ingénierie. Les modèles surfaciques représentent la limite de l’objet, elles
sont utilisées dans presque tous les modèles visuels des objets à partir jeux vidéo jusqu’aux domaines du
design. Il y a deux façon populaire pour représenter un modèle 3D: modélisation polygonale en utilisant des
maillages polygonaux reliant les points dans l’espace 3D, et modélisation Nurbs de courbes et de surfaces en
utilisant l’interpolation de points dans l’espace. Modélisation polygonale est une approche pour la modélisation
des objets en représentant ou en rapprochant leurs surfaces en utilisant des maillages polygonaux.
58 | ü
4.2. Modélisation de maillage polygonal
ü
4.2.1. «Box modeling» et «winged edge data structure»
Une des méthodes les plus populaires et les plus simples de constructions de maille, est «box modeling», où
on commence par une primitive comme un cube pour faire la forme de base et de là on sculpte la forme finale
à l’aide à plusieurs reprises deux outils simples: extrusion et subdivision. L’outil d’extrusion est appliquée à
une face, il crée nouvelle face identique et déplacée, et puis relier chacun de ses bords à des bords existants
par une face. L’outil de subdivision sépare les faces et les arêtes en petits morceaux en ajoutant de nouveaux
sommets, par exemple une face carrée serait subdivisé en ajoutant un sommet au centre et un au chaque côté,
créant quatre nouvelles faces carrés plus petites. Un des éléments les plus importants dans construction de
maillage est sa structure de données, un maillage polygonal est constitué d’un ensemble de sommets, arêtes et
faces avec leurs relations topologiques. En général, il y a deux grandes tendances dans les structures de
données de maillage: basés sur les faces et basés sur les arêtes. Les structures de données basées sur les faces,
enregistre pour chaque face, des pointeurs vers ses sommets et ses faces voisines, ce qui permet de naviguer
autour de chaque sommet et visiter ses faces voisines. Néanmoins, un traitement spécial est nécessaire, lorsque
la navigation passe au-dessus des éléments avec valence variable (par exemple mailles qui combine des
quadrilatères et des triangles). Les structures de données basés sur les arêtes, enregistre pour chaque bord, des
pointeurs vers les sommets et les bords voisins, et puisque les bords ont toujours la même structure
topologique, il est possible de manipuler des polygones avec des valences variables dans un seul maillage. Un
exemple important de la structure de données basés sur les arêtes est «winged edge data structure», qui
enregistre pour chaque bord références à ses sommets, à les deux polygones partageant cette arête, et les
quatre les bords voisins (ou ailes). Traversant le voisinage nécessite un distinction de cas par étape, car un
bord ne code pas pour son orientation explicitement; la «half edge data structure» résout ce problème en
divisant chaque bord en deux moitiés, où chaque demi bord est pointé vers son demi bord opposé, un sommet
incident, un polygone incident [1].
Représentation de «winged edge data structure»
L’algorithme suivant crée un maillage par une succession d’extrusions «box modeling», puis crée une structure
de données «winged edge data structure» du maillage résultant, les extrusions sont atteints par une
combinaison de trois simples opérations algébriques: translation, homothétie et de rotation. Cette combinaison
se retrouve dans la plupart des systèmes de logiciels de modélisation CAO avec «box modeling», car il est
assez intuitive permettant au concepteur de sculpter la forme désirée facilement. La structure de données doit
être capable de s’adapter aux différentes topologies à savoir lors de la création de trous dans le maillage en
supprimant et souder ensemble des faces, mais dans l’algorithme suivant, nous restons dans le même genre
topologique: 0 de la sphère (i.e. sans trous). L’extrusion est que la première partie de la modélisation de la
boîte, la deuxième outil essentiel serait le lissage de maillage au moyen la subdivision, de nombreux algorithmes
sont peuvent être utilisés dans cette opérations comme la subdivision de Catmull-Clark.
| 59Le code pour la création d’une modélisation «box modeling» avec la structure «winged edge data structure»
s@i_D := 8884 Hi + 1L + 1, 4 Hi + 1L + 2<, 84 Hi + 1L + 2, 4 Hi + 1L + 1<<, 884 Hi + 1L + 2, 4 Hi + 1L + 3<, 84 Hi + 1L + 3, 4 Hi + 1L + 2<<,
884 Hi + 1L + 3, 4 Hi + 1L + 4<, 84 Hi + 1L + 4, 4 Hi + 1L + 3<<,
884 Hi + 1L + 4, 4 Hi + 1L + 1<, 84 Hi + 1L + 1, 4 Hi + 1L + 4<<<;
Es@i_D@AA_D := 8s@iD@@1DD, s@iD@@2DD, s@iD@@3DD, s@iD@@4DD,
88s@iD@@1, 1, 1DD, AA@@1DD<, 8AA@@1DD, s@iD@@1, 1, 1DD<<,
88s@iD@@2, 1, 1DD, AA@@2DD<, 8AA@@2DD, s@iD@@2, 1, 1DD<<,
88s@iD@@3, 1, 1DD, AA@@3DD<, 8AA@@3DD, s@iD@@3, 1, 1DD<<,
88s@iD@@4, 1, 1DD, AA@@4DD<, 8AA@@4DD, s@iD@@4, 1, 1DD<<<;
Tri@A_D := 88A@@1DD, A@@2DD, A@@3DD<, 8A@@1DD, A@@3DD, A@@4DD<<;
Par@A_D@u_, v_D := A@@1DD + u HA@@2DD - A@@1DDL + v HHA@@4DD + u HA@@3DD - A@@4DDLL - HA@@1DD + u HA@@2DD - A@@1DDLLL;
deru@c_D@u_, v_D := !uu c@uu, vvD ê. 8uu Ø u, vv Ø v<;
derv@c_D@u_, v_D := !vv c@uu, vvD ê. 8uu Ø u, vv Ø v<;
cNor@c_D@u_, v_D :=
Cross@deru@cD@u, vD, derv@cD@u, vDD ë , HCross@deru@cD@u, vD, derv@cD@u, vDD.Cross@deru@cD@u, vD, derv@cD@u, vDDL;
cen@A_D := Par@AD@0.5, 0.5D;
fN@A_D := cNor@Par@ADD@0.5, 0.5D;
fNln@A_D := 8cen@AD, cen@AD + 0.3 fN@AD<;
Ori@A_D := 8A@@1DD - cen@AD, A@@2DD - cen@AD, A@@3DD - cen@AD, A@@4DD - cen@AD<;
Ext@A_D@l_D := 8A@@1DD + l fN@AD, A@@2DD + l fN@AD, A@@3DD + l fN@AD, A@@4DD + l fN@AD<;
MSR@f_, q_, y_, l1_, l2_, l3_, l_D@A_D :=
:
Cos@qD Cos@yD -Cos@fD Sin@yD + Sin@fD Sin@qD Cos@yD Sin@fD Sin@yD + Cos@fD Sin@qD Cos@yD
Cos@qD Sin@yD Cos@fD Cos@yD + Sin@fD Sin@qD Sin@yD -Sin@fD Cos@yD + Cos@fD Sin@qD Sin@yD
-Sin@qD Sin@fD Cos@qD Cos@fD Cos@qD
.
l1 0 0
0 l2 0
0 0 l3
.Ori@Ext@AD@lDD@@1DD +
cen@Ext@AD@lDD,
Cos@qD Cos@yD -Cos@fD Sin@yD + Sin@fD Sin@qD Cos@yD Sin@fD Sin@yD + Cos@fD Sin@qD Cos@yD
Cos@qD Sin@yD Cos@fD Cos@yD + Sin@fD Sin@qD Sin@yD -Sin@fD Cos@yD + Cos@fD Sin@qD Sin@yD
-Sin@qD Sin@fD Cos@qD Cos@fD Cos@qD
.
l1 0 0
0 l2 0
0 0 l3
.Ori@Ext@AD@lDD@@2DD +
cen@Ext@AD@lDD,
Cos@qD Cos@yD -Cos@fD Sin@yD + Sin@fD Sin@qD Cos@yD Sin@fD Sin@yD + Cos@fD Sin@qD Cos@yD
Cos@qD Sin@yD Cos@fD Cos@yD + Sin@fD Sin@qD Sin@yD -Sin@fD Cos@yD + Cos@fD Sin@qD Sin@yD
-Sin@qD Sin@fD Cos@qD Cos@fD Cos@qD
.
l1 0 0
0 l2 0
0 0 l3
.Ori@Ext@AD@lDD@@3DD +
cen@Ext@AD@lDD,
Cos@qD Cos@yD -Cos@fD Sin@yD + Sin@fD Sin@qD Cos@yD Sin@fD Sin@yD + Cos@fD Sin@qD Cos@yD
Cos@qD Sin@yD Cos@fD Cos@yD + Sin@fD Sin@qD Sin@yD -Sin@fD Cos@yD + Cos@fD Sin@qD Sin@yD
-Sin@qD Sin@fD Cos@qD Cos@fD Cos@qD
.
l1 0 0
0 l2 0
0 0 l3
.Ori@Ext@AD@lDD@@4DD +
cen@Ext@AD@lDD>;
v1 = 80, 0, 0<; v2 = 81, 0, 0<; v3 = 81, 1, 0<; v4 = 80, 1, 0<;
v5 = 80, 0, 1<; v6 = 81, 0, 1<; v7 = 81, 1, 1<; v8 = 80, 1, 1<;
Vr = 8v1, v2, v3, v4, v5, v6, v7, v8<;
ve = 889, 1, 4<, 810, 2, 1<, 811, 3, 2<, 812, 4, 3<, 88, 5, 9<, 85, 6, 10<, 86, 7, 11<, 87, 8, 12<<;
ev = 8881, 2<, 82, 1<<, 882, 3<, 83, 2<<, 883, 4<, 84, 3<<, 884, 1<, 81, 4<<, 885, 6<, 86, 5<<, 886, 7<, 87, 6<<,
887, 8<, 88, 7<<, 888, 5<, 85, 8<<, 885, 1<, 81, 5<<, 886, 2<, 82, 6<<, 887, 3<, 83, 7<<, 888, 4<, 84, 8<<<;
ef = 881, 6<, 82, 6<, 83, 6<, 84, 6<, 85, 1<, 85, 2<, 85, 3<, 85, 4<, 81, 4<, 82, 1<, 83, 2<, 84, 3<<;
ee = 8
889, 85, 1<<, 810, 82, 6<<, 82, 83, 2<<, 84, 81, 4<<<,
8810, 86, 2<<, 811, 83, 7<<, 83, 84, 3<<, 81, 82, 1<<<,
8811, 87, 3<<, 812, 84, 8<<, 84, 81, 4<<, 82, 83, 2<<<,
8812, 88, 4<<, 89, 81, 5<<, 81, 82, 1<<, 83, 84, 3<<<,
888, 88, 5<<, 86, 86, 7<<, 810, 82, 6<<, 89, 85, 1<<<,
885, 85, 6<<, 87, 87, 8<<, 811, 83, 7<<, 810, 86, 2<<<,
886, 86, 7<<, 88, 88, 5<<, 812, 84, 8<<, 811, 87, 3<<<,
887, 87, 8<<, 85, 85, 6<<, 89, 81, 5<<, 812, 88, 4<<<,
885, 86, 5<<, 81, 81, 2<<, 84, 84, 1<<, 88, 85, 8<<<,
886, 87, 6<<, 82, 82, 3<<, 81, 81, 2<<, 85, 86, 5<<<,
887, 88, 7<<, 83, 83, 4<<, 82, 82, 3<<, 86, 87, 6<<<,
888, 85, 8<<, 84, 84, 1<<, 83, 83, 4<<, 87, 88, 7<<<<;
Fv = 88Vr@@1DD, Vr@@2DD, Vr@@6DD, Vr@@5DD<, 8Vr@@2DD, Vr@@3DD, Vr@@7DD, Vr@@6DD<, 8Vr@@3DD, Vr@@4DD, Vr@@8DD, Vr@@7DD<,
8Vr@@4DD, Vr@@1DD, Vr@@5DD, Vr@@8DD<, 8Vr@@5DD, Vr@@6DD, Vr@@7DD, Vr@@8DD<, 8Vr@@1DD, Vr@@4DD, Vr@@3DD, Vr@@2DD<<;
fv = 881, 2, 6, 5<, 82, 3, 7, 6<, 83, 4, 8, 7<, 84, 1, 5, 8<, 85, 6, 7, 8<, 81, 4, 3, 2<<;
Fe = 88ev@@1, 1DD, ev@@10, 2DD, ev@@5, 2DD, ev@@9, 1DD<, 8ev@@2, 1DD, ev@@11, 2DD, ev@@6, 2DD, ev@@10, 1DD<,
8ev@@3, 1DD, ev@@12, 2DD, ev@@7, 2DD, ev@@11, 1DD<, 8ev@@4, 1DD, ev@@9, 2DD, ev@@8, 2DD, ev@@12, 1DD<,
8ev@@5, 1DD, ev@@6, 1DD, ev@@7, 1DD, ev@@8, 1DD<, 8ev@@4, 2DD, ev@@3, 2DD, ev@@2, 2DD, ev@@1, 2DD<<;
fe = 881, 10, 5, 9<, 82, 11, 6, 10<, 83, 12, 7, 11<, 84, 9, 8, 12<, 85, 6, 7, 8<, 84, 3, 2, 1<<;
60 | ndV = 8; ndF = 6; ndE = 12;
DoB
i = RandomInteger@81, ndF0){ $v3=1; }
//description: $e3 is counter increases with k | The two conditions $k=0 & $k>0 activate the unit Vector $v3
for($j=0;$j<$Ax;$j+=1)
{$e2=$j*($Cx);
if($j==0){ $v2=0; } if($j>0){ $v2=1; }
//description: $e2 is counter increases with j | The two conditions $j=0 & $j>0 activate the unit Vector $v2
for($i=0;$i<$Cx;$i+=1)
{$e1=$i; $e=$e1+$e2+$e3;
if($i==0){ $v1=0; } if($i>0){ $v1=1; }
//description: $e1 is counter increases with i & $e is the cell number | The two conditions $i=0 & $i>0 activate the unit Vector $v1
$Sc[$e]=$base[$e]*$Sx*20; $B[$e]=$Sc[$e]*12;
$cell_c=”COP”+($e); $cell[$e]=”COP”+($e);
polyCube -n $cell_c -w $Sc[$e] -d $Sc[$e] -h $Sc[$e];
//description:$Sc[$e] is the size assigned to each cell and it is equal to the (base number).(General scale).(Zoom constant)
//$B is the size of the bubble around each base cell
//$cell[$e] is filling the array $cell[] with {Cop0, Cop1,......CopN}
//polyCube is the creation of the base Cell, naming it $cell_c & assigning it the size of Sc[$e] to its width, depth & height
//print(“cell(“+$e+“)B: “+$B[$e]+“\n”);
if($i==0){ $vyc=$B[$e]; $vyp=0; } if($i>0){ $vyc=$B[$e-1]+$B[$e]; }
if($j==0){ $vxc=$B[$e]; $vxp=0; } if($j>0){ $vxc=$B[$e-$Cx]+$B[$e]; }
if($k==0){ $vzc=$B[$e]; $vzp=0; } if($k>0){ $vzc=$B[$e-($Cx*$Ax)]+$B[$e]; }
$vy[$e]=$v1*($vyc+$vyp);
$vx[$e]=$v2*($vxc+$vxp);
$vz[$e]=$v3*($vzc+$vzp);
//description:The condition assign the value of V_current either as ($B[$e]) or as ($B[$e] + $B[of the proper previous cell])
//Each vector is a product of its unit vector and the sum of V_current and V_previous
//$Cellvector[$e]=”[“+int($vx[$e])+“,”+int($vy[$e])+“,”+int($vz[$e])+“]”;
//print (“Cell(“+$e+“)=”+$Cellvector[$e]+“\n”);
//print (“vxp: “+$vxp+“ vxc: “+$vxc+“ vx: “+$vx[$e]+“\n”);
//print (“vyp: “+$vyp+“ vyc: “+$vyc+“ vy: “+$vy[$e]+“\n”);
//print (“vzp: “+$vzp+“ vzc: “+$vzc+“ vz: “+$vz[$e]+“\n”);
if($i>0){ $vyp=$vy[$e]; }
if($j>0){ $vxp=$vx[$e-$Cx+1]; }
if($k>0){ $vzp=$vz[$e-($Cx*$Ax)+1]; }
//description:Here we cast the value V_previous to be ready for the next round of the loop
move -r $vx[$e] $vy[$e] $vz[$e];
//description:This moves each cell to its 3 dimensional vector namely its ($vx[$e],$vy[$e],$vz[$e])
}
}
}
70 | //________________________________________________________________________________
//Cell Development
//description: Extrusion Sequence | Fractal Growth
//________________________________________________________________________________
int $zd[],$ad[];
int $h[],$d[],$u[],$ff[],$bf[],$rf[],$lf[],$df[],$uf[];
int $dad[],$dl[],$sdl[],$edl[];
int $U1,$U2,$U3,$F1,$F2;
float $Hx,$Hy,$Hz,$Hsx,$Hsy,$Hsz;
float $Hax,$Hay,$Haz,$Harx,$Hary,$Harz,$Hasx,$Hasy,$Hasz;
float $LDx,$LDy,$LDz1,$LDz2,$LDz3,$LDz4,$LDrx,$LDry,$LDrz,$LDsx,$LDsy,$LDsz;
float $LUx,$LUy,$LUz1,$LUz2,$LUz3,$LUrx,$LUry,$LUrz,$LUsx,$LUsy,$LUsz;
float $LFx,$LFy,$LFz1,$LFz2,$LFz3,$LFrx,$LFry,$LFrz,$LFsx,$LFsy,$LFsz;
float $LBx,$LBy,$LBz1,$LBz2,$LBrx,$LBry,$LBrz,$LBsx,$LBsy,$LBsz;
float $LDdx,$LDdy,$LDdz,$LDdrx,$LDdry,$LDdrz,$LDdsx,$LDdsy,$LDdsz;
float $LDux,$LDuy,$LDuz,$LDurx,$LDury,$LDurz,$LDusx,$LDusy,$LDusz;
float $LRx,$LRy,$LRz1,$LRz2,$LRrx,$LRry,$LRrz,$LRsx,$LRsy,$LRsz;
float $LLx,$LLy,$LLz1,$LLz2,$LLrx,$LLry,$LLrz,$LLsx,$LLsy,$LLsz;
float $ARx,$ARy,$ARz,$ARrx,$ARry,$ARrz,$ARsx,$ARsy,$ARsz;
float $ALx,$ALy,$ALrx,$ALry,$ALrz,$ALz,$ALsx,$ALsy,$ALsz;
for($k=0;$k<$Gx;$k+=1)
{$e3= $k*(($Cx)*($Ax));
for($j=0;$j<$Ax;$j+=1)
{$e2=$j*($Cx);
for($i=0;$i<$Cx;$i+=1)
{$e1=$i; $e=$e1+$e2+$e3;
$g=$Gcode[$e]; float $S=$Sc[$e];
//description:Casting the $g number from the $Gcode[$e] and the $S from the $Sc[$e] | the $g numbers is the
//face number from which we start the extrusion sequences
//The Fractal
for($l=0;$l<$Lx;$l+=1)
{
if($l==0){
$zd[$l]=1; $h[$l]=$g+1; $ff[$l]=118; $bf[$l]=119; $rf[$l]=159; $lf[$l]=160; $df[$l]=140; $uf[$l]=130;
if($g==0){ $d[$l]=110; $u[$l]=105; }
if($g==1){ $d[$l]=109; $u[$l]=110; }
if($g==2){ $d[$l]=111; $u[$l]=107; }
if($g==3){ $d[$l]=107; $u[$l]=109; }
if($g==4){ $d[$l]=110; $u[$l]=106; }
if($g==5){ $d[$l]=104; $u[$l]=108; }
}
$Hx=1; $Hy=1; $Hz=1; $Hsx=$Hsy=$Hsz=1.3;
if(($g==4)||($g==5)){ $Hax=1; $Hay=1; $Haz=1;$Hasx=$Hasy=$Hasz= 0.8; $Harx=-10 ;$Hary=0;$Harz=0; }
else{ $Hax=1; $Hay=1; $Haz=1;$Hasx=$Hasy=$Hasz=0.8; $Harx=-10 ;$Hary=10;$Harz=0; }
//description:Head Antena controllers
if($i==0) {
$LDx=0;$LDy=0; $LDz1=10;$LDz2=10;$LDz3=10;$LDz4=60;
$LDrx=5; $LDry=10; $LDrz=0;
if(($g==2)||($g==3)){$LDsx=0.8; $LDsy=1.2;$LDsz=1.2;}else{$LDsx=$LDsy=$LDsz= 1.2 ;}
}else {
$LDx=0;$LDy=0; $LDz1=$LDz2=$LDz3=$LDz4=2;
$LDrx=5; $LDry=0; $LDrz=0; //$LDrx=5; $LDry=0; $LDrz=0;
if(($g==2)||($g==3)){$LDsx=0.8; $LDsy=1.2;$LDsz=1.2;}else{$LDsx= 1.2 ; $LDsy= 1.2 ;$LDsz= 1.2 ;}
}
//description:Down body controllers
if($i==$Cx-1) {
$LUx=0;$LUy=-1;$LUz1=10;$LUz2=10;$LUz3=60;
$LUrx=-5; $LUry=-10; $LUrz=0;
if($g==5){$LUsx=0.8;$LUsy=1;$LUsz=1.5;}else{$LUsx=1.5;$LUsy=1.1;$LUsz=1.5;}
}else {
$LUx=0;$LUy=-1; $LUz1=$LUz2=$LUz3=3;
$LUrx=-5; $LUry=0; $LUrz=0; //$LUrx=-5; $LUry=0; $LUrz=0;
if($g==5){$LUsx=0.8;$LUsy=1;$LUsz=1.5;}else{$LUsx=1.5;$LUsy=1.1;$LUsz=1.5;}
}
//description:Upper body controllers
if($k==$Gx-1){
$LFrx=5;$LFry=0;$LFrz=0; $LFz1=10;$LFz2=10;$LFz3=60;
if(($g==2)||($g==3)){$LFsx=0.8; $LFsy=1.2;$LFsz=1.2;}else{$LFsx=1.2; $LFsy=1.2;$LFsz=1.2;}
}else {
$LFx=0;$LFy=0; if($g==5){$LFz1=$LFz2=$LFz3= 5;}else{$LFz1=$LFz2=$LFz3=2;}
$LFrx=5;$LFry=0;$LFrz=0;
if(($g==2)||($g==3)){$LFsx=0.8; $LFsy=1.2;$LFsz=1.2;}else{$LFsx=1.2; $LFsy=1.2;$LFsz=1.2;}
}
//description:Front body controllers
| 71//description:Front body controllers
if($k==0){
$LBx=0;$LBy=0; $LBz1=10;$LBz2=60;
$LBrx=-5;$LBry=0;$LBrz=0;
if(($g==2)||($g==3)){$LBsx=0.8; $LBsy=1.2;$LBsz=1.2;}else{$LBsx=$LBsy=$LBsz=1.2;}
}else {
$LBx=0;$LBy=0; $LBz1=$LBz2=2;
$LBrx=-5;$LBry=0;$LBrz=0;
if(($g==2)||($g==3)){$LBsx=0.8; $LBsy=1.2;$LBsz=1.2;}else{$LBsx=$LBsy=$LBsz=1.2;}
}
//description:Back body controllers
$LDdx=0;$LDdy=0;$LDdz=4; $LDdsx=$LDdsy=$LDdsz=0.9; $LDdrx=-5;$LDdry=0;$LDdrz=0;
//description:D-U connection D part controllers
$LDux=0;$LDuy=0;$LDuz=4; $LDusx=$LDusy=$LDusz= 0.9 ; $LDurx=20;$LDury=0;$LDurz=0;
//description:D-U connection U part controllers
if($j==0){
$LRx=0;$LRy=0; $LRz1=20;$LRz2=100;
$LRrx=5;$LRry=30;$LRrz=5; //$LRrx=0;$LRry=0;$LRrz=0;
$LRsx=0.8; $LRsy=0.5;$LRsz=0.8;
}else {
$LRx=0;$LRy=0; $LRz1=$LRz2=4;
$LRrx=5;$LRry=0;$LRrz=5; //$LRrx=0;$LRry=0;$LRrz=0;
$LRsx=0.8; $LRsy=0.6;$LRsz=0.8;
}
//description:Right body controllers
if($j==$Ax-1){
$LLx=0;$LLy=0; $LLz1=20;$LLz2=100;
$LLrx=-5;$LLry=-30;$LLrz=-5; //$LLrx=0;$LLry=0;$LLrz=0;
$LLsx=0.8; $LLsy=0.5;$LLsz=0.8;
}else {
$LLx=0;$LLy=0; $LLz1=$LLz2=4;
$LLrx=-5;$LLry=0;$LLrz=-5; //$LLrx=0;$LLry=0;$LLrz=0;
$LLsx=0.8; $LLsy=0.6;$LLsz=0.8;
}
//description:Left body controllers
$ARx=0;$ARy=0;$ARz=10;$ARsx=$ARsy=$ARsz=1; $ARrx=-20;$ARry=-20;$ARrz=0;
//description:Tail Right controllers
$ALx=0;$ALy=0;$ALz=10;$ALsx=$ALsy=$ALsz=1; $ALrx=20;$ALry=20;$ALrz=0;
//description:Tail Left controllers
//description:Setting the prequisites for the extrusion
//$zd[] is the magnification factor | $h[] is the face number for the head extrusion
//$d[] is the face number for the downward extrusion | $u[] is the face number for the upward extrusion
//$df[] is the down face number for the d-u connection | $uf[] is the up face number for the d-u connection
//$rf[] is the face number for the right extrusion | $lf[] is the face number for the left extrusion
//___________________________________________________________________________________________________
//if($l==1){
//int$zp=$zd[$l-1];
//$zd[$l]=($zp*50);
//$ad[$l]=264; $h[$l]=$h[$l-1]+123;
//if($g==0){$d[$l]=375; $u[$l]=369;$sdl[$l]=368;}
//if($g==1){$d[$l]=375; $u[$l]=371;$sdl[$l]=368;}
//if($g==2){$d[$l]=370; $u[$l]=371;$sdl[$l]=368;}
//$dad[$l]=1;$dl[$l]=(($dad[$l]*8)-1);
//$edl[$l]=$sdl[$l]+$dl[$l];
//}
//if($l>1){
//int$zp=$zd[$l-1]; int$ap=$ad[$l-1];
//$zd[$l]=($zp*50); $ad[$l]=($ap*2);
//$h[$l]=$h[$l-1]+$ad[$l-1]; $d[$l]=$d[$l-1]+$ad[$l]; $u[$l]=$u[$l-1]+$ad[$l];
//int$dap=$dad[$l-1];
//$dad[$l]=(($dap*2)+1); $dl[$l]=(($dad[$l]*8)-1);
//$sdl[$l]=($d[$l]-7); $edl[$l]=$sdl[$l]+$dl[$l];
//}
//print “\n”;//not in Animal+
//print (“zd=”+$zd[$l]+“ h=”+$h[$l]+“ d=”+$d[$l]+“ u=”+$u[$l]+“\n”);//not in Animal+
//print (“dad=”+$dad[$l]+“ dl=”+$dl[$l]+“ sdl=”+$sdl[$l]+“ edl=”+$edl[$l]+“\n”);//not in Animal+
//___________________________________________________________________________________________________
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$Hax) ($S*$zd[$l]*$Hay) ($S*$zd[$l]*$Haz) -ls $Hasx $Hasy $Hasz -lr $Harx $Hary $Harz ($cell[$e]+“.f[“+($h[$l]-1)+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$Hax) ($S*$zd[$l]*$Hay) ($S*$zd[$l]*$Haz) -ls $Hasx $Hasy $Hasz -lr $Harx $Hary $Harz ($cell[$e]+“.f[“+($h[$l]-1)+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$Hax) ($S*$zd[$l]*$Hay) ($S*$zd[$l]*$Haz) -ls $Hasx $Hasy $Hasz -lr $Harx $Hary $Harz ($cell[$e]+“.f[“+($h[$l]-1)+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$Hax) ($S*$zd[$l]*$Hay) ($S*$zd[$l]*$Haz) -ls $Hasx $Hasy $Hasz -lr $Harx $Hary $Harz ($cell[$e]+“.f[“+($h[$l]-1)+“]”);
72 | polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$Hax) ($S*$zd[$l]*$Hay) ($S*$zd[$l]*$Haz) -ls $Hasx $Hasy $Hasz -lr $Harx $Hary $Harz ($cell[$e]+“.f[“+($h[$l]-1)+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$Hax) ($S*$zd[$l]*$Hay) ($S*$zd[$l]*$Haz) -ls $Hasx $Hasy $Hasz -lr $Harx $Hary $Harz ($cell[$e]+“.f[“+($h[$l]-1)+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$Hx) ($S*$zd[$l]*$Hy) ($S*$zd[$l]*$Hz) -ls $Hsx $Hsy $Hsz -lr -20 -40 0 ($cell[$e]+“.f[“+$h[$l]+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$Hx) ($S*$zd[$l]*$Hy) ($S*$zd[$l]*$Hz) -ls $Hsx $Hsy $Hsz -lr -20 -40 0 ($cell[$e]+“.f[“+$h[$l]+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$Hx) ($S*$zd[$l]*$Hy) ($S*$zd[$l]*$Hz) -ls $Hsx $Hsy $Hsz -lr -20 -40 0 ($cell[$e]+“.f[“+$h[$l]+“]”);
select -cl; select -r ($cell[$e]+“.f[“+$h[$l]+“]”); Delete ($cell[$e]+“.f[“+$h[$l]+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$Hx) ($S*$zd[$l]*$Hy) ($S*$zd[$l]*$Hz) -ls $Hsx $Hsy $Hsz -lr -10 -20 0 ($cell[$e]+“.f[“+$h[$l]+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$Hx) ($S*$zd[$l]*$Hy) ($S*$zd[$l]*$Hz) -ls $Hsx $Hsy $Hsz -lr -10 -20 0 ($cell[$e]+“.f[“+$h[$l]+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$Hx) ($S*$zd[$l]*$Hy) ($S*$zd[$l]*$Hz) -ls $Hsx $Hsy $Hsz -lr -10 -20 0 ($cell[$e]+“.f[“+$h[$l]+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$Hx) ($S*$zd[$l]*$Hy) ($S*$zd[$l]*$Hz) -ls $Hsx $Hsy $Hsz -lr -10 -20 0 ($cell[$e]+“.f[“+$h[$l]+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$Hx) ($S*$zd[$l]*$Hy) ($S*$zd[$l]*$Hz) -ls $Hsx $Hsy $Hsz -lr -10 -20 0 ($cell[$e]+“.f[“+$h[$l]+“]”);
select -cl; select -r ($cell[$e]+“.f[“+$h[$l]+“]”); Delete ($cell[$e]+“.f[“+$h[$l]+“]”);
//description:PolyExtrudeFacet is the growth command, for each facet we need to specify the LT (translation), LS(scaling), LR(rotation)
select -cl; select -r $cell[$e]; polyMirrorFace -ws 1 -direction 1 -mergeMode 2 -ch 1 $cell[$e]; select -cl;
//description:Selecting the Cell so far and mirroring it to produce the head
//___________________________________________________________________________________________________
//if($l>0){//select -r ($cell[$e]+“.f[“+$sdl[$l]+“:”+$edl[$l]+“]”);// Delete;
//if($g==0){ select -r ($cell[$e]+“.f[“+$sdl[$l]+“:”+($edl[$l]-1)+“]”);Delete; select -r ($cell[$e]+“.f[“+($edl[$l]-3)+“]”); Delete; }
//if($g>0){ select -r ($cell[$e]+“.f[“+$sdl[$l]+“:”+$edl[$l]+“]”); Delete; }}
//___________________________________________________________________________________________________
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LDx) ($S*$zd[$l]*$LDy) ($S*$zd[$l]*$LDz1) -ls $LDsx $LDsy $LDsz -lr $LDrx $LDry $LDrz ($cell[$e]+“.f[“+$d[$l]+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LDx) ($S*$zd[$l]*$LDy) ($S*$zd[$l]*$LDz2) -ls $LDsx $LDsy $LDsz -lr $LDrx $LDry $LDrz ($cell[$e]+“.f[“+$d[$l]+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LDx) ($S*$zd[$l]*$LDy) ($S*$zd[$l]*$LDz3) -ls $LDsx $LDsy $LDsz -lr $LDrx $LDry $LDrz ($cell[$e]+“.f[“+$d[$l]+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LDx) ($S*$zd[$l]*$LDy) ($S*$zd[$l]*$LDz4) -ls $LDsx $LDsy $LDsz -lr $LDrx $LDry $LDrz ($cell[$e]+“.f[“+$d[$l]+“]”);
select -cl; select -r ($cell[$e]+“.f[“+$d[$l]+“]”); Delete ($cell[$e]+“.f[“+$d[$l]+“]”);
//description:The part of the sequence generate the lower body
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LUx) ($S*$zd[$l]*$LUy) ($S*$zd[$l]*$LUz1) -ls $LUsx $LUsy $LUsz -lr $LUrx $LUry $LUrz ($cell[$e]+“.f[“+$u[$l]+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LUx) ($S*$zd[$l]*$LUy) ($S*$zd[$l]*$LUz2) -ls $LUsx $LUsy $LUsz -lr $LUrx $LUry $LUrz ($cell[$e]+“.f[“+$u[$l]+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LUx) ($S*$zd[$l]*$LUy) ($S*$zd[$l]*$LUz3) -ls $LUsx $LUsy $LUsz -lr $LUrx $LUry $LUrz ($cell[$e]+“.f[“+$u[$l]+“]”);
select -cl; select -r ($cell[$e]+“.f[“+$u[$l]+“]”); Delete ($cell[$e]+“.f[“+$u[$l]+“]”);
//description:The part of the sequence generate the upper body
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LFx) ($S*$zd[$l]*$LFy) ($S*$zd[$l]*$LFz1) -ls $LFsx $LFsy $LFsz -lr $LFrx $LFry $LFrz ($cell[$e]+“.f[“+$ff[$l]+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LFx) ($S*$zd[$l]*$LFy) ($S*$zd[$l]*$LFz2) -ls $LFsx $LFsy $LFsz -lr $LFrx $LFry $LFrz ($cell[$e]+“.f[“+$ff[$l]+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LFx) ($S*$zd[$l]*$LFy) ($S*$zd[$l]*$LFz3) -ls $LFsx $LFsy $LFsz -lr $LFrx $LFry $LFrz ($cell[$e]+“.f[“+$ff[$l]+“]”);
select -cl; select -r ($cell[$e]+“.f[“+$ff[$l]+“]”); Delete ($cell[$e]+“.f[“+$ff[$l]+“]”);
//description:The part of the sequence generate the front body
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LBx) ($S*$zd[$l]*$LBy) ($S*$zd[$l]*$LBz1) -ls $LBsx $LBsy $LBsz -lr $LBrx $LBry $LBrz ($cell[$e]+“.f[“+$bf[$l]+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LBx) ($S*$zd[$l]*$LBy) ($S*$zd[$l]*$LBz2) -ls $LBsx $LBsy $LBsz -lr $LBrx $LBry $LBrz ($cell[$e]+“.f[“+$bf[$l]+“]”);
select -cl; select -r ($cell[$e]+“.f[“+$bf[$l]+“]”); Delete ($cell[$e]+“.f[“+$bf[$l]+“]”);
//description:The part of the sequence generate the back body
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LDdx) ($S*$zd[$l]*$LDdy) ($S*$zd[$l]*$LDdz) -ls $LDdsx $LDdsy $LDdsz -lr $LDdrx $LDdry $LDdrz ($cell[$e]+“.f[“+$df[$l]+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LDdx) ($S*$zd[$l]*$LDdy) ($S*$zd[$l]*$LDdz) -ls $LDdsx $LDdsy $LDdsz -lr $LDdrx $LDdry $LDdrz ($cell[$e]+“.f[“+$df[$l]+“]”);
select -cl; select -r ($cell[$e]+“.f[“+$df[$l]+“]”); Delete ($cell[$e]+“.f[“+$df[$l]+“]”);
//description:The part of the sequence generate the down part of the d-u connection
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LDux) ($S*$zd[$l]*$LDuy) ($S*$zd[$l]*$LDuz) -ls $LDusx $LDusy $LDusz -lr $LDurx $LDury $LDurz ($cell[$e]+“.f[“+$uf[$l]+“]”);
select -cl; select -r ($cell[$e]+“.f[“+$uf[$l]+“]”); Delete ($cell[$e]+“.f[“+$uf[$l]+“]”);
//description:The part of the sequence generate the up part of the d-u connection
polyMergeVertex -d 0.01 -am 1 -ch 1 ($cell[$e]+“.vtx[164]”) ($cell[$e]+“.vtx[168]”);
polyMergeVertex -d 0.01 -am 1 -ch 1 ($cell[$e]+“.vtx[165]”) ($cell[$e]+“.vtx[168]”);
polyMergeVertex -d 0.01 -am 1 -ch 1 ($cell[$e]+“.vtx[167]”) ($cell[$e]+“.vtx[168]”);
polyMergeVertex -d 0.01 -am 1 -ch 1 ($cell[$e]+“.vtx[166]”) ($cell[$e]+“.vtx[168]”);
//description:*first use topological unification | PolyMergeVertex is used to mesh unification
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LRx) ($S*$zd[$l]*$LRy) ($S*$zd[$l]*$LRz1) -ls $LRsx $LRsy $LRsz -lr $LRrx $LRry $LRrz ($cell[$e]+“.f[“+$rf[$l]+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LRx) ($S*$zd[$l]*$LRy) ($S*$zd[$l]*$LRz2) -ls $LRsx $LRsy $LRsz -lr $LRrx $LRry $LRrz ($cell[$e]+“.f[“+$rf[$l]+“]”);
select -cl; select -r ($cell[$e]+“.f[“+$rf[$l]+“]”); Delete ($cell[$e]+“.f[“+$rf[$l]+“]”);
//description:The part of the sequence generate the right body
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LLx) ($S*$zd[$l]*$LLy) ($S*$zd[$l]*$LLz1) -ls $LLsx $LLsy $LLsz -lr $LLrx $LLry $LLrz ($cell[$e]+“.f[“+$lf[$l]+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$LLx) ($S*$zd[$l]*$LLy) ($S*$zd[$l]*$LLz2) -ls $LLsx $LLsy $LLsz -lr $LLrx $LLry $LLrz ($cell[$e]+“.f[“+$lf[$l]+“]”);
select -cl; select -r ($cell[$e]+“.f[“+$lf[$l]+“]”); Delete ($cell[$e]+“.f[“+$lf[$l]+“]”);
//description:The part of the sequence generate the left body
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$ARx) ($S*$zd[$l]*$ARy) ($S*$zd[$l]*$ARz) -ls $ARsx $ARsy $ARsz -lr $ARrx $ARry $ARrz ($cell[$e]+“.f[“+($h[$l]-1)+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$ARx) ($S*$zd[$l]*$ARy) ($S*$zd[$l]*$ARz) -ls $ARsx $ARsy $ARsz -lr $ARrx $ARry $ARrz ($cell[$e]+“.f[“+($h[$l]-1)+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$ARx) ($S*$zd[$l]*$ARy) ($S*$zd[$l]*$ARz) -ls $ARsx $ARsy $ARsz -lr $ARrx $ARry $ARrz ($cell[$e]+“.f[“+($h[$l]-1)+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$ARx) ($S*$zd[$l]*$ARy) ($S*$zd[$l]*$ARz) -ls $ARsx $ARsy $ARsz -lr $ARrx $ARry $ARrz ($cell[$e]+“.f[“+($h[$l]-1)+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$ARx) ($S*$zd[$l]*$ARy) ($S*$zd[$l]*$ARz) -ls $ARsx $ARsy $ARsz -lr $ARrx $ARry $ARrz ($cell[$e]+“.f[“+($h[$l]-1)+“]”);
| 73polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$ARx) ($S*$zd[$l]*$ARy) ($S*$zd[$l]*$ARz) -ls $ARsx $ARsy $ARsz -lr $ARrx $ARry $ARrz ($cell[$e]+“.f[“+($h[$l]-1)+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$ARx) ($S*$zd[$l]*$ARy) ($S*$zd[$l]*$ARz) -ls $ARsx $ARsy $ARsz -lr $ARrx $ARry $ARrz ($cell[$e]+“.f[“+($h[$l]-1)+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$ALx) ($S*$zd[$l]*$ALy) ($S*$zd[$l]*$ALz) -ls $ALsx $ALsy $ALsz -lr $ALrx $ALry $ALrz ($cell[$e]+“.f[“+($h[$l]-1+52)+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$ALx) ($S*$zd[$l]*$ALy) ($S*$zd[$l]*$ALz) -ls $ALsx $ALsy $ALsz -lr $ALrx $ALry $ALrz ($cell[$e]+“.f[“+($h[$l]-1+52)+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$ALx) ($S*$zd[$l]*$ALy) ($S*$zd[$l]*$ALz) -ls $ALsx $ALsy $ALsz -lr $ALrx $ALry $ALrz ($cell[$e]+“.f[“+($h[$l]-1+52)+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$ALx) ($S*$zd[$l]*$ALy) ($S*$zd[$l]*$ALz) -ls $ALsx $ALsy $ALsz -lr $ALrx $ALry $ALrz ($cell[$e]+“.f[“+($h[$l]-1+52)+“]”);
polyExtrudeFacet -kft true -lt ($S*$zd[$l]*$ALx) ($S*$zd[$l]*$ALy) ($S*$zd[$l]*$ALz) -ls $ALsx $ALsy $ALsz -lr $ALrx $ALry $ALrz ($cell[$e]+“.f[“+($h[$l]-1+52)+“]”);
//description:The part of the sequence is additional | namely it doesnt change the topology. Only the $vtotal has to increase if new extrusions are made
}
//select -r $cell[$i];//not in Animal+
//move -r ($i*(-3000)*$Sx); select -cl;//not in Animal+
}
}
}
select -r $cell; $animal_c=”AOP”+(0); polyUnite -ch 1 -n $animal_c;
//description:Selecting the array $cell and putting it in one element $animal_current
//_____________________________________________________________________________________________
//Topological unification
// description: equations that describe the numbers of the vertices for the merging
//_____________________________________________________________________________________________
int $ni,$nj,$nk,$vtotal;
int $idu,$iduc,$jdu,$jduc,$kdu,$kduc,$c,$ck,$Nsmall,$Nbig;
int $BNstart,$BNstart_p,$Nino,$Ninc,$Ninc_start,$Nino_p,$Nin[];
int $BGstart,$BGstart_p,$Gigo,$Ginc,$Ginc_start,$GincUnit;
int $BTstart,$BTstart_p,$Tito,$Tinc,$Tinc_start,$IT,$IT_p,$ITinc,$IA,$ITunit,$ITunit_p,$Tit_p,$Tit[];
$vtotal=224;
$ni=127+((1)*$vtotal); $nj=172+($Cx)*$vtotal-($Cx-1)*4; $nk=156+(($Cx*$Ax)*$vtotal)-(($Cx-1)*$Ax*4)-(($Ax-1)*$Cx*4);
//print (“ni:”+$ni+“ nj:”+$nj+“ nk:”+$nk+“\n”);
// description: This part calculates the ni,nj,nk (the equations)
//----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-
if($Cx<$Ax){ $Nsmall=$Cx;$Nbig=$Ax;$GincUnit=$Cx*4; } else { $Nsmall=$Ax;$Nbig=$Cx;$GincUnit=($Ax+1)*4; }
if($Nsmall>2){for($i=0;$i<$Nsmall-2;$i+=1) {
if($i==0){ $Ninc=3;$BNstart_p=0;$Ginc=24;$BGstart_p=24;if($Cx<$Ax){ $Tinc=12;$BTstart_p=32; }else{ $Tinc=12;$BTstart_p=24; }}
$BNstart=$BNstart_p+$Ninc; $BNstart_p=$BNstart;
$BGstart=$BGstart_p+$Ginc; $BGstart_p=$BGstart;
$BTstart=$BTstart_p+$Tinc; $BTstart_p=$BTstart;
$Ninc=$Ninc+2; $Ginc=$Ginc+8; $Tinc=$Tinc; }} else { $BNstart=0;$BGstart=24; if($Cx<$Ax){ $BTstart=32; }else{ $BTstart=24; }}
$Nino=$BNstart+(($Nsmall-1)*($Nbig-$Nsmall)); $Gigo=$BGstart+(($GincUnit)*($Nbig-$Nsmall));
if($Cx<$Ax){ $Tito=$BTstart+(8*($Nbig-$Nsmall-1)); }else{ $Tito=$BTstart+(4*($Nbig-$Nsmall)); }
//print (“Nino:”+$Nino+“\n”);print (“Gigo:”+$Gigo+“\n”); print (“Tito:”+$Tito+“\n”);
// description:This part calculates the starting numbers $BNstart->Nino|$BGstart->Gigo|$BTstart->Tito | which special numbers needed for the unification equations
// These numbers are complex to predict so a graph was made to mapp these numbers through trial and error
if($Nsmall>2){for($i=0;$i<$Nsmall-2;$i+=1){ if($i==0){ if($Cx<$Ax){ $ITinc=3;$IT_p=-2; }else{ $ITinc=2;$IT_p=-2; }}
$IT=$IT_p+$ITinc; $IT_p=$IT; if($Cx<$Ax){ $ITinc=$ITinc+2; }else{ $ITinc=$ITinc+2; } }}else{$IT=2;} //print(“IT”+$IT+“\n”);
// description:This part calculates the initial incrementing unit for each base of Tito:IT
if($Nsmall<3){ if($Cx<$Ax){ $ITunit=-2;
}else{for($i=0;$i<=$Nbig-$Nsmall;$i+=1){ if($i==0){ $ITunit_p=$IT;$IA=0;} $ITunit=$ITunit_p-$IA; $ITunit_p=$ITunit;$IA=$Nsmall-1; } $ITunit=-1*$ITunit; }
}else{ if($Cx<$Ax){ for($i=0;$i<$Nbig-$Nsmall;$i+=1){ if($i==0){ $ITunit_p=$IT;$IA=0; } $ITunit=$ITunit_p+$IA; $ITunit_p=$ITunit;$IA=$Nsmall-2; }
}else{ for($i=0;$i<=$Nbig-$Nsmall;$i+=1){ if($i==0){ $ITunit_p=$IT;$IA=0; } $ITunit=$ITunit_p+$IA; $ITunit_p=$ITunit;$IA=$Nsmall-1; }}}
$ITunit=$ITunit*4;
//print(“ITunit”+$ITunit+“\n”);
// description:This part calculates the incrementing unit for each entry (Cx . Ax) of Tito:ITunit
for($k=0;$k<$Gx;$k+=1)
{
if($k==0){ $Nino_p=-$Nino;$Tit[$k]=0; }$Nin[$k]=$Nino_p+$Nino; $Nino_p=$Nin[$k];
if($k==1){ $Tit[$k]=$Tito;$Tit_p=$Tit[$k]; }
if($k>1){ $Tit[$k]=$Tit_p-$ITunit; $Tit_p=$Tit[$k]; }
//print (“Nin[“+$k+“]:”+$Nin[$k]+“\n”);//print (“Tit[“+$k+“]:”+$Tit[$k]+“\n”);
}
// description:This part calculates the propagation(k) the incrementing unit for Tito->Tit[k] Nino->Nin[k]
//----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
-
for($k=0;$k<$Gx;$k+=1)
{$e3= $k*(($Cx)*($Ax));
for($j=0;$j<$Ax;$j+=1)
{$e2=$j*($Cx); $c=$j+($k*$Ax);
for($i=0;$i<$Cx;$i+=1)
{$e1=$i; $e=$e1+$e2+$e3;
$idu=($e-$c)*4; $iduc=($e-$c)*4;
74 | $idu=($e-$c)*4; $iduc=($e-$c)*4;
if($i!=$Cx-1){
polyMergeVertex -d 0.01 -am 1 -ch 1 ($animal_c+“.vtx[“+(136+($e*$vtotal)-($idu))+“]”) ($animal_c+“.vtx[“+(($ni)+($e*$vtotal)-($iduc))+“]”);
polyMergeVertex -d 0.01 -am 1 -ch 1 ($animal_c+“.vtx[“+(137+($e*$vtotal)-($idu))+“]”) ($animal_c+“.vtx[“+(($ni-1)+($e*$vtotal)-($iduc))+“]”);
polyMergeVertex -d 0.01 -am 1 -ch 1 ($animal_c+“.vtx[“+(138+($e*$vtotal)-($idu))+“]”) ($animal_c+“.vtx[“+(($ni-2)+($e*$vtotal)-($iduc))+“]”);
polyMergeVertex -d 0.01 -am 1 -ch 1 ($animal_c+“.vtx[“+(139+($e*$vtotal)-($idu))+“]”) ($animal_c+“.vtx[“+(($ni-3)+($e*$vtotal)-($iduc))+“]”);
}
}
}
}
// description:This part Unifies in the i-direction (connecting the cells up and down) | The idu & iduc equations describe the number of vertices lost in every connection act
for($k=0;$k<$Gx;$k+=1)
{$e3= $k*(($Cx)*($Ax));
for($j=0;$j<$Ax;$j+=1)
{$e2=$j*($Cx); $c=$j+($k*$Ax);
for($i=0;$i<$Cx;$i+=1)
{$e1=$i; $e=$e1+$e2+$e3;
$jdu=($e*8)-(($c+($Cx-1))*4)-($k*($Cx*4));
$jduc=($e*8)-($c*4)-($k*($Cx*4));
if($j==0){ $jdu=($e*4)+($k*($Nino*4)); }
if($j!=$Ax-1){
polyMergeVertex -d 0.01 -am 1 -ch 1 ($animal_c+“.vtx[“+(180+($e*$vtotal)-($jdu))+“]”) ($animal_c+“.vtx[“+($nj+($e*$vtotal)-($jduc))+“]”);
polyMergeVertex -d 0.01 -am 1 -ch 1 ($animal_c+“.vtx[“+(181+($e*$vtotal)-($jdu))+“]”) ($animal_c+“.vtx[“+($nj+($e*$vtotal)-($jduc))+“]”);
polyMergeVertex -d 0.01 -am 1 -ch 1 ($animal_c+“.vtx[“+(183+($e*$vtotal)-($jdu))+“]”) ($animal_c+“.vtx[“+($nj+($e*$vtotal)-($jduc))+“]”);
polyMergeVertex -d 0.01 -am 1 -ch 1 ($animal_c+“.vtx[“+(182+($e*$vtotal)-($jdu))+“]”) ($animal_c+“.vtx[“+($nj+($e*$vtotal)-($jduc))+“]”);
}
//print (“e:”+$e+“ c:”+$c);
//print (“ jdu:”+$jdu+“ jduc:”+$jduc+“\n”);
//print (“Vside_giv:”+(164+($e*168)-($jdu))+“ Vside_rec:”+($nj+($e*168)-($jduc))+“\n”);
}
}
}
// description:This part Unifies in the j-direction (connecting the cells right and left) | The jdu & jduc equations describe the number of vertices lost in every connection act and the irregularities
described by $Nino
for($k=0;$k<$Gx;$k+=1)
{$e3= $k*(($Cx)*($Ax)); //print (“Tit[“+$k+“]:”+$Tit[$k]+“\n”); //print (“Nin[“+$k+“]:”+$Nin[$k]+“\n”);
for($j=0;$j<$Ax;$j+=1)
{$e2=$j*($Cx); $c=$j+($k*$Ax);
for($i=0;$i<$Cx;$i+=1)
{$e1=$i; $e=$e1+$e2+$e3;
$kdu=($e*12)-($c*4)-($k*($Cx*4))-$Gigo;
$kduc=($e*12)-($c*4)-($k*($Cx*4))-($Cx*4);
if($j==0){$kdu=($e*12)-(($e-$c)*4)-$Tit[$k]; $kduc=($e*12)-(($e-$Nin[$k])*4);}
if($k==0){$kdu=($e*12)-($e*4)-($c*4)-($Cx*4);if($j==0){$kdu=($e*12)/3;$kduc=($e*12)-($e*4);}}
if($k!=$Gx-1){
polyMergeVertex -d 0.01 -am 1 -ch 1 ($animal_c+“.vtx[“+(148+($e*$vtotal)-($kdu))+“]”) ($animal_c+“.vtx[“+($nk+($e*$vtotal)-($kduc))+“]”);
polyMergeVertex -d 0.01 -am 1 -ch 1 ($animal_c+“.vtx[“+(149+($e*$vtotal)-($kdu))+“]”) ($animal_c+“.vtx[“+($nk+($e*$vtotal)-($kduc))+“]”);
polyMergeVertex -d 0.01 -am 1 -ch 1 ($animal_c+“.vtx[“+(151+($e*$vtotal)-($kdu))+“]”) ($animal_c+“.vtx[“+($nk+($e*$vtotal)-($kduc))+“]”);
polyMergeVertex -d 0.01 -am 1 -ch 1 ($animal_c+“.vtx[“+(150+($e*$vtotal)-($kdu))+“]”) ($animal_c+“.vtx[“+($nk+($e*$vtotal)-($kduc))+“]”);
}
//print (“e:”+$e+“ c:”+$c);
//print (“ kdu:”+$kdu+“ kduc:”+$kduc+“\n”);
//print (“Vfront_giv:”+(164+($e*168)-($jdu))+“ Vfront_rec:”+($nj+($e*168)-($jduc))+“\n”);
}
}
}
// description:This part Unifies in the k-direction (connecting the cells front and back)
// The kdu & kduc equations describe the number of vertices lost in every connection act and the irregularities described by $Gigo, $Tit[k], $Nin[k]
| 75ü
4.3. Modélisation par interpolation
ü
4.3.1. Interpolation polynomiale
La seconde technique de modélisation majeur qui est de loin le plus utilisé dans la conception architecturale
est l’interpolation à travers des points discrets, l’interpolation est largement répandu dans le contexte de
l’ingénierie, en raison de sa capacité à rapprocher solution de problèmes pour lesquels nous n’avons pas une
formule explicite. Malgré la propagation de la modélisation par interpolation en architecture, il n’y a pas
beaucoup d’architectes qui construisent ou sont conscients de la construction mathématique de la méthode
d’interpolation qu’ils utilisent. Dans cette recherche, nous nous concentrons à donner des formules explicites
pour les formes que nous concevons, mais dans certains cas où la forme est souhaitable de passer par des
points discrets spécifiques, il est beaucoup plus facile de construire une interpolation polynomiale. Nous
allons voir un exemple de ce cas plus tard, quand nous construisons une surface passant par des points discrets
recueillies à partir d’une mesure externe, nous donnerons également la construction mathématique des courbes
et surfaces de Bézier et NURBS, qui sont les interpolations les plus largement utilisés dans les systèmes de
CAO aujourd’hui. Un système de modélisation CAO typique peut être considéré comme constitué de l’interaction
entre une interface graphique d’utilisateur (GUI) avec une géométrie: NURBS et /ou de représentation de
limite de données (B-rep) par l’intermédiaire d’un noyau de modélisation géométrique. «Non uniform rational
basis spline» (ou NURBS) est un modèle mathématique pour générer et représenter des courbes et des surfaces
avec une grande souplesse et précision. La représentation de limite (B-rep) est une méthode pour
représenter des formes à l’aide des limites; un solide est représenté comme un ensemble d’éléments de surface
reliés, la limite entre solide et non solide. Nous trouvons que la majorité des logiciels de CAO d’aujourd’hui
qui sont couramment utilisés dans la conception architecturale repose sur cette définition de NURBS de
courbes et de surfaces. Pour cette raison, et puisque dans cette recherche, nous nous intéressons à la géométrie
moderne et l’espace formel, nous allons expliquer la définition mathématique formelle de NURBS. Afin de
comprendre les NURBS, nous devons commencer par la notion de base de l’interpolation des courbes ou des
surfaces à travers un ensemble de points discrets, qui nous conduira à des méthodes d’interpolation plus
complexes tels que splines (bi)cubiques, Bézier et finalement NURBS. L’interpolation est un procédé de
construction de nouveaux points de données à l’intérieur de la plage d’un ensemble discret de points de
données connus. Une des méthodes d’interpolation les plus simples est l’interpolation linéaire (Lerp), une
interpolation linéaire est simplement la ligne droite entre deux points donnés dans l’ensemble discret. Naturellement,
dans une interpolation polynomiale, l’interpolant est un polynôme qui passe exactement à travers d’un
ensemble donné de points, et, dans une interpolation spline, l’interpolant est un type particulier: polynomiale
par morceaux appelée spline.
Fonction polynomiale [2]
est une fonction qui peut être définie par l' évaluation d ' un polynôme
une fonction f à un argument est appelé une fonction polynomiale si elle satisfait
f HxL = a0 x
0 + ... + an x
n = ⁄i=0
n ai x
i
Anneau de polynômes #[X] [2]
l' ensemble de tousles polynômes avec des coefficients dansle corps # Havec # = ! ou $L
#n@XD espace vectoriel des polynômes de degré n et #@XD est un anneau commutatif,
le symbole X est couramment appelé la variable
P, Q œ #n@XD , R œ #m@XD , pi
, qi
, ri œ # pour i = 0, ..., n et j = 0, ..., m
PHXL = ⁄i=0
n pi X
i
, QHXL = ⁄i=0
n qi X
i
et RHXL = ⁄j=0
m rj X
j
PHXL + QHXL = HP + QL HXL = ⁄i=0
n
Hpi + qiL X
i
et PHXL RHXL = ⁄k=0
m+n
I⁄i+ j=k pi ri
M X
i
le corps # peut être remplacé par n' importe quel anneau commutatif comme !,
donnant lieu à l' anneau de polynômes sur ! qui est notée !@XD
76 | Avant de commencer à construire les polynômes d’interpolation plus élaborés que nous allons utiliser dans la
conception architecturale, nous devons d’abord commencer par les bases de l’interpolation polynomiale, pour
cela, nous allons montrer la matrice de Vandermonde. Le problème de cette méthode est que le degré du
polynôme va augmenter avec l’augmentation du nombre de points qui donnent lieu à un polynôme moins
stable avec un grand nombre d’oscillations. Nous allons résoudre ce problème lorsque nous allons construire
les splines cubiques et bi-cubiques, où la courbe est faite à partir de segments, chacun est un polynôme de
degré trois.
Interpolation polynomiale [2]
est l' interpolation d ' un ensemble de points donné
par un polynôme qui passe exactement à travers de ces points
pi œ !2
, pour i = 0, ..., n Hun ensemble de n + 1 points de donnéesL " i, j œ 80, .., n< , xi = x jói = j
" i œ 80, .., n< , PHxiL = yi
, P est l' unique interpolation polynomiale degHPL § n
pour n + 1 pointsHxiL, P : #
n+1ö#n@XD est une bijection linéaire,
" i œ 80, .., n<, PHxiL = ⁄k=0
n ak xi
k = a0 xi
0 + ... + an xi
n = yi
pour trouver les coefficients ak pour k = 0, ..., n de l' interpolant P nous résolvonsle système
M A = B ïA = M-1 B , où M est la matrice de Vandermonde
1 x0
1
.. x0
n
1 x1
1
.. x1
n
: : .. :
1 xn
1
.. xn
n
a0
a1
:
an
=
y0
y1
:
yn
Interpolant P avec deg(P) = 3
G = 9pi = Hxi
, yiL œ !2
, for i = 0, ..., 3= est un ensemble de quatre points distincts
p0 = I-1, 1
2
M, p1 = H0, 0L, p2 = I1, -
1
2
M et p3 = H2, 0L
P œ #3@XD est un polynôme d ' interpolation de degré =
3 PHxiL = ⁄k=0
3 ak xi
k = a0 xi
0 + a1 xi
1 + a2 xi
2 + a3 xi
3 = yi
B =
t
Hy0, ..., y3L =
t
H2, 0, -2, 0L est le vecteur connu
A =
t
Ha0, ..., a3L est le vecteur des coefficients de P et M est la matrice de Vandermonde
M A = B ï
1 x0
1
x0
2
x0
3
1 x1
1
x1
2
x1
n
1 x2
1
x2
2
x2
n
1 x3
1
x3
2
x3
n
a0
a1
a2
a3
=
y0
y1
y2
y3
ïA = M-1 B ï
a0
a1
a2
a3
=
1 -1 1 -1
1 0 0 0
1 1 1 1
1 2 4 8
-1
1
2
0
-
1
2
0
=
0
-
2
3
0
-
1
6
ïP : !ö!, PHxL = H0L x
0 + I-
2
3
M x
1 +H0L x
2 + I-
1
6
M x
3 = -
2 x
3
+
x
3
6
Représentation d’un polynôme d’interpolation de degré 3 à travers 4 points
| 77ü
4.3.2. Splines cubique et bicubique
Avec la définition du polynôme d’interpolation clarifié nous allons définir maintenant le spline cubique et
bicubique. Une spline est une fonction polynomiale suffisamment lisse par morceaux polynôm; les types les
plus courants sont: B-spline cubique et cubique splines de Bézier. Une courbe cubique peut avoir qu’un seul
point d’inflexion, de faire une courbe avec trois points d’inflexion, nous devons ajouter des points de contrôle
supplémentaires et utilisant un polynôme de degré supérieur (degré ¥ 3). Néanmoins, ces polynômes de degré
supérieur sont sensibles à la position des points et ne font pas toujours des formes lisses. De construire un
polynôme par morceaux est de laisser chaque paire de points de contrôle représenter un segment (polynôme
cubique) de la courbe.
Construction générale de splines cubiques (forme non paramétrique) [2]
pi œ !2
, pour i = 0, ..., n Hun ensemble de n + 1 points de donnéesL " i, j œ 80, .., n< , xi = x jói = j
PiHxiL = ⁄k=0
3 ak,i xi
k = a0,i xi
0 + a1,i xi
1 + a2,i xi
2 + a3,i xi
3 = yi Hle segment entre pi & pi+1L
les dérivés des segments
Pi
' Hxi+1L = a1,i + 2 a2,i
Hxi+1L + 3 a3,i
Hxi+1L
2
et Pi+1 ' Hxi+1L = a1,i+1 + 2 a2,i+1 Hxi+1L + 3 a3,i+1 Hxi+1L
2
Pi
'' Hxi+1L = 2 a2,i +6 a3,i
Hxi+1L et Pi+1 '' Hxi+1L = 2 a2,i+1 +6 a3,i+1 Hxi+1L
les conditions qui construisent le système
PiHxiL = yi et Pi Hxi+1L = yi+1 IC
0
continuitéM et Pi
' Hxi+1L = Pi+1 ' Hxi+1L IC
1
continuitéM
Pi
'' Hxi+1L = Pi+1 '' Hxi+1L IC
2
continuitéM ,
P0 ' Hx0L = s0 et Pn-1 ' HxnL = sn HPentes aux points des extrémitésL
les équations du système
a1,0 + 2 a2,0 Hx0L + 3 a3,0 Hx0L
2 = s0
a0,i xi
0 + a1,i xi
1 + a2,i xi
2 + a3,i xi
3 = yi
a0,i xi+1
0 + a1,i xi+1
1 + a2,i xi+1
2 + a3,i xi+1
3 = yi+1
a1,i + 2 a2,i
Hxi+1L + 3 a3,i
Hxi+1L
2 - a1,i+1 - 2 a2,i+1 Hxi+1L - 3 a3,i+1 Hxi+1L
2 = 0
2 a2,i +6 a3,i
Hxi+1L - 2 a2,i+1 -6 a3,i+1 Hxi+1L = 0
a1,n-1 + 2 a2,n-1 HxnL + 3 a3,n-1 HxnL
2 = sn
pour n + 1 points que nous avons besoin de n segmentsï 4 n équations
ï le système pour n = 4 Hi.e. 5 points de donnéesL
0 1 2 x0
1 3 x0
2 0 0 0 0 0 0 0 0 0 0 0 0
1 x0
1
x0
2
x0
3 0 0 0 0 0 0 0 0 0 0 0 0
1 x1
1
x1
2
x1
3 0 0 0 0 0 0 0 0 0 0 0 0
0 1 2 x1
1 3 x1
2 0 -1 -2 x1
1 -3 x1
2 0 0 0 0 0 0 0 0
0 0 2 6 x1
1 0 0 -2 -6 x1
1 0 0 0 0 0 0 0 0
0 0 0 0 1 x1
1
x1
2
x1
3 0 0 0 0 0 0 0 0
0 0 0 0 1 x2
1
x2
2
x2
3 0 0 0 0 0 0 0 0
0 0 0 0 0 1 2 x2
1 3 x2
2 0 -1 -2 x2
1 -3 x2
2 0 0 0 0
0 0 0 0 0 0 2 6 x2
1 0 0 -2 -6 x2
1 0 0 0 0
0 0 0 0 0 0 0 0 1 x2
1
x2
2
x2
3 0 0 0 0
0 0 0 0 0 0 0 0 1 x3
1
x3
2
x3
3 0 0 0 0
0 0 0 0 0 0 0 0 0 1 2 x3
1 3 x3
2 0 -1 -2 x3
1 -3 x3
2
0 0 0 0 0 0 0 0 0 0 2 6 x3
1 0 0 -2 -6 x3
1
0 0 0 0 0 0 0 0 0 0 0 0 1 x3
1
x3
2
x3
3
0 0 0 0 0 0 0 0 0 0 0 0 1 x4
1
x4
2
x4
3
0 0 0 0 0 0 0 0 0 0 0 0 0 1 2 x4
1 3 x4
2
a0,0
a1,0
a2,0
a3,0
a0,1
a1,1
a2,1
a3,1
a0,2
a1,2
a2,2
a3,2
a0,3
a1,3
a2,3
a3,3
=
s0
y0
y1
0
0
y1
y2
0
0
y2
y3
0
0
y3
y4
s4
78 | Splines cubique à travers 5 points de données (forme non paramétrique)
G = 9pi = Hxi
, yiL œ !2
, pour i = 0, ..., 4= est un ensemble de 5 points de données distincts
p0 = H0, 1L, p1 = H2, 3L, p2 = H4, -1L ,
p3 = H6, 1L et p4 = H8, 0L et la pente de débuts0 = -1 et la pente du bouts4 = 2
Pi œ #3@XD est un polynôme d ' interpolation de degré =
3 PiHxiL = ⁄k=0
3 ak,i xi
k = a0,i xi
0 + a1,i xi
1 + a2,i xi
2 + a3,i xi
3 = yi
B =
t
Hs0, y0, y1, 0, 0, y1, y2, 0, 0, y2, y3, 0, 0, y3, y4, s4L est le vecteur connu
A =
t
Ha0,0, a1,0, a2,0, a3,0, a0,1, a1,1, a2,1, a3,1, a0,2, a1,2, a2,2, a3,2, a0,3, a1,3, a2,3, a3,3, a0,4, a1,4, a2,4, a3,4L
A est le vecteur des coefficients de l' interpolant P
et M est le système de matrice d’équations M A = B
ï A = M-1 B
ï A =
a0,0
a1,0
a2,0
a3,0
a0,1
a1,1
a2,1
a3,1
a0,2
a1,2
a2,2
a3,2
a0,3
a1,3
a2,3
a3,3
=
0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 2 4 8 0 0 0 0 0 0 0 0 0 0 0 0
0 1 4 12 0 -1 -4 -12 0 0 0 0 0 0 0 0
0 0 2 12 0 0 -2 -12 0 0 0 0 0 0 0 0
0 0 0 0 1 2 4 8 0 0 0 0 0 0 0 0
0 0 0 0 1 4 16 64 0 0 0 0 0 0 0 0
0 0 0 0 0 1 8 48 0 -1 -8 -48 0 0 0 0
0 0 0 0 0 0 2 24 0 0 -2 -24 0 0 0 0
0 0 0 0 0 0 0 0 1 4 16 64 0 0 0 0
0 0 0 0 0 0 0 0 1 6 36 216 0 0 0 0
0 0 0 0 0 0 0 0 0 1 12 108 0 -1 -12 -108
0 0 0 0 0 0 0 0 0 0 2 36 0 0 -2 -36
0 0 0 0 0 0 0 0 0 0 0 0 1 6 36 216
0 0 0 0 0 0 0 0 0 0 0 0 1 8 64 512
0 0 0 0 0 0 0 0 0 0 0 0 0 1 16 192
-1 -1
1
3
0
0
3
-1
0
0
-1
1
0
0
1
0
2
l' interpolant PHxL est égal à
si x0 § x < x1 = P0HxL = 1 - x +
597 x
2
224 -
373 x
3
448
si x1 § x < x2 = P1HxL = -
163
14 +
503 x
28 -
1527 x
2
224 +
335 x
3
448
si x2 § x < x3 = P2HxL =
1097
14 -
1387 x
28 +
2253 x
2
224 -
295 x
3
448
si x3 § x < x4 = P2HxL = -
1598
7
+
1453 x
14 -
3471 x
2
224 +
341 x
3
448
Représentation d’une spline cubique à travers 5 points de données (forme non paramétrique)
| 79Construction générale de splines cubiques (forme paramétrique)
Il s’agissait de la forme générale de la spline cubique mais ce qui est plus intéressant du point de vue de la
conception architecturale est la paramétrisation de cette forme, comme cela, nous sommes en mesure de
libérer la variable x à aller en avant et en arrière si nous sommes dans !2
et que nous pouvons commencer à
dessiner des courbes dans !3
. Ces courbes dans !3
sont largement utilisés dans le logiciel de CAO et ils sont
également la base pour la construction des surfaces qui les relient; cependant l’utilisateur du système de CAO
n’a pas accès à aux fonctions d’interpolation polynomiales de ces courbes, elles sont la plupart du temps caché
dans la bibliothèque du logiciel. Cependant, dans cette recherche, puisque nous construisons ces fonctions
nous-mêmes, nous avons accès à leur structure, et nous pouvons choisir entre les différentes techniques
d’interpolation, en fonction de nos besoins, ce qui sera montré plus tard, quand nous allons utiliser ces fonctions
d’interpolation dans notre processus de conception. Nous allons maintenant définir une forme
paramétrique de la spline cubique
Construction générale de splines cubiques (forme paramétrique) [2]
pi œ !3
, pour i = 0, ..., n Hun ensemble de n + 1 points de donnéesL " i, j œ 80, ..., n< , xi = x jói = j
maintenant le paramètre ne sera pasla variable x,
mais u sur n intervalles Ii = @ci
, diD pour i = 0, ..., n et pour l œ 8x, y, z<
ti = fiHuL fiHciL = 0 et fiHdiL = 1 et d ti
d u =
d fi
d u = 1
l' équation de la courbe cubique paramétrique
Pli
HtiL = Pli
H fi HuLL = ⁄k=0
3
alk,i
fiHuL
k = al0,i
fi HuL
0 + al1,i
fi HuL
1 + al2,i
fi HuL
2 + al3,i
fiHuL
3 = li
Pli
HtiL = al0,i
t
i
0 + al1,i
t
i
1 + al2,i
t
i
2 + al3,i
t
i
3 = li Hle composant l pour le segment entre pi & pi+1L
dérivés par rapport à t Hi.e. f L et par rapport à u
Dfi
@Pli
H fi HuLLD =
d Pli
d fi
= al1,i + 2 al2,i
H fiHuLL + 3 al3,i
H fiHuLL2
Dfi
2
@Pli
H fi HuLLD =
d
2 Pli
d fi
2 = 2 al2,i +6 al3,i
H fiHuLL
Du @Pli
H fi HuLLD =
d Pli
d fi
d fi
d u = Dfi
@Pli
H fi HuLLD = Pli
' H fiHuLL
Du
2
@Pli
H fi HuLLD = J
d Pli
'
d fi
d fi
d u N
d fi
d x = Dfi
2
@Pli
H fi HuLLD = Pli
'' H fiHuLL
les conditions qui construisent le système
Pli
H fi HciLL = li et Pli
H fiHdiLL = li+1 IC
0
continuitéM et Pli
' H fiHdiLL = Pli+1
' H fi+1Hci+1LL IC
1
continuitéM
Pli
'' H fiHdiLL = Pli+1
'' H fi+1Hci+1LL IC
2
continuitéM,
Pl0
' H f0Hc0LL = s0 et Pln-1
' H fn-1Hdn-1LL = sn HPentes aux points des extrémitésL
les équations du système
Pl0
' H f0Hc0LL = al1,0 + 2 al2,0 H f0Hc0LL + 3 al3,0 H f0Hc0LL2 = s0 ï al1,0 = s0 ... H1L
Pli
H fi HciLL = al0,i
fi HciL
0 + al1,i
fi HciL
1 + al2,i
fi HciL
2 + al3,i
fiHciL
3 = li ï al0,i = li
... H2L
Pli
H fi HdiLL = al0,i
fi HdiL
0 + al1,i
fi HdiL
1 + al2,i
fi HdiL
2 + al3,i
fiHdiL
3 = li+1
ï al0,i + al1,i + al2,i + al3,i = li+1 ... H3L
Pli
' H fiHdiLL = Pli+1
' H fi+1Hci+1LL
ï al1,i + 2 al2,i
H fiHdiLL + 3 al3,i
H fiHdiLL2 = al1,i+1 + 2 al2,i+1 H fi+1Hci+1LL + 3 al3,i+1 H fi+1Hci+1LL2
ï al1,i + 2 al2,i +3 al3,i - al1,i+1 = 0 ... H4L
Pli
'' H fiHdiLL = Pli+1
'' H fi+1Hci+1LL
ï 2 al2,i +6 al3,i
H fiHdiLL = 2 al2,i+1 +6 al3,i+1 H fi+1Hci+1LL ï2 al2,i +6 al3,i - 2 al2,i+1 = 0 ... H5L
Pln-1
' H fn-1Hdn-1LL = al1,n-1 + 2 al2,n-1 H fn-1Hdn-1LL + 3 al3,n-1 H fn-1Hdn-1LL2 = sn
ï al1,n-1 + 2 al2,n-1 +3 al3,n-1 = sn ... H6L
80 | pour n + 1 points que nous avons besoin de n segmentsï 4 n équations ï le système pour n =
4 Hi.e. 5 points de donnéesL
0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0
0 1 2 3 0 -1 0 0 0 0 0 0 0 0 0 0
0 0 2 6 0 0 -2 0 0 0 0 0 0 0 0 0
0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0
0 0 0 0 0 1 2 3 0 -1 0 0 0 0 0 0
0 0 0 0 0 0 2 6 0 0 -2 0 0 0 0 0
0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0
0 0 0 0 0 0 0 0 0 1 2 3 0 -1 0 0
0 0 0 0 0 0 0 0 0 0 2 6 0 0 -2 0
0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1
0 0 0 0 0 0 0 0 0 0 0 0 0 1 2 3
ax0,0 ay0,0 az0,0
ax1,0 ay1,0 az1,0
ax2,0 ay2,0 az2,0
ax3,0 ay3,0 az3,0
ax0,1 ay0,1 az0,1
ax1,1 ay1,1 az1,1
ax2,1 ay2,1 az2,1
ax3,1 ay3,1 az3,1
ax0,2 ay0,2 az0,2
ax1,2 ay1,2 az1,2
ax2,2 ay2,2 az2,2
ax3,2 ay3,2 az3,2
ax0,3 ay0,3 az0,3
ax1,3 ay1,3 az1,3
ax2,3 ay2,3 az2,3
ax3,3 ay3,3 az3,3
=
sx0 sy0
sz0
x0 y0 z0
x1 y1 z1
0 0 0
0 0 0
x1 y1 z1
x2 y2 z2
0 0 0
0 0 0
x2 y2 z2
x3 y3 z3
0 0 0
0 0 0
x3 y3 z3
x4 y4 z4
sx4 sy4
sz4
Splines cubique à travers 5 points de données (forme paramétrique)
G = 9pi = Hxi
, yi
, ziL œ !3
, pour i = 0, ..., 4= est un ensemble de 5 points de données distincts
p0 = H2, 0, 0L, p1 = H1, 0, 2L, p2 = H1, 1, 1L , p3 = H-1, 2, 1L et p4 = H3, 3, 5L
les pentes au débuts0 = Is0x
, s0y
, s0z
M = H-1, -1, -1L et les pentes au bouts4 = Is4x
, s4y
, s4z
M = H2, -2, -2L
ti = fiHuL = u - i fiHciL = 0 et fiHdiL = 1 et d ti
d u =
d fi
d u = 1
pour u œ Ii = @ci
, diD pour i = 0, ..., n et pour l œ 8x, y, z<
Pli œ #3@XD est un polynôme d ' interpolation de degré = 3 tel que
Pli
HtiL = ⁄k=0
3 ak,i
t
i
k = al0,i
t
i
0 + al1,i
t
i
1 + al2,i
t
i
2 + al3,i
t
i
3 = li
Bl =
t
Hs0l, l0, l1, 0, 0, l1, l2, 0, 0, l2, l3, 0, 0, l3, l4, s4lL est le vecteur connu
Al =
t
Ha0,0, a1,0, a2,0, a3,0, a0,1, a1,1, a2,1, a3,1, a0,2, a1,2, a2,2, a3,2, a0,3, a1,3, a2,3, a3,3, a0,4, a1,4, a2,4, a3,4L
est le vecteur des coefficients de l' interpolant Pl
et M est le système de matrice d ' équations matrix M Al = Bl où A = H Ax Ay Az L et B = H Bx By Bz L
A = M-1 B =
0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0
0 1 2 3 0 -1 0 0 0 0 0 0 0 0 0 0
0 0 2 6 0 0 -2 0 0 0 0 0 0 0 0 0
0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0
0 0 0 0 0 1 2 3 0 -1 0 0 0 0 0 0
0 0 0 0 0 0 2 6 0 0 -2 0 0 0 0 0
0 0 0 0 0 0 0 0 1 0 0 0 0 0 0 0
0 0 0 0 0 0 0 0 1 1 1 1 0 0 0 0
0 0 0 0 0 0 0 0 0 1 2 3 0 -1 0 0
0 0 0 0 0 0 0 0 0 0 2 6 0 0 -2 0
0 0 0 0 0 0 0 0 0 0 0 0 1 0 0 0
0 0 0 0 0 0 0 0 0 0 0 0 1 1 1 1
0 0 0 0 0 0 0 0 0 0 0 0 0 1 2 3
-1 -1 -1 -1
2 0 0
1 0 2
0 0 0
0 0 0
1 0 2
1 1 1
0 0 0
0 0 0
1 1 1
-1 2 1
0 0 0
0 0 0
-1 2 1
3 3 5
2 -2 -2
| 81l' interpolant PH f HuLL = IPxH f HuLL, PyH f HuLL, PzH f HuLLM est égal à
si 0 § u < 1 , PH f HuLL =
Px0
H f0HuLL
Py0
H f0 HuLL
Pz0
H f0 HuLL
=
2 - u -
27 u
2
28 +
27 u
3
28
-u +
17 u
2
14 -
3 u
3
14
-u +
181 u
2
28 -
97 u
3
28
si 1 § u < 2 , PH f HuLL =
Px1
H f1HuLL
Py1
H f1 HuLL
Pz1
H f1 HuLL
=
1 +
1-u
28 +
27
14 H-1 + uL
2 -
53
28 H-1 + uL
3
11
14 H-1 + uL +
4
7
H-1 + uL
2 -
5
14 H-1 + uL
3
2 +
43
28 H-1 + uL -
55
14 H-1 + uL
2 +
39
28 H-1 + uL
3
si 2 § u < 3 , PH f HuLL =
Px2
H f2HuLL
Py2
H f2 HuLL
Pz2
H f2 HuLL
=
1 -
13
7
H-2 + uL -
15
4
H-2 + uL
2 +
101
28 H-2 + uL
3
1 +
6
7
H-2 + uL -
1
2
H-2 + uL
2 +
9
14 H-2 + uL
3
1 -
15
7
H-2 + uL +
1
4
H-2 + uL
2 +
53
28 H-2 + uL
3
si 3 § u < 4 , PH f HuLL =
Px3
H f3HuLL
Py3
H f3 HuLL
Pz3
H f3 HuLL
=
-1 +
41
28 H-3 + uL +
99
14 H-3 + uL
2 -
127
28 H-3 + uL
3
2 +
25
14 H-3 + uL +
10
7
H-3 + uL
2 -
31
14 H-3 + uL
3
1 +
113
28 H-3 + uL +
83
14 H-3 + uL
2 -
167
28 H-3 + uL
3
Représentation d’une spline cubique (forme paramétrique)
82 | Méthode itérative
La méthode précédente est très simple pour dessiner la spline cubique, le seul problème est que le nombre de
points détermine le nombre d’équations à résoudre donc la matrice M devra être réglée si nous ajoutons ou
supprimer des points dans le processus de conception, qui n’est pas très efficace. Alors maintenant, nous
allons limiter la taille de la matrice à 4ä4 et utiliser une boucle itérative pour calculer les coefficients des
polynômes à travers les segments. Nous allons définir trois types importants de splines cubiques: l’Hermite
cubique, Catmull Rom et la spline Cardinal, qui peuvent être utilisés dans l’itération.
Méthode itérative pour dessiner la spline cubique [2]
pi œ !3
, ti œ !3
, pour i = 0, ..., n Hun ensemble de n + 1 points de donnéesL
Pli
HtiL = ⁄k=0
3 ak,i
t
i
k = al0,i
t
i
0 + al1,i
t
i
1 + al2,i
t
i
2 + al3,i
t
i
3 = li
Hle composant l pour le segment entre pi & pi+1L
ti = fiHuL = u - i fiHciL = 0 et fiHdiL = 1 et d ti
d u =
d fi
d u = 1 pour u œ Ii = @ci
, diD pour i = 0, ...,
n et pour l œ 8x, y, z<
PiHtiL =
PiH fiHuLL =
Px i
HtiL
Py i
HtiL
Pz i
HtiL
=
ax0,i
t
i
0 + ax1,i
t
i
1 + ax2,i
t
i
2 + ax3,i
t
i
3
ay0,i
t
i
0 + ay1,i
t
i
1 + ay2,i
t
i
2 + ay3,i
t
i
3
az0,i
t
i
0 + az1,i
t
i
1 + az2,i
t
i
2 + az3,i
t
i
3
et Pi
' HtiL =
ax1,i + 2 ax2,i
ti + 3 ax3,i
t
i
2
ay1,i + 2 ay2,i
ti + 3 ay3,i
t
i
2
az1,i + 2 az2,i
ti + 3 az3,i
t
i
2
ti =
ti,x
ti,y
ti,z
est la tangente donnée en pi et mi =
mi,x =
ti,x
xi+1-xi
mi,y =
ti,y
yi+1-yi
mi,z =
ti,z
zi+1-zi
est la tangente mise à l' échelle enpi
les conditions qui construisent le système
PiH0L = pi
, PiH1L = pi+1 , Pi
' H0L = mi et Pi
' H1L = mi+1
le système pour le segment entre Hxi
, yi
, ziL et Hxi+1, yi+1, zi+1L est donnée par
1 0 0 0
1 1 1 1
0 1 0 0
0 1 2 3
ax0,i ay0,i
az0,i
ax1,i ay1,i
az1,i
ax2,i ay2,i
az2,i
ax3,i ay3,i
az3,i
=
xi yi zi
xi+1 yi+1 zi+1
mi,x mi,x mi,x
mi+1,x mi+1,y mi+1,z
dansle cas d ' Hermite cubique spline ti =
ti,x
ti,y
ti,z
est donnée à chaque pi
dansle cas de Catmull Rom spline ti =
pi+1-pi-1
2
=
ti,x =
xi+1-xi-1
2
ti,y =
yi+1-yi-1
2
ti,z =
zi+1-zi-1
2
dansle cas de la spline Cardinal ti =
H1-cL Hpi+1-pi-1
L
2
=
ti,x =
H1-cL Hxi+1-xi-1
L
2
ti,y =
H1-cL Hyi+1-yi-1
L
2
ti,z =
H1-cL Hzi+1-zi-1
L
2
Hi.e. un paramètre de forme c est ajouté pour contrôler la courbure autour de piL
| 83Maintenant, nous allons montrer une spline cubique construit en utilisant une itération, en passant par les
points à interpoler, comme nous l’avons mentionné il y a quelques méthodes pour créer cette interpolantion.
Iteration through n points using the Catmul Rom spline
G = 9pi = Hxi
, yi
, ziL œ !3
, pour i = 1, ..., n= est un ensemble de n points de données distincts
la spline ne passe pas par p1 et pn ils ne sont utilisés que pour donner la tangence aux extrémités de la spline
pour n = 8 la spline interpole 6 points ï nous aurons un système de 24 équations, lieu de cela nous allons
créer une itération
p1 = H0, 0, 0L, p2 = I
1
2
,
1
2
,
1
2
M , p3 = H2, 0, 1L , p4 = H4, 0, 4L,
p5 = H4, 3, 2L, p6 = H3, 4, 4L, p7 = H5, 5, 5L et p8 = H6, 6, 6L
n = CardHGL = 8 et c = 1 Hune valeur de comptage initialeL
nous itérons pour i = 2, ..., n - 2
m1 = I
pi+1-pi-1
2
M, m2 = I
pi+2-pi-2
2
M ,
a0
a1
a2
a3
=
1 0 0 0
1 1 1 1
0 1 0 0
0 1 2 3
-1 pi
pi+1
m1
m2
PcHuL = a0 + a1 Hu - Hc - 1LL + a2 Hu - Hc - 1LL2 + a3Hu - Hc - 1LL3
c = c + 1
l' interpolant PHuL est égal à
si 0 § u < 1 , PHuL = P1HuL, si 1 § u < 2 , PHuL = P2HuL, si 2 § u § 3 , PHuL = P3HuL
si 3 § u < 4 , PHuL = P4HuL, si 4 § u < 5 , PHuL = P5HuL, si 5 § u § 6 , PHuL = P6HuL
Représentation d’une itération à travers 8 points en utilisant la spline de Catmull Rom
84 | Spline bicubique
Maintenant que nous avons construit la spline cubique, il est naturel de construire son analogue sur une grille
bidimensionnelle de points, à savoir une spline bicubique qui est une surface paramétrique qui passe par ces
points de grille. La spline bicubique est la première des trois types d’interpolation à deux dimensions que nous
allons construire dans le cadre de cette recherche, la deuxième serait la surface de Bézier et la troisième sera la
surface NURBS. Maintenant, nous allons définir l’interpolation bicubique qui est une extension de l’interpolation
cubique destiné à interpoler des points de données sur une grille régulière à deux dimensions, il est
souvent choisie de préférence à l’interpolation bilinéaire et la méthode du plus proche voisin dans le rééchantillonnage
d’image.
Spline bicubique [3]
G = 9pi, j œ !3
, i = 0, .., m et j = 0, .., n= est un ensemble de Hm + 1LäHn + 1L points de données et ti œ !3
Pli, j
Iti
, sj
M = ⁄k=0
3 ⁄l=0
3
alk,l,i, j
ti
k
sj
l = li, j
Ile composant l pour le carré entre pi, j
, pi+1, j
, pi+1, j+1, pi, j+1M
Pli, j
Iti
, sj
M = al0,0,i, j
ti
0
sj
0 + al0,1,i, j
ti
0
v
1 + al0,2,i, j
ti
0
v
2 + al0,3 ti
0
v
3
+al1,0,i, j
ti
1
sj
0 + al1,1,i, j
ti
1
sj
1 + al1,2,i, j
ti
1
sj
2 + al1,3,i, j
ti
1
sj
3
+al2,0,i, j
ti
2
sj
0 + al2,1,i, j
ti
2
sj
1 + al2,2,i, j
ti
2
sj
2 + al2,3,i, j
ti
2
sj
3
+al3,0,i, j
ti
3
sj
0 + al3,1,i, j
ti
3
sj
1 + al3,2,i, j
ti
3
sj
2 + al3,3,i, j
ti
3
sj
3 = li, j
la surface interpolée sur un carré Ipi, j
, pi+1, j
, pi+1, j+1, pi, j+1M est donnée par
Pi, j
Hu, vL =
Pxi, j
Iti
, sj
M = Pxi, j
I fiHuL, gjHvLM
Pyi, j
Iti
, sj
M = Pyi, j
I fiHuL, gjHvLM
Pzi, j
Iti
, sj
M = Pzi, j
I fiHuL, gjHvLM
ti = fiHuL = u -i etsj = gj HvL = v - j fiHciL = 0 , fiHdiL = 1, gj
Ie j
M = 0, gj
Ihj
M = 1
d ti
d u =
d fi
d u =
d sj
d v =
d gj
d v = 1 pour u, v œ Ii, j = @ci
, diDäAe j
, hjE pour i = 0, ..., m et j = 0, .., n et pour l œ 8x, y, z<
les dérivés dansles directions u, v et u v
Pu li, j
Iti
, sj
M = ⁄k=0
3 ⁄l=0
3
k alk,l,i, j
ti
k-1
sj
l
Pu li, j
Iti
, sj
M = al1,0,i, j
ti
0
sj
0 + al1,1,i, j
ti
0
sj
1 + al1,2,i, j
ti
0
sj
2 + al1,3,i, j
ti
0
sj
3 + 2 al2,0,i, j
ti
1
sj
0
+2 al2,1,i, j
ti
1
sj
1 + 2 al2,2,i, j
ti
1
sj
2 + 2 al2,3,i, j
ti
1
sj
3
+3 al3,0,i, j
ti
2
sj
0 + 3 al3,1,i, j
ti
2
sj
1 + 3 al3,2,i, j
ti
2
sj
2 + 3 al3,3,i, j
ti
2
sj
3
Pv li, j
Iti
, sj
M = ⁄k=0
3 ⁄l=0
3
l alk,l,i, j
ti
k
sj
l-1
Pv li, j
Iti
, sj
M = al0,1,i, j
ti
0
sj
0 + 2 al0,2,i, j
ti
0
sj
1 + 3 al0,3,i, j
ti
0
sj
2
+al1,1,i, j
ti
1
sj
0 + 2 al1,2,i, j
ti
1
sj
1 + 3 al1,3,i, j
ti
1
sj
2
+al2,1,i, j
ti
2
sj
0 + 2 al2,2,i, j
ti
2
sj
1 + 3 al2,3,i, j
ti
2
sj
2
+al3,1,i, j
ti
3
sj
0 + 2 al3,2,i, j
ti
3
sj
1 + 3 al3,3,i, j
ti
3
sj
2
Pu v li, j
Iti
, sj
M = ⁄k=1
3 ⁄l=1
3
k l alk,l,i, j
ti
k-1
sj
l-1
Pu v li, j
Iti
, sj
M = al1,1,i, j
ti
0
sj
0 + 2 al1,2,i, j
ti
0
sj
1 + 3 al1,3,i, j
ti
0
sj
2
+2 al2,1,i, j
ti
1
sj
0 + 4 al2,2,i, j
ti
1
sj
1 + 6 al2,3,i, j
ti
1
sj
2
+3 al3,1,i, j
ti
2
sj
0 + 6 al3,2,i, j
ti
2
sj
1 + 9 al3,3,i, j
ti
2
sj
2
| 85les conditions qui construisent le système
Pli, j
H0, 0L = li, j = al0,0,i, j
Pli, j
H1, 0L = li+1, j = al0,0,i, j + al1,0,i, j + al2,0,i, j + al3,0,i, j
Pli, j
H0, 1L = li, j + 1 = al0,0,i, j + al0,1,i, j + al0,2,i, j + al0,3,i, j
Pli, j
H1, 1L = ⁄k=0
3 ⁄l=0
3
alk,l,i, j
Pu li, j
H0, 0L = al1,0,i, j
Pu li, j
H1, 0L = al1,0,i, j + 2 al2,0,i, j + 3 al3,0,i, j
Pu li, j
H0, 1L = al1,0,i, j + al1,1,i, j + al1,2,i, j + al1,3,i, j
Pu li, j
H1, 1L = ⁄k=1
3 ⁄l=0
3
k alk,l,i, j
Pv li, j
H0, 0L = al0,1,i, j
Pv li, j
H1, 0L = al0,1,i, j + al1,1,i, j + al2,1,i, j + al3,1,i, j
Pv li, j
H0, 1L = al0,1,i, j + 2 al0,2,i, j + 3 al0,3,i, j
Pv li, j
H1, 1L = ⁄k=0
3 ⁄l=1
3
l alk,l,i, j
Pu v li, j
H0, 0L = al1,1,i, j
Pu v li, j
H1, 0L = al1,1,i, j + 2 al2,1,i, j + 3 al3,1,i, j
Pu v li, j
H0, 1L = al1,1,i, j + 2 al1,2,i, j + 3 al1,3,i, j
Pu v li, j
H1, 1L = ⁄k=1
3 ⁄l=1
3
k l alk,l,i, j
le système est donnée par
1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0
1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 1 0 0 0 2 0 0 0 3 0 0 0
0 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0
0 0 0 0 1 1 1 1 2 2 2 2 3 3 3 3
0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0
0 1 2 3 0 0 0 0 0 0 0 0 0 0 0 0
0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3
0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 1 0 0 0 2 0 0 0 3 0 0
0 0 0 0 0 1 2 3 0 0 0 0 0 0 0 0
0 0 0 0 0 1 2 3 0 2 4 6 0 3 6 9
ax0,0,i, j ay0,0,i, j
az0,0,i, j
ax0,1,i, j ay0,1,i, j
az0,1,i, j
ax0,2,i, j ay0,2,i, j
az0,2,i, j
ax0,3,i, j ay0,3,i, j
az0,3,i, j
ax1,0,i, j ay1,0,i, j
az1,0,i, j
ax1,1,i, j ay1,1,i, j
az1,1,i, j
ax1,2,i, j ay1,2,i, j
az1,2,i, j
ax1,3,i, j ay1,3,i, j
az1,3,i, j
ax2,0,i, j ay2,0,i, j
az2,0,i, j
ax2,1,i, j ay2,1,i, j
az2,1,i, j
ax2,2,i, j ay2,2,i, j
az2,2,i, j
ax2,3,i, j ay2,3,i, j
az2,3,i, j
ax3,0,i, j ay3,0,i, j
az3,0,i, j
ax3,1,i, j ay3,1,i, j
az3,1,i, j
ax3,2,i, j ay3,2,i, j
az3,2,i, j
ax3,3,i, j ay3,3,i, j
az3,3,i, j
=
Pxi, j
H0, 0L Pyi, j
H0, 0L Pzi, j
H0, 0L
Pxi, j
H1, 0L Pyi, j
H1, 0L Pzi, j
H1, 0L
Pxi, j
H0, 1L Pyi, j
H0, 1L Pzi, j
H0, 1L
Pxi, j
H1, 1L Pyi, j
H1, 1L Pzi, j
H1, 1L
Pu xi, j
H0, 0L Pu yi, j
H0, 0L Pu zi, j
H0, 0L
Pu xi, j
H1, 0L Pu yi, j
H1, 0L Pu zi, j
H1, 0L
Pu xi, j
H0, 1L Pu yi, j
H0, 1L Pu zi, j
H0, 1L
Pu xi, j
H1, 1L Pu yi, j
H1, 1L Pu zi, j
H1, 1L
Pv xi, j
H0, 0L Pv yi, j
H0, 0L Pv zi, j
H0, 0L
Pv xi, j
H1, 0L Pv yi, j
H1, 0L Pv zi, j
H1, 0L
Pv xi, j
H0, 1L Pv yi, j
H0, 1L Pv zi, j
H0, 1L
Pv xi, j
H1, 1L Pv yi, j
H1, 1L Pv zi, j
H1, 1L
Pu v xi, j
H0, 0L Pu v yi, j
H0, 0L Pu v zi, j
H0, 0L
Pu v xi, j
H1, 0L Pu v yi, j
H1, 0L Pu v zi, j
H1, 0L
Pu v xi, j
H0, 1L Pu v yi, j
H0, 1L Pu v zi, j
H0, 1L
Pu v xi, j
H1, 1L Pu v yi, j
H1, 1L Pu v zi, j
H1, 1L
C’est le système de base à résoudre pour le carré Hi, jL, ceci devra être mis en une boucle itérative pour
calculer les surfaces d’interpolation pour toutes les carrés Hi, jL; c’est ce que l’on va montrer dans l’exemple
suivant où nous interpolons à travers une grille de 4ä4 points.
86 | Maintenant, nous allons montrer le premier exemple concret de la construction d’une surface interpolée
travers des points discrets, comme nous l’avons mentionné ci-dessus, il y aura deux autres types de surfaces
d’interpolation: les surfaces de Bézier et les surfaces NURBS. La spline bicubique ne se propage pas dans les
pratiques architecturales autant que les Bézier et les NURBS, mais dans cette recherche, nous allons l’utiliser
en raison de sa bonne précision.
Itération à travers 4ä4 points en utilisant la spline bicubique
G = 9pi, j = Ixi, j
, yi, j
, zi, j
M œ !3
, pour i = 1, ..., m et j = 1, .., n =
est un ensemble de mä n points de données distincts
p1,1 = H0, 0, 0L, p1,2 = I-
1
4
,
1
2
,
1
2
M , p1,3 = I
1
2
, 2, -
1
4
M , p1,4 = I0, 3, 1
4
M,
p2,1 = I1, -
1
4
, -
1
4
M, p2,2 = H1, 1, 0L, p2,3 = I1, 2, -
1
4
M , p2,4 = I1, 5
2
, 0M
p3,1 = H2, 0, 0L, p3,2 = I2, 1, 1
2
M , p3,3 = H2, 2, 0L , p3,4 = I2, 3, 1
4
M,
p4,1 = I3, 0, 1
4
M, p4,2 = I
5
2
, 1, -
1
4
M, p4,3 = I3, 2, 1
2
M et p4,4 = I3, 5
2
,
1
2
M
les tangentes aux extrémités
Su = (1, 0, 0), Sv
= (0, 1, 0), Su v = (1, 1, 0), Eu = (1, 0, 0), Ev
= (0, 1, 0) et Eu v = (1, 1, 0)
facteur d’échelle tr =
1
2
ak,l,i, j = Iaxk,l,i, j
, ayk,l,i, j
, azk,l,i, j
M, Pi, j
Iti
, sj
M = IPxi, j
Iti
, sj
M, P yi, j
Iti
, sj
M, Pzi, j
Iti
, sj
MM
Pu i, j
Iti
, sj
M = IPu xi, j
Iti
, sj
M, Pu yi, j
Iti
, sj
M, Pu zi, j
Iti
, sj
MM
Pv i, j
Iti
, sj
M = IPv xi, j
Iti
, sj
M, Pv yi, j
Iti
, sj
M, Pv zi, j
Iti
, sj
MM
Pu v i, j
Iti
, sj
M = IPu v xi, j
Iti
, sj
M, Pu v yi, j
Iti
, sj
M, Pu v zi, j
Iti
, sj
MM
m = 4 et n = 4
nous itérons pour i = 1, ..., m - 1 et j = 1, ..., n - 1
Conditions pour les tangentes
si i = 1, Pu i, j
H0, 0L = tr Su sinon Pu i, j
H0, 0L = trIpi+1, j - pi-1, j
M
et Pu i, j
H0, 1L = tr Su sinon Pu i, j
H0, 1L = trIpi+1, j+1 - pi-1, j+1M
si i = m - 1, Pu i, j
H1, 0L = tr Eu sinon Pu i, j
H1, 0L = trIpi+2, j - pi, j
M
et Pu i, j
H1, 1L = tr Eu sinon Pu i, j
H0, 1L = trIpi+2, j+1 - pi, j+1M
si j = 1, Pv i, j
H0, 0L = tr Sv sinon Pv i, j
H0, 0L = trIpi, j+1 - pi, j-1M
et Pv i, j
H1, 0L = tr Sv sinon Pv i, j
H1, 0L = trIpi+1, j+1 - pi+1, j-1M
si j = n - 1, Pv i, j
H0, 1L = tr Ev sinon Pv i, j
H0, 1L = trIpi, j+2 - pi, j
M
et Pv i, j
H1, 1L = tr Ev sinon Pv i, j
H1, 1L = trIpi+1, j+2 - pi+1, j
M
si i = 1 Í j = 1, Pu v i, j
H0, 0L = tr Su v sinon Pu v i, j
H0, 0L = trIpi+1, j+1 - pi+1, j-1 - pi-1, j+1 - pi-1, j-1M
si i = m - 1 Í j = 1, Pu v i, j
H1, 0L = tr Su v sinon Pu v i, j
H1, 0L = trIpi+2, j+1 - pi+2, j-1 - pi, j+1 - pi, j-1M
si i = 1 Í j = n - 1, Pu v i, j
H0, 1L = tr Su v sinon Pu v i, j
H0, 1L = trIpi+1, j+2 - pi+1, j - pi-1, j+2 - pi-1, j
M
si i = m - 1 Í j = n - 1, Pu v i, j
H1, 1L = tr Eu v sinon Pu v i, j
H1, 1L = trIpi+2, j+2 - pi+2, j - pi, j+2 - pi, j
M
| 87Le système est donnée par
ax0,0,i, j ay0,0,i, j
az0,0,i, j
ax0,1,i, j ay0,1,i, j
az0,1,i, j
ax0,2,i, j ay0,2,i, j
az0,2,i, j
ax0,3,i, j ay0,3,i, j
az0,3,i, j
ax1,0,i, j ay1,0,i, j
az1,0,i, j
ax1,1,i, j ay1,1,i, j
az1,1,i, j
ax1,2,i, j ay1,2,i, j
az1,2,i, j
ax1,3,i, j ay1,3,i, j
az1,3,i, j
ax2,0,i, j ay2,0,i, j
az2,0,i, j
ax2,1,i, j ay2,1,i, j
az2,1,i, j
ax2,2,i, j ay2,2,i, j
az2,2,i, j
ax2,3,i, j ay2,3,i, j
az2,3,i, j
ax3,0,i, j ay3,0,i, j
az3,0,i, j
ax3,1,i, j ay3,1,i, j
az3,1,i, j
ax3,2,i, j ay3,2,i, j
az3,2,i, j
ax3,3,i, j ay3,3,i, j
az3,3,i, j
=
1 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0
1 0 0 0 1 0 0 0 1 0 0 0 1 0 0 0
1 1 1 1 0 0 0 0 0 0 0 0 0 0 0 0
1 1 1 1 1 1 1 1 1 1 1 1 1 1 1 1
0 0 0 0 1 0 0 0 0 0 0 0 0 0 0 0
0 0 0 0 1 0 0 0 2 0 0 0 3 0 0 0
0 0 0 0 1 1 1 1 0 0 0 0 0 0 0 0
0 0 0 0 1 1 1 1 2 2 2 2 3 3 3 3
0 1 0 0 0 0 0 0 0 0 0 0 0 0 0 0
0 1 0 0 0 1 0 0 0 1 0 0 0 1 0 0
0 1 2 3 0 0 0 0 0 0 0 0 0 0 0 0
0 1 2 3 0 1 2 3 0 1 2 3 0 1 2 3
0 0 0 0 0 1 0 0 0 0 0 0 0 0 0 0
0 0 0 0 0 1 0 0 0 2 0 0 0 3 0 0
0 0 0 0 0 1 2 3 0 0 0 0 0 0 0 0
0 0 0 0 0 1 2 3 0 2 4 6 0 3 6 9
-1
.
Pxi, j
H0, 0L Pyi, j
H0, 0L Pzi, j
H0, 0L
Pxi, j
H1, 0L Pyi, j
H1, 0L Pzi, j
H1, 0L
Pxi, j
H0, 1L Pyi, j
H0, 1L Pzi, j
H0, 1L
Pxi, j
H1, 1L Pyi, j
H1, 1L Pzi, j
H1, 1L
Pu xi, j
H0, 0L Pu yi, j
H0, 0L Pu zi, j
H0, 0L
Pu xi, j
H1, 0L Pu yi, j
H1, 0L Pu zi, j
H1, 0L
Pu xi, j
H0, 1L Pu yi, j
H0, 1L Pu zi, j
H0, 1L
Pu xi, j
H1, 1L Pu yi, j
H1, 1L Pu zi, j
H1, 1L
Pv xi, j
H0, 0L Pv yi, j
H0, 0L Pv zi, j
H0, 0L
Pv xi, j
H1, 0L Pv yi, j
H1, 0L Pv zi, j
H1, 0L
Pv xi, j
H0, 1L Pv yi, j
H0, 1L Pv zi, j
H0, 1L
Pv xi, j
H1, 1L Pv yi, j
H1, 1L Pv zi, j
H1, 1L
Pu v xi, j
H0, 0L Pu v yi, j
H0, 0L Pu v zi, j
H0, 0L
Pu v xi, j
H1, 0L Pu v yi, j
H1, 0L Pu v zi, j
H1, 0L
Pu v xi, j
H0, 1L Pu v yi, j
H0, 1L Pu v zi, j
H0, 1L
Pu v xi, j
H1, 1L Pu v yi, j
H1, 1L Pu v zi, j
H1, 1L
ti = fiHuL = u -Hi - 1L etsj = gj HvL = v - H j - 1L, Pi, j
Hu, vL = IPxi, j
Hu, vL, P yi, j
Hu, vL, Pzi, j
Hu, vLM où
Pl i, j
Hu, vL =
al0,0,i, j + al0,1,i, j
Hv - H j - 1LL + al0,2,i, j
Hv - H j - 1LL2 + al0,3,i, j
Hv - H j - 1LL3 + al1,0,i, j
Hu - Hi - 1LL +
al1,1,i, j
Hu - Hi - 1LL Hv - H j - 1LL + al1,2,i, j
Hu - Hi - 1LL Hv - H j - 1LL2 + al1,3,i, j
Hu - Hi - 1LL Hv - H j - 1LL3 +
al2,0,i, j
Hu - Hi - 1LL2 + al2,1,i, j
Hu - Hi - 1LL2
Hv - H j - 1LL +
al2,2,i, j
Hu - Hi - 1LL2
Hv - H j - 1LL2 + al2,3,i, j
Hu - Hi - 1LL2
Hv - H j - 1LL3 +
al3,0,i, j
Hu - Hi - 1LL3 + al3,1,i, j
Hu - Hi - 1LL3
Hv - H j - 1LL +
al3,2,i, j
Hu - Hi - 1LL3
Hv - H j - 1LL2 + al3,3,i, j
Hu - Hi - 1LL3
Hv - H j - 1LL3
l' interpolant PHu, vL est égal à
si 0 § u < 1 Ï 0 § v < 1 , PHu, vL = P1,1Hu, vL, si 0 § u < 1 Ï 1 § v < 2 ,
PHu, vL = P1,2Hu, vL , si 0 § u < 1 Ï 2 § v § 3 , PHu, vL = P1,3Hu, vL
si 1 § u < 2 Ï 0 § v < 1 , PHu, vL = P2,1Hu, vL, si 1 § u < 2 Ï 1 § v < 2 ,
PHu, vL = P2,2Hu, vL, si 1 § u < 2 Ï 2 § v § 3 , PHu, vL = P2,3Hu, vL
si 2 § u § 3 Ï 0 § v < 1 , PHu, vL = P3,1Hu, vL, si 2 § u § 3 Ï 1 § v < 2 ,
PHu, vL = P3,2Hu, vL, si 2 § u § 3 Ï 2 § v § 3 , PHu, vL = P3,3Hu, vL
Représentation d’une itération à travers 4ä4 points en utilisant la spline bicubique
88 | Construire une surface à partir de données collectées
Maintenant que nous avons expliqué comment construire une surface bicubique à partir d’un ensemble de
points donnés, nous allons montrer comment il pourrait être très utile pour le processus de conception architecturale,
à savoir la création d’un modèle mathématique d’un certain contexte.
Collecte des points de données de la surface de la statue
L’ensemble des 17ä11 points de données
pts = 8887.4, 0., 0.<, 85.9, 0., 3.45575<, 88.65, 0., 6.9115<, 89.25, 0., 10.3673<, 811.65, 0., 13.823<, 811.95, 0., 17.2788<,
812.65, 0., 20.7345<, 812.65, 0., 24.1903<, 87.95, 0., 27.646<, 87.6, 0., 31.1018<, 87.1, 0., 34.5575<<,
886.59937, 2.73355, 0.<, 86.6376, 2.74938, 3.45575<, 87.99156, 3.31021, 6.9115<, 88.03165, 3.32682, 10.3673<,
812.2664, 5.08089, 13.823<, 811.7128, 4.85161, 17.2788<, 810.5399, 4.36578, 20.7345<, 811.0146, 4.5624, 24.1903<,
87.42396, 3.0751, 27.646<, 87.21927, 2.99032, 31.1018<, 86.91556, 2.86452, 34.5575<<,
884.98519, 4.98519, 0.<, 84.87878, 4.87878, 3.45575<, 84.52606, 4.52606, 6.9115<, 85.05635, 5.05635, 10.3673<,
85.76382, 5.76382, 13.823<, 86.25869, 6.25869, 17.2788<, 85.41066, 5.41066, 20.7345<, 85.87011, 5.87011, 24.1903<,
85.26807, 5.26807, 27.646<, 85.4447, 5.4447, 31.1018<, 85.02046, 5.02046, 34.5575<<,
882.41091, 5.82044, 0.<, 82.31523, 5.58947, 3.45575<, 81.68381, 4.06507, 6.9115<, 81.16718, 2.81783, 10.3673<,
81.07151, 2.58686, 13.823<, 82.31523, 5.58947, 17.2788<, 82.71705, 6.55954, 20.7345<,
82.87013, 6.9291, 24.1903<, 82.9658, 7.16007, 27.646<, 83.138, 7.57581, 31.1018<, 83.46329, 8.36111, 34.5575<<,
880., 6.05, 0.<, 80., 5.2, 3.45575<, 80., 3.4, 6.9115<, 80., 2.05, 10.3673<, 80., 1.8, 13.823<, 80., 3.25, 17.2788<,
80., 6.05, 20.7345<, 80., 5.85, 24.1903<, 80., 7.75, 27.646<, 80., 8.35, 31.1018<, 80., 10.75, 34.5575<<,
88-1.16718, 2.81783, 0.<, 8-1.39679, 3.37216, 3.45575<, 8-1.10978, 2.67925, 6.9115<, 8-0.650562, 1.5706, 10.3673<,
8-0.593159, 1.43201, 13.823<, 8-1.24372, 3.00261, 17.2788<, 8-2.41091, 5.82044, 20.7345<,
8-2.1813, 5.26611, 24.1903<, 8-2.58311, 6.23619, 27.646<, 8-3.17627, 7.6682, 31.1018<, 8-4.13298, 9.9779, 34.5575<<,
88-2.80312, 2.20312, 0.<, 8-2.22028, 1.02028, 3.45575<, 8-2.94454, 2.34454, 6.9115<, 8-2.09602, 1.09602, 10.3673<,
8-3.27279, 2.27279, 13.823<, 8-3.50018, 3.50018, 17.2788<, 8-7.17713, 7.17713, 20.7345<, 8-5.26795, 5.26795, 24.1903<,
8-5.51543, 5.51543, 27.646<, 8-7.03571, 7.03571, 31.1018<, 8-8.3085, 8.3085, 34.5575<<,
88-7.52962, 3.11887, 0.<, 8-4.98634, 1.32277, 3.45575<, 8-8.82305, 3.65463, 6.9115<, 8-3.70918, 1.30796, 10.3673<,
8-6.28238, 2.60225, 13.823<, 8-6.8829, 2.85099, 17.2788<, 8-11.2251, 4.6496, 20.7345<, 8-9.28499, 3.84597, 24.1903<,
8-9.05402, 3.7503, 27.646<, 8-10.3013, 4.26692, 31.1018<, 8-9.00783, 3.73116, 34.5575<<,
88-9.05, 0., 0.<, 8-9.55, 0., 3.45575<, 8-11.3, 0., 6.9115<, 8-11.55, 0., 10.3673<, 8-11.05, 0., 13.823<, 8-13.45, 0., 17.2788<,
8-14.35, 0., 20.7345<, 8-13.55, 0., 24.1903<, 8-10.2, 0., 27.646<, 8-12.05, 0., 31.1018<, 8-9.85, 0., 34.5575<<,
88-9.05402, -3.7503, 0.<, 8-8.82305, -3.65463, 3.45575<, 8-7.76059, -3.21454, 6.9115<, 8-6.28238, -2.60225, 10.3673<,
8-7.06768, -2.92753, 13.823<, 8-10.3013, -4.26692, 17.2788<, 8-8.82305, -3.65463, 20.7345<, 8-7.6682, -3.17627, 24.1903<,
8-8.82305, -3.65463, 27.646<, 8-9.65454, -3.99904, 31.1018<, 8-8.73066, -3.61636, 34.5575<<,
88-6.47003, -6.47003, 0.<, 8-6.39932, -6.39932, 3.45575<, 8-5.58614, -5.58614, 6.9115<, 8-4.10122, -4.10122, 10.3673<,
8-4.20729, -4.20729, 13.823<, 8-3.6416, -3.6416, 17.2788<, 8-4.09602, -2.79602, 20.7345<, 8-4.06569, -2.56569, 24.1903<,
8-3.51127, -3.51127, 27.646<, 8-5.69221, -5.69221, 31.1018<, 8-2.01525, -2.01525, 34.5575<<,
88-3.40588, -8.22253, 0.<, 8-3.17627, -7.6682, 3.45575<, 8-2.50658, -6.05141, 6.9115<, 8-1.79861, -4.34223, 10.3673<,
8-1.97082, -4.75798, 13.823<, 8-1.35853, -3.27977, 17.2788<, 8-1.49749, -1.50104, 20.7345<, 8-1.24874, -1.00052, 24.1903<,
8-1.24623, -2.20157, 27.646<, 8-2.64052, -6.37477, 31.1018<, 8-0.593159, -1.43201, 34.5575<<,
880., -3.15, 0.<, 80., -1.8, 3.45575<, 80., -2.4, 6.9115<, 80., -0.95, 10.3673<, 80., -4.05, 13.823<, 80., -3.45, 17.2788<,
80., -1.35, 20.7345<, 80., -0.65, 24.1903<, 80., -1.75, 27.646<, 80., -5.45, 31.1018<, 80., -1.35, 34.5575<<,
881.35853, -3.27977, 0.<, 81.5271, -1.75537, 3.45575<, 81.51844, -2.41731, 6.9115<, 81.58268, -2.02388, 10.3673<,
81.93255, -4.66559, 13.823<, 81.74121, -4.20365, 17.2788<, 81.63143, -2.0244, 20.7345<, 81.58701, -1.39291, 24.1903<,
81.5271, -2.25537, 27.646<, 82.08562, -5.03514, 31.1018<, 80.593159, -1.43201, 34.5575<<,
885.33862, -5.33862, 0.<, 83.80399, -2.50399, 3.45575<, 83.55894, -3.0894, 6.9115<, 83.68841, -3.08841, 10.3673<,
85.58711, -5.58711, 13.823<, 84.98637, -4.98637, 17.2788<, 83.5712, -3.2712, 20.7345<, 83.51011, -2.31011, 24.1903<,
83.55876, -3.05876, 27.646<, 84.7025, -4.7025, 31.1018<, 81.62758, -1.62758, 34.5575<<,
887.35095, -3.04486, 0.<, 85.49045, -2.27422, 3.45575<, 87.04219, -2.91697, 6.9115<, 87.04272, -2.91719, 10.3673<,
89.49738, -3.93394, 13.823<, 89.14163, -3.78659, 17.2788<, 810.1048, -4.18555, 20.7345<, 86.9007, -2.85836, 24.1903<,
85.84168, -2.4197, 27.646<, 86.98193, -2.89201, 31.1018<, 86.5991, -2.73344, 34.5575<<,
887.4, 0., 0.<, 85.9, 0., 3.45575<, 88.65, 0., 6.9115<, 89.25, 0., 10.3673<, 811.65, 0., 13.823<, 811.95, 0., 17.2788<,
812.65, 0., 20.7345<, 812.65, 0., 24.1903<, 87.95, 0., 27.646<, 87.6, 0., 31.1018<, 87.1, 0., 34.5575<<<;
| 89Or, ces points peuvent être utilisés par la spline bicubique pour générer la surface d’interpolation suivante. Par
exemple, pour créer une structure de robe autour d’une statue (ou un corps humain) qui est précisément adapté
à ce corps, nous aurons besoin de définir une représentation de la surface de ce corps, mais nous pouvons
recueillir que des points discrets de nombre fini de la surface (normalement effectué à l’aide d’un scanner 3D).
Ici, la spline bicubique nous offre un moyen pour interpoler ces points discrets et en nous fournissant une
surface paramétrique continue, qui peut s’approcher de plus en plus la surface de la statue en recueillant plus
de points de données. Dans l’exemple suivant, nous allons utiliser un nombre relativement faible de points
collectées de la surface de la statue, afin de créer une surface d’interpolation spline bicubique, qui en ellemême
va être utile plus tard pour l’adaptation de la conception.
Représentation d’une l’interpolation de points de données en utilisant la spline bicubique
Cet exemple est cruciale, car elle nous permet de créer une surface paramétrique à partir des points discrets
par interpolation, ce qui signifie que nous pouvons commencer à relier nos constructions géométriques qui
sont continu aux données du monde physique qui sont toujours discrètes. Et avec cette surface d’approximation
à notre disposition, nous montrerons comment l’adapter à une autre surface, en utilisant par exemple des
transformations homotopes, tout cela est possible parce que nous avons transformé les points discrets à une
surface continue. Après cela, nous allons créer des éléments architecturaux reliant ces deux surfaces, des
éléments qui pourraient être utilisés pour les attacher ensemble d’une manière structurelle.
90 | ü
4.3.3. Bézier et NURBS
Après avoir défini les splines cubiques et bicubiques nous allons maintenant définir la courbe de Bézier et la
surface de Bézier qui sont un type important de méthodes d’approximation. Les courbes et surfaces de Bézier
sont fréquemment utilisés dans l’infographie et dans autres domaines similaires beaucoup plus que les splines
cubiques et bicubiques en particulier dans les systèmes de logiciels de CAO. Courbes et surfaces de Bézier,
sont entièrement contenues dans l’enveloppe convexe de ses points de contrôle. Pour définir la fonction de
Bézier, nous devons définir le polynôme de Bernstein qui est une combinaison linéaire de polynômes de
Bernstein de base, puis nous définissons la courbe et surface de Bézier et leurs versions rationnelles. Les
versions rationnelles, ajoute simplement des poids réglables pour fournir des approximations plus proches de
formes arbitraires.
Polynôme de Bernstein [4]
un binôme est un polynôme à deux termesHla somme de deux monômesL avec le cas particulier donné par
x
n+1 - y
n+1 = Hx - yL ⁄k=0
n
x
n-k
y
k
binôme élevé à la n - ième puissance est donnée par Hx + yL
n =
n
0
x
n
y
0 + ... +
n
n
x
0
y
n = ⁄k=0
n
n
k
x
n-k
y
k
, où le coefficient
n
k
=
n!
k! Hn-kL!
BHxL = ⁄k=0
n bk,nHxL bk
, où bk sont les coefficients de Bernstein et bk,n sont les n +
1 polynômes de Bernstein de base de degré n
où bk,nHxL =
n
k
H1 - xL
n-k
x
k
, pour k = 0, ..., n
Courbe de Bézier (rationnelle) [4]
G = 8pi œ !p
, i = 0, ..., n < est un ensemble de n + 1 points de données
BHtL = ⁄i=0
n bi,nHtL pi = ⁄i=0
n
n
i
H1 - tL
n-i
t
i pi est la courbe de Bézier pour G
BHtL =
⁄i=0
n
n
i
H1-tL
n-i
t
i pi wi
⁄i=0
n
n
i
H1-tL
n-i
t
i wi
est la courbe de Bézier rationnelle pour G et wi sont les poids
Surface de Bézier (rationnelle) [4]
G = 9pi, j œ !p
, i = 0, .., m et j = 0, .., n = est un ensemble de Hm + 1LµHn + 1L points de données
BHu, vL = ⁄i=0
m ⁄j=0
n bi,mHuL bj,nHvL pi, j = ⁄i=0
m ⁄j=0
n
m
i
H1 - uL
m-i u
i
n
j
H1 - vL
n- j
v
j pi, j
est la surface de Bézier pour G
B Hu, vL =
⁄i=0
m ⁄ j=0
n m
i
H1-uL
m-i u
i
n
j
H1-vL
n- j
v
j pi, j wi, j
⁄i=0
m ⁄ j=0
n m
i
H1-uL
m-i u
i
n
j
H1-vL
n- j
v
j pi, j
est la surface de Bézier rationnelle pour G et wi, j sont les poids
en fixant le paramètre u ou v Hi.e. u = u0 ou v = v0L la surface
de Bézierse réduit à une courbe de Bézier Hcourbes isoparamétriquesL
BHu, v0L = ⁄i=0
m ci bi,mHuL , ci = ⁄j=0
n bj,nHv0L pi, j et BHu0, vL = ⁄j=0
n
c j bj,nHvL , c j = ⁄i=0
m bi,mHu0L pi, j
| 91Approximation à travers 4 points en utilisant la courbe de Bézier (rationnelle)
G = 9pi, j = Ixi, j
, yi, j
, zi, j
M œ !3
, pour i = 1, ..., n = est un ensemble de n points de données distincts
p1 = H0, 0, 0L, p2 = I-
1
4
,
1
2
,
1
2
M , p3 = I
1
2
, 2, -
1
4
M et p4 = I0, 3, 1
4
M
et les poids sont w1 = 1, w2 = 3, w3 = 3 et w4 = 1
la courbe de Bézier pour G
BHtL = 3 H1 - tL
2
t + 6 H1 - tL t
2 + 3 t
3
, 6 H1 - tL
2
t + 3 H1 - tL t
2 + 2 t
3
, t
3
la courbe de Bézier rationnelle pour G
BHtL =
9 H1-tL
2
t+6 H1-tL t
2+3 t
3
H1-tL
3+9 H1-tL
2
t+3 H1-tL t
2+t
3
,
18 H1-tL
2
t+3 H1-tL t
2+2 t
3
H1-tL
3+9 H1-tL
2
t+3 H1-tL t
2+t
3
,
t
3
H1-tL
3+9 H1-tL
2
t+3 H1-tL t
2+t
3
Représentation d’une approximation à travers 4 points en utilisant une courbe de Bézier (rationnelle)
Approximation à travers 4ä4 points utilisant les surface de Bézier (rationnelle)
G = 9pi, j = Ixi, j
, yi, j
, zi, j
M œ !3
, pour i = 1, ..., m et j = 1, .., n =
est un ensemble de män points de données distincts
p1,1 = H0, 0, 0L, p1,2 = I-
1
4
,
1
2
,
1
2
M , p1,3 = I
1
2
, 2, -
1
4
M , p1,4 = I0, 3, 1
4
M,
p2,1 = I1, -
1
4
, -
1
4
M, p2,2 = H1, 1, 0L, p2,3 = I1, 2, -
1
4
M , p2,4 = I1, 5
2
, 0M
p3,1 = H2, 0, 0L, p3,2 = I2, 1, 1
2
M , p3,3 = H2, 2, 0L , p3,4 = I2, 3, 1
4
M,
p4,1 = I3, 0, 1
4
M, p4,2 = I
5
2
, 1, -
1
4
M, p4,3 = I3, 2, 1
2
M et p4,4 = I3, 5
2
,
1
2
M
les poids sont
w1,1 = 1, w1,2 = 1 , w1,3 = 1 , w1,4 = 1, w2,1 = 1, w2,2 = 1, w2,3 = 1 , w2,4 = 1
w3,1 = 1, w3,2 = 10 , w3,3 = 1 , w3,4 = 1, w4,1 = 1, w4,2 = 1, w4,3 = 1 et w4,4 = 1
la surface de Bézier approximant G
BHu, vL = 3 H1 - uL
2 u H1 - vL
3 + 6 H1 - uL u
2
H1 - vL
3 + 3 u
3
H1 - vL
3 -
3
4
H1 - uL
3
H1 - vL
2
v +
9 H1 - uL
2 u H1 - vL
2
v + 18 H1 - uL u
2
H1 - vL
2
v +
15
2
u
3
H1 - vL
2
v +
3
2
H1 - uL
3
H1 - vL v
2 +
9 H1 - uL
2 u H1 - vL v
2 + 18 H1 - uL u
2
H1 - vL v
2 + 9 u
3
H1 - vL v
2 + 3 H1 - uL
2 u v3 + 6 H1 - uL u
2
v
3 + 3 u
3
v
3
,
-
3
4
H1 - uL
2 u H1 - vL
3 +
3
2
H1 - uL
3
H1 - vL
2
v + 9 H1 - uL
2 u H1 - vL
2
v + 9 H1 - uL u
2
H1 - vL
2
v +
3 u
3
H1 - vL
2
v + 6 H1 - uL
3
H1 - vL v
2 + 18 H1 - uL
2 u H1 - vL v
2 + 18 H1 - uL u
2
H1 - vL v
2 +
6 u
3
H1 - vL v
2 + 3 H1 - uL
3
v
3 +
15
2
H1 - uL
2 u v3 + 9 H1 - uL u
2
v
3 +
5 u
3
v
3
2
,
-
3
4
H1 - uL
2 u H1 - vL
3 +
1
4
u
3
H1 - vL
3 +
3
2
H1 - uL
3
H1 - vL
2
v +
9
2
H1 - uL u
2
H1 - vL
2
v -
3
4
u
3
H1 - vL
2
v -
3
4
H1 - uL
3
H1 - vL v
2 -
9
4
H1 - uL
2 u H1 - vL v
2 +
3
2
u
3
H1 - vL v
2 +
1
4
H1 - uL
3
v
3 +
3
4
H1 - uL u
2
v
3 +
u
3
v
3
2
92 | la surface de Bézier rationnelle approximant G
BHu, vL =
JI3 H1 - uL
2 u H1 - vL
3 + 6 H1 - uL u
2
H1 - vL
3 + 3 u
3
H1 - vL
3 -
3
4
H1 - uL
3
H1 - vL
2
v + 9 H1 - uL
2 u H1 - vL
2
v +
180 H1 - uL u
2
H1 - vL
2
v +
15
2
u
3
H1 - vL
2
v +
3
2
H1 - uL
3
H1 - vL v
2 + 9 H1 - uL
2 u H1 - vL v
2 +
18 H1 - uL u
2
H1 - vL v
2 + 9 u
3
H1 - vL v
2 + 3 H1 - uL
2 u v3 + 6 H1 - uL u
2
v
3 + 3 u
3
v
3
Më
IH1 - uL
3
H1 - vL
3 + 3 H1 - uL
2 u H1 - vL
3 + 3 H1 - uL u
2
H1 - vL
3 + u
3
H1 - vL
3 +
3 H1 - uL
3
H1 - vL
2
v + 9 H1 - uL
2 u H1 - vL
2
v + 90 H1 - uL u
2
H1 - vL
2
v +
3 u
3
H1 - vL
2
v + 3 H1 - uL
3
H1 - vL v
2 + 9 H1 - uL
2 u H1 - vL v
2 + 9 H1 - uL u
2
H1 - vL v
2 +
3 u
3
H1 - vL v
2 + H1 - uL
3
v
3 + 3 H1 - uL
2 u v3 + 3 H1 - uL u
2
v
3 + u
3
v
3
M,
J-
3
4
H1 - uL
2 u H1 - vL
3 +
3
2
H1 - uL
3
H1 - vL
2
v + 9 H1 - uL
2 u H1 - vL
2
v + 90 H1 - uL u
2
H1 - vL
2
v +
3 u
3
H1 - vL
2
v + 6 H1 - uL
3
H1 - vL v
2 + 18 H1 - uL
2 u H1 - vL v
2 + 18 H1 - uL u
2
H1 - vL v
2 +
6 u
3
H1 - vL v
2 + 3 H1 - uL
3
v
3 +
15
2
H1 - uL
2 u v3 + 9 H1 - uL u
2
v
3 +
5 u
3
v
3
2
Ní
IH1 - uL
3
H1 - vL
3 + 3 H1 - uL
2 u H1 - vL
3 + 3 H1 - uL u
2
H1 - vL
3 + u
3
H1 - vL
3 +
3 H1 - uL
3
H1 - vL
2
v + 9 H1 - uL
2 u H1 - vL
2
v + 90 H1 - uL u
2
H1 - vL
2
v +
3 u
3
H1 - vL
2
v + 3 H1 - uL
3
H1 - vL v
2 + 9 H1 - uL
2 u H1 - vL v
2 + 9 H1 - uL u
2
H1 - vL v
2 +
3 u
3
H1 - vL v
2 + H1 - uL
3
v
3 + 3 H1 - uL
2 u v3 + 3 H1 - uL u
2
v
3 + u
3
v
3
M,
J-
3
4
H1 - uL
2 u H1 - vL
3 +
1
4
u
3
H1 - vL
3 +
3
2
H1 - uL
3
H1 - vL
2
v + 45 H1 - uL u
2
H1 - vL
2
v -
3
4
u
3
H1 - vL
2
v -
3
4
H1 - uL
3
H1 - vL v
2 -
9
4
H1 - uL
2 u H1 - vL v
2 +
3
2
u
3
H1 - vL v
2 +
1
4
H1 - uL
3
v
3 +
3
4
H1 - uL u
2
v
3 +
u
3
v
3
2
Ní
IH1 - uL
3
H1 - vL
3 + 3 H1 - uL
2 u H1 - vL
3 + 3 H1 - uL u
2
H1 - vL
3 + u
3
H1 - vL
3 +
3 H1 - uL
3
H1 - vL
2
v + 9 H1 - uL
2 u H1 - vL
2
v + 90 H1 - uL u
2
H1 - vL
2
v +
3 u
3
H1 - vL
2
v + 3 H1 - uL
3
H1 - vL v
2 + 9 H1 - uL
2 u H1 - vL v
2 + 9 H1 - uL u
2
H1 - vL v
2 +
3 u
3
H1 - vL v
2 + H1 - uL
3
v
3 + 3 H1 - uL
2 u v3 + 3 H1 - uL u
2
v
3 + u
3
v
3
MN
Représentation d’une approximation à travers 4ä4 points en utilisant une surface de Bézier (rationnelle)
| 93NURBS
Après avoir défini les courbes et surfaces de Bézier nous allons maintenant définir le plus populaire des
méthodes d’approximation utilisées dans les logiciels de CAO aujourd’hui, à savoir les NURBS (non uniform
rational B-spline) courbes et surfaces. NURBS sont une généralisation des courbes et surfaces de Bézier (i.e.
la représentation de Bézier est un simple cas de B-splines lorsque le nombre de points de contrôle = l’ordre de
k). Pour définir la NURBS, nous devons définir la fonction B-spline et le vecteur de nœud.
Courbes et surfaces NURBS [5]
G = 8pi œ !p
, i = 0, ..., n < est un ensemble de n + 1 points de données
T = 8t0, ..., tm< t0 § ... § tm est le vecteur de nœud
la même valeur ti ne doit pas apparaître plus d ' une fois où k
k = l' ordre de la B - spline Hi.e. le degré = l' ordre - 1L
la courbe NURBS de base est donnée par NHtL = ⁄i=0
n hi,k
HtL pi où
hi,k
HtL est la fonction B - spline de degré Hk - 1L associé au vecteur de nœud T
pour k = 1, hi,1HtL = 1 si t œ @ti
, ti+1D et 0 sinon et pour k > 1, hi,k
HtL =
t-ti
ti+k-1-ti
hi,k-1HtL +
ti+k-t
ti+k-ti+1
hi+1,k-1HtL
ti § t § ti+k ï hi,k
HtL > 0 ,
t0 § t § ti et ti+k § t § tn+k ï hi,k
HtL = 0 et tk-1 § t § tn+1 ï ⁄i=0
n hi,k
HtL = 1 Hpropriété de normalisationL
# nœuds = # points de contrôle + l' ordre de la courbe Hdegré + 1L ï Hm + 1L = Hn + 1L + k ï m = n + k
Hpour 5 points de contrôle i.e. n = 4L
vecteur de nœud uniforme HpériodiqueLï ti - ti-1 = constant
ï T = 80, 1, 2, 3, 4, 5, 6, 7< avec une plage de paramètres : Hk - 1L § t § Hn + 1L
vecteur de nœud non périodique ï k valeurs répétées à la fin ï T = 80, 0, 0, 1, 2, 3, 3, 3<
vecteur de nœud non - uniforme ï k valeurs répétées à la finï T = 80, 0, 0, 1.5, 2.3, 3, 3, 3<
avec une plage de paramètres 0 § t § Hn - k + 2L
NHtL =
⁄i=0
n
hi,k
HtL wi pi
⁄i=0
n
hi,k
HtL wi
est la courbe NURBS avec wi sont les poids
G = 9pi, j œ !3
, i = 0, .., m et j = 0, .., n= est un ensemble de Hm + 1LäHn + 1L points de données
U = 9u0, ..., up= u0 § ... § up vecteur de noeud dansla direction uet
V = 9v0, ..., vq= v0 § ... § vq vecteur de nœud dansla direction v
la même valeur ui Hresp. viL ne doit pas apparaître plus que k Hresp.lL fois où
k = l' ordre de la B - spline dansla direction u Hresp.l dansla direction vL
la surface de NURBS de base est donnée par NHu, vL = ⁄i=0
m ⁄j=0
n hi,k
HuL h j,l
HvL pi, j
où hi,k
HuL et h j,l
HvLsont des fonctions B - splines de degré Hk - 1L et Hl - 1L
associé aux vecteurs de nœud U et V
# nœuds = # points de contrôle + l' ordre de la courbe Hdegré + 1L
ï Hp + 1L = Hm + 1L + k ï p = m + k et Hq + 1L = Hn + 1L + l ï q = n + l
NHu, vL =
⁄i=0
m ⁄ j=0
n
hi,k
HuL hj,l
HvL wi, j pi, j
⁄i=0
m ⁄ j=0
n
hi,k
HuL hj,l
HvL wi, j
est la surface NURBS rationnelle avec wi, j sont les poids
94 | Approximation à travers 9 points utilisant la courbe NURBS d’ordre 3 avec un vecteur de nœud non périodique
G = 9pi, j = Ixi, j
, yi, j
, zi, j
M œ !3
, pour i = 1, ..., n = est un ensemble de n points de données distincts
p1 = H1, 2, 0L, p2 = H2, 4, 1L , p3 = H3, 2, 0L , p4 = H4, 1, 2L , p5 = H4, 7, 9L,
p6 = H5, -2, 6L , p7 = H6, 3, 3L , p8 = H7, 0, 2L et p9 = H8, -1, 4L
les poids sont w1 = 1, w2 = 3, w3 = 3 , w4 = 2, w5 = 4, w6 = 1, w7 = 3 , w8 = 1 et w9 = 1
le vecteur de nœud non périodique est donnée par 80, 0, 0, 1, 2, 3, 4, 5, 6, 7, 7, 7<
Représentation d’une approximation à travers 9 points utilisant la courbe NURBS d’ordre 3
Comme nous l’avons mentionné plus tôt, l’interpolation (approximation) NURBS serait la troisième méthode
d’interpolation, nous allons définir dans cette recherche. Modélisation NURBS a gagné grande popularité ces
derniers temps dans les logiciels de CAO destinés à conception architecturale et ils sont à la base de ces
systèmes. Il était important pour nous dans le cadre de cette recherche de donner une construction mathématique
des courbes et des surfaces NURBS, car il y a certaines parties des conceptions architecturales créés ici
faites en utilisant des logiciels de CAO basé sur NURBS. De cette façon, nous pouvons procéder dans la
conception de ces formes à l’aide ces systèmes logiciels mais avec la compréhension mathématique de la
façon dont ces outils de conception sont construits. Cela signifie restant en conformité avec le discours initial
de la recherche, à savoir fonder le processus de conception sur une compréhension mathématique complète
des méthodes géométriques impliqués. Les courbes et les surfaces de NURBS sont largement utilisés dans la
conception de des formes qui nécessitent des lignes de courant et de continuité qui est le cas dans la conception
automobile et la conception aéronautique. Dans notre contexte architectural nous allons montrer des
conceptions de formes qui partagent certaines de ces caractéristiques, de cette manière, nous sommes en
mesure de montrer la capacité et l’intérêt pour l’utilisation et la construction de ces outils de modélisation.
| 95Approximation à travers 5ä5 points en utilisant la surface NURBS d’ordre 3
G = 9pi, j = Ixi, j
, yi, j
, zi, j
M œ !3
, pour i = 1, ..., m et j = 1, .., n =
est un ensemble de män points de données distincts
p1,1 = H0, 0, 0L, p1,2 = I-
1
4
,
1
2
,
1
2
M , p1,3 = I
1
2
, 2, -
1
4
M , p1,4 = I0, 3, 1
4
M, p1,5 = I0, 4, 1
4
M ,
p2,1 = I1, -
1
4
, -
1
4
M, p2,2 = H1, 1, 0L, p2,3 = I1, 2, -
1
4
M , p2,4 = I1, 5
2
, 0M, p2,5 = I1, 4, 1
4
M,
p3,1 = H2, 0, 0L, p3,2 = I2, 1, 1
2
M , p3,3 = H2, 2, 0L , p3,4 = I2, 3, 1
4
M, p3,5 = I2, 4, 1
4
M,
p4,1 = I3, 0, 1
4
M, p4,2 = I
5
2
, 1, -
1
4
M, p4,3 = I3, 2, 1
2
M , p4,4 = I3, 5
2
,
1
2
M, p4,5 = I3, 4, 1
4
M,
p5,1 = I4, 0, 1
4
M, p5,2 = I4, 1, -
1
4
M, p5,3 = I4, 2, 1
2
M , p5,4 = I4, 5
2
,
1
2
M et p5,5 = I4, 4, 1
4
M
les poids sont
w1,1 = 1, w1,2 = 1 , w1,3 = 1 , w1,4 = 1, w2,1 = 1, w2,2 = 1, w2,3 = 1 , w2,4 = 1
w3,1 = 1, w3,2 = 1 , w3,3 = 1 , w3,4 = 1, w4,1 = 1, w4,2 = 1, w4,3 = 1 et w4,4 = 1
le vecteur de nœud non périodique dansla direction u est donnée par 80, 0, 0, 1, 2, 3, 3, 3<
le vecteur de nœud non périodique dansla direction v est donnée par 80, 0, 0, 3, 4, 5, 5, 5<
Representation of an approximation à travers 5ä5 points en utilisant la surface NURBS d’ordre 3
Avec cet exemple, nous terminons la construction mathématique des courbes et des surfaces NURBS, qui à
son tour termine les constructions de l’interpolation polynomiale, que nous avions l’intention de faire dans
cette recherche. Dans la partie suivante, nous allons montrer quelques exemples de conceptions architecturales,
faites en utilisant la modélisation NURBS avec l’aide d’un système de logiciels de CAO. Après ces
exemples, nous aimerions réfléchir sur la vague actuelle de l’intérêt de l’architecture dans ces outils de
modélisation, de leur application de base comme outil de dessin utilisant une interface utilisateur graphique,
aux applications plus sophistiquées utilisant des scripts et des simulations. Cette vague a développé au cours
des deux dernières décennies, possédant des noms différents et des convictions différentes, dans cette
recherche, nous allons choisir le terme: architecture numérique, de se référer à cette vague dans le sens le plus
large.
96 | ü
4.3.4. Concevoir utilisant NURBS
Maintenant que nous avons à notre disposition la construction mathématique des courbes et surfaces NURBS
nous allons montrer une certaine génération de forme en utilisant la modélisation NURBS avec l’aide d’un
système de CAO. Nous allons définir une surface NURBS définie par une série de courbes NURBS planes,
dont chacune est située dans un plan perpendiculaire à une courbe de base.
Représentation du processus de génération de la forme architecturale utilisant Nurbs
Représentation des courbes et des surfaces NURBS faites en utilisant un système de logiciel de CAO
| 97Plus d’exemples de conception utilisant NURBS
Maintenant, nous allons montrer un exemple de génération de forme à l’aide d’une modélisation Nurbs pour la
conception d’une maison-bateau, ces exemples montrent la capacité des NURBS pour gérer conception de
surfaces courbes telles que celles dans les coques de bateaux et des conceptions d’automobiles.
Représentation du processus de génération de forme en utilisant des courbes et des surfaces NURBS
Représentation d’un dessin fait en utilisant les NURBS dans un système de logiciel de CAO
98 | Exemple de conception en utilisant NURBS en combinaison avec la «box modeling»
Jusqu’à présent, nous avons montré des conceptions en utilisant soit la modélisation «box modeling» ou
l’interpolation utilisant des surfaces NURBS, dans cette partie, nous allons montrer que nous pouvons combiner
les deux méthodes à savoir que la peau externe pourrait être conçu utilisant la modélisation «box modeling»
et l’intérieur pourrait être élaboré en utilisant la surfaces NURBS.
Représentation de l’intérieur d’une maison-bateau conçu en utilisant des surfaces NURBS
Représentation de la conception extérieure de la peau en utilisant la «box modeling»
| 99Plus d’exemples de conception utilisant NURBS en combinaison avec «box modeling»
C’est un exemple de plus d’avoir la peau extérieure conçu en utilisant la «box modeling» tandis que l’intérieur
est travaillé à l’aide de surfaces de NURBS.Il est important de présenter ces exemples qui sont établis utilisant
de logiciels de CAO, car ils montrent l’étendue de la liberté et aussi la limitation de l’utilisation des interpolations
méthodes (NURBS) dans la conception architecturale.
Représentation de l’intérieur d’une forme que nous avons développé en utilisant la «box modeling»
Représentation d’une autre partie intérieure de la même forme architecturale
100 | ü
4.4. Critique de la conception assistée par ordinateur
Dans les deux premiers chapitres, nous étions occupés des questions relatives à la position de cette recherche
entre les deux disciplines de l’architecture et les mathématiques (chapitre 1) et la préparation pour la construction
de l’espace formel: variétés (chapitre 2). Dans le troisième chapitre, nous avons construit l’espace comme
une variété et nous avons donné les définitions formelles de des formes comme des sous-variétés de l’espace
euclidien utilisant submersion (définition algébrique) et l’immersion (dans la plupart des cas un plongement -
définition paramétrique). Dans ce chapitre, nous avons donné des approximations de formes continue en les
définissant utilisant des maillages polygonaux et des interpolations polynomiales, qui, comme nous l’avons
mentionné sont le type le plus utilisé de la définition de la forme dans la conception architecturale en raison de
leur utilisation dans les systèmes de logiciels de CAO. Malgré leur large diffusion, peu de architectes ont
connaissance de leurs constructions mathématiques, cela dit, nous aimerions à ce point avant de commencer
les définitions des opérations sur les des formes, de prendre un certain recul et de réfléchir sur ces méthodes
de conception utilisant CAO. Nous aimerions comprendre la raison de leur succès et de quelle manière ils
diffèrent des méthodes traditionnelles de dessin architectural en utilisant la géométrie descriptive. En cela,
nous ferions une fois de plus l’utilisation des noumènes et les phénomènes de Kant pour comprendre sur le
plan ontologique l’expérience de simulation de dessin. En plus de Kant, nous apporter quelques concepts de la
théorie critique, en particulier de philosophes: Jean Baudrillard et Gilles Deleuze pour nous aider à comprendre
le contexte global de la réussite de ces technologies numériques. Nous allions enfin réfléchir davantage
ponctuellement sur les mouvements architecturaux réunis sous le parapluie de l’architecture dite numérique.
Le succès de la conception utilisant de logiciels de CAO, c’est parce qu’elle est fondée sur l’idée intuitive de
l’interpolation de points qui sont donnés par l’entrée du créateur à travers l’interface graphique (la souris) sans
la nécessité d’avoir des connaissances mathématiques sur la fonction d’interpolation. C’est en substance rend
l’ensemble du processus de dessiner en utilisant l’ordinateur rappelle le processus de dessiner utilisant le
crayon et de la planche à dessin, car il n’y avait pas de transcendance de l’expérience au sens kantien a été
impliqué. Ceci, certainement augmenté la vitesse de production et la précision des dessins, mais il n’y avait
pas de changement de perspective. Les architectes ont pensé et ont dessiné de la même manière que précédemment,
seulement maintenant en utilisant l’ordinateur, dans d’autres terme, ils ont simulé l’expérience du
dessin, mais ce qui est plus problématique est la simulation de la connaissance qui se pose avec le logiciel de
CAO, qui dans le cas de la conception architecturale est la simulation de la connaissance en géométrie. Nous
sommes capables de voir le problème dans un exemple simple: si l’on prend la tâche de dessiner deux lignes
perpendiculaires, d’abord à la main et ensuite par l’ordinateur: dans le premier cas, nous sommes confrontés à
un problème classique des mathématiques qui est celui de la construction et afin de réaliser la tâche, nous
appliquons les méthodes de la géométrie descriptive. Néanmoins, dans le deuxième cas à savoir, en utilisant
un interface graphique du logiciel de CAO, nous allons chercher les icônes dans le menu du programme qui
correspondent au dessin d’une ligne et qui correspond à trouver la perpendiculaire à cette ligne. Maintenant, la
connaissance mathématique nécessaire pour effectuer cette tâche est entièrement caché de l’utilisateur dans la
bibliothèque du programme; ce qui est perceptible au concepteur est la connaissance de la façon de gérer
l’interface. Cette situation est problématique, non pas parce que d’une idée romantique que l’expérience de
dessin est plus authentique, mais il est problématique parce que la simulation créée par le logiciel de CAO
donne au concepteur l’illusion d’avoir la connaissance géométrique nécessaire pour effectuer la tâche. C’est-à-
dire que le logiciel de CAO modifie la nature du problème d’un problème de géométrie à un problème d’interface,
et dans ce saut il existe une perte importante de connaissances qui n’est pas nécessairement remarqué et
qui va devenir de moins en moins remarqué que les interfaces de logiciels de CAO deviendront de plus en
plus intuitive. Ce problème de la simulation n’est en aucun cas limité à la conception architecturale, En fait, il
s’agit de la version architecturale d’un problème plus large de la société, un problème qui a été prévu par le
théoricien critique Guy Debord dans son livre La société du spectacle et a été au centre du travail de
philosophe Jean Baudrillard dans de son traité philosophique Simulacres et simulation. Justement, en appliquant
la géométrie moderne dans la conception architecturale, nous soulignons le problème en créant une
turbulence dans la simulation de la connaissance que les systèmes logiciels de CAO établissent, pour comprendre
cette turbulence nous devons d’abord comprendre comment l’architecture contemporaine se rapporte à la
société du spectacle de Debord. L’idée de Debord tourne autour de la dégradation de la société moderne dans
laquelle la vie sociale authentique a été remplacé par sa représentation à savoir que les expériences humaines
| 101société du spectacle de Debord. L’idée de Debord tourne autour de la dégradation de la société moderne dans
laquelle la vie sociale authentique a été remplacé par sa représentation à savoir que les expériences humaines
qui étaient autrefois vécu sont devenu simples représentations, la dégradation selon Debord se passe par le
déclin d’être à avoir à apparaître [6]. Le compte de Baudrillard sur la société est tout à fait similaire de nombreux
égards, comme il le prétend que notre société actuelle a remplacé toute la réalité et la signification par
des symboles et des signes et que l’expérience humaine est une simulation de la réalité. Donc, à partir Alberti
et Desargues (deux architectes et mathématiciens) ayant une connaissance approfondie de la géométrie comme
la langue de la conception architecturale, aux architectes dits paramétriques maîtrisant leur dernier logiciel de
CAO, on peut voir clairement cette dégradation de la connaissance aux apparences. Quand les architectes
paramétriques utilisent des termes comme géométrie complexe ce qu’ils signifient réellement: sont des formes
qui apparaissent complexe à savoir par leur nature courbée, alors que le processus de leur création contient
peu de connaissance de la géométrie. Il s’agit d’un abus de langage assez fréquent, qui est toujours négligé en
raison de la confusion entre la connaissance et la simulation de la connaissance, l’utilisation du terme: simulation
ici ne signifie pas simplement faire semblant. Baudrillard dans Simulacres et simulation, définit la
dissimulation, comme le semblant de ne pas avoir ce que l’on a, et la simulation est feindre d’avoir ce que l’on
n’a pas. Il explique que la simulation est plus complexe que feindre ou faire semblant, en donnant l’exemple
de simuler la maladie; il explique que, pour prétendre qu’on est malade, on reste tout simplement dans le lit et
faire croire aux autres on est malade. Alors que si l’on simuler la maladie, on produit en soi certains des
symptômes. La différence fondamentale ici est clair, faire semblant conserve la réalité intacte, tandis que la
simulation menace la différence entre le vrai et le faux. Quelque chose de cette nature peut être vu quand les
architectes utilisent des logiciels de CAO pour représenter et résoudre certains des problèmes géométriques de
leur conception; la vraie connaissance n’est pas simplement remplacée par semblant (à savoir l’architecte est
conscient de l’ignorance) mais cette connaissance est simulé à l’aide symptômes (i.e. gestion de l’interface),
laissant l’architecte ignorent de la différence entre le vrai et le faux. Le deuxième concept important dans le
livre de Baudrillard est: simulacres, il définit simulacre, non comme cacher la vérité, mais comme la vérité qui
cache qu’il n’y en a pas. Simulacres sont des copies qui représente des choses qui soit n’avaient pas une réalité
pour commencer, ou N’ayant plus un original, tandis que la simulation est l’imitation des opérations d’un
processus du monde réel par la production de certains de ses symptômes [7]. La progression actuelle, et la
vitesse de développement de logiciels de CAO de plus en plus complexe, capable de faire la stimulation
visuelle de plus en plus avancé: l’architecture paramétrique, est un exemple de simulacre, où le mot
paramétrique a perdu son sens mathématique original et est devenu une référence sans un référent. Baudrillard
décompose la relation entre l’image et la réalité en quatre étapes qu’il relie plus tard à des périodes historiques.
La première étape est une relation fidèle, entre l’image et la copie, où le signe est le reflet d’une
réalité profonde, il associe ce stade avec la période pré-moderne où la représentation est clairement un portelieu
artificiel pour la vraie chose. La deuxième étape est la perversion de la réalité, nous croyons que le signe
est copie infidèle, qui masque et dénature la réalité comme une apparence, Baudrillard associe ce stade avec la
modernité et la révolution industrielle où la distinction entre la représentation et la réalité a été rompu en
raison de la prolifération des copies produites en masse d’articles, qui les transforme en produits de base. La
troisième étape, masque l’absence d’une réalité profonde, où simulacre prétend être une copie fidèle, mais
c’est une copie sans originale; Baudrillard associé ce stade avec la postmodernité et le capitalisme tardif où
simulacre précède l’original. La quatrième étape est la simulation pure, dans laquelle le simulacre n’a pas de
relation, à aucune réalité que ce soit. Ici, les produits culturels ne seraient même pas besoin de faire semblant
d’être vrai au sens naïf car les expérience des vie des consommateurs sont essentiellement artificielles, il a
utilisé le terme: l’hyper-réalité pour décrire cette réalité qui est de plus en plus notre vie quotidienne [7]. On
peut voir une corrélation entre les étapes de Baudrillard de la relation entre l’image et la réalité et le développement
de la relation entre l’architecture et les mathématiques. Les périodes médiévales et la Renaissance
représentent la première étape de la relation image-réalité, où la connaissance de la géométrie visant à l’utiliser
pour représenter une réalité profonde d’un univers harmonieux de divines proportions et géométrie
sacrée. L’expression parfaite de cette étape, était dans l’invention de la perspective linéaire par les polymathes:
Alberti, Brunelleschi et Desargues, ici on peut voir presque une tentative littérale d’utiliser l’image
comme un reflet fidèle de la réalité, à savoir la peinture basée sur la perspective. Avec l’arrivée de la modernité
et de la domination du cogito cartésien de la science positiviste et la révolution industrielle, la deuxième
étape est claire, il y a une méfiance dans les apparences et la perception comme l’accès à la réalité. Ici, l’image
est une copie infidèle qui dénature la réalité, l’architecture et l’art ne sont plus des représentations de pro-
102 | étape est claire, il y a une méfiance dans les apparences et la perception comme l’accès à la réalité. Ici, l’image
est une copie infidèle qui dénature la réalité, l’architecture et l’art ne sont plus des représentations de profondes
réalités harmonieuses, l’esthétique kantienne avec l’accent mis sur l’objet d’art lui-même remplacé
l’esthétique classique ouvrant la voie à l’art moderne. L’intérêt en mathématiques pour représenter fidèlement
la réalité a diminué hors de la faveur, cela peut être vu dans les mouvements de la peinture moderne de
l’impressionnisme au cubisme et leurs équivalents architecturaux, de l’art nouveau au Bauhaus et le style
international où la géométrie est enfin détaché de l’architecture. Au même temps, la science est devenue
excessivement positiviste, rejetant la métaphysique et les apparences comme trompeuses et ne comptant que
sur la raison humaine comme le seul accès à la réalité objective des choses qui est obscurcie par nos sens, cela
peut être vu dans l’interprétation moderne de la géométrie et en physique des particules. La période postmoderne
capitaliste tardive est caractérisée par la troisième phase de la relation image-réalité, c’est l’ère de la
communication de masse, la mondialisation et la consommation où l’image ne représente plus un original et
même masques l’absence de réalité profonde. Mouvements postmodernes dans l’art et l’architecture expriment
clairement cette propriété, ce qui peut être vu, de l’essor du pop art à l’ajout de motifs classiques de l’architecture
postmoderne; clairement la position de la géométrie dans l’architecture a atteint son point le plus bas. Ce
qui est plus intéressant, c’est ce qui se passe aujourd’hui, qui commence à la fin du postmodernisme, et que
nous pouvons identifier comme la quatrième étape de la relation image réalité, à savoir la simulation pure ou
le stade hyper-réalité. Dans l’art et en particulier dans l’architecture il y a une augmentation de ce qu’on
appelle l’art numérique, et au sein de la communauté architecturale: l’architecture paramétrique; on peut déjà
voir dans le nom, les premiers symptômes d’une juxtaposition problématique. Numérique, étant synonyme de
données informatisée numériques, qui est le monde des mathématiques discrètes de calcul, couplés avec l’art,
le monde que depuis plus de deux siècles a rejeté les mathématiques. Ce couplage semble à première vue être
un renouveau de l’utopie prémoderne de la renaissance mais cela ne pouvait pas être plus loin de la vérité. En
fait, il est un symptôme parfait de la quatrième étape de Baudrillard de la relation image-réalité où le simulacre
n’a plus aucun rapport avec la réalité et les signes se réfèrent seulement à d’autres signes [7]. Un bon
exemple de cette propriété peut être vu dans l’intérêt retourné en géométrie dans l’architecture paramétrique,
ce retour est fondamentalement et purement simulée sans lien véritable avec l’étude moderne de la géométrie.
Cette simulation est réalisée par la création d’un mythe, à savoir inventer de nouveaux termes, expressions, un
système de signes référant seulement à d’autres signes sans réalités originale ou, dans certains cas avait une
réalité originale qui n’est plus là. Par exemple, des mots comme: paramétrique, continue, morphogenèse et
topologie, sont coupés de leurs origines mathématiques et donné une nouvelle vie dans le système simulé.
Même termes fondamentaux, comme la «géométrie» lui-même ne se réfèrent plus à son sens mathématique
universelle, mais cela signifie tout simplement la forme. Le problème ici, n’est pas simplement un problème
de vulgarisation des termes scientifiques comme c’est le cas dans de nombreuses œuvres philosophiques et
littéraires, il est beaucoup plus problématique. Il est compréhensible de faire des actes individuels de vulgarisation
pour exprimer certains concepts philosophiques, il a toujours été fait par les philosophes et des artistes,
mais ici ce qui se passe n’est rien de moins que d’une tentative pour une fausse universalité. À savoir, que, par
exemple, quand un mot comme “géométrie” (ou “paramétrique”) est utilisé dans son sens hyper-réel simulé, il
est entendu par tout le monde, et créant ainsi un mythe à propager. Le long de la même ligne de Simulacres et
simulation, nous rencontrons un autre phénomène important du capitalisme tardif, à savoir le passage de
discipline au contrôle, ce concept a été élaboré par le philosophe français Gilles Deleuze, dans un de ses
derniers essais intitulé Post-scriptum sur les sociétés de contrôle. Dans ce post-scriptum, nous trouvons un ton
beaucoup plus politique par rapport aux écrits précédents de Deleuze, en substance Deleuze exprimer une
préoccupation envers la technologie et en particulier ce qu’il appelle les machines de troisième génération:
ordinateurs; une position qui rappelle la position de Heidegger envers la technologie. Il élabore des thèmes
soulevés par le philosophe français Michel Foucault sur les sociétés disciplinaires; Deleuze explique que ces
sociétés disciplinaires ont évolué vers des sociétés de contrôle. Foucault situé les sociétés disciplinaires dans
le 18ème et 19ème siècles, elles ont atteint leur hauteur au début de la 20ème. Elles initient l’organisation de
vastes espaces d’enclos; l’individu ne cesse passer d’un milieu fermé à un autre, chacun ayant ses propres lois:
d’abord, la famille, puis l’école, puis la caserne, puis l’usine, parfois l’hôpital ou même la prison, l’instance
prééminent d’enclos. Le projet idéal de ces milieux de enclos, est de distribuer dans l’espace, et d’ordonner
dans le temps; de composer une force productive dans la dimension de l’espace-temps dont l’effet sera plus
grand que la somme de ses forces composantes [8]. Deleuze affirme que nous ne sommes plus dans ces
sociétés disciplinaires, nous sommes dans une crise généralisée par rapport à tout l’environnement d’enclos:
| 103grand que la somme de ses forces composantes [8]. Deleuze affirme que nous ne sommes plus dans ces
sociétés disciplinaires, nous sommes dans une crise généralisée par rapport à tout l’environnement d’enclos:
famille, école, usine, hôpital, prison. Les administrations en charge ne cesse d’annoncer des réformes nécessaires;
de réformer les écoles, de réformer les hôpitaux, de réformer les prisons, alors que tout le monde sait
que ces institutions sont finis, quelle que soit la longueur de leurs périodes d’expiration. Les sociétés de
contrôle, sont maintenant dans le processus de remplacement de ces sociétés disciplinaires, le contrôle est le
nom du nouveau monstre, qui Deleuze et Foucault reconnaissent comme notre avenir immédiat. Deleuze
exprime sa préoccupation en ce qu’il considère comme un passage de l’analogique au numérique (ou digital).
Il dit que dans les sociétés disciplinaires, les différents espaces de enclos à travers laquelle l’individu passe,
sont des variables indépendantes avec un langage commun analogique, en les reliant. Alors que, dans les
sociétés de contrôle, on obtient à la place de différents espaces de enclos, des mécanismes de contrôle différents
qui sont des variations inséparables avec un langage commun numérique. Les enclos sont des moules,
des moulages distincts, mais les contrôles sont une modulation, comme un moulage auto-déformant qui
continue changer d’un moment à l’autre, ce qui peut être vu dans la différence entre l’usine et la corporation;
l’usine était un corps qui a tenu ses forces internes à un niveau d’équilibre, mais la corporation, qui l’a remplacé,
est un esprit ou un gaz. Comme la corporation a remplacé l’usine, la formation perpétuelle tend à
remplacer l’école, et le contrôle continu l’examen, ce qui est le plus sûr moyen de livrer de l’école à la corporation.
Dans les sociétés disciplinaires, on a commencé toujours à nouveau; de l’école à la caserne à l’usine,
tandis que dans les sociétés de contrôle, on n’est jamais fini avec quoi que ce soit, la corporation, le système
éducatif, les services armés, sont tous des états métastables coexistent dans un et la même modulation, comme
un système universel de déformation [8]. C’est tout à fait clair, dans la façon dont les écoles d’architecture
d’aujourd’hui sont liés à des agences des architectes qui sont à la fois les enseignants et les patrons. Et comment
la dynamique des studios de design et des cabinets d’architectes se ressemblent de plus en plus, devenant
variations de la même chose, donc un étudiant en architecture qui a suivi une certaine doctrine d’un certain
architecte peut commencer sa vie professionnelle dans le bureau de cet architecte sans jamais se sentir la
transition. Alors que, dans le passé, la transition de la vie étudiante à la vie professionnelle a été très clair, ou
comme le dit Deleuze: l’étudiant repartir de zéro en passant d’un enclos à l’autre i.e. de l’école au bureau.
Dans les sociétés disciplinaires, l’individu a été désigné par une signature et a été indiqué dans les masses par
un numéro; dans les sociétés de contrôle ce qui est important n’est pas la signature ou le nombre, mais un
code: le code est un mot de passe, qui marque l’accès à informations ou la rejette. Nous nous trouvons plus,
face à la paire: masse / individu, les individus sont devenus dividus, et les masses des échantillons, des
données, des marchés ou des banques. L’homme disciplinaire était un produit d’énergie discontinu, mais
l’homme de la société de contrôle est ondulatoire, en orbite, dans un réseau continu, partout, le surf a déjà
remplacé les les sports anciens. Sociétés disciplinaires se équipés de machines portant sur l’énergie, avec le un
danger passif de l’entropie et le danger actif du sabotage, les sociétés de contrôle fonctionnent avec les
machines du troisième type, les ordinateurs, dont passive un danger est le brouillage et dont un danger actif est
le piratage et l’introduction des virus. C’est le capitalisme de production d’ordre supérieur. Il n’achète plus des
matières premières et ne vend plus les produits finis: il achète des produits finis et assebles parties, ce qu’il
veut vendre est un service et ce qu’il veut acheter est des stocks [8]. La conception d’un mécanisme de
contrôle, donnant la position d’un élément dans un environnement à un instant donné, est devenu une réalité
avec le «smart phone». La ville imaginée par psychanalyste français Félix Guatari, où on serait en mesure de
quitter son appartement, sa rue, son quartier, grâce à de une carte électronique individu qui soulève un barier
donné ou être rejetée sur un jour donné ou à certaines heures, est en grande partie réaliser. Ce qui compte n’est
pas la barrière, mais l’ordinateur qui permet de suivre la position de chaque personne licites ou illicites et
effectue une modulation universelle [8]. On peut facilement le voir, dans le nombre écrasant des réseaux
sociaux, les blogs et les plates-formes numériques pour l’échange d’informations, sur nos activités et nos
emplacements, qui prolifère en permanence chaque partie de nos vies. Dans l’architecture c’est tout à fait
tangible dans l’explosion des blogs et des communautés numériques favorisant l’architecture paramétrique, ce
qui est l’architecture de contrôle par excellence, l’idéologie favorise l’efficacité et le contrôle sur la conception
et la production de la forme architecturale. Cependant, nous devons être très vigilants ici, parce que même
si il semble une motivation raisonnable pour un architecte d’être en contrôle de la conception de la forme, il
est bien loin d’un type de contrôle technique qui vient de la formation disciplinaire. Dans les sociétés disciplinaires
contrôle est livré avec des connaissances disciplinaires, à savoir l’architecte devrait recevoir la
formation adéquate, par exemple, dans l’analyse structurelle et à partir de là un contrôle en termes de connais-
104 | plinaires contrôle est livré avec des connaissances disciplinaires, à savoir l’architecte devrait recevoir la
formation adéquate, par exemple, dans l’analyse structurelle et à partir de là un contrôle en termes de connaissances
disciplinaires est atteint. Alors que la plupart des logiciels de CAO aujourd’hui essaient indéfiniment à
fournir aux architectes avec de plus en plus d’informations sur l’objet conçu; informations qui dépassent la
connaissance de l’architecte et même son intérêt; informations qui sont en quelque sorte inutile, c’est comme
si l’objectif de contrôle est le contrôle lui-même. C’est tout à fait comparable à ces heures interminables de
vidéos de caméras de sécurité, pour fournir des quantités infinies d’informations, dans l’espoir que certaines
d’entre elles pourrait se révéler utile si certains attaque se produirait pour traquer les attaquants. La question
de savoir si nous avons besoin de ce montant de la surveillance est un autre débat, mais ce qui est clair, c’est le
lien entre leur informations superflues et les informations superflues du logiciel de CAO, à savoir que soustend
les deux, n’est pas une question de l’utilité comme au sens disciplinaire mais plutôt l’idéologie de
contrôle. Il est devenu aujourd’hui un avantage pour un architecte d’avoir un logiciel qui permet de calculer la
pression du vent sur l’objet, sans que l’architecte ait la moindre idée de ce que cela signifie du point de vue de
la science de l’ingénierie structurelle. Autant il est devenu important pour un téléphone portable, d’indiquer le
taux de battre cardiaque de son utilisateur sans que l’utilisateur ait la moindre idée de ce que cela signifie du
point de vue médical. Nous pouvons voir dans ces exemples ce que Deleuze tentait de souligner avec sa
préoccupation au sujet de la prolifération des ordinateurs dans notre vie humaine, ils alignent simplement tout
dans un seul plan à l’aide d’un code numérique.
| 105ü
4.5. Concernant l'architecture numérique
L'influence de la montée des ordinateurs sur l'architecture est vraiment remarquable, en dehors de l'influence
évidente, en termes de productivité efficace rendue possible par les logiciels de CAO (et modélisation 3D),
l'influence est idéologique et assez problématique. Cette problématique vient du fait que, même si les ordinateurs
rendent les choses plus faciles, plus rapides et plus efficaces, il y a un coût indirect; que ce soit hyper
réalité de Baudrillard, la société de spectale de Debord ou la société de Deleuze de contrôle. Malgré le fait que
l'architecture numérique dans n'importe quelle saveur il arrive, est informé, efficace et visuellement complexe;
dans de nombreux aspect pourrait être considérée comme supérieure aux mouvements architecturaux
antérieures, c'est l'architecture de l'hyper réalité par excellence. C'est précisément dans ce passage de l'analogue
aux outils numériques, nous pouvons voir la prédiction de Deleuze de l'aplatissement de tout dans un
seul plan du code numérique, et où les disciplines sont toutes des variations dans ce plan, ce qui explique
l'inondation des concepts scientifiques à l'architecture numérique avec une facilité absolue. La relation de
l'architecture aux disciplines scientifiques a toujours existé, mais elle a exigé un grand effort de transgression
disciplinaire des architectes; résultant dans le fait que l'utilisation de concepts scientifiques dans l'architecture
est restée dans une large mesure métaphorique. Et si l'utilisation d'un concept scientifique n'allait pas être
métaphorique alors ce concept n'était pas d'une complexité scientifique de haut niveau; cette modestie disparaît
avec l'architecture numérique en raison de l'ordinateur. L'architecture numérique utilise des concepts
scientifiques de la plus haute complexité et actualités: de la topologie à la théorie du chaos, les architectes
pour la première fois ont la possibilité d'utiliser ces concepts non métaphoriquement sans avoir à passer à
travers les difficultés de transgression disciplinaire. Tout cela rendu possible parce que l'ordinateur était
capable de simuler les connaissances nécessaires pour utiliser et manipuler ces concepts scientifiques sous la
forme d'une interface conviviale du logiciel de CAO. De ce point de vue, on peut voir que, même si il est vrai
qu'il y a un changement dans la pensée scientifique vers des concepts de complexité, il est tout à fait exagéré
de penser que l'architecture numérique a son fondement dans cette nouvelle tendance scientifique. Ceci est
simplement dû au fait que la science moderne et en particulier la physique et les mathématiques se concentre
uniquement sur la logique formelle et l'expérimentation positiviste sans aucune attention à l'ontologie, tandis
que l'architecture (numérique ou non) restera toujours ontologiquement compris. En d'autres termes la science
moderne a atteint un niveau auquel il est fortement déconnectée de l'existence quotidienne intuitive, que la
façon dont les individus moyens comprennent les faits scientifiques est similaire à la façon dont les individus
antérieures ont compris leurs mythes de la création. Par exemple, tout individu aujourd'hui connaît les concepts
scientifiques de l'ADN ou de la physique quantique, et serait en mesure de dire à peu près certains de
leurs mécanismes. Ce qui manque toutefois, c'est une compréhension ontologique, en d'autres termes, comment
la compréhension de l'individu de son existence quotidienne est différente avec la connaissance de ces
concepts scientifiques; qui sont dans bien des cas tout à fait contre-intuitive. Un architecte numérique a la
même position que l'individu moyen, car même si les logiciels CAO peuvent simuler certains concepts
scientifiques comme l'évolution ou les systèmes dynamiques non linéaires, l'architecte qui l'utilise, n'a aucune
compréhension formelle ou expérimentale de ces concepts. Ce qui signifie que l'architecte ne peut pas être
pleinement conscient de l'évolution de la pensée scientifique, plus que l'individu moyen, en d'autres termes,
pour que l'architecture numérique faire partie de ce changement scientifique, les architectes ont besoin de
transgresser l'architecture vers les disciplines scientifiques et non seulement les simuler. Mais même si cela
arrive et que les architectes reçu la connaissance scientifique disciplinaire appropriée, ils sont maintenant
confrontés au problème de l'ontologie: comment rendre ces concepts scientifiques formelles significatives
pour l'existence humaine quotidienne. Aujourd'hui, nous assistons de plus en plus dans les écoles d'architecture
des programmes éducatifs orientés vers une approche scientifique, ce qui signifie que les les architectes
qui sortent de ces programmes auraient en quelque sorte une compréhension plus profonde des sciences en
question de l'individu moyen. Cependant, nous voyons que l'ensemble de ces connaissances scientifiques est
médiée par l'ordinateur, puisque tous ces programmes éducatifs sont fondées sur la compréhension numérique
des concepts scientifiques, et non sur les cours disciplinaires réguliers qui bien sûr serait prendre beaucoup
plus de temps et d'efforts à saisir. Le fait est que, malgré la forte progression de l'architecture numérique, elle a
encore un long chemin avant de donner une véritable nouvelle architecture; c'est parce qu'elle doit surmonter
deux difficultés. Tout d'abord, elle a besoin de travailler durement pour correspondre à ses ambitions scientifiques
et, deuxièmement, elle doit travailler encore plus dur pour fournir l'ontologie appropriée pour elle-
106 | deux difficultés. Tout d'abord, elle a besoin de travailler durement pour correspondre à ses ambitions scientifiques
et, deuxièmement, elle doit travailler encore plus dur pour fournir l'ontologie appropriée pour ellemême,
et que, tout en étant informée par la science moderne, elle n'a pas perdu son sens artistique et poétique
et se réduite à un problème d'optimisation. Une autre question fondamentale qui semble être souvent négligé
est pourquoi ce grand intérêt pour la science qui caractérise l'architecture numérique. Il est vrai que la relation
entre l'architecture et la science a une longue histoire, d'un côté des raisons pratiques de l'ingénierie du bâtiment,
et de l'autre côté, les analogies entre les méthodes de conception et des phénomènes naturels, mais
l'architecture numérique se rapporte à la science dans une manière totalement nouvelle dépassant à la fois la
pratique et le raisonnement analogique. Malgré l'apparence extérieure de fonctionnalité que l'architecture
numérique donne à son intérêt pour la science, la vérité est que la science entre dans l'architecture numérique
comme un obscur objet du désir, un objet de fascination pure. Ceci peut être vu dans le très grand nombre de
publications, des cours théoriques et pratiques, tous dédiés sous une forme ou une autre d'utiliser des
phénomènes scientifiques en tant que donateur de la forme architecturale, au point que l'on s'interroge sur le
sens de ces conceptions. En dépit de leur force visuelle, ces conceptions clairement n'abordent pas les questions
architecturales, comme l'espace, la circulation, etc. Et s'ils le font, il est fait d'une manière assez réductrice,
comme si ces questions étaient des problèmes quantitatifs simplement positivistes (paramètres), ils
n'abordent pas non plus des questions scientifiques ou techniques, après tout une enquête scientifique exige
des connaissances disciplinaires et pas seulement du logiciel de CAO. Ainsi, la question de l'intérêt de l'architecture
numérique dans la science n'a rien à voir avec la relation historique entre l'architecture et la science,
mais une fois de plus, il fait partie d'un plus grand problème social contemporain qui se manifeste dans
l'architecture à travers le couvert de l'architecture numérique. Le problème a à voir avec la position de la
science moderne dans la société contemporaine en général, et comment elle a changé dans l'ère numérique. Il
ne fait aucun doute, que la science a toujours été motivée par la fascination, à savoir la fascination du scientifique
avec un certain phénomène et son envie de le démystifier, cela signifiait que la science (au moins
depuis le siècle des Lumières) traite de fascinations sans être un objet de fascination en soi. Maintenant, avec
l'ordinateur, la science devient l'objet de fascination en soi, ce qui peut être vu dans la montée de ce qu'on
appelle les "geeks" (à ne pas confondre avec les informaticiens). La différence est la suivante: compte tenu
n'importe quel phénomène physique, un scientifique serait fasciné par ce phénomène lui-même, tandis que les
geeks plupart du temps dépourvus des connaissances disciplinaires, seraient intéressés par la simulation
offerte par l'ordinateur pour étudier ce phénomène. Par exemple, les geeks qui peuvent montrer tout l'aspect
d'un logiciel pour enregistrer, analyser et manipuler le son, sans aucune connaissance ou un intérêt dans la
physique des ondes sonores. Cela signifie que dans notre société d'ordinateurs, des réseaux sociaux et des
smartphones, la science acquiert un important nouvelles caractéristiques: le «scientific look», ce qui est au
cœur de la façon dont il est entendu par l'individu moyen. Dans notre société de l'hyperréalité de Baudrillard,
il ne suffit pas de simplement faire de la science telle qu'elle se fait traditionnellement en utilisant les connaissances
disciplinaires, la science plus que tout doit avoir le «scientific look», pour qu'elle soit acceptée par la
société dans la science. Ce «scientific look» est ce qui fait de la science un objet de désir dans les yeux de la
personne moyenne contemporain, il est ce qui est fait des ordinateurs et smartphones se vendent très bien,
parce que lors de l'utilisation d'un logiciel ou d'une application, il semble que si l'on fait la science. Maintenant,
l'architecture numérique traite la science le long de ces mêmes lignes, un logiciel de CAO contemporain
serait capable de modéliser des formes géométriques complexes de certains phénomènes physiques et un
geeks serait capable de la maîtriser sans intérêt ou des connaissances dans le science elle-même. Le logiciel de
CAO donne l'ingrédient magique pour le travail, notamment son «scientific look». L'ironie est que si un
travail d'architecture aurait eu une étude scientifique sérieuse derrière lui, mais il n'est pas fait à l'aide d'un
logiciel de CAO, il serait perçu comme moins scientifique qu'un travail fait en utilisant le logiciel de CAO,
mais sans science derrière. Cela nous amène à la conclusion que l'architecture numérique n'est pas intéressé à
faire entrer la science dans le travail, mais simplement le «scientific look»; qui est ensuite complété par
l'utilisation abusive des termes scientifiques d'une grande complexité. On ne peut pas commencer à compter le
nombre de publications de l'architecture numérique qui utilisent constamment des termes tels que la topologie,
fractale, paramétrique, code génétique pour n'en nommer que quelques-uns.
| 107ü
4.6. Références
[1] Winged edge data structure, Hanan Samet, University of Maryland, 1998
[2] Lecture notes on Cubic spline, Donald H.House, Clemeson University, 2011
[3] http://en.wikipedia.org/wiki/Bicubic_interpolation
[4] Bezier curves and surfaces, Andres Iglesias, University of Cantabria, 2001
[5] B-splines and NURBS curves and surfaces, Andres Iglesias, University of Cantabria, 2001
[6] The Society of the spectacle, Guy Debord , Buchet-Chastel, 1967
[7] Simulacra and simulation, Jean Baudrillard , Éditions Galilée, 1981
[8] Postscript on the society of control, Gilles Deleuze, Jstor, 1992
108 | 5. Opérations algébriques
ü
5.1. Construction des espaces vectoriel et affine
A ce stade, nous arrivons à la fin de la première partie des constructions mathématiques à savoir les définitions
de formes; dans cette partie, nous avons vu le définitions paramétriques et algébriques de courbes et de
surfaces, en plus nous avons vu les techniques de approximations de formes en utilisant des mailles et interpolations
qui sont à la base des systèmes de logiciels de CAO. Ici, la qualité de la définition des formes mathématiquement
va commencer à montrer son potentiel, à savoir lorsque nous sommes en mesure d'utiliser les
formules pour extraire des informations sur la forme et les utiliser pour générer d'autres formes. En d'autres
termes, dans la partie qui suit, nous allons nous concentrer sur la façon de modifier ces formes que nous avons
définies en utilisant des opérations mathématiques. Ces modifications sont une partie essentielle de la conception
depuis tant qu'architectes nous commençons toujours par une forme de base qui se fait adaptée au long du
processus de conception pour des raisons différentes esthétiques et pratiques. Ces opérations mathématiques
que nous allons utiliser pour modifier les formes sont classés en trois types: les opérations algébriques,
analytiques et algorithmiques. Cette catégorisation est très clair, à savoir que dans les opérations algébriques
nous allons utiliser des applications linéaire, affine et projectives, ce qui signifie que les géométries concernées
ici sont des géométries affine, euclidienne et projectives. La façon dont nous allons construire les
opérations algébriques: linéaire, affines et projectives, serait entre des espaces vectoriels en utilisant des
matrices de transformation, ce sont des opérations familiers comme les traductions, les rotations, mise à
l'échelle et la projection. Dans la partie analytique, nous allons utiliser les opérations de calcul différentiel et
intégral, ce qui signifie que la géométrie de cette partie est la géométrie différentielle, nous devrions utiliser
ces opérations pour calculer des informations cruciales sur la forme à savoir les dérivés, courbures, des
longueurs d'arc, les zones et volumes, etc. Ensuite, utilisez ces informations pour générer des variantes de la
forme de champs de vecteurs, par exemple les surfaces minimales, trouver géodésiques sur la surface, sont
tous des outils de conception utiles et intéressants. Enfin dans la partie algorithmique, nous utiliserons des
algorithmes et traitions des éléments géométriques discrets qui signifie que les géométries concernées ici sont
des géométries computationnelle et combinatoires. Dans cette dernière famille d'opérations; différentes
méthodes numériques computationnelle vont être utilisés, par exemple des algorithmes d'optimisation et des
algorithmes de recherche (comme la méthode de Monte Carlo) et des formes générées de manière itérative,
modèle computationnelle. Maintenant que nous avons une idée générale des trois types d'opérations différentes,
nous allons commencer par le premier type: les opérations algébriques. Les opérations algébriques
sont les bases sur lesquelles tout repose, il y a beaucoup de notions que nous connaissons intuitivement dans
l'architecture comme un espace tridimensionnel euclidien, la distance, la projection et beaucoup d'autres, mais
nous ne connaissons pas leur formulation mathématique. Dans cette recherche comme mentionné plus tôt,
nous essayons de combler l'écart entre l'abstrait et l'intuitive, de sorte qu'une approche mathématique approprié
pour la conception peut fonctionner. Nous commençons par expliquer le monde où nous faisons toutes
ces formes à savoir l'espace euclidien à trois dimensions, il est aussi l'espace dans lequel nos variétés sont soit
immergées ou submergées et où nous allons appliquer nos opérations. Il est tout d'abord un !-espace
vecteuriel normé avec une norme appelée la norme euclidienne. Afin de bien définir un espace euclidien nous
avons besoin de quelques autres notions qui nous aideront à comprendre sa construction mathématique, le
premier de ces serait la notion fondamentale d'un groupe et comment nous pouvons aller de groupe à l'autre en
utilisant des applications linéaires (morphismes).
| 109Groupe et morphisme de groupe [1]
est une structure algébrique constituée d ' un ensemble non vide G, muni d ' une loi interne associative ù ,
admettant un élément neutre, et tel que tout x œ G , x possède un inverse
si x ù y = yù x ï G est appelé un groupe abélien ou commutatif
Nous disons que G est un groupe si etseulementsi
ù associative : " a, x, y œ G, H aù xLù y = aùHxù yL
$ e est l' élément neutre : " a œ G, eùa = aùe = a
$ a' est l' inverse de a : " a œ G , aùa' = a'ùa = e
H Õ G est un sous - groupe de G si " x, y œ H , x'ù y œ H
ZHGL = 8z œ G " g œ H, zùg = gù z< est le centre du groupe G
H1, H2 Õ G sous groupes conjugués de G si " h1 œ H1, $ g œ G et h2 œ H2 h1 = g
-1 h2 g
HG, ùL et HG', *L , deux groupes et f : GöG' ,
f est un homomorphisme ó " x, y œ G f Hxù yL = f HxL* f HyL
f est un isomorphisme si bijective et f est un endomorphisme si HG, ùL = HG', *L
Action de groupe [1]
G un groupe, X un ensemble alorsl' action de G sur X est donnée par
Gä Xö X, Hg, xL Ø g.x vérifiant que
" g1, g2 œ G , " x œ X , g1. Hg2.xL = Hg1 g2L.x et 1G.x = x Hoù 1G = élément neutre de GL
si " x, y œ X, $ g œ G y = g.x l' action est transitive
si " x œ X, g.x = x ó g = 1G l' action est libre
x, y œ X, ~ est une relation d ' équivalence si etseulementsi il est
réflexive : x ~ x , symétrique : x ~ y ïy ~ x et transitive : x ~ y et y ~ z ï x ~ z
X êG est l' ensemble quotient de la relation d ' équivalence y ~ x si y = g.x
p : Xö X êG , x # x est la projection canonique
x = G.x = 8y œ X y = g.x , " g œ G < = 8y œ X y ~ x<
L'espace vectoriel
Après avoir défini le groupe, nous pouvons passer à la définition de l'espace vectoriel sur un corps de
scalaires, le corps de scalaires est tout simplement l'ensemble où les coordonnées d'un vecteur viennent. Tout
vecteur est un tuple de cette forme Hv1, ..., vnL où les vi
pour i=1,..,n sont des nombres réels (mais ils peuvent
aussi être des nombres complexes ou des éléments de n'importe quel corps). Nous verrons ci-dessous que un
espace vectoriel est un ensemble E d'éléments appelés vecteurs (c. coordonnées des points) avec une loi
interne de l' addition de vecteurs et une loi externe de la multiplication par les scalaires (éléments du corps #)
où l'ensemble E muni de la loi d'addition est un groupe abélien. Cela semble un peu abstrait, mais il est assez
intuitive, par exemple, lorsque nous additionnons deux vecteurs (points) dans l'espace euclidien nous obtenons
encore un vecteur dans le même espace euclidien et si l'on divise ce résultat par deux on obtient le point milieu
entre ces deux points initiales.
Représentation d'un espace vectoriel de dimension trois
110 | Espace vectoriel [2]
# un corps de scalairesH# = ! ou $L
E un ensemble dont les éléments sont appelés vecteurs,
E a deux lois
une loi interne « + » : E
2 Ø E, appelée loi d ' addition ou somme vectorielle, HE, +L est un groupe abélien
une loi extérieure à la gauche « • » : #µE Ø E, appelé multiplication par un scalaire
" u, v œ E, et " l, m œ #
u + v = v + u et u + Hv + wL = Hu + vL + w, Hi.e. commutative et associative L
$ 0E élément neutre 0E + v = v
" u œ E a opposé un, noté - u u + H-uL = 0E
l •Hu + vL = Hl • uL + Hl •vL, Hi.e. distributive sur la gauche par rapport à la loi « + » de EL
Hl + µL • u = Hl • uL + Hµ • uL, Hi.e. distributive sur la droite par rapport à l' addition du corps #L
HlmL • u = l • Hµ • uL , Hi.e. associatives sur la droite par rapport à la multiplication dans #L
1 • u = u ,
Hi.e. l' élément neutre multiplicatif du corps #, noté 1 est neutre sur la gauche pour la loi externe « • »L
l • 0E = 0E, Hi.e. 0E est absorbant à droite pour la loi « • » L
0# • u = 0E, Hi.e. le produit de tout vecteur de E par un scalaireL
-1 • u = -u, Hi.e. -v Hl' opposé de vL est le produit de v par le scalaire - 1L
Base de l'espace vectoriel [2]
e = He1, ..., enL une famille de vecteurs linéairement indépendants
" Hl1, ..., lnL œ !n
, ⁄i=1
n li ei = 0 ï " i œ 81, ..., n<, li = 0
" x œ E , $ Hl1, ..., lnL x = ⁄i=1
n li ei
ï e = He1, ..., enL une base de E
Il est tout à fait naturel après avoir défini l'espace vectoriel; de définir le sous-espace vectoriel, par exemple un
sous-espace vectoriel de l'espace euclidien à trois dimensions, est le plan euclidien qui contient les vecteurs
qui ont coordonnée z nulle.
Sous-espace vectoriel [2]
F Õ E , F " «
stable pour l' addition vectorielle et la multiplication par un scalaire Hcombinaison linéaireL
" u, v œ F et " l, m œ #
l u + m v œ F
ce sous ensemble F contient l' opposé de chacun de ses vecteurs
" u œ F $ v œ F u + v = 0E Hi.e. v = -uL
F est le sous - groupe de HE, +L
F1 et F2 sont des sous - espaces de E sont en somme directe F1$F2 ó F1 › F2 = 80E<
F1 et F2 sont des sous - espaces de E sont complémentaires ó F1$F2 = E
F1, ... Fn sont des sous - espaces de E, alors ⁄i=1
n Fi = 8x œ E $ Hx1, ..., xnL œ F1 ä ...äFn , x = x1 + .. + xn<
| 111La norme
Venons-en maintenant à la définition de la norme euclidienne qui conduit à la définition de l'espace euclidien.
Pour ce faire, nous définissons de quelques notions importantes à savoir la forme bilinéaire symétrique et sa
forme quadratique et la signature de cette forme quadratique.
Norme euclidienne [3]
°.¥ : Eö!+ , °.¥ norme euclidienne sur E qui vérifie, " x œ E
séparabilité : °x¥ = 0 óx = 0E vecteur nul
positivité : " l œ #, °l x¥ = †x§ ° x¥
inégalité triangulaire : ° x + y¥ b °x¥ + °y¥
°x¥p = H⁄i=1
n
†xi
§
p
L
1
p
, x œ E = H!n
, °.¥ L
Forme bilinéaire symétrique [3]
E est un ! - espace vectoriel,
j : E
2ö! est une forme bilinéaire symétrique si " l, m œ ! and " x, y, u, v œ E
jHl x + m u, yL = l jHx, yL + m jHu, yL and jHx, l y + m vL = l jHx, yL + m jHx, vL
Forme quadratique [3]
E est un ! - espace vectoriel, dim E = n ,
j est une forme bilinéaire symétrique et q : E ö! quadratic form
qHxL = jHx, xL and qHxL = ⁄i=1
n aii xi
2 + ⁄1bi< jbn aij xi x j
jHx, yL =
1
2
@qHx + yL - qHxL - qHyLD,
jHx, yL = ⁄i=1
n aii xi yi +
1
2 ‚
1bi< jbn
aij Ixi y j + x j yi
M
aprèsla réduction de Gauss et de la signature $ n formes linéairement indépendantes : v1, ..., vn
q = ai @viD
2
, ai œ 81, 0, -1< , SignHqL = 8# 8i : ai = 1<, # 8i : ai = -1<<
q est définie positive si sa signature est Hn, 0L = Hdim E, 0L , à savoir " x œ E , qHxL = jHx, xL > 0
Enfin, nous définissons le produit scalaire qui est l'ingrédient principal pour fabriquer l'espace euclidien. Il
s'agit essentiellement de la règle selon laquelle on mesure la distance entre deux points x, y dans l'espace. En
d'autres termes la longueur de leur vecteur x y
Ø
= v = y - x which is Xv, v\
Produit scalaire [3]
est une forme bilinéaire symétrique définie positive, °.¥ la norme associée
" x œ E , °x¥ = Xx, x\ , " x, y œ E , °x + y¥
2 = °x¥
2 + 2 Xx, y\ + °y¥
2
inégalité triangulaire : °x + y¥ § °x¥ + °y¥
inégalité de Cauchy Schwarz : †Xx, y\§ § °x¥ °y¥
" x, y œ E , q angle entre x, y où q œ P0, pT, cosq = Xx,y\
°x¥ °y¥ ó -1 §
Xx,y\
°x¥ °y¥
§ 1
Maintenant, avec les définitions précédentes, nous sommes en mesure de définir l'espace euclidien comme suit
Espace euclidien [3]
est un ! - espace vectoriel muni d ' un produit scalaire, dim E = n
112 | L'espace euclidien
L'espace euclidien de dimension trois est un !-espace vectoriel muni d'un produit scalaire, dim E = 3 avec la
base canonique (e1, e2, e3) comme sa base où e1 est le vecteur colonne (1,0,0), e2 est le vecteur colonne (0,1,0)
et e3 est le vecteur colonne (0,1,0). Maintenant que nous avons défini l'espace euclidien !3
nous pouvons
commencer par définir la transformation qui nous permettra de générer de nouvelles formes à partir des
initiales, nous allons nous concentrer principalement sur les transformations linéaires, affines et projectives,
nous devons aussi voir les définitions de formes dans la base canonique. On a vu à cette définition du cylindre
cHu, vL = Ha CosHuL, b SinHuL, c vL, cette définition peut aussi s'écrire plus explicitement comme une combinaison
linéaire des vecteurs de base canoniques (e1, e2, e3), à savoir dans cette forme cHu, vL= Ha CosHuLL e1 +
Hb SinHuLL e2+ Hc vL e3. Dans cette forme, nous pouvons voir clairement que l'application cHu, vL est rien d'autre
qu'une application à valeurs dans !3
, ce qui signifie que l'évaluation de cHu, vL Hu,vL
va donner un vecteur qui
est une combinaison linéaire de (e1, e2, e3). Cela signifie que pour le même équation écrite dans une autre base
va donner une version déformée du cylindre.
Définition de la forme dans une base de l'espace euclidien !3
(e1, e2, e3) est la base canonique, e1 =
1
0
0
, e2 =
0
1
0
, e3 =
0
0
1
cHu, vL = H1, 1, 0L +
1
2
CosHuL e1 +
1
2
SinHuL e2 +
v
4
e3
Maintenant, si nous prenons la même équation et l'écrire est une autre base de l'espace euclidien !3
(b1, b2, b3)
où il n'est pas une base orthonormée, nous pouvons voir dans la figure ci-dessous la déformation de la forme
(cylindre). Cependant, dans cette recherche, nous considérerons toujours la base canonique la base de notre
espace euclidien !3
(b1, b2, b3) est la base canonique, b1 =
1
1
2
0
, b2 =
0
1
0
, b3 =
1
5
1
5
1
cHu, vL = cHu, vL = H1, 1, 0L +
1
2
CosHuL b1 +
1
2
SinHuL b2 +
v
4
b3
Représentation d'un cylindre dans la base canonique et d'une base non orthonormé de l'espace euclidien !3
| 113Applications entre espaces vectoriels
Premièrement, nous allons considérer la transformation linéaire à savoir de transformation qui sont produites
en multipliant le vecteur par une matrice nommée matrice de transformation. La translation n'est pas une
transformation linéaire mais une transformation affine dont la partie linéaire est la matrice d'identité. Nous
allons montrer plus en détail comment les transformations affines fonctionnent et comment elles sont utiles
dans la conception architecturale, en fait, toute transformation affine est un produit semi-direct de traduction et
une transformation linéaire. Alors d'abord, nous définissons une application linéaire, à savoir une application
qui prend des vecteurs comme ses variables et c'est la façon dont nous nous déplaçons entre différents espaces
vectoriels ou dans le même espace vectoriel. Dans cette recherche, nous allons nous concentrer principalement
sur les applications linéaires qui envoie un espace vectoriel dans lui-même à savoir endomorphismes c'est
parce que la plupart de nos objets sont définis dans !3
et les images de leurs transformations sont également
dans !3
.
Application linéaire (homomorphisme de !-espaces vectoriels) [3]
E, F sont des # - espaces vectoriels, f est une application f : E öF telle que " l, m œ # et " x, y œ E
f Hl x + m yL = l f H xL + m f HyL, f est additif et homogène
si f est bijective ï f est un isomorphisme, si E = F ï f est un endomorphisme,
si f is bijective et E = F ï f est un automorphisme
LHE, FL est l' espace vectoriel des applications linéaires de E à F,
IsomHE, FL est l' ensemble des isomorphismes de E à F
LHEL est l' espace vectoriel des endomorphismes de E, G LHEL est le groupe des automorphismes de E
les applications linéaires peuvent être représentés dans une base donnée par une matrice
Théorème du rang [3]
KerH f L = 8x œ E f HxL = 0< = f
-1
H80 0 et A renverse l' orientation si detHAL < 0
Orthogonal endomorphism [3]
u est un endomorphisme orthogonal HA est une transformation orthogonaleLsi
" x, y œ !n
, °uHxL¥2 = °A x¥
2 = °x¥
2 =
t
x x = Xx, x\
XuHxL, uHyL\ = XA x, A y\ =
t
x
tA A y =
t
x y = Xx, y\
une rotation de !n
est une transformation orthogonale qui préserve l' orientation
114 | L'espace affine
Une autre notion importante est l'espace affine. Par exemple, si nous voulons faire pivoter un objet en réalité,
nous le faisons en choisissant une origine et un axe autour duquel il sera tourné. Ce choix de l'origine peut être
considérée comme une translation ou d'un déplacement de l'espace vectoriel à partir de l'origine canonique à la
nouvelle origine, cette copie déplacé est un espace affine.
Espace affine [5]
E est ensemble non vide, muni d ' un action de groupe libre et transitif de l' espace vectorielKE
Ø
, +Osur E
KE
Ø
, +OäEö E , Jv
Ø
, pN Ø v
Ø
.p = p + v
Ø
vérifiant que
" p, q œ E , $ v
Ø
œ E
Ø
q = p + v
Ø
Ji.e. v
Ø
= p qN and if p + v
Ø
= p ï v
Ø
= 0
E
Ø , or dim E = dim E
Ø
Sous-espace affine [5]
Soit O œ E , " F Õ E, F = O + F
Ø
est le sous - espace affine avec un sous - espace vectoriel directeur F
Ø
Õ E
Ø
Coordonnées barycentriques et cartésiennes [5]
S = 8p0, p1, .., pk< Õ Eï F = XS\ est le plus petit sous - espace affine contenant S
les pi sont affinement inpedendantsi " i ,
les vecteurs :pi pj
, j = 0, ..., k and i " j> sont linéairement indépendants
ï dim XS\ = k et " p œ XS\, $ ! Hl0, ..., lkL œ #
k+1
, ⁄i=0
k li = 1 et " o œ E, o p = ⁄i=0
k li o pi
Hl0, ..., lkLsont les coordonnées barycentriques par rapport à S,
et nous pouvons écrire : p = l0 p0 + ... + lk pk
soit p0 = o ï o p = l1 o p1 + ... + lk o pk
Hl1, ..., lkLsont les coordonnées cartésiennes
de p par rapport à l' origine o et la base et :o p1 , ..., o pk > de F
Ø
Vectorialization de l'espace affine E à l'espace vectoriel !n
Hnon - canoniqueL [5]
E espace affine, E
Ø
son espace vectoriel directeur avec Je1
Ø
, .., en
Ø
N comme sa base canonique
soit o œ E sera appelé l' origine, qo : EöE
Ø
, qoHpL = o p est une bijection avec qo
-1
H u
öL = o + u
ö
ï nous pouvons ajouter à E une structure d ' un espace vectoriel Eo appelé le vectorialization de E en o
par lesformules p + q = r o p + o q = o r , l.p = l o p etson élément neutre 0Eo = o
f : !nö E, f Hl1, ..., lnL = P = o + l1 e1
Ø
+ ... +ln en
Ø
est un isomorphisme de !n
à Eo
ï Hl1, ..., lnLsont les coordonnées cartésiennes of p relative to the origin o and the canonical base
L'extension vectorielle de l'espace affine (canonique) [5]
E espace affine, E
Ø
son espace vectoriel directeur
E
`
est l' extension vectorielle de E E hyperplan affine, E
Ø
hyperplan vectoriel
E
`
= E
Ø
‹ 8l x x œ E, l œ #
*
< avec 1 x = x
h : E
` ö # est une forme linéaire hHv
`
L = 0 si v
`
œ E
Ø
et hHv
`
L = l si v
`
= l x
E
Ø
= ker h et E = h
-1
H1L
| 115ü
5.2. Symétrie et géométrie
L'intérêt dans les opérations algébriques a été intrinsèque dans la conception architecturale à travers toute son
histoire, cela est dû à l'importance de la notion de symétrie dans l'architecture. Depuis la conception architecturale
est largement basée sur la composition, elle repose sur la symétrie dans de nombreuses façons pour
générer des formes et des motifs, de la conception des plans d'étage aux façades et toitures. En effet, les
opérations algébriques comme la translation, l'homothétie et la rotation ont formé la palette générale de
transformation dans la conception architecturale pour la plupart de son histoire. Que très tard, que les architectes
ont commencé à avoir un intérêt dans d'autres types de transformation, à savoir infinitésimal au lieu de
algébrique. Jusqu'au milieu du XXe siècle, les transformations d'éléments architecturaux en rapport à une
surface de base (par exemple des ouvertures sur la façade) ont été confinés à des surfaces planes. Mais, avec
l'intérêt croissant pour les surfaces courbes un autre type de transformation sera définie, à savoir celle qui
utilise un champ de vecteurs comme une direction variable au lieu d'un seul vecteur. Ce type de transformation
est considéré dans la section des opérations d'analyse de cette recherche où les notions de champs de
vecteurs et courbes intégrales sont considérés.
Représentation d'un plan d'étage de basilique romaine
Nous allons maintenant définir la symétrie du point de vue de la théorie des groupes, à savoir la définition du
groupe de symétrie d'un objet. Le groupe de symétrie d'un objet est le groupe de toutes les isométries sous
lequel l'objet est invariant, avec la composition comme la loi du groupe, c'est un sous groupe du groupe
d'isométrie de l'espace concerné. Le principal groupe de symétrie sur lequel nous allons nous concentrer dans
cette recherche est le groupe de symétrie de l'espace euclidien connu comme le groupe euclidien qui est un
sous groupe du groupe affine. Le groupe de symétrie est parfois appelé le groupe de symétrie complète afin de
souligner ce qu'il comprend les isométries qui renversent l'orientation (comme la réflexion), sous lequel la
forme est invariante. Le sous groupe des isométries qui préservent l'orientation (comme translations et rotations)
qui laisse l''objet invariant est appelé le groupe de symétrie propre. Tout groupe de symétrie dont les
éléments ont un point fixe commun, ce qui est vrai pour tous les groupes de symétrie finis et les groupes de
symétrie des figures bornées sont représentés comme un sous groupe du groupe orthogonal en choisissant
l'origine pour être le point fixe. Le groupe de symétrie propre est un sous groupe du groupe spécial orthogonal
aussi connu comme le groupe de rotation. Les groupes de symétrie peuvent être soit des groupes de symétrie
discrètes ou continues. Le groupe de symétrie discrète vient dans trois types: les groupes de ponctuels finis, y
compris seulement des réflexions, des rotations, des inversions et roto-inversions, les groupes de réseau infini,
y compris que des translations et le groupe d'espace infini qui combine des éléments des deux types. Le
groupe de symétrie continue, qui contient de rotation d'angles arbitrairement petits et de translations de
distances arbitrairement petites, ces groupes de symétrie sont étudiés comme des groupes de Lie. Deux figures
géométriques sont considérées comme étant du même type de symétrie si leurs groupes de symétrie sont des
sous groupes conjugués du groupe euclidien.
Groupe de symétrie [6]
X est un ensemble, G est un groupe et Gä XöX , Hg, xLög.x est une action de groupe de G sur X
g.x = y ïy estsymétrique à x
S = 8g œ G g.x = x < Õ G est le groupe de symétrie des objets dans X
116 | Les groupes de symétrie d'une forme
Afin de clarifier cette notion de symétrie, nous allons donner un tableau des différents types de groupes de
symétrie principalement celles de l'espace affine, l'espace euclidien et l'espace projectif (i.e. les groupes de
transformations affines, euclidien et projectives) et leurs géométries respectives. En plus des transformations
topologiques continus qui ne conserve que des notions topologiques (comme l'ouverture, la fermeture, la
compacité, la connexité, etc) qui est liée plus à la géométrie différentielle. L'idée générale est illustrée dans
l'image ci-dessous, qui montre toutes les façons dont un carré peut être transformée. La transformation dans la
rangée 1 est la dispersion, la seule propriété qui est préservée dans ce cas est que chaque point correspond à un
point. La transformation de la ligne 1 est: dispersion, la seule propriété qui est préservée dans ce cas est que
chaque point correspond à un point. La transformation dans la rangée 2 est continue et de préserver également
la séquence de points résultant en une figure topologiquement fermé. Sous la transformation de perspective
dans la rangée 3, la propriété: ligne droite, est également conservé. La transformation affine, dans la rangée 4
conserve tout ce qui a précédé et aussi le parallélisme, d'ailleurs quand le vrai angle est conservé, la forme
peut encore être transformé par mettre à l'échelle, les formes restent les mêmes comme dans la rangée 5. Enfin
à la ligne 6, la taille réelle est également conservée, ce qui signifie que la forme conserve toutes ses propriétés,
mais peut encore être transformé par la translation et deux opérations de symétrie: réflexion et de rotation. Les
deux niveaux inférieurs sont liés à la géométrie métrique descendu de l'antiquité grecque, le troisième niveau
concerne la géométrie affine, le quatrième niveau de la géométrie projective, et le cinquième niveau de la
topologie. En géométrie métrique (euclidienne), le carré est toujours représenté par un carré dans le sens
habituel, alors que dans la géométrie affine tout parallélogramme y compris le carré métrique représente un
carré; qui illustre le fait que la géométrie (euclidienne) métrique est comprise par la géométrie affine: la
dernière est plus grand, plus riche et plus abstrait, et dans ce sens plus complexe que la précédente. La
géométrie Affine est à son tour comprise par la géométrie projective, où tout quadrilatère peut représenter un
carré donc un nouveau niveau de complexité est atteint, et par cette logique, un niveau encore plus élevé de
complexité est atteint avec la topologie, depuis le carré peut maintenant être représentée par toute forme
fermée. Cela nous donne une idée intuitive du programme d'Erlangen de Félix Klein où chaque géométrie est
considérée comme un cas particulier de son prédécesseur plus abstrait; du début intuitive nous allons maintenant
formaliser ces notions en donnant leur description mathématique en utilisant le langage de la théorie
des groupes.
Représentation des groupes de symétrie d'une forme carrée
| 117ü
5.3. La géométrie euclidienne vs l'arithmétique pythagoricienne en architecture
Avec les définitions formelles des différentes géométries comme les différents groupes de symétrie, nous
voudrions donner une certaine attention à la plus pertinente de ces groupes à l'architecture à savoir le groupe
euclidien et sa géométrie: la géométrie euclidienne. Sa présence en architecture a été et est toujours le plus
important de tous les autres géométries, mais il est moins connu que la géométrie euclidienne n'était pas la
seule présence des mathématiques en architecture, il a eu le système arithmétique pythagoricienne de proportions
comme son principal rival. En montrant ce bref historique, nous allons compter sur un article publié dans
Nexus Journal en 2001 par le professeur Michele Sbacchi de l'université de Palerme intitulé: Euclidism et la
théorie de l'architecture [7]. La géométrie euclidienne est l'une des branches fondamentales de géométrie, elle
est restée presque inchangée, nous l'utilisons encore aujourd'hui comme elle a été codifié par Euclide d'Alexandrie
en treize livres appelé les éléments. Ce livre très influent traité géométrie planaire et contient les définitions
de base des éléments géométriques tels que les célèbres point, ligne et surface, un point, c'est ce qui n'a
pas de part, une ligne a une longueur sans largeur et une surface est celle qui a longueur et la largeur. En plus
de toute une série de propositions où les caractéristiques des figures géométriques plus complexes sont définis.
Euclide fournit également des procédures pour générer des formes et des solides planes et à résoudre des
problèmes géométriques. Il est assez impressionnant que jusqu'au 17ème siècle, la géométrie euclidienne a été
tout simplement la géométrie tout court, car ce n'est qu'à partir de la seconde moitié de ce siècle que d'autres
branches de géométrie ont été développés, notamment la géométrie analytique et projective et beaucoup tard
la topologie. Ces disciplines plutôt que de contester la validité de la géométrie euclidienne, elles ont ouvert
des compréhensions complémentaires; confirmant ainsi l'efficacité de la géométrie euclidienne, mais certains
sujets euclidiennes subi des attaques violentes et encouragés d'immenses débats, par exemple le 5ème postulat
(le postulat des parallèles). Euclide n'était guère un génie isolé; historiens ont précisé qu'il a attiré d'autres
sources essentiellement Theatetus et Eudoxs, donc plutôt que d'inventer il a surtout systématisé un corpus de
connaissances qui ont circulé autour de savants dans des formes un peu rugueuses. Les éléments, représentait
un grand pas en avant en particulier par rapport à la façon fragmentaire dans lequel la géométrie a été connu et
transmis, il est vite devenu un livre extrêmement utile pour tous les domaines où la géométrie a été appliquée.
Optique, mensuration, l'arpentage, la navigation, l'astronomie et l'architecture, tous bénéficié en diverses
manières de ce nouvel ensemble complet de règles capables de surmonter les problèmes géométriques. Suite
au destin de la plupart des textes scientifiques grecs, il fut bientôt traduit en arabe et a été connu à travers cette
langue pendant près de quinze siècles, une traduction latine bien connue a été faite par Adelard de Bath dans
le 12ème siècle mais c'était traduction en latin de Campano de 1482, le premier à être publié. La première
traduction anglaise est due à Henry Billingsley en 1570. Non moins important sont les commentaires sur les
éléments, si ce n'est que parce qu'ils ont été témoins des débats continus que les érudits ont eu sur le texte.
L'architecture, la discipline concernée avec la fabrication de formes, peut-être le plus profité de cette connaissance,
il est tout à fait évident, la relation entre l'architecture et la géométrie euclidienne; de Vitruve et jusqu'à
l'architecture moderne. Il est vrai que d'autres branches de géométrie qui ont résulté de la 17ème siècle, ont
affecté l'architecture comme la géométrie projective et la topologie mais cela reste loin d'être comparable à
l'utilisation écrasante de la géométrie euclidienne dans la conception architecturale à travers l'histoire. La
pertinence des méthodes euclidiennes pour la réalisation de l'architecture a été soulignée par de nombreux
spécialistes, et parmi les maçons et les charpentiers les procédures euclidiennes étaient répandues beaucoup
plus qu'on ne le pensait jusqu'ici. Nous pouvons croire que pendant le moyen âge, pour faire de l'architecture,
la lignes euclidiennes, facilement établis et visualisées, étaient le plus souvent une bonne alternative à des
calculs numérologiques plus complexes. Par conséquent, nous pouvons supposer qu'une culture euclidienne
associée à l'architecture existait depuis longtemps et qu'il a été prééminente parmi les masses et les travailleurs,
mais parmi les cercles raffinés de clients et des architectes la tradition assez différente de Vitruve
était également en vigueur. Cette tradition a été fondée sur l'idée platonique de Pythagore que les proportions
et les rapports numériques réglementés l'harmonie du monde, toute la théorie, dont le domaine est bien sûr
beaucoup plus large que la simple application d'architecture a été construit autour de la notion de proportion,
comme Platon compris dans le Timée. Il a été fondé sur l'analogie entre les rapports musicaux et visuels
établis par Pythagore: il a soutenu que des rapports numériques existaient entre les hauteurs de sons, obtenus
avec une certaine musique et l'architecture. En architecture, les numéros utilisés à des fins différentes: la
détermination des proportions globales dans les bâtiments et la construction modulaire des ordres architec-
118 | avec une certaine musique et l'architecture. En architecture, les numéros utilisés à des fins différentes: la
détermination des proportions globales dans les bâtiments et la construction modulaire des ordres architecturaux,
le premier considéré les dimensions réciproques de l'hauteur, la largeur et la longueur dans les chambres
ainsi que dans le bâtiment dans son ensemble. Le second était un module mis en place généralement à
partir de la moitié du diamètre de la colonne à partir de laquelle toutes les dimensions des ordres pourraient
être dérivés. L'ordre déterminé le système numérique à adopter, et donc chaque élément de l'ordre architectural
a été déterminée par un rapport au module. En effet, il était possible d'exprimer l'architecture par un
algorithme, simplement en mentionnant le style une formule numérique a été impliqué et les dimensions de
l'ordre pourrait être construit. Si l'on compare maintenant à nouveau ces procédures avec celles euclidiennes, il
semble que la différence entre les deux systèmes est significative. Selon Vitruve, multiplications et divisions
de nombres réglementées les formes et dimensions architecturales, mais en adoptant des constructions euclidiennes,
l'architecture et ses éléments ont été faite de lignes à l'aide d'un compas et une règle. La théorie
pythagoricienne des nombres et la géométrie euclidienne des lignes établies ainsi une polarité au sein de la
théorie de l'architecture, la dichotomie était une plus générale, étant donné que chaque forme peut être déterminée
soit par le traçage d'une ligne ou par calcul numérique. Pendant le moyen âge, la procédure euclidienne
et la procédure de Vitruve empiriquement coexistaient dans la pratique de la construction, pendant la Renaissance
l'avènement d'une théorie de l'architecture établi basé sur le texte de Vitruve, promus l'aspect de la
numérologie néo-pythagoricienne de l'architecture. Leon Battista Alberti, le plus important théoricien de
l'architecture de la Renaissance, était bien conscient de la géométrie euclidienne mais il était dans la tradition
orthodoxe de Pythagore-Vitruve de rapports numériques. Pour Alberti, le nombre était encore la source la plus
fondamentale. Il n'était pas jusqu'à ce que Francesco di Giorgio Martini que les définitions euclidiennes de
point, ligne et surface ont fait leur première apparition dans un traité d'architecture, mais plutôt d'une manière
non systématique. Serlio va ensuite plus loin, y compris dans son livre des définitions et des constructions
euclidiennes, principalement comme motif pour la perspective que pour l'architecture. Dans le 17ème siècle,
la situation subirait un changement important; avec le travail de Guarino Guarini, la géométrie euclidienne fait
son apparition ouvert dans un traité. Cela est dû à plusieurs raisons, d'abord il était un mathématicien qui lui a
fait obligés de considérer la géométrie euclidienne, et il a enseigné les mathématiques à Messine, où des
érudits Cela est dû à plusieurs raisons, d'abord il était un mathématicien qui lui a fait obligés de considérer la
géométrie euclidienne, et il a enseigné les mathématiques à Messine, où des érudits euclidiennes distingués
enseignaient. Pourtant, il est probable que son intérêt pour la géométrie euclidienne élargi, car il y rencontra
un milieu scientifique animé et en particulier le mathématicien François Millet de Chales, qui l'a influencé
profondément. Guarini dans son traité Architecttura Civile déclare ses intérêts géométriques en disant que,
depuis l'architecture en tant que discipline utilise des mesures dans chacune de ses activités, elle dépend de la
géométrie, et au moins veut savoir ses éléments primaires, et donc il s'est mis ces principes géométriques qui
sont les plus nécessaires. Le traité contient neuf définitions de point, ligne, surface, angle, angle droit, angle
aigu et des lignes parallèles; avec des chapitres consacrés à des surfaces, formes rectilignes et des formes
circulaires. Le tout premier traité continue essentiellement de cette manière avec les postulats, d'autres
principes et plusieurs transformations euclidiennes typiques, par exemple instructions géométriques comme la
façon de tracer une ligne d'un point afin de toucher le cercle. Le cinquième traité porte sur la discipline
euclidienne de géodésie: la manière de diviser et de transformer des formes planes en équivalents, certains
d'entre eux sont peu développées dans la lumière de leur application architecturale. La position de Guarini est
clairement géométrique, par opposition à la tradition arithmétique de Vitruve; dans Architecttura Civile le
cœur de la numérologie de Vitruve est éclipsé par l'approche géométrique alternative. Remarquablement la
procédure modulaire, enracinée en nombres, est remplacé par un système mixte où la dimension des éléments
architecturaux sont déterminés par des constructions géométriques et seulement dans certains cas, par des
opérations numériques. Guarini n'était pas le seul à faire revivre cette culture euclidienne dans la théorie
architecturale, le traité de l'architecte milanais Carlo Osio également intitulé Architecttura Civile, présente un
système pour les ordres qui est, encore plus géométrique que celui de Guarini. Avec Guarini et Osio la tradition
euclidienne est consciemment reconnu dans le domaine de la théorie savant et non plus appartenu à une
culture orale et empirique; avec la particularité des leurs traités où les géomètres Euclide et Chales sont
préconisés comme autorités architectural, même dans les pièces les plus typiquement architecturales. En
Architecttura Civile les éléments de géométrie assez souvent deviennent simplement les éléments de l'architecture,
par exemple un mur est une surface et un dôme est une demi-sphère, par conséquent, la conception
architecturale semble le plus souvent être identifiées avec le dessin architectural. Comme un véritable
| 119ture, par exemple un mur est une surface et un dôme est une demi-sphère, par conséquent, la conception
architecturale semble le plus souvent être identifiées avec le dessin architectural. Comme un véritable
géomètre Guarini décrit la production du projet plutôt que la production du bâtiment, sans tenir compte de
l'aspect constructif de l'architecture en faveur des descriptions détaillées techniques de dessin, à cet égard, il
est assez curieux que des outils de dessin sont en fait regroupés sous le titre : instruments architectural. Le
problème pour lui n'était pas la façon de construire mais comment dessiner, donc la géométrie euclidienne est
devenu une partie de la théorie architecturale, mais elle a aussi entraîné avec lui son essence linéaire. Nous
tenons également à mentionner que la raison pour laquelle la géométrie euclidienne était capable de passer de
la reconnaissance timide de Martini et Serlio à la grande inclusion de Guarini dans l'architecture est due aux
travaux de savants tels que Francesco Barozzi.
120 | ü
5.4. Géométrie affine et euclidienne
ü
5.4.1. Définition du groupe
Nous allons maintenant donner une catégorisation générale de ces opérations de transformations affines à
savoir les éléments du groupe affine qui est une extension du groupe linéaire. Un important sous-groupe du
groupe affine est le groupe euclidien aussi connu comme le groupe de symétrie de l'espace euclidien (ie le
groupe des isométries de l'espace euclidien); ce groupe de symétrie est cruciale pour la conception architecturale
et l'utilisation historique en architecture est tout à fait évidente. De ce point de vue (Programme d'Erlangen
de Félix Klein), nous lisons la géométrie euclidienne, la géométrie du groupe de symétries euclidien
comme une spécialisation de la géométrie affine. Tous les théorèmes affines s'appliquent avec le facteur
supplémentaire de la distance euclidienne, dont l'angle peut être déduite. Nous commençons par définir les
groupes linéaires et affines, puis nous allons définir la notion de symétrie qui nous permettra de définir le
groupe de symétrie de l'espace euclidien.
Représentation d'une transformation affine dans !2
d'un triangle à l'autre
Groupes linéaire et affine [5]
GLKE
Ø
O = : f
Ø
: E
Øö E
Ø
bijection> est le groupe linéaire Ksi E
Ø
= #
nï GLKE
Ø
O = GLnH#L O
GLnH#L = 8A œ Mn H#L A est inversible Hi.e. det A " 0L<
SLnH#L = 8A œ GLn H#L det A = 1< est le groupe spécial linéaire
GA HEL = 8 f : Eö E bijection< est le groupe affine
p : GA HELöGL KE
Ø
O, pH f L = f
Ø
est la projection canonique
T HEL = Ker p = : f œ GA HEL f
Ø
= id
E
Ø> est le groupe de translation, THELsous groupe de GA HEL
le groupe quotient GA HEL êTHEL est isomorphe à GLKE
Ø
O
le groupe de translation THEL est isomorphe à KE
Ø
, +O Hi.e. l' espace vectorielL
GA HEL = KE
Ø
, +O äGLKE
Ø
O produitsemi directe
Hi.e. f œ GA HEL ,
f peut être considéré comme un produitsemi direct d ' un vecteur de translation et une application linéaireL
| 121Le groupe euclidien
Comme nous avons défini le groupe affine comme le produit semi direct du groupe de translation et le groupe
linéaire général, nous allons maintenant définir le groupe euclidien comme le produit direct de semi du groupe
de translation et le groupe orthogonal. Le groupe orthogonal de la forme bilinéaire symétrique ou une forme
quadratique sur un espace vectoriel est le groupement d'opérateurs linéaires inversibles sur l'espace qui
permettent de préserver la forme. Dans cette recherche, nous allons seulement se concentrer sur le produit
scalaire sur l'espace euclidien comme notre forme bilinéaire alors le groupe orthogonal correspondant est un
ensemble de n matrices carrés orthogonales.
Représentation de transformation euclidienne !2
Groupe orthogonal [4]
j : !n ä!nö! est une forme bilinéaire symétrique et q : !n ö! forme quadratique
où j = X , \ est un produit scalaire
He1, ..., enL est une base orthonormée de !n
Hpar choix ou par le processus de Graham - SchmidtL
A = Aai, jE
1§i, j§n ï " i, j œ 81, ..., n< , ai, j = jIei
, e j
M = 1 si i = j et jIei
, e j
M = 0 if i " j
pour que A = Aai, jE
1§i, j§n
préserve j
ï jIei
, e j
M = jIAHeiL, AIe j
MM = jI⁄k=1
n ai,k ek
, ⁄l=1
n aj,l el
M = ⁄k,l=1
n ai,k aj,l jHek
, elL = ⁄k=1
n ai,k aj,k
où H
tA ALi, j = ⁄k=1
n ai,k aj,k = 1 si i = j et 0 si i " j ï t A A = In
ï On H!L = 8A œ GLnH!L
tA A = A
tA = In< est le groupe orthogonal
SOn H!L = 8A œ OnH!L det A = 1< est le groupe spécial orthogonal
On H!L Õ En Hle groupe euclidienL , On H!L = En › GLnH!L
Groupe euclidien [8]
En Õ GA HEL où E
Ø
= !n ï GLKE
Ø
O = GLnH!L , On KE
Ø
O = On H!L et SOn KE
Ø
O = SOn H!L
p : EnöGLKE
Ø
O, pH f L = f
Ø
est la projection canonique
THEL = Ker p = : f œ En f
Ø
= id
E
Ø> est le groupe de translation, THELsous groupe de En
le groupe quotient En êTHEL est isomorphe à OnKE
Ø
O
le groupe quotient En
+
êTHEL est isomorphe à S On KE
Ø
O
En = KE
Ø
, +O äOnKE
Ø
O produitsemi directe
En = : f œ GAHEL f
Ø
œ OnKE
Ø
O> est le groupe euclidien Hle groupe de symétrieL
En
+ = : f œ GAHEL f
Ø
œ S On KE
Ø
O> est le groupe de symétrie propre
Maintenant, avec l'espace affine, le groupe affine et le groupe euclidien définis, nous pouvons définir le plan
affine (et éventuellement la transformations affine).
122 | Application affine [5]
E, E' espaces affines et E
Ø
, E
Ø
' leurs espaces vectoriels directeurs E = Xo, e1, .., en\ et E' = Xo', e1 ', .., em '\
ïB = Jo e1 , ..., o en N et B' = Ko' e1 ' , ..., o' em 'O deux bases de E
Ø
et E
Ø
'
f : Eö E' est une application affine si $ o œ E et
f
Ø
: E
Øö E'
Ø
l' application linéaire attachée f HpL = f Jo + o p N = f HoL + f
Ø
Ho p L
f
Ø
can be represented by the transformation matrix A œ Mn,mH#L ï f HpL = o' + v
Ø
+ A x
Ø
, où v
Ø
= o' f HoL
nous identifions E avec #
n
avec l' origine o Hi.e. Eo = #
n
L et E' avec #
m avec l' origine o' Hi.e. Eo'
' = #
mL
p œ E = Eo = #
n ï p = x0 o + x1 e1 + ... + xn en ï o p = x1 o e1 + ... + xn o en ï p = x
Ø
dans Eo = #
n
x
Ø
= Hx1, ..., xnL avec les coordonnées cartésiennes
de p par rapport à l' origine o et la base :o e1 , ..., o en> de Eo = #
n
ï f HpL = f Jx
Ø
N = v
Ø
+ A x
Ø
il est commode d ' écrire cette représentation de f comme f
`
où p = x
Ø
œ E = Eo = #
n
est représenté par p
`
=
x
Ø
1
œ E
`
= #
n+1
f
`
: E
`
= #
n+1öE
`
' = #
m+1
, f
`
Hp
`
L = f
` x
Ø
1
= v
Ø
+ f
Ø
Jx
Ø
N =
A v
Ø
0 1
x
Ø
1
=
A x
Ø
+ v
Ø
1
si E = E' = !3 nous avons E
`
= E
`
' = !4
, Jo e1 , ..., o en N = Ko' e1 ' , ..., o' em 'O et o = o' = f HoL
" p œ E ïp
`
=
x1
x2
x3
1
, A =
a1,1 a1,2 a1,3
a2,1 a2,2 a1,3
a3,1 a3,2 a3,3
œ M3H!L est la transformation linéaire
f
`
: !4ö!4
, f HpL = f
`
Hp
`
L =
a1,1 a1,2 a1,3 v1
a2,1 a2,2 a2,3 v2
a3,1 a3,2 a3,3 v3
0 0 0 1
x1
x2
x3
1
=
a1,1 x1 + a1,2 x2 + a1,3 x3 + v1
a2,1 x1 + a2,2 x2 + a2,3 x3 + v2
a3,1 x1 + a3,2 x2 + a3,3 x3 + v3
1
=
q1
q2
q3
1
si A est une matrice orthogonale ï f est une transformation euclidienne
avec cette construction, nous sommes en mesure de transformer des formes dans l'espace euclidien !3
en
ajoutant simplement 1 comme quatrième coordonnée à un point (i.e. p =
x1
x2
x3
œ !3 Ø p
`
=
x1
x2
x3
1
œ !4
)
puis en appliquant le plan affine (représenter par une matrice augmentée de M4H!L) puis enlever enfin le 1 à
nouveau du vecteur l'image (i.e. f
`
Hp
`
L =
q1
q2
q3
1
œ !4 Ø f HpL =
q1
q2
q3
œ !3
)
| 123ü
5.4.2. Transformations affines isométriques (i.e. transformation euclidienne)
Symétrie de translation
La première transformation affine nous construisons est la translation aussi connu comme symétrie de translation.
La traduction est l'un des la transformation la plus connue et utilisée dans la conception architecturale à
travers son histoire. De copier éléments dans un, deux ou trois directions (par exemple, colonnes, poutres,
arcs, fenêtres, escaliers marches, etc) est la forme la plus basique et la plus simple de la composition des
formes et des motifs. La translation est une symétrie isométrique savoir qu'il garde la forme non déformée
après son application. La translation dans une direction a été utilisé dans l'organisation des éléments structurels
par exemple colonnes, poutres, arcs et des poutres etc alors que la traduction dans deux directions a été
le principal outil de conception de façade en créant un tableau à deux dimensions de fenêtres. La translation en
trois dimensions peut être utilisé dans l'étude de la composition volumétrique dans la première phase de la
conception. Les exemples de symétrie de translation en architecture sont très nombreux puisque l'on peut à
peine imaginer l'architecture sans translation. Classique styles architecturaux ont fait usage de la traduction
des colonnes et des arcs pour la conception des temples et des églises mais le style qui a poussé à sa limite
traduction comme un outil esthétique serait le haut modernisme.
Translation (symétrie isométrique propre) [5]
E = Xo, e1, e2, e3 \ = !3
, f : Eö E,
f HpL = t
v
ØHpL = p + v
Ø
est la translation, f est une isométrieó ° f HpL¥ = °p¥
E
`
= !4
, f
`
Hp
`
L est la matrice représentant la translation dans E
`
= !4
" p, v œ !4
, p
`
=
x1
x2
x3
1
et v
`
=
v1
v2
v3
1
ï f
`
Hp
`
L =
1 0 0 v1
0 1 0 v2
0 0 1 v3
0 0 0 1
x1
x2
x3
1
=
x1 + v1
x2 + v2
x3 + v3
1
Translation d'une forme dans l'espace euclidien !3
Nous allons utiliser le cylindre comme notre forme initiale et appliquer la traduction sur elle. Depuis affine (de
cartes linéaire prolongée) prend vecteurs comme des variables, nous définissons notre forme comme un
ensemble de vecteurs qui sont l'image de l'application paramétrique.
ImHcL = 9p œ !3 p = cHu, vL , où cHu, vL = HCosHuLL e1 + HSinHuLL e2 + I
v
2
M e3 , Hu, vL œ @0, 2 pDä@0, 2 pD=
soit v
Ø
=
t
H2, 2, 0L le vecteur de translation
t
v
Ø : Eö E la translation par le vecteur v
Ø
, t
v
ØHpL = H2 + CosHuLL e1 + H2 + SinHuLL e2 + I
v
2
M e3
Représentation d'une translation d'un cylindre dans l'espace euclidien !3
124 | Symétrie de rotation en architecture
la Symétrie de rotation est également fait partie des symétries isométriques, et est une technique de composition
très important dans la conception architecturale. Comme toutes les autres opérations algébriques, il a été
plus utilisé dans l'architecture classique que dans l'architecture moderne et contemporaine. Il a été poussé à
son comble avec le style architectural byzantin et son intérêt dans les structures en forme de dôme. L'architecture
islamique montre quelques-uns des exemples les plus élaborées de l'utilisation de la symétrie de rotation
non seulement dans les dômes, mais aussi dans les motifs graphiques utilisés pour décorer les façades et les
intérieurs.
Rotation (symétrie isométrique propre) [5]
Fix HrL = 8p œ E rHpL = p< est l' axe de rotation
E = Xo, e1, e2, e3 \ = !3
, r : Eö E,
rHpL = rJm + m p N = m + rq
Ø
Hm p L est la rotation de centre m et d ' angle q
rq
Ø
rotation vectorielle sur les axes x, y et z est représenté par la matrices orthogonales
r
Ø
x,q =
1 0 0
0 cosHqL -sin HqL
0 sin HqL cosHqL
, r
Ø
y,q =
cosHqL 0 sin HqL
0 1 0
-sin HqL 0 cosHqL
, r
Ø
z,q = mate
HuL =
cosHqL -sin HqL 0
sin HqL cosHqL 0
0 0 1
r
Ø
f,q,y = r
Ø
z,y r
Ø
y,q r
Ø
x,f préserve l' orientation correspondant à la rotation
dansle sens horaire avec les angles d ' Euler f, q, y avec la convention x, y, z
r
Ø
f,q,y =
cosHqL cosHyL -cosHfLsinHyL + sinHfLsinHqL cosHyL sinHfLsinHyL + cosHfLsinHqL cosHyL
cosHqLsinHyL cosHfL cosHyL + sinHfLsinHqLsinHyL -sinHfL cosHyL + cosHfLsinHqLsinHyL
-sinHqL sinHfL cosHqL cosHfL cosHqL
rotation générale autour d ' un axe m a où u
Ø
=
m a
°m a ¥
= Hu1, u2, u3L estson vecteur normalisé
r
Ø
m a ,q
=
cosHqL + u1
2
H1 - cosHqLL u1 u2H1 - cosHqLL - u3 sinHqL u1 u3H1 - cosHqLL + u2 sinHqL
u1 u2 H1 - cosHqLL + u3 sin HqL cosHqL + u2
2
H1 - cosHqLL u2 u3 H1 - cosHqLL - u1 sinHqL
u1 u3 H1 - cosHqLL - u2 sinHqL u2 u3 H1 - cosHqLL + u1 sinHqL cosHqL + u3
2
H1 - cosHqLL
E
`
= !4
, r
`
Hp
`
L est la matrice représentant la rotation dans E
`
= !4
" p, v œ !4
, p
`
=
x1
x2
x3
1
et v
`
=
v1
v2
v3
1
r
`
f,q,yHp
`
L =
cosHqL cosHyL -cosHfLsinHyL + sinHfLsinHqL cosHyL sinHfLsinHyL + cosHfLsinHqL cosHyL v1
cosHqLsinHyL cosHfL cosHyL + sinHfLsinHqLsinHyL -sinHfL cosHyL + cosHfLsinHqLsinHyL v2
-sinHqL sinHfL cosHqL cosHfL cosHqL v3
0 0 0 1
x1
x2
x3
1
et
r
`
u
Ø
,q
Hp
`
L =
cosHqL + u1
2
H1 - cosHqLL u1 u2H1 - cosHqLL - u3 sinHqL u1 u3H1 - cosHqLL + u2 sinHqL v1
u1 u2 H1 - cosHqLL + u3 sin HqL cosHqL + u2
2
H1 - cosHqLL u2 u3 H1 - cosHqLL - u1 sinHqL v2
u1 u3 H1 - cosHqLL - u2 sinHqL u2 u3 H1 - cosHqLL + u1 sinHqL cosHqL + u3
2
H1 - cosHqLL v3
0 0 0 1
x1
x2
x3
1
| 125Rotation d'une forme dans l'espace euclidien !3
Comme mentionné avant toute transformation affine est composé d'une transformation linéaire et une translation,
pour la rotation affine (i.e. la rotation + translation) nous devons choisir son centre et souvent ce centre
n'est pas à l'origine de !3
. Nous devons donc composer notre rotation avec une translation d'un vecteur
(vecteur entre l'origine et le centre de rotation) et utiliser son inverse comme le vecteur de translation de la
rotation affine.
Nous allons utiliser le cylindre à nouveau comme notre forme initiale à laquelle on applique la rotation.
ImHcL = 9p œ !3 p = cHu, vL , où cHu, vL = HCosHuLL e1 + HSinHuLL e2 + I
v
2
M e3 , Hu, vL œ @0, 2 pDä@0, 2 pD=
soit m =
t
I0, 0, p
2
M , a =
t
I0, -3, p
2
M œ !3
tel que m a est l' axe de rotation, q = p
2
l' angle de rotation
soit m O =
t
I0, 0, -
p
2
M le vecteur de translation, afin de coïncider l' origine avec le centre de la rotation
soit u
Ø
=
m a
°m a ¥
est le vecteur normalisé de l' axe de rotation
t
m O
HpL = H0 + CosHuLL e1 + H0 + SinHuLL e2 + II v
2
M -
p
2
M e3 est la forme translatée
soit v
Ø
=
t
I0, 0, p
2
M = O m le vecteur de translation de la rotation affine
r : Eö E est la rotation d ' axe m a et angle q = p
2
" p œ ImHcL, rJt
m O
HpLN = I
p
2
-
v
2
M e1 + SinHuL e2 + I
p
2
+ CosHuLM e3
Représentation d'une rotation d'un cylindre le long d'un axe dans l'espace euclidien !3
126 | Symétrie de réflexion (bilatéral)
La symétrie bilatérale avec la translation est l'opération algébrique la plus utilisée dans la conception architecturale.
Historiquement, la majorité des bâtiments étaient symétriques autour d'un axe; spécialement, les
bâtiments importants, puisque cette esthétique symétrique donné un sens d'équilibre et de puissance. Cette
technique de composition utilisé sur tous échelle dans la conception architecturale de la plus petite des
meubles aux grands plans d'urbanisme. La raison de cet intérêt dans la symétrie bilatérale vient de la croyance
en la beauté du corps humain qui est bien sûr symétrique, et que, puisque Dieu a créé l'homme à son image
donc symétrie a une certaine forme de divinité en elle. Les exemples de la symétrie bilatérale est beaucoup
plus évidente dans l'architecture classique que dans l'architecture moderne, mais elle reste bien présente.
Seulement à la fin du 20ème siècle, avec l'intérêt pour des formes courbes que cette importance de la symétrie
bilatérale diminue considérablement, donnant lieu à des effets plus cinématographique de la dynamique plutôt
que l'ancienne intérêt dans l'équilibre statique.
Représentation de l'utilisation symétrie de réflexion (bilatéral) dans l'architecture
Réflexion (symétrie isométrique) [5]
s : Eö E, réflexion affine, s
Ø
: E
Øö E
Ø
, réflexion vectoriel
F Õ E sous - espace affine dont le sous - espace vectoriel directeur est F
Ø
,
G Õ E sous - espace affine dont le sous - espace vectoriel directeur est G
Ø
E
Ø
= F
Ø
$G
Ø ï " p œ E ,
s
Ø
est la réflexion vectorielle de E
Ø
par rapport à F
Ø
parallèle à G
Ø
,
où v
Ø
= v1
Ø
$v2
Ø ï s
Ø
Jv
Ø
N = v1
Ø
$J-v2
Ø
N , s
Ø
G
Ø = -id
G
Ø
ï G
Ø
= ker Js
Ø
+ id
E
ØN et F
Ø
= ker Js
Ø
- id
E
ØN ï E
Ø
= ker Js
Ø
+ id
E
ØN $ker Js
Ø
- id
E
ØN
ï s
Ø
Js
Ø
N = id
E
Ø Hi.e. involutionL , FixHsL = F
| 127Réflexion (symétrie isométrique) [5]
E = Xo, e1, e2, e3 \ = !3
, F = Xo, e1, e2 \ = !2
, G = Xo, e3 \ = !
s : Eö E, sHpL = sJo + o p N = o + s
Ø
Ho p L est la réflexion de p par rapport à F parallèle à G
Ø
s
Ø
est la réflexion vectorielle de o p
E
`
= !4
, s
`
Hp
`
L est la matrice représentant la réflexion dans E
`
= !4
" p, v œ !4
, p
`
=
x1
x2
x3
1
et v
`
=
v1
v2
v3
1
s
`
Hp
`
L =
-1 0 0 v1
0 1 0 v2
0 0 1 v3
0 0 0 1
x1
x2
x3
1
=
-x1 + v1
x2 + v2
x3 + v3
1
la réflexion sur le plan y - z
s
`
Hp
`
L =
1 0 0 v1
0 -1 0 v2
0 0 1 v3
0 0 0 1
x1
x2
x3
1
=
x1 + v1
-x2 + v2
x3 + v3
1
la réflexion sur le plan x - z
s
`
Hp
`
L =
1 0 0 v1
0 1 0 v2
0 0 -1 v3
0 0 0 1
x1
x2
x3
1
=
x1 + v1
x2 + v2
-x3 + v3
1
la réflexion sur le plan x - y
Réflexion d'une forme dans l'espace euclidien !3
Nous allons utiliser le cylindre à nouveau comme notre forme initiale à laquelle nous appliquons la réflexion
affine.
ImHcL = 9p œ !3 p = cHu, vL , où cHu, vL = HCosHuLL e1 + HSinHuLL e2 + I
v
2
M e3 , Hu, vL œ @0, 2 pDä@0, 2 pD=
soit v
Ø
=
t
H0, -2, 0L le vecteur de translation de la réflexion affine
s : Eö E la réflexion affine par rapport au plan x - z
" p œ ImHcL, sHpL = CosHuL e1 + H-2 - SinHuLL e2 + I
v
2
M e3
Représentation d'une réflexion d'un cylindre dans l'espace euclidien !3
128 | ü
5.4.3. Transformation affine non-isométrique
Homothétie (mise à l'échelle)
Le deuxième type de transformation affine nous construisons est l'homothétie et mise à l'échelle non uniforme.
Mise à l'échelle comme une symétrie est non isométrique à savoir que la forme est déformée après son application.
Historiquement, ce type d'opérations algébriques n'a pas été utilisé autant que les symétries isométriques
comme la translation et la rotation mais on peut encore le voir dans la répétition de certains éléments architecturaux
de différentes tailles, souvent comme une technique de décoration. Homethety peut être vu clairement
dans la pagode chinoise traditionnelle comme chaque calque du toit a la même forme que la précédente, mais
de plus petite taille ou dans la tour de Pise où les colonnes sont plus petits à chaque niveau. Homothétie est
beaucoup plus utilisé aujourd'hui en raison de l'intérêt dans des formes courbes, ce qui est visible lorsque l'on
veut créer un tableau à deux dimensions d'éléments sur une surface courbe, par exemple pavage sur une façade
courbe ou d'un toit. En raison de la courbure, chaque tuile ou élément sera similaire aux autres, mais à une
échelle différente pour une meilleure approximation de la surface courbe. Homethety est poussé à sa limite
esthétiquement avec l'utilisation des opérations algorithmiques qui automatise la mise à l'échelle des éléments
donnant le sentiment cinématographique du mouvement des éléments variables.
Représentation d'une homothétie dans !2
d'un triangle à l'autre
Homothétie (symétrie non isométrique) [5]
Fix HhL = 8p œ E hHpL = p<
E = Xo, e1, e2, e3 \ = !3
, h : Eö E,
hHpL = hJm + m p N = m + h
Ø
Hm p L = m + l id
E
ØHm p L est l' homothétie de centre m et un rapport l
h
Ø
= l id
E
Ø est l' homothétie vectorielle Hmise à l' échelle uniformeL
m hHpL = J
m hHpL
m p N m p ï le rapport l = m hHpL
m p
E
`
= !4
, h
`
Hp
`
L est la matrice représentant l' homothétie dans E
`
= !4
" p, v œ !4
, p
`
=
x1
x2
x3
1
et v
`
=
v1
v2
v3
1
ï h
`
Hp
`
L =
l 0 0 v1
0 l 0 v2
0 0 l v3
0 0 0 1
x1
x2
x3
1
=
l x1 + v1
l x2 + v2
l x3 + v3
1
h
`
Hp
`
L =
l1 0 0 v1
0 l2 0 v2
0 0 l3 v3
0 0 0 1
x1
x2
x3
1
=
l1 x1 + v1
l2 x2 + v2
l3 x3 + v3
1
est la mise à l' échelle non uniforme
| 129Homothétie (et mise à l'échelle non uniforme) d'une forme dans l'espace euclidien !3
Comme mentionné ci-dessus toute transformation affine est composé de une transformation linéaire et une
translationtion, pour l'homothétie (et mise à l'échelle non uniforme) nous avons besoin de choisir son centre et
souvent ce centre n'est pas l'origine de !3
. Nous devons donc composer notre homothetie avec une translation
par un vecteur (vecteur entre l'origine et le centre de l'homothétie) et utiliser son inverse comme le vecteur de
translation de l'homothétie affine.
Homothetie
ImHcL = 9p œ !3 p = cHu, vL , où cHu, vL = HCosHuLL e1 + HSinHuLL e2 + I
v
2
M e3 , Hu, vL œ @0, 2 pDä@0, 2 pD=
soit m =
t
I0, 0, p
2
M le centre de l' homothetie
soit m O =
t
I0, 0, -
p
2
M le vecteur de translation, afin de coïncider l' origine avec le centre de l' homothety
t
m O
HpL = H0 + CosHuLL e1 + H0 + SinHuLL e2 + II v
2
M -
p
2
M e3 est la forme translatée
soit v
Ø
=
t
I0, 0, p
2
M = O m le vecteur de translation de l' homothety
h : Eö E est l' homothétie de centre o et de rapport 1
2
" p œ ImHcL, hJt
m O
HpLN =
1
2
CosHuL e1 +
1
2
SinHuL e2 + I
1
2
II v
2
M -
p
2
M +
p
2
M e3
Non uniform scaling
ImHcL = 9p œ !3 p = cHu, vL , où cHu, vL = HCosHuLL e1 + HSinHuLL e2 + I
v
2
M e3 , Hu, vL œ @0, 2 pDä@0, 2 pD=
soit o =
t
I0, 0, p
2
M le centre de la mise à l' échelle non uniforme
soit m O =
t
I0, 0, -
p
2
M le vecteur de translation,
afin de coïncider l' origine avec le centre de la mise à l' échelle non uniforme
t
m O
HpL = H0 + CosHuLL e1 + H0 + SinHuLL e2 + II v
2
M -
p
2
M e3 est la forme translatée
soit v
Ø
=
t
I0, 0, p
2
M = O m le vecteur de translation de la mise à l' échelle non uniforme
h : Eö E est la mise à l' échelle non uniforme de centre o et rapports l1 = 2, l2 =
3
2
et l3 =
1
4
" p œ ImHcL, hJt
m O
HpLN = 2 CosHuL e1 +
3
2
SinHuL e2 + I
1
4
II v
2
M -
p
2
M +
p
2
M e3
Représentation d'une homothetie et une mise à l'échelle non uniforme d'un cylindre dans l'espace euclidien !3
130 | ü
5.4.4. Projections orthogonales
Maintenant, nous allons examiner certains des transformation affine les plus traditionnellement utilisé dans
l'architecture à savoir les projections affines. les projections orthogonales affines sont généralement connus
dans l'architecture que le plan, élévation, coupe, et il n'est pas nécessaire de souligner l'importance de ces
types de représentations de formes dans l'architecture. En fait, les projections orthogonales sont un type
particulier de projections affines où la direction de la projection est perpendiculaire au sous-espace affine sur
lequel nous projetons. Pour la perspective, nous avons besoin de comprendre quelques notions de la géométrie
projective afin de la définir, mais il y a aussi une version affine qui la plus souvent utilisée dans l'architecture.
Ces projections orthogonales affine: le plan, l'élévation et la section sont connus comme le dessin technique
d'un bâtiment ou un projet qui correspond à la définition de l'architecture. Ils sont utilisés pour développer une
idée de conception en une proposition cohérente, de communiquer des idées et des concepts et convaincre le
client des mérites d'une conception et de permettre à un entrepreneur pour le construire. Ils sont aussi utilisés
comme un dossier du travail accompli, et de faire un enregistrement d'un bâtiment qui existe déjà.
Représentation de la projection orthographique architectural
Projection [5]
r : Eö E, projection affine , r
Ø
: E
Øö E
Ø
, projection vectoriel
F Õ E sous - espace affine dont le sous - espace vectoriel directeur est F
Ø
,
G Õ E sous - espace affine dont le sous - espace vectoriel directeur est G
Ø
E
Ø
= F
Ø
$G
Ø ï " p œ E , F › Kp + G
Ø
O = 8rHpL< un point Ki.e. la projection de p sur F parallèle à G
Ø
O
r
Ø
est la projection vectorielle de E
Ø
sur F
Ø
parallèle à G
Ø
, où v
Ø
= v1
Ø
$v2
Ø ï r
Ø
Jv
Ø
N = v1
Ø
, r
Ø
F
Ø = id
F
Ø
ï G
Ø
= ker r
Ø
et F
Ø
= ker Jr
Ø
- id
E
ØN ï E
Ø
= ker r
Ø
$kerJr
Ø
- id
E
ØN
ï r
Ø
Jr
Ø
N = r
Ø
, FixHrL = F et rHEL = F
| 131Projection [5]
E = Xo, e1, e2, e3 \ = !3
, F = Xo, e1, e2 \ = !2
, G = Xo, e3 \ = !
r : Eö E, rHpL = rJo + o p N = o + r
Ø
Ho p L la projection de p sur F parallèle à G
Ø
r
Ø
est projection vectorielle de o p
E
`
= !4
, r
`
Hp
`
L est la matrice représentant de la projection dans E
`
= !4
" p, v œ !4
, p
`
=
x1
x2
x3
1
et v
`
=
v1
v2
v3
1
r
`
Hp
`
L =
1 0 0 v1
0 1 0 v2
0 0 0 v3
0 0 0 1
x1
x2
x3
1
=
x1 + v1
x2 + v2
0 + v3
1
projection sur le plan x - y
r
`
Hp
`
L =
0 0 0 v1
0 1 0 v2
0 0 1 v3
0 0 0 1
x1
x2
x3
1
=
0 + v1
x2 + v2
x3 + v3
1
projection sur le plan y - z
r
`
Hp
`
L =
1 0 0 v1
0 0 0 v2
0 0 1 v3
0 0 0 1
x1
x2
x3
1
=
x1 + v1
0 + v2
x3 + v3
1
projection sur le plan x - z
Affine projection orthogonale d'une forme dans l'espace euclidien !3
Nous allons utiliser le cylindre à nouveau comme notre forme initiale à laquelle on applique la projection
affine.
ImHcL = 9p œ !3 p = cHu, vL , où cHu, vL = HCosHuLL e1 + HSinHuLL e2 + I
v
2
M e3 , Hu, vL œ @0, 2 pDä@0, 2 pD=
soit v
Ø
=
t
H1, 1, 0L le vecteur de translation de la projection affine
r : Eö E est la projection affine sur le plan x - z
" p œ ImHcL, rHpL = CosHuL e1 + 3 e2 + I
v
2
M e3
Représentation d'une projection orthogonale d'un cylindre dans l'espace euclidien !3
132 | ü
5.4.5 Conception en utilisant la géométrie affine
Maintenant que nous avons défini ces transformation affine essentiel, nous allons maintenant montrer comment
lesutiliser comme outils pour la conception, dans la partie qui suit, nous allons montrer quelques projets
architecturaux où l'idée principale de la conception a été basée sur la transformation affine. L'idée était de
créer un bâtiment de faible hauteur qui sera composée d'une série des composants, ces composants peuvent
être considérés comme des ensembles de vecteurs ou de points qui seront progressivement transformé le long
de la longueur du bâtiment, en utilisant des transformations affine comme mise à l'échelle et translations.
Représentation de la série des composants qui transforment le long de la longueur du bâtiment
Représentation de la forme architecturale générée à partir des série de composants
| 133Plus de conception utilisant des transformations affines
Maintenant que nous avons montré le principe de base, nous allons montrer des conceptions plus élaborées
utilisant cette méthode des transformations affines.
Représentation de la manière dont ces éléments se transforment dans le plan et dans la coupe
Représentation du bâtiment de faible hauteur conçu par des transformations affines
134 | Plus de conception utilisant des transformations affines
Dans ces deux exemples suivants, les transformations des composantes sont liées à certaines propriétés
ambiantes des activités, qu'ils abriteront en termes de programme architectural. Ces propriétés ambiantes n'ont
pas été testés en termes de ingénierie environnementale, mais notre accent est mis sur la méthode géométrique
en utilisant des transformations affines et le lien avec les ambiances est plus hypothétique. Dans ce premier
exemple, les transformations sont liées à la chaleur des activités dans chacun des composants, allant d'un
extrême à l'autre.
Représentation de la manière dont les composants ont différentes températures
Représentation des différentes activités intérieures avec leurs différentes températures
| 135Plus de conception utilisant des transformation affines
Dans ce second exemple, c'est le flux d'air chaud qui est stimulé par les différentes formes de composants qui,
comme dans le premier exemple créerait des différents espaces ambiantes pour différentes activités.
Représentation de la manière dont les composants auront des flux d'air différents
Représentation des différentes ambiances provoquées par les différentes composantes
136 | Plus de conception utilisant des transformation affines
Dans ce qui suit, nous allons présenter une autre application de transformation affine, cette fois au lieu de
travailler à l'échelle du bâtiment, nous allons transformer les composants à l'échelle éléments de façade pour
créer des pavages. Dans cet exemple, il existe deux principales transformations affines: le premier est sur le
réseau où se trouve le composent, ce qui à son tour déforme le composant elliptique et la seconde est la
rotation de ce composant.
Représentation de la transformation affine du réseau et le composant
Représentation du motif généré en utilisant une transformation affine sur le réseau et le composant
| 137ü
5.5. Géométrie projective
ü
5.5.1. Espace projectif et groupe projectif
Notre étude de symétrie nous a amené à comprendre la géométrie euclidienne comme l'étude des propriétés
géométriques invariantes par le groupe euclidien (de transformations euclidiennes) comme une spécialisation
de géométrie affines qui en elle-même l'étude des propriétés géométriques invariantes par le groupe affine
(des transformations affines). De même, la géométrie projective serait l'étude des propriétés géométriques
invariantes par le groupe projectif (des transformations projectives); naturellement, la géométrie projective a
un contexte différent avec des notions telles que l'espace projectif, homographie, coordonnées homogènes. Un
aspect important de la géométrie projective qui est différente de la géométrie euclidienne est que les lignes
parallèles se rencontrent aux points à l'infini; cette notion a son origine dans l'invention de la perspective
linéaire par des artistes de la Renaissance. En géométrie euclidienne, les angles et les distances sont invariantes
par transformations euclidiennes, en géométrie affine, colinéarité, le parallélisme et des rapports de
distance le long de lignes parallèles sont invariantes par transformation affine. En géométrie projective, la
structure de l'incidence et de la relation de conjugués harmonique projective (entre autres) sont conservées
sous des transformations projectives. Avant de discuter en détail la perspective, nous allons d'abord définir
l'espace projectif et la transformation projective, qui est plus radical dans son expression que les transformations
affine et euclidienne, exprimé par une translation et une transformation linéaire.
Représentation du plan projectif réel comme une sphère S
2
où les points antipodaux sont identifiés
Espace projectif [5]
E
Ø
est un # - espace vectoriel et # est un corps commutatif et #
* = #\ 80<
#
* äE
Ø
\ 80<ö E
Ø
\ 80<
, Jl, x
Ø
Nö l.x
Ø
= l x
Ø
est une action de groupe
PKE
Ø
O = E
Ø
\ 80<ì#
*
est l' espace projectif de E
Ø
Kl' ensemble de droites de E
Ø
O
x = PHxL œ PKE
Ø
O est un point dansl' espace projectif de E
Ø
, x = OrbHxL = :y
Ø
œ E
Ø
\ 80< y
Ø
= l.x
Ø
>
dim PKE
Ø
O = dim E
Ø
- 1
si E
Ø
= !n+1ïPKE
Ø
O = PnH!L l' espace projectif réel et x = @x0 : ... : xnD les coordonnées homogènes
138 | Espace projectif comme une variété [9]
Ui Õ PnH#L ouvert, Ui = 8@x0 : ... : xnD xi " 0<
pour i = 0, ..., n où PnH#L = ‹0§i§nUi et HUi
, jiL est une carte de PnH#L
ji
: Ui Õ PnH#Lö #
n
, @x0 : ... : xnD ö x0
xi
, ..,
xi
xi
fl
, ..,
xn
xi
est un difféomorphisme lisse
toutesles cartes de l' atlas maximal $ = HUi
, jiLiœI
sont compatibles ï PnH#L est une variété différentiable
Sous-espace projectif [5]
F
Ø
Õ E
Ø
sous - espace vectoriel ï PKF
Ø
O Õ PKE
Ø
O est le sous - espace projectif
si H
Ø
est un hyperplan vectorielKi.e. codim H
Ø
= 1O ïPKH
Ø
O est un hyperplan projectif
S = 8p0, .., pk< est un ensemble de points de PKE
Ø
O ïXS\ est le plus petit sous -
espace projectif de PKE
Ø
O contenant S
p0 = PHDiL, où Di = # vi
Ø
est une droite vectorielle E
Ø
et F
Ø
= vectJ:vi
Ø
, i = 0, ..., k>N
pour i = 0, ..., k,
vi
Ø
sont linéairement indépendantï pi = PHDiL = PJ# vi
Ø
N sont projectivement indépendants
Transformation projective (homographie) [5]
E
Ø
, E
Ø
' deux espaces vectoriels, PKE
Ø
O, PKE
Ø
'Oleurs espaces projectifs associés
f
Ø
: E
Øö E
Ø
' est une application linéaire continue ï " D
Ø
Õ E
Ø
est une droite vectorielle
f
Ø
KD
Ø
O = 0
Ø
E
Ø
'
si D
Ø
Õ ker f
Ø
ou f
Ø
KD
Ø
O = D'
Ø
une droite vectorielle de E
Ø
'
ï PKf
Ø
O : PKE
Ø
O
\P ker f
Ø ö PKE
Ø
'O, PKf
Ø
O HDL = PKf
Ø
KD
Ø
OO = P KD'
Ø
O est une application projective
si f
Ø
est un isomorphisme ï PKf
Ø
O est une transformation projective Hou une homographieL
Groupe projectif [5]
G P KE
Ø
O =
:PKf
Ø
O : E
Øö E
Ø
, transformation projective> est le groupe projectif muni de la loi PKf
Ø
OÎPJg
Ø
N = PKf
Ø
Î g
Ø
O
P : GLKE
Ø
Oö G P KE
Ø
O est un groupe de isomorphism
ZKGLKE
Ø
OO = :l.id
E
Ø , l œ #
*
> isomorphe à #
* ïGLKE
Ø
Oì#
*
.id
E
Ø = PGL KE
Ø
O est le groupe projectif
si E
Ø
= #
n+1ï GLn+1 H#Lë#
* = PGLn+1H#L est le groupe linéaire projective
Le perspective HprojectiveL est une homographie qui est un élément du groupe projectif
| 139ü
5.5.2. Bref historique de la perspective
Le système de perspective que nous tenons pour acquis aujourd'hui est une invention relativement récente
dans l'histoire de l'art. Avant le 14ème siècle, il n'y avait presque aucune tentative de dépeindre de façon
réaliste le monde en trois dimensions dans l'art dans la manière dont nous sommes maintenant habitués à voir.
L'art des périodes byzantines, médiévales et gothiques riches comme il était, il n'a fait aucune tentative pour
créer l'illusion de la profondeur et de l'espace. Il n'était pas jusqu'à ce que les peintres de la pré-renaissance,
comme Giotto et Duccio qu'une idée précoce de perspective a été en cours d'expérimentation. Ils ont utilisé les
ombres à grand effet de créer une illusion de profondeur, mais il était encore loin d'être le genre de perspective
que nous connaissons aujourd'hui. La première image connue à utiliser la perspective linéaire a été créé par la
polymathe Filippo Brunelleschi, il dépeint le baptistère de Florence à partir de la grille d'entrée de la cathé-
drale inachevée. Le système de la perspective linéaire projeté l'illusion de profondeur sur un plan à deux
dimensions par l'utilisation de points de fuite à laquelle toutes les lignes convergent, au niveau des yeux sur
l'horizon. Masaccio a été le premier grand peintre du début de la Renaissance qui a démontré commandement
intégral des nouvelles règles de la perspective, les personnages de ses peintures ont un volume et les bâtiments
et le paysage se retirent de façon réaliste dans la distance. Mosaccio est considéré aujourd'hui comme l'initiateur
du nouveau style de réalisme florentin. À la fin du 15ème siècle, les artistes étaient en commande totale
de la perspective et ont réussi à créer dans leur art un monde beau et réaliste. Derrière ces changements dans
les méthodes artistiques et l'utilisation de la perspective était un désir renouvelé à décrire la beauté de la nature
et de démêler sa beauté mathématique, avec les œuvres des maîtres de la Renaissance comme Léonard de
Vinci. Les développements dans la perspective linéaire n'ont pas été seulement limitées à la Renaissance
italienne, mais aussi la Renaissance du nord dans les œuvres des maîtres hollandais tels que Jan van Eyck,
dont les peintures ont exprimé un haut niveau de détails en perspective. Cette corrélation entre les arts et les
mathématiques a atteint son apogée avec le développement de la géométrie projective ayant ses origines dans
la théorie de la perspective; les mathématiciens et les artistes étaient intéressés par les principes qui ont régi
cette technique artistique. En particulier, l'intérêt pour les lignes de vue et les lignes parallèles qui convergent
à un point de fuite, qui est connu plus tard comme le points à l'infini. La théorie de la perspective représente
un moment unique où l'architecture, l'art et les mathématiques ont partagé un intérêt commun directe, un
moment où de nouveaux concepts en mathématiques ont été créés à partir des origines artistiques. Le mathé-
maticien et architecte Girard Desargues était l'un des premiers à poser les bases de ce qui sera la géométrie
projective; sur la base de son travail sur la perspective. Desargues introduit une nouvelle technique pour
l'élaboration de la perspective sans attirer le point de fuite (i.e. qu'ils se situent en dehors du plan de l'image);
contrairement aux techniques de la perspective linéaire communes qui commencent par dessiner les points de
fuite. Cette technique repose sur des mesures de l'objet, et des constructions des échelles dans le plan de
l'image, ces échelles sont construits à partir des mesures et sont utilisés de manière à préserver la distance et la
dimension dans l'image. Une fois les échelles ont été établies, l'artiste peut tout simplement utiliser un compas
et une règle pour décrire le sujet souhaité de manière appropriée en perspective. Suite à cette construction de
la perspective, Desargues crée son théorème qui stipule que si trois lignes droites reliant les sommets correspondants
de deux triangles, les trois intersections des paires de côtés correspondants se trouvent sur une ligne
droite.
Représentation du système des miroirs de Filippo Brunelleschi pour construire la perspective
140 | Théorème de Desargues
théorème de Desargues (affine) théorème de Desargues (projective)
Théorème de Desargues (affine) [5]
soit HA B CL et HA' B' C'L deux triangles dans un plan affine E
tel que A " A', B " B' and C " C' , HB CL êê HB' C'L, HC AL êê HC' A'L and HA BL êê HA' B'L
ïHA A'L, HB B'L and HC C'Lsont parallèles ou concurant
Théorème de Desargues (projective) [5]
soit A, B, C Het A', B', C'L trois points projectivement indépendants dans un plan projectif
tel que A " A', B " B' et C " C' , P = HB CL › HB' C'L, Q = HC AL › HC' A'L et R = HA BL › HA' B'L
alors P, Q, R sont alignés óHA A'L, HB B'L et HC C'Lsont concurant
Représentation de la pyramide visuelle de Alberti montrant le théorème de Desargues
Il existe un lien clair entre ce théorème et la perspective linéaire ceci peut être vu dans l'image représentant la
technique de la pyramide visuelle d'Alberti. Ici, le triangle A B C se trouve dans le plan de sol (la base de la
pyramide), le triangle A ' B ' C' se trouve dans le plan de l'image, le point E au cours de laquelle la lignes de
vue (raccordement sommets correspondants) se rencontrent est l'œil de la l'artiste , la sommet de la pyramide
visuelle. Ce théorème établir le lien entre les études de la perspective à la géométrie projective moderne.
Considérons par exemple l'intersection HA BL › HA' B'L si elle est dans le plan contenant les deux lignes, c'est
garanti par le théorème, Cependant, si les droites sont parallèles, dans le plan dans lequel ils se trouvent, ils ne
se coupent dans ce plan. Cependant, le théorème garantit ces lignes se croisent; Desargues introduit un point
où deux lignes parallèles se croisent à savoir le point à l'infini.
| 141ü
5.5.3. Points à l'infini
Depuis l'époque de Desargues, la géométrie projective a été élargi pour devenir un champ unique en mathématiques
comme nous l'avons montré avec ses propres réglages et opérations (espace projectif, transformations
projectives), mais cet espace projectif moderne peut être développée de la même manière qu'il était en
géométrie projective classique. Nous avons construit plus tôt l'espace projectif réel comme l'ensemble des
droites de l'espace euclidien, maintenant, nous allons montrer comment ce connecter à l'idée des lignes de vue
de l'art de la perspective. Nous allons nous concentrer uniquement sur l'espace euclidien !3
et le plan projectif
réel P2H!L et puis nous allons donner la définition générale formelle de l'espace projectif abstrait. Voyons
d'abord prétendons que sur une ligne de vue, il est seulement un point que l'on voit, l'objet qui est le plus
proche contiendra ce point, donc pour une ligne de vue que vous choisissez, le résultat est que vous voyez un
seul point correspondant à la ligne de vue comme on le voit dans la formulation suivante. Voyons d'abord
prétendons que sur une ligne de vue, il y a seulement un point que l'on voit, l'objet qui est le plus proche
contiendra ce point, donc pour une ligne de vue que vous choisissez, le résultat est que vous voyez un seul
point correspondant à la ligne de vue comme on le voit dans la formulation suivante.
!* ä !3
\ 80<ö !3
\ 80<
, Jl, x
Ø
Nö l.x
Ø
= l x
Ø
est une action de groupe,
P2H!L = !3
\ 80< ë!*
est le plan projectif de !3
x
Ø
= Hx1, x2, x3L est équivalent à l.x
Ø
= l x
Ø
= y
Ø
= Hl x1, l x2, l x3L Hi.e. ilsse trouvent sur la même ligne de vueL
x = PHxL œ P2H!L est un point dansle plan projectif, x = OrbHxL = :y
Ø
œ !3
y
Ø
= l.x
Ø
>
Nous procédons maintenant à construire le plan projectif réel; Imaginez que vous êtes debout à l'origine et il y
a une toile dans l'espace euclidien !3
au niveau du plan y = 1. Vous pouvez regarder dans n'importe quelle
direction et vous verrez un point situé sur la ligne de vue; cette ligne de vue lorsqu'il est étendu à l'infini ferait
l'une des deux choses, soit elle coupe le plan y = 1 ou elle est parallèle à savoir dans y = 0 plan. Si la ligne
coupe le plan y = 1 au point d'intersection, par exemple Hx1, 1, x3L dans l'espace euclidien !3
alors Hx1, 1, x3L
est dans le point d'intersection dans le plan projectif. Toutefois, si la ligne est parallèle au plan y = 1, le point
dans le plan projectif d'intersection serait Hx1, 0, x3L (i.e. le point à l'infini). Cela nous indique que le plan
projectif est l'union de l'ensemble des points dans le plan y = 1 (isomorphe à !2
) et l'ensemble de points à
l'infini, donc P2H!L = !3 ‹ 8points à ¶<. Maintenant, nous définissons les lignes dans le plan projectif
Hi.e. par l' équation a X1 + b X3 + c = 0L, en accord avec notre toile y = 1 plan, si nous pensons d'une ligne dans
ce plan compte tenu de notre relation d'équivalence, nous pouvons prendre le point Hx1 ê x2 , 1, x3 ê x2L en tant
que représentant de certain point Hx1, x2, x3L dans !3with HX1 = x1 ê x2 and X3 = x3 ê x2L. De cette façon,
l'équation de la ligne a X1 + b X3 + c = 0 est bien définie dans le plan projectif puisque
a Hx1 ê x2L + b Hx3 ê x2L + c = a x1 + b x3 + c x2 = 0 et a x1 + b x3 + c x2 = 0 est bien défini dans le plan projectif.
C'est parce que tout point Hl x1, l x2, l x3L est une solution de l'équation puisque
a l x1 + b l x3 + c l x2 = lHa x1 + b x3 + c x2L = l .0 = 0. Maintenant, nous regardons ce qui se passe aux droites
parallèles dans le plan projectif. Nous savons que les lignes parallèles ont la même pente si l'on considère les
lignes X3 = HaêbL X1 + c = 0 et X3 = HaêbL X1 + d = 0 avec HaêbL la pente en commun, maintenant en multipliant
les équations par b et substitution par X1 = x1 ê x2 et X3 = x3 ê x2, nous obtenons les deux équations
b x3 - a x1 - c b x2 = 0 et b x3 - a x1 - d b x2 = 0. Pour trouver le point d'intersection nous supposons x2 = 1, ce
qui nous donne les équations x1 = HbêaL - Hc bêaL x2 et x1 = HbêaL - Hd bêaL x2 qui donne le point d'intersection
Hbêa, 0, 1L, Cela signifie que les points d'intersections des lignes parallèles en effet se situent sur le plan y = 0
(i.e. à l'infini) [10]. Maintenant que nous avons compris le construction mathématique de la perspective
linéaire du point de vue de la géométrie projective moderne, nous allons maintenant donner la définition
générale et abstraite des points à l'infini en utilisant des coordonnées homogènes et aller plus loin pour définir
le perspective tant que transformation projective.
142 | ü
5.5.4. Construction de la perspective
Coordonnées homogènes [5]
E
Ø
= #
n+1ï PKE
Ø
O = PnH#L = PI#
n+1
M estson espace projectif associé
si v
Ø
= HX0, ..., XnL , v'
Ø
= HX0 ', ..., Xn 'L D
Ø
= v v' , $ l œ #
*
, Xi = l Xi
' pour i = 0, ..., n
p œ PnH#L, p = PKD
Ø
O = @X0 : ... : XnD = @X0 ' : ... : Xn 'D
Hi = 8p = @X0 : ... : XnD œ PnH#L Xi = 0< est un hyperplan projectif
Projectivisation de l'espace affine [5]
E
Ø
est # - espace vectoriel, E estson espace affine associé à E
`
son extension vectoriel
ï PHE
`
L = E ‹ PKE
Ø
O est la projectivisation de E
où E est un ouvert affine de PHE
`
L avec un complémentaire le hyperplan projectif PKE
Ø
O = E¶
Points à l'infini [5]
E
Ø
= #
n+1ï PKE
Ø
O = PnH#L estson espace projectif associé
H0
Ø
= :p = HX0, ..., XnL œ E
Ø
X0 = 0> est l' hyperplan vectoriel
PKH0
Ø
O = H0 = 8p = @X0 : ... : XnD œ PnH#L X0 = 0< est l' hyperplan projectif associé
PKH0
Ø
O
c
= H0 est un ouvert affine dans PnH#L ï p œ H0, p = B1 : x1 =
X1
X0
: ... : xn =
Xn
X0
F
H0 = e0
Ø
+ H0
Ø
avec e0
Ø
comme origine et He1, ..., enL comme base ï p œ H0,
p = Hx1, ..., xnL coordonnées cartésiennes
de même, si E un espace affine, dim E = n E = Xo, e1, ..., en \ = #
n
et E
`
= #$#
n
son extension vectoriel
ï p œ E, p = Hx1, ..., xnL coordonnées cartésiennes et p
`
œ E
`
, p
`
= Hx0, x1, ..., xnL coordonnées cartésiennes
ï PnH#L = PI#
n+1
M = PHE
`
L = E ‹ E¶
E = 8@1 : x1 : ... : xnD, Hx1, ..., xnL œ #
n
<
E¶ = PH8x0 = 0 0,
$ h : ° h¥E > h tel que
1
° h¥E
° f Ha + hL - f HaL - f ' HaL.h¥F § e
f est différentiable en a ó f Ha + hL = f HaL + f ' HaL.h +°h¥E.eHhL , où eHhL öhØ0
0F , h " 0
Aapplications composées [2]
HE, ° .¥EL , HF, ° .¥FL and HG, ° .¥GL trois espaces vectoriels normés
f : U Õ EöF , g : V Õ FöG ,
supposons f HaL = b œ V et W = f
-1
HVL Õ U un ouvert de E , a œ W
h = g Î f : W Õ EöG supposons f est différentiable en a et g est différentiable en b = f HaL
alors h est différentiable en a et h' HaL = g ' H f HaLLÎ f ' HaL
où f ' HaL œ 'HE, FL , g ' HaL œ 'HF, GL , h' HaL œ 'HE, GL
| 149Différentiabilité d'applications [2]
cas : 1
E , F1, ..., Fn n + 1 espaces vectoriels normés , U ouvert de E, f : U Õ EöF = F1µ ...µFn
y œ F ï y = Hy1, ..., ynL tel que pour 1 § i § n
yi œ Fi
, °y¥p = I⁄i=1
n
†yi
§Fi
p
M
1
p et °y¥¶ = Sup
i=1,..,n
†yi
§Fi
projection, pi
: FöFi
, piHyL = yi
injection canonique , ui
: FiöF , uiHyiL = H0, .., 0, yi
, 0, ..., 0L
pour 1 § i § n , pi et ui sont des applications continues linéaires donc différentiable
piÎui = idFi
et ⁄i=1
n uiÎ pi = idF
pour a œ U , f est différentiable en a ó " i = 1, ...,
n fi = piÎ f : U Õ EöFi est différentiable en a et
f ' HaL = ⁄i=1
n uiÎ fi
' HaL , où f ' HaL œ 'HE, FL et fi
' HaL œ 'HE, FiL
cas : 2
E1, ..., En, F n + 1 espaces vectoriels normés ,
U ouvert de E = E1µ ...µEn , f : U Õ E = E1µ ...µEn öF
x œ E ï x = Hx1, ..., xnL , °x¥E = Sup
i=1,..,n
†xi
§Ei
pour a œ U , a = Ha1, ..., anL et h = Hh1, ..., hnL
application partielle f Îli
, li
: EiöE ,
liHxiL = a + uiHxi - aiL = Ha1, .., ai-1, xi
, ai+1, ..., anL = a - uiHaiL + uiHxiL
li est différentiable en xi et li
' HxiL = ui
, f Îli
: li
-1
HUL Õ EiöF ,
f Îli est différentiable car li et f sont différentiables
pour a œ U , f est différentiable en a ó " i = 1, ...,
n les applications partielles sont différentiables en les ai
cette différentielle est notée ! f
!xi
HaL la dérivée partielle par rapport à xi en a
! f
!xi
HaL = f ' HaLÎui
, f ' HaL = ⁄i=1
n
! f
!xi
HaLÎ pi ï pour a, h œ U , f ' HaL.h = ⁄i=1
n
! f
!xi
HaL.hi
cas : 3
E = !n
, F = !p
espaces vectoriels normés, U ouvert de E,
f : U Õ EöF , f Hx1, ..., xnL = I f1Hx1, ..., xnL, ..., fpHx1, ..., xnLM
f est différentiable ó " i = 1, ..., p , " j = 1, ..., n fi est différentiable
fi
: !nö! ï l' existence de ! fi
!x j
HxL , où ! fi
!x j
HxL œ 'H!, !L º !
la matrice jacobienne
pour a, h œ !n
J f HaL =
! f1
!x1
HaL ..
! f1
!xn
HaL
: : :
! fp
!x1
HaL ..
! fp
!xn
HaL
, f ' HaL.h = J f HaL.h =
! f1
!x1
HaL ..
! f1
!xn
HaL
: : :
! fp
!x1
HaL ..
! fp
!xn
HaL
h1
:
hn
ligne i : ⁄k=1
n
! fi
!xk
HaL.hk
150 | Maintenant, nous allons donner deux théorèmes fondamentaux équivalents en calcul différentiel, à savoir, le
théorème d'inversion locale et le théorème des fonctions implicites.
Difféomorphisme [2]
E, F deux espaces vectoriels normés, U Õ E ouvert
f : U Õ EöF C1
Hi.e. différentiable etsa dérivée est continueL, bijective et f
-1
est C
1
ï f est un C
1 difféomorphisme
Théorème d'inversion locale (difféomorphisme local) [2]
E, F sont des espaces de Banach, x œ U Õ E ouvert
f : U Õ EöF est C
1
est f ' HxL : EöF est un isomorphisme
ï $ V œ #x et W œ #f HxL
f : VöW est un C
1 difféomorphisme
Théorème des fonctions implicites [2]
E, F, G sont des espaces de Banach, Hx, yL œ U Õ EäF ouvert , f : U Õ EäFöG
tel que f Hx, yL = 0, f est C
1
sur U et #y
f Hx, yL œ IsomHF, GL
ï $ V œ #Hx,yL
, W œ #x et j : Wö F C1
Hx, yL œ V , f Hx, yL = 0 ó x œ W , y = jHxL et j' HxL = -I#y
f Hx, j HxLLM-1
Î#x
f Hx, jHxLL
Théorème des fonctions implicites (en dimension finie) [2]
f : U Õ !n ä!pö!p
, f Hx, yL = 0, f est C
1
sur U et detIJac fyHx, yLM " 0
ï $ V œ #x
, W œ #y V äW Õ U Õ !n ä!p
et j : Vö W C1
x œ V , y œ W, f Hx, yL = 0 ó x œ V , y = jHxL
Représentation de la théorème des fonctions implicites
Ces théorèmes sont en fait équivalent, et le théorème des fonctions implicites a été utilisé plus tôt dans la
définition des surfaces locales qui recouvrent une surface algébriquement définis; et qui permettent alors de
faire toutes les opérations définies plus tard.
| 151ü
6.2. Géométrie différentielle des courbes
ü
6.2.1. Définition d'une courbe régulière
Auparavant, nous avons donné une définition plus généralisée des courbes et des surfaces, comme des variétés
de dimensions un et deux, définies par paramétrage local, maintenant nous allons les définir plus en détail
avec des explication des notions mathématiques nécessaires.
Courbe paramétrée [1]
a : I Õ Ha, bL Õ !ö!n
est une courbe parametrique à condition que a can be
étendue en fonction différentiable par morceaux à partir de Ha, bL à !n
aHIL est la trace d ' a et S Õ !n
est paramétrée par a si $ I Õ ! aHIL = S
Courbe régulière [1]
a : Ha, bL Õ ! ö!n une courbe régulière si " t œ Ha, bL a est différentiable et °a' HtL¥ " 0"H","n
L
si " t œ Ha, bL °a' HtL¥ = 1 alors a est de vitesse unité
Maintenant, nous définissons les champs de vecteurs sur la courbe et le repère de Frenet et après la courbure
des courbes et leur longueurs de l'arc. Intuitivement la courbure d'une courbe, mesure l'échec d'une courbe
pour être une ligne droite, plus la vitesse tourne le long d'une courbe, plus la courbure. Maintenant, nous
démontrons le contrôle de la forme en utilisant l'analyse, à savoir en tout point de la courbe nous savons son
espace tangent, la longueur de la courbe, sa courbure et sa torsion, avec cette information, nous pouvons
concevoir et décider beaucoup de choses sur cette courbe.
Représentation du rayon de courbure d'une courbe en un point
152 | Vélocité de la courbe [1]
a : I Õ ! ö!n une courbe avec aHtL = Ha1HtL, ..., anHtLL , t œ I
alorsla vélocité de f est donnée par l' application a' HtL = Ha1 ' HtL, ..., an ' HtLL ,
où a' HtL œ 'H!, !n
L , a' HtL est une application linéaire
vHtL = °a' HtL¥ est la vitesse de a en t, a'' HtL est l' accélération de a en t
pour n = 3, a : Ha, bL ö!3
, aHtL = Ha1HtL, a2HtL, a3HtLL
la vélocité , l' accélération et la vitesse sont donnés par
a' HtL = Ha1 ' HtL, a2 ' HtL, a3 ' HtLL et v1HtL = °a' HtL¥
a'' HtL = Ha1 '' HtL, a2 '' HtL, a3 '' HtLL et v2HtL = °a'' HtL¥
a''' HtL = Ha1 ''' HtL, a2 ''' HtL, a3 ''' HtLL et v3HtL = °a' HtLä a'' HtL¥
Champ de vecteur de la courbe [1]
un champ de vecteursle long a est une application Y qui associe à chaque t œ
Ha, bL un vecteur YHtL au point aHtL
YHtL = Hy1HtL, ..., ynHtLL , Y est différentiableó " i = 1, ..., n yi
: Ha, bL ö! est différentiable
parfois, nous devons faire la distinction entre le vecteur YHtL en aHtL et le vecteur parallèle à celui à l' origine
soit f : Ha, bL ö! , f différentiable et X, Y champs de vecteursle long a alors
f YHtL = f HtL YHtL , H f YL' = f ' Y + f Y '
HX + YL' = X ' + Y ' , XX, Y\' = XX ', Y\ + XX, Y '\
HJ YL' = J Y ' , où J est la structure complexe, HJHx, yL = H-y, xLL
Champs de vecteurs tangente et normale normalisé de la courbe plane [1]
g : Ha, bL ö!2
, gHtL = HxHtL, yHtLL, une courbe régulière H°g' HtL¥ " 0L et différentiable par morceaux
T 2 HtL =
g' HtL
°g' HtL¥ est le vecteur tangent à la courbe normalisé g at t œ Ha, bL
N 2 HtL = JJ
g' HtL
°g' HtL¥ N est le vecteur normal à la courbe normalisé g at t œ Ha, bL ,
où J est la structure complexe IJ
2 = -id"2 M
Repère de Frenet le long d'une courbe dans l'espace [1]
a : Ha, bL Õ ! ö!3
est une courbe régulière si " t œ Ha, bL a est différentiable et °a' HtL¥ " 0"I","3
M
THtL =
a' HtL
°a' HtL¥ est le champ de vecteur tangent unitaire de a
NHtL = BHtLäTHtL est le champ de vecteur normal principal de a
BHtL =
a' HtLäa'' HtL
°a' HtLäa'' HtL¥ est le champ de vecteur binormale unité de a
Homotopies de la courbe régulière [1]
l : !ö! est fonction scalaire qui pourrait être remplacée par lesfonctions de la longueur de l' arc,
la courbure ou la torsion
a, bT, bN, bB : Ha, bL Õ ! ö!3
courbes régulières
bTHtL = aHtL + †lHtL§ THtL
bNHtL = aHtL + †lHtL§ NHtL
bBHtL = aHtL + †lHtL§ BHtL
T La, l, N La, l , B La, l : Ha, bL Õ !ä@0, 1Dö!3
T La, lHt, uL = aHtL + u †lHtL§ THtL T La, lHt, 0L = aHtL et T La, lHt, 1L = bTHtL
N La, lHt, uL = aHtL + u †lHtL§ NHtL N La, lHt, 0L = aHtL et N La, lHt, 1L = bNHtL
B La, lHt, uL = aHtL + u †lHtL§ BHtL B La, lHt, 0L = aHtL et B La, lHt, 1L = bBHtL
T La, l, N La, l et B La, l sont des homotopies entre a et bT, bN, bB respectivement
| 153ü
6.2.2. Analyse d’une courbe régulière
Courbure de la courbe plane [1]
g : Ha, bL ö!2
, gHtL = HxHtL, yHtLL, une courbe régulière H°g' HtL¥ " 0L et différentiable par morceaux
kgHtL =
g'' HtL. J g' HtL
°g' HtL¥3 =
x' HtL y'' HtL - x'' HtL y' HtL
Ix'
2
HtL + y'
2
HtLM3ê2 =
"!Ig'' HtL i g' HtLM
°g' HtL¥3
est la courbure de g ,
rk2HtL =
1
kgHtL
est le rayon de courbure
si g' HtL = 0 ou g' HtL n' existe pas ï kgHtL n' est pas défini etsi g'' HtL = 0 ï kgHtL s' annule
b : Hc, dL ö!2
, une courbe de vitesse unité H°b' HsL¥ = 1, " s œ Hc, dLL ï b'' = kb J b'sa courbure signée
La courbure et la torsion d'une courbe de l'espace [1]
KHtL =
°a' HtLäa'' HtL¥
°a' HtL¥3
est la fonction de courbure de a ,
rKHtL =
1
KaHtL
est le rayon de la fonction de courbure de a
tHtL =
Xa' HtLäa'' HtL, a''' HtL\
°a' HtLäa'' HtL¥2
est la fonction de torsion de a
KbHsL = °b'' HsL¥ est la courbure de b Ine s' annule jamais et Kb = °kb•si b est contenu dans !2
M
La longueur de l'arc [1]
a : Ha, bL Õ ! ö!n une courbe, soit I = Ha, bL supposons a est defind et différentiable en a et b
LHaL = Ÿa
b
°a' HtL¥ „s est la longueur de a ne dépend pas de la paramétrisation de a
SaHtL = Ÿt0
t
°a' HuL¥ „u est la fonction de longueur de l' arc de a à partir de t0 œ Ha, bL
SbHtL =
Ÿt0
t
°b' HuL¥ „u = t - t0 est la longueur de l' arc d ' une courbe de vitesse unité b : Hc, dLö!n
à partir de t0
Analyse d'une courbe régulière [1]
L'équation de la courbe de base est donnée par
j : U Õ @0, 4 pD Õ !ö!3
, jHtL = It + SinI
t
2
M -
1
100 SinHtL, SinI
t
2
M, 1 - CosHtL + SinI
t
2
MM
le repère de Frenet jHt=3 pL
= {T, N, B} jHt=3 pL={
1
0
0
,
0
1
10
-3
10
,
0
3
10
1
10
}
la longueur de l'arc jHt=3 pL
= 12.1154 , la courbure jHt=3 pL
= 0.774992 et la torsion jHt=3 pL
= 0
Représentation du repère de Frenet sur une courbe régulière
154 | Jusqu'à présent, nous avons défini le repère de Frenet sur une courbe qui va nous permettre de définir les
champs de vecteurs sur la courbe, qui à son tour est un outil de conception utile. Ensuite nous avons défini
l'analyse de courbure et la longueur de l'arc de la courbe qui peut être également utilisé dans la conception
d'autres courbes à partir de la courbe initiale. Avant de commencer à concevoir de nouvelles courbes à partir
de courbes initiales à l'aide de ces définitions, nous allons définir une autre analyse utile qui est de trouver des
points d'intersection entre les courbes.
Points d'intersection
si a, b deux droites , avec a, b, x, y œ !3
aHtL = a + t x et bHsL = b + s y ï aHtL = bHsL ï
a1HtL
a2HtL
a3HtL
=
b1HsL
b2HsL
b3HsL
ï
a1 - b1
a2 - b2
a3 - b3
=
-x1 y1
-x2 y2
-x3 y3
t
s
si a est une courbe et b est une droite,
nous pouvons toujours trouver des points d ' intersection algébriquement en résolvant aHtL = bHsL
si a est une droite et c un plan , avec a, c, x, y, z œ !3
aHtL = a + t x et cHu, vL = c + u y + v z ï aHtL = cHu, vL ï
a1HtL
a2HtL
a3HtL
=
c1Hu, vL
c2Hu, vL
c3Hu, vL
ï
a1 - c1
a2 - c2
a3 - c3
=
-x1 y1 z1
-x2 y2 z2
-x3 y3 z3
t
u
v
ï
t
u
v
=
-x1 y1 z1
-x2 y2 z2
-x3 y3 z3
-1 a1 - c1
a2 - c2
a3 - c3
si a est une courbe et c un plan,
nous pouvons toujours trouver des points d ' intersection algébriquement en résolvant aHtL = cHu, vL
Les points d'intersection de ligne / courbe et de courbe / plan
a, b : U Õ @0, 1D Õ ! ö!3
, aHtL = I2 CosH2 p t - pL, 2 SinH2 p t - pL ,
H2 p t-pL
2
M , bHsL = H4 s, 0 , 2 p s - pL
c : % Õ @-2, 2Dä@-2, 2D Õ !2 ö!3
, cHu, vL = H0, u - 2, v L
aHtL = bHsL ï le point d ' intersection est H2, 0, 0L
aHtL = cHu, vLï le point d ' intersection est H0, -2, -0.785L
Représentation des intersections de ligne / courbe et de courbe / plan
| 155ü
6.2.3. Conception en utilisant l'analyse d’une courbe régulière
Avec ces définitions, nous pouvons déjà donner un exemple sur la façon d'utiliser l'analyse pour générer de
nouvelles formes de celles définies précédemment. Par exemple, la courbe spirale allongée que nous avons
défini plus haut va être utilisé comme notre courbe de base et nous allons définir son champ de vecteur normal
et sa courbure et les utiliser pour dessiner une autre courbe. La courbure et la torsion peuvent être visualisées
sur le domaine de la courbe, afin de voir clairement où elles sont les plus importantes et où elles ne sont pas
définies.
Conception en utilisant l'analyse (homotopies sur une courbe régulière)
Le champ de vecteur normal défini sur cette courbe nous donne l'homotopie
N LjHt, uL = jHtL + u †rKHtL§ NHtL
rK : U Õ @0, 4 pD Õ !ö!, rKHtL =
1
KjHtL
=
°j' HtL¥3
°j' HtLäj'' HtL¥ le rayon de courbure
Représentation des deux courbes reliées par une homotopie
Représentation des tubes où le rayon de la section transversale varie avec la courbure
156 | ü
6.2.4. Tubes le long des courbes
Maintenant, on peut construire une surface à partir d'un champ de vecteur le long d'une courbe, à savoir un
tube le long de la courbe
Tube le long d'une courbe [1]
a : Ha, bL ö!3 une courbe , avec HT, N, B L est le repère de Frenet de a
N et B sont perpendiculaires à a au point t , " t œ Ha, bL, HN, B L former une base orthonormée dans !2
ft0
: uö CosHuL NHt0L + SinHuL BHt0L en un t0 fixé, le cercle ft0
HuL est perpendiculaire à aHt0L
pour t œ Ha, bL , le cercle ft0
HuLse déplace le long a et la trace de f est appelé le tube autour de a
le tube autour de a est définie par
c : % Õ !2ö!3
, ca, l, mHt, uL = aHtL + HlHtL CosHuL NaHt0L + mHtL SinHuL BaHt0LL ,
où l, m : U Õ !ö! sont deux fonction scalaire
Tube autour de le noeud de tore
L' équation de la courbe de base est donnée par
j : U Õ @0, 2 pD Õ !ö!3
,
jHtL = HH8 + 3 CosH5 tLL CosH2 tL, H8 + 3 CosH5 tLL SinH2 tL, 5 SinH5 tLL
nous définissonslesfonctions scalaires l, m et l' équation pour le tube le long de j
l, m : U Õ !ö! , l = 3
4
, mHtL = 100 Kj HtL
2
cj : % Õ !2ö!3
, cjHt, uL = jHtL + Il CosHuL NjHtL + mHtL SinHuL BjHtLM
où KjHtL est la fonction de courbure de j et NjHtL, BjHtLsont les vecteurs normale et binormale de j au point t
Représentation d'une surface tube autour d'un noeud de tore
| 157ü
6.2.5. Conception utilisant des tubes
Avec cette définition du tube le long de la courbe, nous allons montrer un exemple comment d'utiliser cette
définition pour générer des surfaces de potentiel architecturale.
l' équation de la courbe de base est donnée par
j : U Õ @0, 2 pD Õ !ö!3
, jHtL = ICosH3 uL, SinH2 uL,
3
10 I
7
10 + SinH3 uLMM
l' équation du tube le long de la courbe j
cj : % Õ !2ö!3
, cjHu, vL = jHuL +
1
2
I
23
20 CosI
v
2
M BjHuL +
2
5
SinI
v
2
M NjHuLM
où NjHuL, BjHuLsont les vecteurs normale et binormale de j au point u
Représentation de la courbe de section transversale en mouvement le long de la courbe de trajectoire
Maintenant, nous allons démontrer avec un exemple concret l'application de l'analyse d'une courbe régulière
dans une conception architecturale. L'idée de la génération de forme était de travailler à partir d'une courbe
dans l'espace et de générer une surface à partir de cette courbe.
Représentation l'application en architecture pour la conception utilisant des tubes
158 | Conception en utilisant le tube le long de la courbe en CAD
Maintenant que nous avons défini le tube le long d'une courbe et la fonction de NURBS plus tôt, nous allons
montrer d'autres exemples de l'utilisation de cette méthode d'un tube le long d'une courbe pour générer des
formes architecturales, ces exemples ont été réalisées en utilisant le logiciel de modélisation NURBS.
Représentation du processus de la création de courbes transversales le long d'une courbe
Dans cet exemple, nous pouvons voir la qualité sculpturale qui peut être introduit en utilisant le procédé d'un
tube le long d'une courbe et la variation de la taille de la courbe transversale en utilisant une fonction à valeurs
réelles le long de la courbe.
Représentation de la surface tube en suivant les courbes transversales le long de la courbe de trajectoire
| 159Plus de conception utilisant des tubes
Dans cet exemple, on montre une conception de la forme d'un bâtiment construit entièrement à partir d'un tube
le long d'une courbe avec des variation de l'échelle et de la rotation de la courbe transversale telle qu'elle
progresse le long de la courbe de trajectoire. La surface tube peut être recoupé par des plans horizontaux pour
obtenir des plans d'étage de base.
Représentation des plans d'étage internes obtenus par l'intersection de la surface tube avec des plans
horizontaux
Représentation de la forme d'un bâtiment construit par la méthode du tube le long d'une courbe
160 | Plus de conception utilisant des tubes
Maintenant, nous allons montrer d'autres exemples de générer une forme architecturale utilisant cette méthode
du tube le long d'une courbe, cet exemple a également été conçu à l'aide d’un logiciel de CAO. On voit cidessous
que dans ces exemples, nous n'avons pas créé une surface, mais les courbes transversales ont été
utilisés pour créer des éléments discrets; ces éléments pourraient être des éléments structurels.
Représentation d'une forme structurelle développée en utilisant le tube le long de la courbe
Représentation d'une forme structurelle développée en utilisant le tube le long de la courbe montrant les
sections
| 161ü
6.3. Géométrie différentielle des surfaces
ü
6.3.1. Calcul vectoriel
Nous commençons par l'analyse d'une application f : !nö!m et en particulier pour le cas n = 2 et m = 3,
c'est ce qu'on appelle une surface locale ou un patch. La surface locale est de plusieurs manières l'analogue en
deux dimensions de la courbe dans l'espace, que nous avons défini plus tôt.
Représentation de l'espace tangent à une surface régulière
Vecteurs tangents à !n
[1]
Un vecteur tangent vp à l' espace euclidien !n
se compose d ' une paire de points v, p œ !n
v est appelé la partie vecteur et p est appelé le point d ' application de vp
Espace tangent !p
n
[1]
soit p œ !n
, l' espace tangent de !n
en p est l' ensemble !p
n = 9vp v œ !n
=,
l' espace tangent !p
n
est une copie de l' espace vectoriel !n
il y a un isomorphisme canonique entre eux donnée par vp # v
ce qui nous permet de transformer !p
n
à un espace vectoriel avec toutesses propriétés
" p, v, w œ !n
, l œ ! , et J la structure complexe de !2
IJ
2 = -IM
vp + wp = Hv + wLp
, lIvpM = Hl vLp
, Yvp, wp] = Xv, w\ , °Yvp, wp]• § ± vpµ ± wpµ
J vp = HJ vLp
, YJ vp, J wp] = Yvp, wp]
" p, v , w œ !3
, vp äwp = HväwLp
, ±vp äwpµ
2
= ±vpµ
2
±wpµ
2
- Yvp, wp]
2
162 | Tangent vectors as directional derivatives [1]
f , g : !nö! fonctions différentiables, vp , wp vecteurs tangents à !n
en p œ !n
, l, m œ !
vp@ f D =
d
d t f Hp + t vL t=0 Ila dérivée directionnelle dansla direction vpM , vp@ f D = ⁄i=1
n !
!ui
f HpL vi
Il vp + m wpM@ f D = l vp@ f D + m wp@ f D ,
vp@l f + m gD = l vp@ f D + m vp@gD , vp@ f gD = f HpL vp@gD + gHpL vp@ f D
g1, ..., gk
: !nö! et F : !kö! fonctions différentiables
vp , wp vecteurs tangents à !n
en p œ !n
et f = FHg1, ..., gkL , vp@ f D = ⁄i=1
n !
!ui
FHg1HpL, ..., gkHpLL vp@giD
Difféomorphisme [1]
% Õ !n ouvert, A Õ % , F
è
: % Õ !nö!m
F
è
HpL = I f1
è
HpL, ...., fm
è
HpLM, fi
è
: !nö! for i = 1, ..., m IF
è
différentiable car fi
è
différentiableM
F : A Õ !nö!m, F = F
è
A IF est la restriction de F
è
MïF est différentiable
un difféomorphisme F entre % et V Õ !m est une application différentiable
F : %öV qui a un inverse différentiable F
-1
: Vö%
Application tangente [1]
% Õ !n ouvert, F : %ö!m application différentiable, p œ %, " vp œ !p
n
F* : !p
nö!FHpL
m est appelé l' application tangente de F en p
F*IvpM = FHp + t vL' H0L Hla vélocité initiale de la courbe t # FHp + t vLL , F*IvpM = Ivp@ f1D, ...., vp@ fmDMFHpL
si a : Ha, bLö% une courbe ï HFÎaL' HtL = F*Ha' HtLL etsi vp = a' H0L et aH0L = p ï F*IvpM = HFÎaL' H0L
Champ de vecteurs [1]
% Õ !n ouvert,
un champ de vecteurs V est une application qui associe à chaquep œ % un vecteur tangent VHpL œ !p
n
f : %ö! différentiable, alors V agit sur f par V@ f D HpL = VHpL@ f D
le champ de vecteurs est dit être différentiable à condition que V@ f D : %ö! est différentiable si f l' est
V est un champ de vecteursil existe des fonctions vi
: %ö! Hpour i = 1, ..., nL tel que V = ⁄i=1
n
vi Ui
Fonctions coordonnes naturelles et repère naturel [1]
Fonctions coordonnes naturelles de !n
8u1, ..., un< are defined by uiHpL = pi
, pour p = Hp1, ..., pnL
dansles cas particuliers de ! , !2
, !3
f
lesfonctions coordonnes naturelles sont désignés par t, 8u, v< and 8x, y, z<
le champ de vecteurs UiHpL = H0, ..., 1, ..., 0Lp avec le 1 apparaissant dansla i
ème position
le repère naturel de !n
8U1, ..., Un< il est évident que Ui@ f D =
! f
!ui
pour toute fonction différentiable f
Matrice jacobienne [1]
% Õ !n ouvert, F : %ö!m application différentiable,
p œ %, F = H f1, ...., fmL, la matrice jacobienne est la matrice
JHFL HpL =
! f1
!u1
HpL ..
! fm
!u1
HpL
: .. :
! f1
!un
HpL ..
! fm
!un
HpL
Gradient
f : !nö! fonction différentiable, le gradient de f est le champ de vecteurs grad f = ⁄i=1
n
! f
!ui
Ui
| 163ü
6.3.2. Définition d'une surface régulière
Nous pouvons maintenant définir ces notions de champs de vecteurs et la tangence à une surface locale (patch)
qui, avec les notions de l'injectivité et la régularité sont les ingrédients essentiels pour définir les champs de
vecteurs et la tangence à une surface régulière.
Surface locale (patch) dans !n
[1]
% Õ !2 ouvert, A Õ %, q œ % , c
è
: %ö!n
est une application différentiable
c : Aö!n
est une surface locale à condition que c peut être étendue à c
è
, cHAL est la trace de c
une surface locale peut être écrit comme un n - uplet de la fonctions cHu, vL = Hx1Hu, vL, ..., xn Hu, vLL
Les dérivées partielles de la surface locale [1]
% Õ !2 ouvert, q œ %
c : %ö!n une surface locale ï c*I
!
!u
qM = I
!x1
!u
HqL, ...,
!xn
!u
HqLM
cHqL
= cuHqL,
où c* est l' application de poussée en avant de c
cuHu, vL = I
!x1
!u
Hu, vL, ...,
!xn
!u
Hu, vLM , cvHu, vL = I
!x1
!v
Hu, vL, ...,
!xn
!v
Hu, vLM
cu uHu, vL = J
!
2
x1
!u
2
Hu, vL, ...,
!
2
xn
!u
2
Hu, vLN , cv vHu, vL = J
!
2
x1
!v
2
Hu, vL, ...,
!
2
xn
!v
2
Hu, vLN
cu vHu, vL = I
!
!v
I
!x1
!u
M Hu, vL, ...,
!
!v
I
!xn
!u
M Hu, vLM = cv uHu, vL
Normes
VuHu, vL = °cuHu, vL¥ , VvHu, vL = °cvHu, vL¥ , Vu ä v
Hu, vL = °cuHu, vLä cvHu, vL¥
Jacobienne
% Õ !2 ouvert, c : %ö!n une surface locale ïest la matrice jacobienne est l' application
JHcL Hu, vL =
!c1
!u
Hu, vL ..
!cm
!u
Hu, vL
!c1
!v
Hu, vL ..
!cm
!v
Hu, vL
=
cu Hu, vL
cv Hu, vL
Injectivité de la surface locale [1]
% Õ !2 ouvert, q œ %, c : %ö!n une surface locale injective à condition que
" Hu1, v1L et Hu2, v2L œ % , cHu1, v1L = cHu2, v2L ó Hu1, v1L = Hu2, v2L
Régularité de la surface locale [1]
c : %ö!n une surface locale réguliere ó JHcL Hu, vL est de rang 2 pour tousHu, vL œ %
ce qui est équivalent à " Hu, vL œ % ,
cuHu, vL et cvHu, vLsont linéairement indépendants, sens de det
Xcu, cu\ Xcu, cv\
Xcv
, cu\ Xcv
, cv\
" 0
c : %ö!n une surface locale réguliere en q œ % ó c* : !q
nö !cHqL
n
est injective
c : %ö!n une surface locale réguliere en œ % ï $ %q un voisinage de q
c : %qö cI%qM est un difféomorphisme
c : %ö!3 une surface locale réguliere en q œ % ó cuHqLä cvHqL " 0
Pour définir la tangence de la la surface, nous allons utiliser l'idée intuitive d'une courbe dont la trace se trouve
dans la surface. Cette idée est tout à fait essentiel dans la géométrie différentielle des surfaces dans l'espace
euclidien à trois dimensions, car une tangente à la surface peut être considérée comme une tangente à cette
courbe.
164 | Naturellement, la surface locale vient avec les deux courbes de paramètres dans les directions u et v si nous
commençons par les définir et nous définissons une courbe générale dont la trace se trouve dans cette surface
locale.
Courbes de paramètres [1]
% Õ !2 ouvert, Hu0, v0L œ % , c : %ö!n une surface locale alorsles courbes
u # cHu, v0L and v # cHu0, vL sont appeléesles courbes des paramètres u et v de c
Courbe dont la trace se situe sur la surface locale [1]
% Õ !2 ouvert, p = cHu0, v0L œ cH%L ,
c : %ö!n une surface local régulier telle que c : %ö cH%L est un homéomorphisme
a : Ha, bLö!n une courbe dont la trace se situe sur la trace cH%L ï $ ! u,
v : Ha, bLö ! différentiable telle que
aHtL = cHuHtL, vHtLL pour t œ Ha, bL , a' HtL = u' HtL cuHuHtL, vHtLL + v' HtL cvHuHtL, vHtLL
un vecteur tangent à c en p est un vecteur tangent vp œ !p
n
est tel que aH0L = p et a' H0L = vp
Espace tangent à la surface locale [1]
% Õ !2 ouvert, p œ cHUL , c : %ö!n une surface locale réguliere ,
on note l' ensemble des vecteurs tangents à c en p par cH%Lp
où cH%Lp
forme un espace vectoriel de dimension 2 qui est engendré par cuHu0, v0L et cvHu0, v0L
cH%Lp
¨ = 9zp œ !p
n " vp œ cH%Lp
, Yzp, vp] = 0= et !p
n = cH%Lp$ cH%Lp
¨
Champs de vecteurs sur la surface locale [1]
% Õ !2 ouvert, q œ % et p = cHqL , c : %ö!n une surface locale ,
un champ de vecteurs V sur c est une application qui associe à chaque q œ % un vecteur tangent VHqL œ !p
n
V est tangent à c si VHqL œ cH%LcHqL " q œ % , V est normal à c si YVHqL, vp] = 0 " vp œ cH%Lp et " q œ %
Champ de vecteurs normal unitaire [1]
% Õ !2 ouvert , c : %ö!3 une surface locale injective ,
UHu, vL =
cuä cv
°cuä cv¥
Hu, vL le vecteur normal unitaire à la surface locale
Enfin, nous allons maintenant définir les notions de la tangence, des champs de vecteurs d'une surface
régulière (variété de dimension two par paramétrisation locale).
Surface régulière (variété lisse de deux dimension par paramétrisation locale) [1]
% Õ !2 ouvert , & Õ !n
est une surface régulière à condition que
" p œ & $ # un voisinage de la p et !n
et $ c : %öH# › &L Õ !n où
c est differetiable,
c : %ö# ›& est un homéomorphisme et c : %ö& est une surface locale réguliere
c : %ö !n
est une surface locale réguliere ï " q œ % $ %q un voisinage de q
cI%qM est une surface régulière
c : %ö !n une surface locale injective régulière ï cI%qM est une surface régulière
A partir de maintenant, nous allons toujours utiliser le terme surface régulière pour désigner une variété
riemannienne lisse de deux dimensions (qui signifie tout simplement une variété lisse de deux dimensions
avec une métrique riemannienne), cette définition d'une surface régulière est également connu comme une
surface abstraite.
| 165ü
6.3.3. Analyse d’une surface régulière
ü
6.3.3.1. Champs de vecteurs
Carte d'une surface régulière [3]
c : %ö& est une surface locale réguliere sur & ,
HcH%L = UL Õ & ouvert, Ic
-1 = jM : Uö !2 homéomorphisme
Une carte sur une surface régulière est définie comme le couple : HU, jL ou H%, cL
Fonction sur la surface [3]
f :) Õ &ö ! est différentiable en p œ) à condition que pour
c : %ö& avec p œ cH%L Õ) la composition f Î c : %ö ! est différentiable en c
-1
HpL
si f est différentiable en tout points de) on dit que f est différentiable sur)
f : &ö ! est différentiable Hou lisseL à condition que
" p œ &, $ HU, jL carte de & en p f Îj
-1
: jHULö ! est différentiable Hou lisseL
Différentiabilité d'une courbe sur une surface régulière [3]
% Õ !2 ouvert, & Õ !n
est une surface régulière , c : %ö& une surface régulière ,
a : Ha, bLö!n " t œ Ha, bL aHtL œ & ,
a est différentiable à condition que c
-1
Îa : Ha, bLö % est différentiable
Vecteur tangent à la surface régulière [3]
& Õ !n
est une surface régulière, p œ &, CHp, &L est l' ensemble des couplesHI, aL a : Iö& , aH0L = p
~ est une relation d ' équivalence sur CHp, &L telle que
HI1, a1L~HI2, a2L équivalent ó " HU, jL carte de & en p, j : U Õ &ö !2
, HjÎa1L' H0L = HjÎa2L' H0L
ï un vecteur tangent à & en p est une classe d ' équivalence @I, aD = vp aH0L = p and a' H0L = vp
&p est l' ensemble des vecteurs tangents à & en p,
&p est isomorphe à !2
Ietson espace tangent !jHpL
2
M par l' application
Dp j : &pö !jHpL
2
, Dp jH@I, aDL = Dp jIvpM = HjÎaL' H0L
Application tangente [3]
c : % Õ !2ö& surface locale réguliere, q œ % Õ !2
, cHqL = p œ & et HU, jL carte de &
" HI1, g1L~HI2, g2L œ CIq, !2
Mï HI1, cÎg1L~HI2, cÎg2L et ai = cÎgi pour i = 1, 2
ï nous pouvons définir l' application tangente entre les espaces tangents de la surfaces régulières % et &
ï Tq c : %q Õ !q
2ö &p, Tq cH@I, gDL = Tq cIvqM = @I, cÎgD = @I, aD = vp
Dp jIvpM = DcHqL jH@I, cÎgDL = HjÎ cÎgL' H0L = Dq jÎ cHg' H0LL
Espace tangent à la surface régulière [3]
% Õ !2 ouvert, & Õ !n
est une surface régulière, q œ % et p œ & et vp est un vecteur tangent à & en p
&p = 9vp œ !p
n
vp vecteur tangent à & en p= est l' espace tangent à & en p,
un sous - espace vectoriel de !p
n de dimension 2
si c : %ö& est une surface locale régulière Hi.e. un plongementL ï TcHqL cH%L =
Im ITq c : %q Õ !q
2ö &pM = &p
&p
¨ = 9zp œ !p
n " vp œ &p , Yzp, vp] = 0= and !p
n = &p$&p
¨
166 | Intuitivement, un champ de vecteurs sur une surface & est une application qui associe à chaque point p un
vecteur tangent vp mais ici nous allons définir la généralisation d'un champ de vecteurs comme une section du
fibré tangent sur une surface régulière.
Vector Bundle to a regular surface [3]
& une surface régulière, E est l' espace total, P : Eö & is a vector bundle of rank = n ,
$ U Õ & ouvert f : P
-1
HULö U ä!n un difféomorphisme
" p œ & , " e œ Ep et fp : P
-1
HpLö !n
IP
-1
HpL = Ep la fibre estM
f : P
-1
HpLö 8p<ä !n
, fHeL = IPHeL = p, fpHeLM isomorphisme d ' espaces vectoriels
Fibré tangent sur une surface régulière [3]
& une surface régulière, p œ &, &p estson espace tangent à p
T& = ‹pœ# &p = 9Ip, vpM p œ & et vp œ &p= est le fibré tangent de &
V : &öT&, VHpL = vp œ &p, V est appelée une section de T& qui est un champ de vecteurs tangent
GH&, T&L est l' ensemble de touteslessections
Fibré normal sur une surface régulière [4]
& une surface régulière, & est une sous - variété de * = !n
, p œ &, &p estson espace tangent à p
Np is &p
¨
est orthogonal à l' espace tangent en p ,
#N & = ‹pœ# *p ë&p est le fibré normal de &
N& = ‹pœ# Np = 9Ip, npM p œ & et np œ &p
¨
= est le fibré normal de &
N&ö#N & , Ip, npM # Ip, AnpEM est un isomorphisme canonique
N : &öN&, NHpL = np œ &p
¨
, N est appelée une section de N& qui est un champ de vecteurs normal
" p œ &, g œ GI*, T
* *#2
M une métrique riemannienne sur * ï gpIvp, npM = 0
GH&, N&L est l' ensemble de touteslessections
Fibré contangent et fibré alterné sur une surface régulière [3]
& une surface régulière, p œ &, &p
* = 'I&p, !M est le dual de son espace tangent en p
T
* & = ‹pœ# &p
* = 9Ip, lpM p œ & et lp œ &p
*
= est le fibré cotangent de &
l : &öT
* &, lHpL = lp œ &p
*
, l est appelée une section de T
* & qui est une 1 - forme différentielle
GH&, T
* &L est l' ensemble de touteslessections
fl
k T
* & =
‹pœ# fl
k &p
* = 9Ip, lpM p œ & et lp œ fl
k &p
*
= est la k
ième puissance du fibré cotangent de &
l : &öfl
k T
* &, lHpL = lp œ fl
k &p
*
,
l est appelée une section de fl
k T
* & qui est une k - forme différentielle
GI&, fl
k T
* &M est l' ensemble de touteslessections Hcomme dim & = 2 , k = 0, 1, 2L
Système de coordonnées pour une surface régulière [3]
U Õ & une surface régulière, x1, x2 œ C
¶HU, !L j : Uö!2
, jHpL = Hx1HpL, x2HpLL difféomorphisme
ï HU, jL est un système de coordonnées
ï H# x1, # x2L est un repère de T& et Hd x1, d x2L est un repère de T
* &
X = HX1 # x1 + X2 # x2L œ GH&, T&L , f œ C
¶H&, !L , l = Hl1 d x1 + l2 d x2L œ H&, T
* &L
d f = #x1
f d x1 + #x2
f d x2 , où Xi = X@xiD = Xd xi
, X\ et li = Xl, # xi\ pour i = 1, 2
X@ f D = Xd f , X\ = X1 #x1
f + X2 #x2
f
| 167Pousser en avant des champs de vecteurs sur la surface régulière [3]
% Õ !2
est une surface régulière, c : % Õ !2ö& une surface locale régulière
U Õ % ouvert, Hu, vL œ C
¶HU, !L j : Uö!2
, jHqL = HuHqL, vHqLL difféomorphisme
ï HU, jL est un système de coordonnées
" V œ GH%, T%L , V = V1
!
!u
+ V2
!
!v
est un champ de vecteurs tangent de %, où V1, V2 œ C
¶HU, !L
" g : Iö %, gHtL = HuHtL, vHtLL ,
VHqL = VHgHtLL = g' HtL = HuÎgL' HtL I !
!u
gHtL
M +HvÎgL' HtL I !
!v
gHtL
M
ï c*HVL œ GH&, T&L un champ de vecteurs tangent de &
" p œ &, c*HVL HpL = Tc
-1
HpL
cAVIc
-1
HpLME = Tq c@VHqLD est le poussé en avant de V
c*HVL = V1 c*I
!
!u
M + V2 c*I
!
!v
M = V1 cu + V2 cv
" a : Iö &, aHtL = cHgHtLL = cHuHtL, vHtLL ,
c*HVL HpL = c*HVL HaHtLL = a' HtL = HuÎgL' HtL Icu gHtL
M + HuÎgL' HtL Icv gHtL
M
Produit extérieur [3]
E , F espaces vectoriels, w : E
kö # est une forme k - linéaire, sk
le groupe de permutation de 81, ..., k<
" s œ sk
, wHxsH1L
, ..., xsHkL
L = es wHx1, ..., xkL ï w est antisymétrique
" Hx1, ..., xkL œ E
k
, $ i " j xi = x j ï wHx1, ..., xkL = 0 ï w est alternée
w alternée ó w antisymétrique
fl
k E
*
est l' ensemble des formes k - linéaire alternées
fl
0 E
* = # , fl
1 E
* = E
* = 'HE, #L et fl
k E
*
est la k
ième puissance extérieure de E
*
f : EöF est une application linéaire ,
a œ fl
k F
* ï f
*
: fl
k F
*ö fl
k E
*
, f
* a œ fl
k E
*
est le tiré en arrière de a
f
* a : E
kö #, f
* aHx1, ..., xkL = aH f Hx1L, ..., f HxkLL
Tirer en arrière des formes différentielles d'une surface régulière [3]
U Õ !n
, V Õ !m ouvert, p œ U
Wk
HUL = C
¶IU, fl
k
H!n
L
*
M est l' espace des k - formes différentielles de U avec W0
HUL = C
¶HU, !L
HeiLi base de !n
, Hei
*
Li base de H!n
L
*
et HeI
*
LIÕ81,...,n< base de fl
k
H!n
L
*
f : UöV lisse, Dp f : Upö Vf HpL
, IDp f M
*
: fl
k
H!mL
*ö fl
k
H!n
L
*
a œ Wk
HVL ï f
*
: Wk
HVLö Wk
HUL, f
* a œ Wk
HUL est la tirée en arrière de a
f
* a : Uö fl
k
H!n
L
*
, f
* aHpL œ fl
k
H!n
L
*
, f
* aHpL = IDp f M
*
aH f HpLL
ï f
* aHpL : !n ä ...ä!nö!, f
* aHpL Hx1, ..., xkL = aH f HpLLADp f Hx1L, ..., Dp f HxkLE
& une surface régulière, p œ &, &p estson espace tangent en p ,
HU, jL est une carte de & en p , fl
k T
* & le fibré des k - formes alternées de &
Dp j : &pö !jHpL
2
isométrie , IDp jM
*
: fl
k
I!jHpL
2
M
*ö fl
k &p
* ïA IDp jM
*
E
-1
: fl
k &p
*öfl
k
I!jHpL
2
M
*
ï GI&, fl
k T
* &M
bijection
Wk
HUL , a # Ip # A IDp jM
*
E
-1
aHpLM
Vecteurs unitaires tangent et normal à la surface régulière [1]
% Õ !2 ouvert, q œ % et p = cHqL
c : %ö& Õ !3
, cHu, vL = Hx1Hu, vL, x2Hu, vL, x3Hu, vLL une surface locale injective régulière
cU Hu, vL =
cu
°cu¥
Hu, vL est le champ de vecteur tangent unitaire dansla direction u
cV Hu, vL =
cv
°cv¥
Hu, vL est le champ de vecteur tangent unitaire dansla direction v
cNHu, vL =
cuä cv
°cuä cv¥
Hu, vL est le champ de vecteur unitaire normal à la surface
!p
3 = &p$&p
¨ = VectH8cU , cV , cN 0, XHi, ixL =
ix
i
, if i = 0, XHi, ixL = 0
RHi, ix
, !r
, rr
, hrL : U Õ @0, 2 pD Õ !ö!,
RHi, ix
, !r
, rr
, hrL HuL = I1 + !r SinI
Hu+H1-2 XHi,ixLL pL
2
M
hr
M + !r Sin rr
i
Ju+J
p XHi,ixL
ix
NN
2
hr
L'équation du profil
rH!o, !a, !c
, !d, ra, rb, rc
, haL : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!2
rH!o, !a, !c
, !d, ra, rb, rc
, haL Hu, vL =
IrxH!o, !a, !c
, !d, ra, rb, rc
, haL Hu, vL, ryH!o, !a, !c
, !d, ra, rb, rc
, haL Hu, vLM
rH!o, !a, !c
, !d, ra, rb, rc
, haL Hu, vL =
Jv + !o !c SinHrc uL SinHrb vL, J1 + !oJ2 + CosJraJv +
p
ra
NNN J1 + !d SinJHra !aL Jv +
p
ra
NNha
NNN
L'équation totale de la robe
cDIJT, !r, ia, ix a, ib, ix b, ic
, ix c, !b, !o, !a, !c
, !d, ra, rb, rc
, ha, !r
, rr
, hr
M :
% Õ @0, 2 pDä@0, 2 pD Õ !2ö!3
cDIJT, !r, ia, ix a, ib, ix b, ic
, ix c, !b, !o, !a, !c
, !d, ra, rb, rc
, ha, !r
, rr
, hr
M Hu, vL =
IICosHJT vL ICosI!r
v
4
M
8
HHia + 1L CosHuL RHia, ix a, !r
, rr
, hrL HuL + !b CosHHia + 1L uLL +
SinI!r
v
2
M
4
HHib + 1L CosHuL RHib, ix b, !r
, rr
, hrL HuL + !b CosHHib + 1L uLL +
SinI!r
v
4
M
8
HHic + 1L CosHuL RHic
, ix c, !r
, rr
, hrL HuL + !b CosHHic + 1L uLLM -
SinHJT vL ICosI!r
v
4
M
8
HHia + 1L SinHuL RHia, ix a, !r
, rr
, hrL HuL + !b SinHHia + 1L uLL +
SinI!r
v
2
M
4
HHib + 1L SinHuL RHib, ix b, !r
, rr
, hrL HuL + !b SinHHib + 1L uLL +
SinI!r
v
4
M
8
HHic + 1L SinHuL RHic
, ix c, !r
, rr
, hrL HuL + !b SinHHic + 1L uLLMM
ryH!o, !a, !c
, !d, ra, rb, rc
, haL Hu, vL,
ICosHJT vL ICosI!r
v
4
M
8
HHia + 1L SinHuL RHia, ix a, !r
, rr
, hrL HuL + !b SinHHia + 1L uLL +
SinI!r
v
2
M
4
HHib + 1L SinHuL RHib, ix b, !r
, rr
, hrL HuL + !b SinHHib + 1L uLL +
SinI!r
v
4
M
8
HHic + 1L SinHuL RHic
, ix c, !r
, rr
, hrL HuL + !b SinHHic + 1L uLLM +
SinHJT vL ICosI!r
v
4
M
8
HHia + 1L CosHuL RHia, ix a, !r
, rr
, hrL HuL + !b CosHHia + 1L uLL +
SinI!r
v
2
M
4
HHib + 1L CosHuL RHib, ix b, !r
, rr
, hrL HuL + !b CosHHib + 1L uLL +
SinI!r
v
4
M
8
HHic + 1L CosHuL RHic
, ix c, !r
, rr
, hrL HuL + !b CosHHic + 1L uLLMM
ryH!o, !a, !c
, !d, ra, rb, rc
, haL Hu, vL,
Hia + ib + ic + 1L rxH!o, !a, !c
, !d, ra, rb, rc
, haL Hu, vLM
174 | Les paramètres de l'option choisie pour la surface de la robe
JT = 0.3, !r = 1, ia = 0, ix a = 1, ib = 3, ix b = 1, ic = 2, ix c = 2, !b = 0.08, !o = 1, !a = 0.9,
!c = -0.6, !d = 0.3, ra = 2.5, rb = 2.9, rc = 2, ha = 2, !r = 0.11, rr = 1, hr = 2
cc
, b : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3 b est la surface d ' une spline bicubique
cc = cDIJT, !r, ia, ix a, ib, ix b, ic
, ix c, !b, !o, !a, !c
, !d, ra, rb, rc
, ha, !r
, rr
, hr
M
Vcc, b : H% Õ @0, 2 pDä@0, 2 pDLä@0, 1D Õ !3ö!3
Vcc, bHu, v, tL = ccHu - HJT vL , vL + t HbHu, vL - ccHu - HJT vL , vLL est l' homotopie entre cc et b
cHu, vL = Vcc, bIu, v,
7
10 M est la surface déformée "adapté"
Représentation de la surface adapté à l'aide de l'homotopie
| 175ü
6.3.3.3. Courbes intégrales et systèmes dynamiques
L'étude des champs de vecteurs nous amène naturellement à l'étude de flot et des courbes intégrales et des
systèmes dynamiques continus par la suite. Donc, nous commençons par définir la notion de courbe intégrale
et le flot d'un champ de vecteurs, puis plus tard, nous allons examiner certains systèmes dynamiques du plan et
leur poussé en avant sur une surface régulière.
Représentation d'un système dynamique (flot d'un champ de vecteurs dans !2
)
Courbe intégrale d'un champ de vecteurs [3]
& surface régulière, V œ GH&, T&L est un champ de vecteurs tangent de &
I Õ ! ouvert, a : Iö & " t œ I, a' HtL = VHaHtLL ï HI, aL est appelée la courbe intégrale deV
si 0 œ I et aH0L = p ï HI, aL est d ' origine p , Ip est l' intervalle de vie de p et apHtL est la courbe intégrale
si & est compacte le champ de vecteurs est complet et Ip = !
Flot d'un champ de vecteurs [3]
& surface régulière, V œ GH&, T&L est un champ de vecteurs tangent &
W = 9Ht, pL œ !ä&, t œ Ip= Hetsi V est complet W = !ä&L ,
F : W ö &, F Ht, pL = apHtL est une application lisse
" t œ !, Wt = 9p œ & t œ Ip= , Ft
: Wtö &, FtHpL = apHtL est appelée le flot de V
ï " p œ Wt Õ &, Ft=0HpL = p , Ft+s
HpL = FtÎFsHpL et Tp Ft@VHpLD = V@FtHpLD
c : % Õ !2ö& surface locale réguliere, V est un champ de vecteurs tangent de %
ï c*HVL œ GH&, T&L un champ de vecteur de tangente de & ,
si Ft est le flot de V ï cÎFtÎ c
-1
est le flot de c*HVL
Maintenant, nous allons étudier certains des systèmes dynamiques du plan, puis nous allons utiliser le poussé
en avant pour le flot du champ de vecteurs d'une surface régulière.
Système dynamique comme le flot d'un champ de vecteurs [5]
F est un champ de vecteurs sur U Õ !n
, " x œ !n
, FHxL = H f1HxL, ..., fnHxLL est C
k
Hk ¥ 1L
d x
d t = FHxL , est le système différentiel d xi
d t = fiHxL for i = 1, ..., n
le flot F Ht, xL est la solution de d x
d t = FHxL qui dépend de la condition initiale x
telle que Ft=0HxL = x , Ft+s
HxL = FtÎFsHxL est un système dynamique continu sur U Õ !n
un point fixe est le point x œ !n FHxL = 0 Hi.e. le champ de vecteurs est nul en xL
si le système estsousla forme d x
d t =
FHxL = A.x avec A œ MnH#L il est appelé un système dynamique linéaire
ï FtHxL = ‰t A
.x0 est le flot de F, axHtL = FtHxL = xHtL est la courbe intégrale et 0#
n est le seul point fixe
où ‰
t A = ⁄k¥0
t
k A
k
k!
176 | Système dynamique du plan [5]
V est un champ de vecteurs sur % Õ !2
, " q œ % , VHu, vL = HV1Hu, vL, V2Hu, vLL
le système est d u
d t = V1Hu, vL ,
d v
d t = V2Hu, vL
le flot F Ht, qL est la solution du système, F Ht, qL = gqHtL est une courbe intégrale de V
si le système est linéaire, il est dans cette forme
d u
d t
d v
d t
=
a11 a12
a21 a22
u
v
, avec
a11 a12
a21 a22
= A œ M2H!L
dans ce cas, le seul point fixe est H0, 0L la nature de ce point fixe est déterminée par les valeurs propres de A
cas : l1, l2 œ !, l1 " l2 " 0
l1, l2 > 0ïH0, 0L est répulsif , l1, l2 < 0 ïH0, 0L est attractif , l1 < 0, l2 > 0ïH0, 0L est col
cas : l1 = l2
ReHl1L = ReHl2L = 0ïH0, 0L est centre
ReHlL > 0ïH0, 0L est foyer répulsif, ReHlL < 0ïH0, 0L est foyer attractif
Le flot de poussé en avant d'un champ de vecteurs linéaire
% Õ @-p, pDä@-p, pD et cH%L = & sont des surfaces régulières,
c : % Õ !2ö& Õ !3
, cHu, vL = ICosHu + pL SinI
Hv+pL
2
M, SinHu + pL SinI
Hv+pL
2
M, 1 - CosI
Hv+pL
2
MM
V = V1
!
!u
+ V2
!
!v
est champ de vecteurs de % ï c*HVL = V1 cu + V2 cv est champ de vecteurs de &
le système différentiel est
d u
d t
d v
d t
=
vHtL
-uHtL
est un système dynamique linéaire
g : Iö %, gHtL = HuHtL, vHtLL VHqL = VHgHtLL = g' HtL
ï gHtL = YtHu, vL = HuHtL, vHtLL = Hu0 CosHtL + v0 SinHtL, v0 CosHtL - u0 SinHtLL est le flot de V
a : Iö &,
aHtL = cHgHtLL = cHuHtL, vHtLL c*HVL HpL = c*HVL HaHtLL = u' HtL cuHuHtL, vHtLL + v' HtL cvHuHtL, vHtLL
ï aHtL = FtHcHu, vLL = cÎYtÎ c
-1
HcHu, vLL = cÎYtHu, vL = cHgHtLL = cHuHtL, vHtLL est le flot de c*HVL
aHtL = I-CosHu0 CosHtL + v0 SinHtLL SinI
1
2
Hp + v0 CosHtL - u0 SinHtLLM,
-SinI
1
2
Hp + v0 CosHtL - u0 SinHtLLM SinHu0 CosHtL + v0 SinHtLL, 1 - CosI
1
2
Hp + v0 CosHtL - u0 SinHtLLMM
Représentation du flot d'un champ de vecteurs linéaire du plan et son poussé en avant dans la surface
| 177Le flot de poussé en avant d'un champ de vecteurs non linéaire
% Õ @-p, pDä@-p, pD et cH%L = & sont des surfaces régulières,
c : % Õ !2ö& Õ !3
, cHu, vL = ICosHu + pL SinI
Hv+pL
2
M, SinHu + pL SinI
Hv+pL
2
M, 1 - CosI
Hv+pL
2
MM
V = V1
!
!u
+V2
!
!v
est champ de vecteurs de % ï c*HVL = V1 cu + V2 cv est champ de vecteurs de &
le système différentiel est
d u
d t
d v
d t
=
-uHtL
vHtL + u
2
HtL
est un système dynamique non linéaire
g : Iö %, gHtL = HuHtL, vHtLL VHqL = VHgHtLL = g' HtL
ï gHtL = YtHu, vL = HuHtL, vHtLL = Ju0 ‰
-t
, Jv0 +
u0
2
3
N ‰
t - J
u0
2
3
N ‰
-2 t
N est le flot de V
a : Iö &,
aHtL = cHgHtLL = cHuHtL, vHtLL c*HVL HpL = c*HVL HaHtLL = u' HtL cuHuHtL, vHtLL + v' HtL cvHuHtL, vHtLL
ï aHtL = FtHcHu, vLL = cHgHtLL est le flot de c*HVL
aHtL = J-CosHu0 ‰
-t
L SinJ
1
2
Jp + Jv0 +
u0
2
3
N ‰
t - J
u0
2
3
N ‰
-2 t
NN,
-SinHu0 ‰
-t
L SinJ
1
2
Jp + Jv0 +
u0
2
3
N ‰
t - J
u0
2
3
N ‰
-2 t
NN, 1 - CosJ
1
2
Jp + Jv0 +
u0
2
3
N ‰
t - J
u0
2
3
N ‰
-2 t
NNN
Représentation du flot d'un champ de vecteurs non linéaire du plan et son poussé en avant sur la surface
La courbe intégrale d'un champ de vecteur d'une surface peut être utilisé comme un outil de conception, car
après tout, c'est une courbe paramétrique dont la trace se trouve sur la surface qui permet toutes les opérations
que nous avons définies sur les courbes régulières. Maintenant, en utilisant une surface et un système
dynamique linéaire que nous avons défini plus tôt, nous nous allons concevoir une homotopie de la courbe
intégrale.
178 | ü
6.3.3.4. Conception en utilisant des courbes intégrales
La courbe intégrale
aHtL = I-CosHu0 CosHtL + v0 SinHtLL I1 + SinHv0 CosHtL - u0 SinHtLL2
M
I1 -
1
p
I-p +
9
10 Hp + v0 CosHtL - u0 SinHtLLM SinH2 Hp + u0 CosHtL + v0 SinHtLLL4
M,
-I1 + SinHv0 CosHtL - u0 SinHtLL2
M SinHu0 CosHtL + v0 SinHtLL
I1 -
1
p
I-p +
9
10 Hp + v0 CosHtL - u0 SinHtLLM SinH2 Hp + u0 CosHtL + v0 SinHtLLL4
M,
2 Hp + v0 CosHtL - u0 SinHtL + SinHv0 CosHtL - u0 SinHtLLLM
L'homotopie
Le champ de vecteurs normal défini sur cette courbe nous donne l' homotopie
N LaHt, uL = aHtL + u †rKHtL§ NHtL
Représentation d'une homotopie entre une courbe intégrale et la courbe définie par sa normale et sa courbure
| 179ü
6.3.3.5. Métrique riemannienne sur une surface régulière
Nous commençons par définir la distance infinitésimale qui définit la métrique riemannienne (soit la première
forme fondamentale) sur une surface régulière (comme une image d’une surface locale régulière injective).
Géométriquement d s peut être interprété comme la distance infinitésimale d’un point
cHu, vL à cHu + d u , v + d vL mesurée le long la surface, De même, nous allons définir l’aire de la surface
courbe en utilisant la même logique de la distance courbe. Ces analyses serait la deuxième analyse, nous
réalisons sur notre surface régulière, il nous donne des informations comme l’aire de la surface, mais aussi des
informations sur la courbe se situant dans la surface. Cet outil est d’être en mesure d’envoyer des courbes
planes du plan à une surface régulière, il offre beaucoup de possibilités de conception pour les architectes
intéressés dans la conception sur des toits ou des façades incurvées. Depuis que nous avons défini plus haut
nos surfaces comme des variétés différentiables de deux dimensions en utilisant le paramétrage local et les
cartes, la métrique riemannienne décrit les distances et les aires dans chaque carte locale, et cette surface a
alors la structure d’une variété riemannienne de dimension deux. Chaque sous-variété lisse de !n
a une
métrique riemannienne induite g sur chaque espace tangent qui est une restriction du produit scalaire de !n
,
qui est un H0, 2L tenseur défini positif. Dans chaque carte locale une métrique riemannienne est donnée par
l’attribution d’une matrice 2ä2 définie positive à chaque point; quand une carte différente est adoptée, la
matrice est transformée selon la matrice jacobienne du changement de coordonnées. Une variété riemannienne
connexe porte la structure d’un espace métrique dont la fonction de la distance est la longueur de l’arc d’une
géodésique minimisante.
Variété riemannienne [6]
& variété lisse, p œ &, gp est un produit scalaire sur son espace tangent &p
X, Y œ GH&, T&L sont des champs de vecteurs tangents de & ,
gp : &p ä&pö ! p # gpHXHpL, YHpLL fonction lisse
ï H&, gL variété riemannienne et la famille gp de produits scalaires est appelé une métrique riemannienne
Métrique riemannienne [6]
c : %ö& une surface locale sur la surface régulière , U Õ & ouvert, p œ U
Hu, vLsystème de coordonnées de % ïH#u, #vL
est une base de vecteurs tangents à % et Hd u, d vL est la base duale
Hx1, x2L est un système de coordonnées sur &
ïH# x1, # x2L est une base de vecteurs tangents à & and Hd x1, d x2L est la base duale
g œ GI&, T
*
M est le tenseur métrique
g = ⁄i, j gi j d xi%d x j = g1,1 Hd x1L
2 + 2 g1,2 d x1 d x2 + g2,2Hd x2L
2 = Hd sL
2
" p œ U, gi j = gI# xi
, # x j
M = Y# xi
, # x j] = pour i, j = 1, 2 est la componant du tenseur métrique
c
*
: W2
H&L ö W2
H%L, c
* g est la tirée en arrière de g, c
* g œ W2
H%L , c
* g : %öT
* %#2
c
* gHqL œ T
* %#2
, où q œ %, #u, #v œ %q
c
* gHqL : %q ä%qö !, c
* gHpL H#u, #vL = gHcHqLLADq cH#uL, Dq cH#vLE = gHpL Hc*H#uL, c*H#vLL
où # x1 = c*H#uL = cu et # x2 = c*H#vL = cv ï g1,1 Î c = E, g1,2 Î c = g2,1 Î c = F, g2,2 Î c = G
c
* g = c*
Ag1,1Hd x1L
2 + 2 g1,2 d x1 d x2 + g2,2Hd x2L
2
E = EHd uL
2 + 2 F d u d v + GHd vL
2
si U Õ !n
, H#u1, ..., #unL est le repère naturel i.e. #ui = ei = H0, ..., 1, ..., 0L avec 1 à la i
ème position
ï gp : Up äUpö !, I⁄i ai #ui
, ⁄j bj #uj
M # ⁄i ai bi
ï gp = Yei
, e j] = di j la métrique riemannienne est la métrique euclidienne canonique
Les coefficients de la première forme fondamentale [1]
E, F, G : !nö ! , E = °cu¥
2
, F = Xcu, cv\ , G = °cv¥
2
et la matrice
E F
F G est définie positive
180 | La distance infinitismal (i.e. la première forme fondamentale) [1]
c : %ö !n a patch , Hd sL
2 = E Hd uL
2 + 2 F Hd uL Hd vL + G Hd vL
2
est la première forme fondamentale
a : Ha, bLö!n a curve whose trace lies on the trace cH%L ,
aHtL = cHuHtL, vHtLL et d s
d t = E I
d u
d t M
2
+ 2 F I
d u
d t M I d v
d t M + G I
d v
d t M
2
sHtL = Ÿc
t
E I
d u
d t M
2
+ 2 F I
d u
d t M I d v
d t M + G I
d v
d t M
2
„t est la fonction de longueur de l' arc de a à partir de aHcL
L’aire infinitismal [1]
d V = d x1Ô ...Ôd xn est l' élément volume infinitésimal de !n
, d A = E G - F
2 d u ä d v ,
où E G - F
2 = °cu ä cv¥ = °cu¥ °cv¥ sinq est l' aire du parallélogramme engendré par °cu¥ et °cv¥
c : %ö !n une surface locale injective régulière , AHcH%LL = Ÿ&
E G - F
2 d u ä d v est l' aire de cH%L
Variété riemannienne comme espace métrique [6]
H&, gL variété riemannienne, p, q œ &
c : Ha, bLö& une courbe dans & ï La
b
HcL := Ÿa
b
gHc' HtL, c' HtLL d t = Ÿa
b
°c' HtL¥ d t
avec un changement de variables nous paramétrer c parsa longueur de l' arc i.e. " t œ Ha, bL, °c' HtL¥ = 1
d : &ä&ö!+ ,
dHp, qL = inf LHgL est la borne inférieure sur toutesles courbes différentiables g à partir de p et finissant à q
Connexion sur une surface régulière [6]
& une surface régulière, une connexion ou dérivée covariante sur & est l' application
D : GH&, T&Lä GH&, T&Lö GH&, T&L " X, Y, Z œ GH&, T&L , f , g œ C
¶H&, !L
DX : GH&, T&Lö GH&, T&L
Df X+ g Y = f DX + g DY , DX HY + ZL = DX Y + DX Z , DX H f YL = X@ f D Y + f DX Y
avec le système de coordonnées de & est Hx1, x2L , Y = Y1 # x1 + Y2 # x2ï DX Y = X@Y1D # x1 + X@Y2D # x2
Champ de vecteurs le long d’une courbe dans une surface régulière [6]
& une surface régulière, X, Y, Z œ GH&, T&L , I Õ ! ouvert, a : Iö & une courbe intégrale de X
a' HtL = XHaHtLL, YHaHtLL = ZHaHtLLï DX YHaHtLL = DX ZHaHtLL
V est un champ de vecteursle long a si " t œ I , VHtL œ &aHtL
si a : Iö & est une courbe régulière injective ï V ' HtL = Da' HtL V , où V HaHtLL = VHtL
Symboles de Christoffel [6]
& une surface régulière Hmuni d ' une métrique riemannienneL,
D estsa connexion riemannienne, Hx1, x2L estson système de coordonnées
ï Gi j
k = d xk
ID!xi
# x j
M pour i, j, k = 1, 2 sont lessymboles de Cristoffel D par rapport à Hx1, x2L
ï D!xi
# x j = Gi j
1 # x1 + Gi j
2 # x2 où Gi j
k = Gj i
k
c : %ö !n une surface locale régulière, alorslessymboles de Christoffel Gi j
k pour i,
j, k = 1, 2 correspondants à c sont définis par
G1,1
1 =
G Eu -2 F Fu+F Ev
2 IE G-F
2
M
, G1,2
1 =
G Ev - F Gu
2 IE G-F
2
M
, G2,2
1 =
2 G Fv -G Gu-F Gv
2 IE G-F
2
M
G1,1
2 =
2 E Fu -E Ev-F Eu
2 IE G-F
2
M
, G1,2
2 =
E Gu - F Ev
2 IE G-F
2
M
, G2,2
2 =
E Gv -2 F Fv+F Gu
2 IE G-F
2
M
avec G1,2
1 = G2,1
1
and G1,2
2 = G2,1
2
| 181Maintenant, nous démontrons le contrôle de la forme à l’aide de notre deuxième analyse, à savoir donner l’aire
de la surface, la longueur de la courbe entre deux points quelconques sur la surface et le traçage de la courbe
qui se trouvant sur la surface.
Deuxième analyse d’une surface régulière
L’équation de la surface de base est donnée par
c : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3
c1Hu, vL =
3
2
ICosHuL +
5
2
CosI
u
2
M
8
M I2 +
35
100 CosI
v
2
MM I1 - CosI
v
2
M
6
+ SinI
v
2
MM
c2Hu, vL = 3 SinHuL I2 +
35
100 CosI
v
2
MM I1 - CosI
v
2
M
6
+ SinI
v
2
MM
c3Hu, vL = v - SinHvL, cHu, vL = Hc1Hu, vL, c2Hu, vL, c3Hu, vLL
l’équation de la courbe plane dont la trace se situe dans le domaine
q1, q2 œ %, q1 = I
2
3
p, pM and q2 = I
3
2
p,
3
2
pM
g : U Õ @0, 2 pD Õ !ö!2
, gHtL = q1 +
t
2 p
Hq2 - q1L = HuHtL, vHtLL = I
2 p
3
+
5 t
12 , p +
t
4
M , where d u
d t =
5
12 ,
d v
d t =
1
4
l’équation de la courbe a dont la trace se trouve dans la surface
a : U Õ @0, 2 pD Õ !ö!3
, aHtL = HcÎgL HtL = cHuHtL, vHtLL = Ha1HtL, a2HtL, a3HtLL
a1HtL = c1HuHtL, vHtLL =
3
2
I2 +
7
20 CosI
1
2
Ip +
t
4
MMM J1 - CosI
1
2
Ip +
t
4
MM6
+ SinI
1
2
Ip +
t
4
MMN J 5
2
CosI
1
2
I
2 p
3
+
5 t
12 MM8
- SinI
p
6
+
5 t
12 MN
a2HtL = c2HuHtL, vHtLL = 3 I2 +
7
20 CosI
1
2
Ip +
t
4
MMM CosI
p
6
+
5 t
12 M J1 - CosI
1
2
Ip +
t
4
MM6
+ SinI
1
2
Ip +
t
4
MMN
a3HtL = c3HuHtL, vHtLL = p +
t
4
+ SinI
t
4
M
aH0L = cHq1L = cHuH0L, vH0LL = p1 and aH2 pL = cHq2L = cHuH2 pL, vH2 pLL = p2
" t œ U , a' HtL = HcÎgL' HtL = cuHuHtL, vHtLL I d u
d t M + cvHuHtL, vHtLL I d u
d t M = HHcÎgL1
ç
HtL, HcÎgL2
ç
HtL, HcÎgL3
ç
HtLL
la longueur de l’arc entre p1 et p2 dans la surface
E, F, G : !3ö!, E = °cu¥
2
, F = Xcu, cv\ , G = °cv¥
2
d s
d t = E I
d u
d t M
2
+ F I
d u
d t M I d v
d t M + G I
d v
d t M
2
est la première forme fondamentale
SHtL = Ÿc
t
E I
d u
d t M
2
+ F I
d u
d t M I d v
d t M + G I
d v
d t M
2
est la fonction de longueur de l' arc de a
SH2 pL = 23.298 est la longueur de l' arc de a à partir de aH0L = p1 et finissant à aH2 pL = p2
L’aire de la surface
Ac@Hu0, v0L, Hun, vnLD = Ÿv0
vn
Ÿu0
un E G - F
2 d u ä d v est la fonction de l' aire de c
Ac@H0, 0L, H2 p, 2 pLD = 1213 est l' aire de c à partir de cH0, 0L et finissant à cH2 p, 2 pL
Représentation de la courbe entre deux points sur une surface régulière
182 | ü
6.3.3.6. Conception en utilisant la métrique riemannienne
Exemple de conception en utilisant la longueur de l’arc d’une courbe dans une surface régulière
L’équation de la courbe a dont la trace se situe dans la surface
j : U Õ @0, 2 pD Õ !ö!3
, jHtL = HcÎgL HtL = cHuHtL, vHtLL
jHtL = I-CosHCosHtLL SinI
1
2
I
6 p
5
+ SinHtLMM, -SinHCosHtLL SinI
1
2
I
6 p
5
+ SinHtLMM, 1 - CosI
1
2
I
6 p
5
+ SinHtLMMM
SH2 pL = 4.375 est la longueur de l' arc de j à partir de jH0L et finissant à jH2 pL
N LjHt, uL = jHtL + u SHtL NHtL est le champ de vecteurs normal défini sur cette courbe
Représentation de l’envoi d’une courbe du plan à une surface régulière
Représentation d’une conception utilisant une courbe dans la surface et son champ de vecteurs normal
| 183Exemple de conception utilisant l’aire de la surface
Dans l’exemple suivant, nous allons montrer le calcul d’aire peut être utilisé comme un outil de conception, à
savoir dans la conception de la tour ci-dessous, l’aire de chaque plancher horizontal détermine la hauteur du
plafond au-dessus de lui. Ceci à son tour détermine la taille des ouvertures, ce qui permet par exemple lumière
d’atteindre plus profondément dans le plancher avec des aires supérieures.
Représentation de la variation des hauteurs de plafond en fonction de la superficie de chaque étage
Maintenant que nous avons créé une variation de la hauteur du plafond à chaque étage porportional à la
superficie de chaque étage (plafond plus haut pour une aire plus grande), nous allons de manière similaire
créer des variations dans la taille des ouvertures en porportion à l’hauteur du plafond.
Représentation de la variation de la taille des ouvertures à chaque étage en fonction des aires
184 | ü
6.3.3.7. Volume contenu par une surface régulière
Après le calcul de l’aire d’une surface régulière en intégrant d A = E G - F
2 d uÔd v qui est une forme
différentielle (donnée localement dans la carte Hx1, x2L et la base d uÔd v = c*
Hd x1Ôd x2L où Hd x1, d x2L est
le repère pour T
* & ). Cette forme différentielle est de même degré que la dimension de la variété à savoir de
degré deux. Cette forme différentielle est appelé une forme de volume puisqu’elle n’est jamais nulle sur la
variété et son degré est égale à la dimension de la variété, donc du point de vue de la variété, le volume est
l’intégration de la forme de volume. En d’autres termes, puisque la surface est une variété de deux dimensions
ce que nous appelons l’aire est essentiellement le volume de la surface, mais dans l’architecture, nous sommes
également intéressés au volume dans !3
contenue par le plongement de la variété dans !3
Dans cette perspective,
nous allons traiter la surface comme une application de deux variables avec son image dans !3
, et
calculer le volume de solide contenue par cette surface à l’aide des techniques usuelles de changement des
variables dans !3
(coordonnées polaires, sphériques et cylindriques). En plus du changement de variables,
nous allons utiliser aussi la technique de balayage volumétrique, qui est simplement calculer l’aire de la
surface plane obtenue en coupant le volume par un plan, puis l’intégration de cette aire en tant que fonction
réelle le long de direction de la hauteur. Ce volume contenu par la surface est la troisième analyse, nous allons
faire sur une surface régulière, son application dans l’architecture est tout à fait clair. Dans cette recherche,
nous allons montrer un exemple comment le calcul du volume peut être utilisé en combinaison avec le calcul
de l’aire comme un outil pour tester l’aptitude de certaines variations d’une surface donnée dans un algorithme
d’optimisation. Par exemple, étant donné un grand espace de variations d’une surface, nous aimerions trouver
ceux avec un plus grand rapport volume / surface en d’autres termes, nous essayons de s’approcher de la
sphère algorithmiquement.
Représentation du volume du cylindre
| 185s-algèbre (tribu) [7]
E un ensemble non vide, $ , C sont des classes des parties de E, $ est une s - algèbre HtribuLsi f œ $ ,
si A œ $ïA
c œ $ etsi HAnLn¥0 une suite d ' éléments de $ ï‹n¥0 An œ $
sHCL = ›CÕ! $ est la tribu engendrée, etsi
C = 8Ha, bL ouvert -¶ < a § b < ¶ , a, b œ !<ï sHCL = +H!L est la tribu borélienne
% est une topologie si f, E œ %, si HOnLn¥0 une suite d ' éléments de %
ï‹n¥0On œ % etsi HOnL0§n¥N une suite d ' éléments de % ï›0§n¥N On œ %
dans un espace topologique HE, %L la tribu borélienne +H%L = sH%L
Fonctions mesurables et boréliennes [7]
f : HE, $Lö HF, +L est mesurableó " B œ + , f
-1
HBL Õ $ , f : HE, $Lö HE1 ä ...äEn, $1% ....%$nL,
xö H f1HxL, ..., fnHxLL est mesurable ó " i œ 1, ..., n , fi
: HE, $Lö HEi
, $iL est mesurable
f : HE1 ä ...äEn, $1% ....%$nLö H!, +H!LL,
Hx1, ..., xnLö f Hx1, ..., xnL est mesurable ó " i œ 1, ..., n , fi
: HEi
, $iLö H!, +H!LL est mesurable
f : HE, $Lö H!, +H!LL est mesurable ó " a œ ! , f
-1
HHa, ¶LL = 8 f > a< Õ $
f : HE, %Lö HF, #L est continue,
+H%L = sH%L ï f est borélienne f : HE, +H%LLö HF, +H#LL est mesurable
Mesure de Lebesgue et fonction l-intégrable [7]
E un ensemble non vide, $ une tribu
m : HE, $Lö@0, ¶D, A œ $ömHAL mHfL = 0 et HAnLn¥1
suite d ' éléments 2 à 2 disjoints,
mH⁄n¥1 AnL = ⁄n¥1mHAnL ï m est une mesure positive
et pour f : HE, $, mLö I!+
, +H!+
LM mesurable ï mHAL = ŸA
f ,m
l : H!, +H!LLö@0, ¶D " B œ +H!L, " x œ !, lHBL = lHx + BL,
lH@a, bDL = b - a et lH8a
det H cu c Nc L
det Hc ww Nw L
det Hws c Nw L
, soit YHtL =
uHtL
vHtL
sHtL
wHtL
et Y0 =
u0
v0
s0
w0
ïY ' HtL = FHYHtLL et YH0L = Y0
système de équations différentielles ordinaires avec le problème de la valeur initiale
ï
d u
d t
d v
d t
d s
d t
d w
d t
=
f1 Hu HtL, v HtL, sHtL, w HtLL
f2 Hu HtL, v HtL, sHtL, w HtLL
f3 Hu HtL, v HtL, sHtL, w HtLL
f4 Hu HtL, v HtL, sHtL, w HtLL
=
det HcHuHtL, vHtL,sHtL, wHtLL cvHuHtL, vHtLL NcHuHtL, vHtLLL
det H cuHuHtL, vHtLL c HuHtL, vHtL,sHtL, wHtLL Nc HuHtL, vHtLL L
det Hc HuHtL, vHtL,sHtL, wHtLL wwHsHtL, wHtLL NwHsHtL, wHtLL L
det HwsHsHtL, wHtLL c HuHtL, vHtL,sHtL, wHtLL Nw HsHtL, wHtLLL
| 205Courbe d’intersection entre une sphère et un tore
Les équations des surfaces de base sont donnés par
c, w : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3
cHu, vL = ISinI
v
2
M CosHuL, SinI
v
2
M SinHuL, CosI
v
2
MM
wHs, wL = KCosHsL I1 +
CosHwL
2
M + K
2+ 3
2
O, I1 +
CosHwL
2
M SinHsL,
SinHwL
2
O
nous devons trouver le point de départ de la courbe d ' intersection i.e. q1 =
Hu0, v0L et q2 = Hs0, w0L cHu0, v0L = wHs0, w0L
si u0 = 0 ets0 = p ï les courbes de paramètres cHu0, vL et wHs0, wLse coupent en hauteur =
1
2
en utilisant des fonctions inverses nous sommes en mesure de trouver v0 et w0
Y ' HtL = FHYHtLL et YH0L = Y0 ï YHtL = HuHtL, vHtL, sHtL, wHtLL
les équations des des courbes planes g et b dont les traces se situe dans les domaines %Õ@0, 2 pDä@0, 2 pD
Hu0, v0L œ %, Hu0, v0L = H0, 2.0944L , g : U Õ @0, 2 pD Õ !ö!2
, gHtL = HuHtL, vHtLL
Hs0, w0L œ %, Hs0, w0L = Ip,
p
2
M , b : U Õ @0, 2 pD Õ !ö!2
, bHtL = HuHtL, vHtLL
les équations de la courbe d’intersection de la surface sont aHtL = cHuHtL, vHtLL = wHsHtL, wHtLL
Représentation de la courbe d’intersection de deux surfaces régulières
206 | ü
6.3.3.14. Conception en utilisant l’intersection entre les surfaces régulières
Maintenant que nous avons défini l’intersection de surfaces paramétriques, nous allons montrer comment ces
intersections peuvent être utiles du point de vue de la conception architecturale. Dans cet exemple, on montre
que la forme des ouvertures dans la peau d’un bâtiment peut être déterminée par la courbe résultant de l’intersection
d’une surface cylindrique avec la surface principale de la forme. Cette surface cylindrique est réalisé
en extrudant une courbe dans l’espace tangent à la surface principale en un point donné le long de la normale
en ce point; outre on peut faire varier le rayon de la base du cylindre en le définissant comme une fonction de
la distance entre le point donné et un autre objet.
Représentation d’une courbe d’intersection comme le contour de la forme de l’ouverture et ses variations
Représentation des ouvertures dans la peau du bâtiment basées sur des courbes d’intersection
| 207ü
6.3.4. Surfaces spéciales
ü
6.3.4.1. Surfaces non orientables
Maintenant, nous allons définir une famille importante des surfaces ce sont les surfaces non orientables.
Représentation des surfaces non orientables
Orientation d’un espace vectoriel [3]
E espace vectorie dim E < ¶ , E a deux classes d ' équivalence d ' orientation surses bases
B, B' œ 8bases de E< , B équivalente à B' ó det MB
B' > 0 , où MB
B'
est la matrice de changement de base
!n
admet une orientation canonique avec la base canonique, qui est dansle sens direct
f : U Õ !nö V Õ !n difféomorphisme, f préserve l' orientation si detJacx
f > 0 , pour x œ U
Orientation d’une variété [3]
& variété différentiable, 8HUi
, jiL< atlas de & est orientable si
" i, j detJacx jjÎji
-1 > 0 , pour x œ ji
IUi › Uj
M
& variété différentiable est orientable sison atlas maximal est orientable
IOpM
pœ#
famille d ' orientations de l' espace tangent &p , Op est continue si
" p œ Ui
, dp ji
: &pö !n préserve l' orientation
& variété différentiable est orientable ó IOpM
pœ#
est une famille continue
Orientation des surfaces régulières [1]
& Õ !3
surface régulière, & est orientable ó $ une application continue U : &ö &p
¨
, p # UHpL
où UHpL est un vecteur normal unitaire à & en point p
si & est la trace d ' une surface locale injective régulière ï & est orientable
si & est une surface orientable connexe
ï & a exactement deux vecteurs normal unitaires définis globalement
208 | Ruban de Mobius et la bouteille de Klein [3]
M le ruban de Möbius est construit comme le quotient !2
ë% par l' action de groupe
%ä !2 ö !2
, Hk, Hu, vLL = k.Hu, vL = Iu + k, H-1L
k
vM
K la bouteille de Klein est construit comme le quotient de !2
ë%2 par l' action de groupe
%2 ä !2 ö !2
, HHk, lL, Hu, vLL = Hk, lL.Hu, vL = Iu + k, H-1L
k
v + lM
nous pouvons construire un plongement du ruban de Möbius et
une immersion de la bouteille de Klein dans !3 by the parametrizations
cM : !2ö!3
,
cM Hu, vL = II1 + 2 p + Hv - pL CosI
u
2
MM CosHuL, I1 + 2 p + Hv - pL CosI
u
2
MM SinHuL, Hv - pL SinI
u
2
MM
cK : !2ö!3
,
cKHu, vL = ICosHuL Ip - CosI
u
2
M CosHvL - SinI
u
2
M SinH2 Hv - pLLM,
SinHuL Ip - CosI
u
2
M CosHvL - SinI
u
2
M SinH2 Hv - pLLM, -CosHvL SinI
u
2
M + CosI
u
2
M SinH2 Hv - pLLM
Représentation du ruban de Möbius montrant la famille non continue d’orientations IOpM
pœM
Représentation de la bouteille de Klein montrant son non orientabilité et un ruban de Möbius dedans
| 209ü
6.3.4.2. Conception en utilisant des surfaces non orientables
Maintenant, nous allons montrer un exemple d’une conception architecturale basée sur une surface non
orientable. Dans cet exemple, nous allons utiliser le plongement du ruban de Möbius dans !3
, cela peut
entraîner dans de nombreuses applications architecturales. À savoir que la distinction entre l’extérieur et
l’intérieur du bâtiment n’est plus là, qui donne lieu à un jeu beaucoup plus riche entre le sentiment d’être à
l’intérieur ou à l’extérieur.
Représentation de la conception d’un ruban de Möbius plié plusieurs fois sur lui-même
Représentation d’une conception architecturale utilisant le ruban de Möbius
210 | ü
6.3.4.3. Surfaces réglées et développables
Avec ces définitions des courbes asymptotiques nous allons maintenant définir les surfaces réglées et développables,
comme nous l’avons mentionné plus tôt, ils sont d’une importance particulière pour la conception
architecturale parce qu’elles contiennent des lignes droites qui rend la réalisation de ces formes plus facile. Par
exemple, la tangente développable à une hélice peut être construit à partir d’une feuille de papier en découpant
un disque et tournant la partie restante autour d’un cylindre.
Représentation de la construction d’une surfaces réglée
Surfaces réglée [1]
& Õ !3
surface régulière, a, g : Ha, bL Õ !ö!3
avec a' " 0 ,
c : %ö&, cHu, vL = aHuL + v gHuL est la paramétrisation de &
c est une surface locale réglée,
a est la courbe de base directrice et g est la courbe génératrice Hvecteur directeurL
v # cHu0, vL = aHu0L + v gHu0L sont leslignes droites dirigeantesHi.e. des courbes asymptotiquesL
& a deux surfaces locales réglées distinctes sur elle ï & est doublement réglées
& est une surface réglée ï " p œ & , .HpL la courbure gaussienne est non positives
| 211Il existe deux formes extrêmes des surfaces réglées: les surfaces réglées planes et les surfaces réglées non
cylindriques. Les surfaces réglées planes sont celle qui ont une courbure gaussienne nulle (i.e. développables),
géométriquement elles sont de trois types, la développable tangente, le cylindre et le cône;
Surfaces réglée plane [1]
& est une surface réglée , p, q œ !3
, a : Ha, bL Õ !ö!3
, c : %ö& , est la paramétrisation de &
cHu, vL = aHuL + v a' HuL est la développable tangente
cHu, vL = aHuL + v q est le cylindre généralisé
cHu, vL = v a HuL + q le cône est généralisée
& est une surface réglées plane ï g = 0 ï f = 0 et " p œ & ,
.HpL = 0 la courbure gaussienne est égale à zéro
b : Hc, dL Õ !ö!3
, est une courbe de vitesse unitaire et cHu, vL = bHuL + v b' HuL est la tangente développable
ï E = 1 + v
2 Kb
2
, F = 1 et G = 1 ,
le coefficient de la première forme fondamentale dépend uniquement de la courbure de b
régularité
c est une développable tangente alors est régulière partout sauf sur a Hoù a est une courbe régulière, KHaL " 0 L
c est un cylindre généralisé alors est régulière partout tant que a'äq " 0
c est un cône généralisé alors est régulière partout tant que v a ä a' " 0
Surfaces réglées non cylindriques [1]
& Õ !3
surface régulière , a, g : Ha, bL Õ !ö!3
avec a' " 0 ,
c : %ö&, cHu, vL = aHuL + v gHuL est la paramétrisation de&
& est une surface réglées non cylindrique si g ä g' " 0 partout sur &
Courbe de striction [1]
c
è
Hu, vL = aHuL + v gHuL est une surface réglée non cylindrique
et cHu, vL = sHuL + v dHuL est un reparamétrage où °d¥ = 1 et Xs', d'\ = 0
ï s est la courbe de striction de c
è
Hil ne dépend pas du choix de la courbe de baseL
cHu, vL =
sHuL + v dHuL est un reparamétrage où °d¥ = 1 ï c paramétrisation d ' une surface réglées plane telle que
si s' HuL = 0 ï & est un cône
si d' HuL = 0 ï & est un cylindre
si s', d' " 0 ï & est une tangente développable
Paramètre de distribution [1]
cHu, vL = sHuL + v dHuL est une surface réglée non cylindrique ï p =
Xs',däd'\
Xd',d'\
est le paramètre de distribution
cHu, vL = sHuL + v dHuL est une surface réglée non cylindrique
le long de v # v dHuL la courbure gaussienne .Hu, vL
vض 0
.Hu, vL = 0 ó pHuL = 0
pHuL " 0 ï .Hu, vL est continue et †.Hu, vL§ assume son maximum à v = 0
c est une surface réglée ï c est régulière lorsque v " 0 ou lorsque v = 0 et pHuL " 0
la courbure gaussienne d ' une surface réglée est donnée par . =
-pHuL
IpHuL
2+v
2
M
2
212 | Surface réglée (développable) [1]
L’équation de la surface réglée développable tangente est donnée par
a : U Õ @0, 4 pD Õ !ö!3
, aHuL = ICosHuL, SinHuL,
u
5
M
c : % Õ @0, 4 pDä@0, 2D Õ !2ö!3
,
cHu, vL = aHuL + v
a' HuL
°a' HuL¥ = JCosHuL -
3 v SinHuL
10
,
3 v CosHuL
10
+ SinHuL,
u
3
+
v
10
N
l’équation de la surface réglée cylindre généralisé est donnée par
a : U Õ @0, 2 pD Õ !ö!3
, aHuL = H2 CosHuL, SinH2 uL, 0L , q = H1, 0, 1L
c : % Õ @0, 2 pDä@0, 2D Õ !2ö!3
, cHu, vL = aHuL + v q = Hv + 2 CosHuL, SinH2 uL, vL
l’équation de la surface réglée cône généralisé est donnée par
a : U Õ @0, 2 pD Õ !ö!3
, aHuL = H2 CosHuL, SinH2 uL, -2L , q = H0, 0, -1L
c : % Õ @0, 2 pDä@0, 2D Õ !2ö!3
, cHu, vL = v aHuL + q = H2 v CosHuL, v SinH2 uL, -1 - 2 vL
Surface réglée (non cylindrique) [1]
L’équation de la surface hélicoïdale est donnée par
s, d : U Õ @0, 2 pD Õ !ö!3
, sHuL = H0, 0, uL, dHuL = H CosHuL, SinHuL, 0L ,
avec dHuLä d' HuL = I0, 0, CosHuL
2 + SinHuL
2
M Hi.e.s' annule jamaisL
c : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3
, cHu, vL = sHuL + v dHuL = Hv CosHuL, v SinHuL, uL
s' HuL = H0, 0, 1L , d' HuL = H- SinHuL, CosHuL, 0L et Xs' HuL, d' HuL\ = 0 ï s est la courbe de striction
pHuL =
Xs' HuL,dHuLäd' HuL\
Xd' HuL,d' HuL\ =
CosHuL
2+ SinHuL
2
1
= 1 est le paramètre de distribution
l’équation de la surface de paraboloïde hyperbolique est donné par
s, d : U Õ @0, 2 pD Õ !ö!3
, sHuL = Hu, 0, 0L, dHuL = H 0, 1, uL ,
with dHuLä d' HuL = H1, 0, 0L Hi.e. never vanishesL
c : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3
, cHu, vL = sHuL + v dHuL = Hu, v, u vL
s' HuL = H1, 0, 0L , d' HuL = H0, 0, 1L et Xs' HuL, d' HuL\ = 0 ï s est la courbe de striction
pHuL =
Xs' HuL,dHuLäd' HuL\
Xd' HuL,d' HuL\ =
1
1
= 1 est le paramètre de distribution
Représentation des surfaces réglées planes (développables)
Représentation des surfaces réglées non cylindrique
| 213ü
6.3.4.4. Conception en utilisant les surfaces réglées
Après notre étude de surfaces réglées, nous allons montrer un projet de conception architecturale où ces
méthodes ont été utilisées pour concevoir la forme.
Conception en utilisant les surfaces réglées (homotopies sur un courbes régulières)
Les équations des courbes
a : @0, 2 pD Õ !ö!3
, aHuL = II4 CosHuL -
3
10 CosH4 uLM, I4 SinHuL -
3
10 SinH4 uLM, 4M
g : @0, 2 pD Õ !ö!3
, gHuL = H12 CosHuL, 12 SinHuL , 0L
D : @0, 2 pD Õ !ö!3
, DHuL = H3 CosHuL, 3 SinHuL, 0L
b : @0, 2 pD Õ !ö!3
, bHuL = H10 CosHuL, 10 SinHuL, 4 + 2 SinH3 uLL
Les équations des surfaces
cab : @0, 2 pDä@0, 1D Õ !2ö!3
, cabHu, vL = bHuL + v HaHuL - bHuLL
cbg : @0, 2 pDä@0, 1D Õ !2ö!3
, cbgHu, vL = gHuL + v HbHuL - gHuLL
caD : @0, 2 pDä@0, 1D Õ !2ö!3
, caDHu, vL = DHuL + v HaHuL - DHuLL
Représentation d’une conception architecturale en utilisant les surfaces réglées
214 | Plus des conceptions architecturales en utilisant surfaces réglées
L’intérêt de l’architecture dans les surfaces réglées en général et les développables (plates), en particulier
parce que leur construction peut être réalisée en utilisant des éléments plats (i.e. éléments de courbure gaussienne
nulle); qui est bien sûr moins cher et plus facile d’un point de vue pratique.
Représentation des dirigeantes de la surface qui devient les éléments structurels
Représentation d’une conception architecturale en utilisant des surfaces réglées
| 215ü
6.3.4.5. Surfaces de révolution
Notre étude des courbes asymptotiques et la définition de comment les trouver nous a conduit à l’étude des
surfaces réglées, qui, comme nous l’avons mentionné plus tôt sont d’une grande utilité dans la conception
architecturale surtout les développables. De manière similaire, notre étude des courbes principales et la
définition analytique de la façon de les trouver nous conduiraient à l’étude des surfaces de révolution, qui sont
aussi d’une grande importance dans la conception architecturale pour leur symétrie rotationnelle.
Représentation d’une surface de révolution
Surface de révolution [1]
¤un plan dans !3
, L Õ ¤est une ligne Haxe de révolutionL
et C Õ ¤un ensemble de pointsHcourbe de profilL ï & est une surface de révolution de C autour de L
Supposons ¤est le plan x - z et L est l' axe z et a : Ha, bL Õ !öC ,
aHvL = HjHvL, yHvLL est la paramétrisation de C qui est différentiable
c : %ö&, cHu, vL = HjHvL CosHuL, jHvL SinHuL, yHvLL est le paramétrage standard de &
¤›& est une courbe méridienne et L
¨ › & est une courbe parallèle
216 | Courbure de la surface de révolution (surface locale principale) [1]
a : Ha, bL Õ !ö!2
, aHvL = HjHvL, yHvLL est une courbe de profil
c : %ö&, cHu, vL = HjHvL CosHuL, jHvL SinHuL, yHvLL est le paramétrage standard de &
E, F, G, e, f , g, k1, k2, ., / sont tous constantesle long des parallèles
E = j2
, F = 0 , G = j'
2 + y'
2
, e =
-†j§ y'
j'
2+y'
2
, f = 0 ,
g =
signHjL Hj'' y'-j' y''L
j'
2+y'
2
et UHu, vL =
signHjL Hy' CosHuL-y' SinHuL,j'L
j'
2+y'
2
k1 =
e
E
=
-y'
†j§ j'
2+y'
2
, k2 =
g
G
=
signHjL Hj'' y'-j' y''L
Ij'
2+y'
2
M
3
2
, . =
-y'
2 j'' + j' y' y''
jIj'
2+y'
2
M
2
et / =
jHj'' y'-j' y''L - y' Ij'
2+y'
2
M
2 †j§ Ij'
2+y'
2
M
3
2
si aHvL = HjHvL, yHvLL a une vitesse unitaire Hi.e. " v œ Ha, bL , °aHvL¥ = 1L alors nous avons
E = j2
, F = 0 , G = 1 , e = -†j§ y' , f = 0 ,
g = signHjL Hj'' y' - j' y''L et UHu, vL = signHjL Hy' CosHuL - y' SinHuL, j'L
k1 =
e
E
=
-y'
†j§
, k2 =
g
G
= signHjL Hj'' y' - j' y''L , . =
-j''
j
et / =
1
2
JsignHjL Hj'' y' - j' y''L -
y'
†j§
N
& surface de révolution qui est minimale ï & est contenu dans un plan ou une caténoïde
Surface de révolution [1]
L’équation de la surface caténoïde est donnée par
a : U Õ @0, 2 pD Õ !ö!2
, aHvL = HjHvL, yHvLL = HCoshHvL, vL
c : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3
,
cHu, vL = HjHvL CosHuL, jHvL SinHuL, yHvLL = HCosHuL CoshHvL, SinHuL CoshHvL, vL
k1 =
e
E
= -
1
Cosh2
Hv
, k2 =
g
G
=
1
Cosh2
HvL
ï / =
k1+ k2
2
= 0 ïla caténoïde est une surface minimale
Représentation d’une surface de révolution (caténoïde)
| 217Conception utilisant la surface de révolution
Les surfaces de révolution ont été un outil fondamental de conception en architecture, c’est bien sûr très claire
dans la conception des dômes et des coupoles. Dans cet exemple, nous allons montrer la conception d’un
dôme à l’aide de la répétition d’un élément profil le long de la base circulaire et la hauteur de cet élément
profil est en relation avec sa distance par rapport au centre de la base circulaire. Cela signifie qu’il va être
identique partout, nous donnant des éléments propres de la surface de révolution.
Représentation de la répétition de l’élément profilé le long de la base circulaire
Représentation de la structure en dôme résultante
218 | Plus de conception en utilisant la surface de révolution
Maintenant, on va étendre l’idée de révolution en utilisant différentes formes de la courbe de base autre que le
cercle et les différentes positions pour le point central, ce qui conduirait à des éléments de surface non identiques,
et ne produirait pas une surface de révolution. Mais l’idée de la construction d’un élément profil le long
d’une courbe de base est toujours respectée et les résultats pourrait être intéressant du point de vue architectural.-
Représentation des composants générés sur une base carré centré et décentré
Représentation des composants générés le long de n’importe quelle forme de la courbe de base
| 219ü
6.3.4.6. Surfaces à courbure constante
Maintenant, nous allons définir les surfaces de révolution à courbure constante abord à courbure positive et
ensuite à courbure négative, pour cela nous avons besoin d’utiliser la notion de la fonction elliptique et
l’intégrale elliptique. La sphère de rayon a présente une courbure Gaussienne constante positive (. = 1ëa
2
M,
Imaginez maintenant prendre la moitié de cette sphère et le plier de différentes manières sans l’étirer, et
puisqu’il n’y a pas d’étirement la courbure gaussienne est un invariant isométrique (la sphère complète est
cependant rigide). Maintenant, nous essayons de trouver ces surfaces (dans cet exemple, les différentes demi
sphères) en trouvant des restrictions sur une paramétrisation c de &. L’intérêt de cela d’un point de vue
architectural est tout à fait évident, à savoir parce que ce sera un outil de conception très utile de trouver la
famille de surfaces qui ont la même aire, mais différentes formes.
Représentation des espaces à deux dimensions de courbures constantes négatifs, positifs et zéro
220 | Elliptic integral [1]
EHf mL = Ÿ0
f
I1 - m Sin2
HqLM2
„ q est l' intégrale elliptique du second type,
EI
p
2
mM est l' intégrale elliptique complète
" f œ Ip
2
,
p
2
M , EHf 1L = SinHfL ï EHf mL est une généralisation de la fonction sin
-ÂEHÂf -mL = Ÿ0
f
I1 - m Sinh2
HqLM2
„ q ï -ÂEHÂf -mL est une généralisation de la fonction sinh
Surfaces de révolution à courbure constante positive [1]
M Õ !3
surface de révolution, " p œ M,
.HpL =
1
a
2 ï M est contenue dans une surface & paramétrée par cHu, vL = HjHvL CosHuL, jHvL SinHuL, yHvLL
aHvL = HjHvL, yHvLL courbe de profil , jHvL = b CosI
v
a
M , yHvL = Ÿ0
v
1 -
b
2
a
2
ISin I
t
a
MM2
„t = a EJ
v
a
b
2
a
2
N
SHa, bL est une surface de révolution dont la courbe de profil est a
si b = a ï v œ Ap
2
,
p
2
E et SHa, aL est la sphère de rayon a
si b œ H0, aLï v œ @-¶, ¶D et SHa, bL est une broche Hsurfaces en forme de football L
si a œ H0, bLï v œ A-a ArcSinI
a
b
M, a ArcSinI
a
b
ME et SHa, bL est un renflement Hsurfaces en forme d ' un baril L
Surfaces de révolution à courbure négative constante [1]
M Õ !3
surface de révolution, " p œ M,
.HpL = -
1
a
2 ï M est contenue dans une surface & paramétrée par cHu, vL = HjHvL CosHuL, jHvL SinHuL, yHvLL
aHvL = HjHvL, yHvLL courbe de profil, qui a trois types
Pseudosphère
aHvL = a e
-v
a , Ÿ0
v
1 - e
-2 t
a „t , " 0 b v < ¶ et aHvL = a e
v
a , Ÿ0
v
1 - e
-2 t
a , „t , " -¶ < v b 0
Hyperboloïde
b positive , v œ A-a Sinh-1
I
a
b
M, a Sinh-1
I
a
b
ME ï jHvL = b Cosh I
v
a
M ,
yHvL = Ÿ0
v
1 -
b
2
a
2
ISinh I
t
a
MM2
„t = -Â a EJ
 v
a
-b
2
a
2
N
Conique
b œ H0, aD , v œ B-a Sinh-1
a
2-b
2
b
, a Sinh-1
a
2-b
2
b
F ï jHvL = b Sinh I
v
a
M ,
yHvL = Ÿ0
v
1 -
b
2
a
2
ICosh I
t
a
MM2
„t = -Â a
2 - b
2 EJ
 v
a
-b
2
a
2-b
2
N
| 221Les trois types de surface de révolution à courbure constante positive
on fixe a = 1ïla courbure gaussienne constante = 1
l’équation du type broche SI1, 2
3
M est donnée par
c : % Õ @0, 2 pDäAp
2
,
p
2
E Õ !2ö!3
,
cHu, vL = HjHvL CosHuL, jHvL SinHuL, yHvLL = I
2
3
CosHuL CosHvL,
2
3
SinHuL CosHvL , EIv
4
9
MM
son aire A
SJ1, 2
3
N
AI0, -
p
2
M, I2 p,
p
2
ME = 8.377
l’équation du type sphère SH1, 1L est donnée par
c : % Õ @0, 2 pDäAp
2
,
p
2
E Õ !2ö!3
,
cHu, vL = HjHvL CosHuL, jHvL SinHuL, yHvLL = HCosHuL CosHvL, SinHuL CosHvL , EHv 1LL
son aire A SH1,1LAI0, -
p
2
M, I2 p,
p
2
ME = 4 p
l’équation du type renflement SI1, 3
2
M est donnée par
c : % Õ @0, 2 pDäA-ArcSinI
2
3
M, ArcSinI
2
3
ME Õ !2ö!3
,
cHu, vL = HjHvL CosHuL, jHvL SinHuL, yHvLL = I
3
2
CosHuL CosHvL,
3
2
SinHuL CosHvL ,
2
3
EIv
9
4
MM
l’équation du type renflement SH1, 2L est donnée par
c : % Õ @0, 2 pDäA-ArcSinI
1
2
M, ArcSinI
1
2
ME Õ !2ö!3
,
cHu, vL = HjHvL CosHuL, jHvL SinHuL, yHvLL = H2 CosHuL CosHvL, 2 SinHuL CosHvL , EHv 4LL
l’équation du type renflement SH1, 3L est donnée par
c : % Õ @0, 2 pDäA-ArcSinI
1
3
M, ArcSinI
1
3
ME Õ !2ö!3
,
cHu, vL = HjHvL CosHuL, jHvL SinHuL, yHvLL = I3 CosHuL CosI
3 v
2
M, 3 SinHuL CosI
3 v
2
M , EHv 9LM
leur aires A
SJ1, 3
2
N
AI0, -ArcSinI
2
3
MM, I2 p, ArcSinI
2
3
MME =
A SH1,2LAI0, -ArcSinI
1
2
MM, I2 p, ArcSinI
1
2
MME = A SH1,3LAI0, -ArcSinI
1
3
MM, I2 p, ArcSinI
1
3
MME = 4 p
Représentation des trois types de surface de révolution à courbure constante positive
222 | Les trois types de surface de révolution à courbure négative constante
on fixe a = 1ïla courbure gaussienne constante = -1
the equation of the pseudo sphere type is given by
c : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3
,
cHu, vL = HjHvL CosHuL, jHvL SinHuL, yHvLL = ICosHuL SinHvL, SinHuL SinHvL , CosHvL + LogITanI
v
2
MMM
son aire A@H0, 0L, H2 p, 2 pLD = 25.132
the equation of the hyperboloid type is given by
c : % Õ @0, 2 pDäA-ArcSinh-1
H1L, ArcSinh-1
H1LE Õ !2ö!3
,
cHu, vL = HjHvL CosHuL, jHvL SinHuL, yHvLL = HCosHuL SinHvL, SinHuL SinHvL , -Â EHÂ v -1LL
son aire AAI0, -ArcSinh-1
H1LM, I2 p, ArcSinh-1
H1LME = 17.519
the equation of the conic type is given by
c : % Õ @0, 2 pDäA-ArcSin-1
I 3 M, ArcSin-1
I 3 ME Õ !2ö!3
cHu, vL = HjHvL CosHuL, jHvL SinHuL, yHvLL = K
1
2
CosHuL SinhHvL,
1
2
SinHuL SinhHvL , -
 3
2
EJÂ v
-1
2 3
NO
son aire AAI0, -ArcSin-1
H2LM, I2 p, ArcSin-1
H2LME = 1.91
Représentation des trois types de surface de révolution à courbure négative constante
| 223ü
6.3.4.7. Surfaces minimales
Dans cette section, nous allons étudier une autre propriété importante d’analyse de surface qui est pratique
dans la conception architecturale, à savoir la capacité à trouver la surface minimale dans une famille de
surfaces. Une surface minimale est une surface d’aire minimale au sein d’une famille de surfaces, et elles est
aussi une surface dont la courbure moyenne est identiquement nulle. Afin de montrer l’équivalence de ces
deux définitions, nous devons définir la fonction de la variation normale qui représente la façon dont la
surface & change lorsqu’elle est tiré dans le sens normal, et comment la courbure moyenne est nulle si et
seulement si la dérivée première de la fonction de l’aire s’annule.
Domaine borné et région [1]
& Õ !n
surface régulière ,
O Õ & est un ouvert connexe HdomaineL f : S
1 ö fIS
1
M = #O la frontière de O,
f homéomorphisme différentiable
l' application tangente f* " 0 sauf pour un nombre fini de points, et D = O ‹ #O est une région de &
D est bornée si $ m œ ! " p œ D , °p¥ § m
c : %ö & est une surface locale réguliere, D Õ & est une région bornée
AHDL = Ÿc
-1
HDL
E G - F
2 d u d v = Ÿc
-1
HDL
°cu ä cv¥ d u d v est l' aire de D
Variation normale et la disparition courbure moyenne [1]
c : %ö !3
est une surface locale réguliere, W Õ % est une région bornée,
h : W ö ! différentiable, e > 0 , U est la normale unitaire
c : H-e, eLä W ö !3
, cHtL Hu, vL = cHu, vL + t hHu, vL UHu, vL est la variation normale de c et W
EHtL = Xc HtLu
, c HtLu
\ ,
FHtL = Xc HtLu
, c HtLv
\ et GHtL = Xc HtLv
, c HtLv
\ pouresuffisamment petite EH0L = E, FH0L = F et GH0L = G
AHtL = ŸW
EHtL GHtL - FHtL
2 d u ä d v est l' aire de cHtL Hu, vL
A' H0L = -2 ŸW
h / E G - F
2 d u ä d v , où / est la courbure moyenne
c est minimal sur W ó A' H0L = 0 pour une variation normale de c et W par rapport à toute h : W ö !
Représentation de la surface Enneper (exemple d’une surface minimale)
224 | ü
6.4. Références
[1] Modern differential geometry of curves and surfaces, Alfred Gray, CRC Press, 1993
[2] Cours de Calcul différentiel et équations différentielles, Mireille Chaleyat-Maurel, Université Paris
Descartes, Paris, 2011
[3] Cours de Géométrie Différentielle, Laurent Charles, Université Pierre et Marie Curie, Paris, 2012
[4] Cours de Géométrie et topologie Différentielles, Alexandru Oancea, Université Pierre et Marie Curie,
Paris, 2013
[5] Cours de Théorie des systèmes dynamiques, Jean-Pierre Françoise, Université Pierre et Marie Curie, Paris,
2012
[6] Cours de Géométrie Riemannienne, Alexandru Oancea, Université Pierre et Marie Curie, Paris, 2013
[7] Cours d’Intégration et théorie de la mesure, Valentine Genon-Catalot, Université Paris Descartes, Paris,
2011
[8] Tracing surface intersection with validated ODE system solver, H.Mukundan, K.H.Ko, T.Maekawa,
T.Sakkalis, N.M.Patrikalakis, MIT, Cambridge, 2004
| 2257. Opérations algorithmiques
ü
7.1. Dessin automatisé
Après avoir défini une palette d’opérations (algébrique et analytique), nous allons maintenant définir certaines
opérations algorithmiques qui utilisent dans une large mesure à la fois les deux autres opérations. Les opérations
algorithmiques sont probablement les plus accessibles pour les architectes car elles sont moins abstraites
que les opérations algébriques et analytiques. Dans cette partie de l’étude, nous allons voir quelques applications
architecturales des propriétés définies dans les chapitres précédents qui étaient assez abstraites et loin du
domaine architectural. Les algorithmes sont rien d’autre que des ensembles d’instructions qui peuvent être
exécutées automatiquement et souvent de manière itérative, pour cette raison, ils sont les méthodes utilisées
pour accomplir des tâches répétitives avec une grande précision et pour un grand nombre de fois. Les opérations
algorithmiques traite des objets géométriques discrets en utilisant des méthodes computationnelles donc
elles sont naturellement liés à des notions de géométrie discrète et combinatoire, ainsi que la géométrie
computationnelle. Les géométries discrètes et combinatoires sont des branches de géométrie qui étudient les
propriétés combinatoires et des méthodes constructives des objets géométriques discrets, tandis que la
géométrie computationnelle est une branche de l’informatique consacrée à l’étude des algorithmes qui peuvent
être déclaré en termes de la géométrie. La géométrie computationnelle peut être divisé en géométrie computationnelle
combinatoire et numériques; la computationnelle combinatoire est naturellement porté sur l’utilisation
des algorithmes pour résoudre des problèmes combinatoires. Alors que la géométrie computationnelle
numérique (aussi connu comme la modélisation géométrique) est plus soucieux de la modélisation et la
représentation des courbes et des surfaces en utilisant des méthodes paramétriques telles que splines de Bézier
et NURBS. Il existe de nombreuses façons d’appliquer les opérations algorithmiques dans l’architecture, mais
nous allons définir deux directions principales que nous allons appeler: le dessin automatisé et la méthode de
recherche. Le dessin automatisé est essentiellement d’automatiser le processus de dessin des éléments répétitifs,
un exemple classique de cela, sera le dessin de panneaux, fenêtres, poutres, escalier, etc. Cette pratique a
connu une croissance très populaire récemment auprès des architectes en raison du développement de logiciels
basé sur des scripts qui permet aux architectes de réaliser ces tâches. Dans le dessin automatisé, nous allons
utiliser des notions et des techniques de la géométrie combinatoire et computationnelle, par exemple créer des
pavages et de trouver le point le plus proche d’un point donné dans un ensemble fini. Mais avant d’entrer dans
les techniques combinatoires et computationnelles, nous allons montrer comment créer des surfaces qui
peuvent être utilisés comme des éléments architecturaux dans la peau générale défini par la surface principale.
Jusqu’ici, nous avons été préoccupés seulement par la création de cette surface principale qui pourrait être
comprise comme l’enveloppe du bâtiment, mais bien sûr, la conception architecturale est non seulement la
conception de l’enveloppe extérieure, il comprend également la conception de l’organisation interne, par
exemple escalier et subdivisions internes. Nous tenons à regrouper ces opérations relatives à l’organisation
interne avec les opérations algorithmiques, même si elles ne sont pas entièrement computationnelles, c’est
parce qu’ils traitent des surfaces séparées (éléments), par exemple, les niveaux différents de sol ou des étapes
dans un escalier. Après ceux-ci nous allons nous concentrer davantage sur les techniques computationnelles et
combinatoires à générer des motifs d’objets architecturaux. Dans la deuxième partie de ce chapitre à savoir la
méthode de recherche, nous allons explorer les techniques des optimisations et nous aurons un supplément de
la biologie de l’évolution afin de nous aider à comprendre les origines de la terminologie dans les algorithmes
génétiques. Pour le moment, nous commençons avec le dessin automatisé pour créer des éléments d’organisation
interne.
226 | ü
7.1.1. Organisation interne
ü
7.1.1.1. Circulation verticale
La première de ces applications serait la création d’éléments d’organisation interne de base par exemple des
connexions verticales comme les escaliers et les séparateurs d’espace comme les surfaces de séparation
verticales et horizontales.
L’équation du cylindre de base est donnée par
c : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3
, cHu, vL = ICosHuL, SinHuL,
v
2
M
Ii = AHi - 1L I 2 p
2 m
M, HiL I 2 p
2 m
ME, lesintervalles de i = 1, ..., 2 m, où m est le nombre d ' étages
l' équation de la courbe plane par morceaux g dont la trace se situe dansle domaine Hm = 3L
est donnée par g : U Õ @0, 2 pD Õ !ö!2
, gHtL = HuHtL, vHtLL
si t œ I1, gHtL = It, 2 t -
0
3
2 pM, si t œ I2, gHtL = It,
1
3
2 pM
si t œ I3, gHtL = It, 2 t -
1
3
2 pM, si t œ I4, gHtL = It,
2
3
2 pM
si t œ I5, gHtL = It, 2 t -
2
3
2 pM, si t œ I6, gHtL = It,
2
3
2 pM
l' équation de la courbe par morceaux dansle cylindre est aHtL = cHuHtL, vHtLL
si t œ I1, aHtL = ICosHtL, SinHtL,
1
2
I2 t -
0
3
2 pMM, si t œ I2, aHtL = ICosHtL, SinHtL,
1
2
I
1
3
2 pMM
si t œ I3, aHtL = ICosHtL, SinHtL,
1
2
I2 t -
1
3
2 pMM, si t œ I4, aHtL = ICosHtL, SinHtL,
1
2
I
2
3
2 pMM
si t œ I5, aHtL = ICosHtL, SinHtL,
1
2
I2 t -
2
3
2 pMM, si t œ I6, aHtL = ICosHtL, SinHtL,
1
2
I
2
3
2 pMM
l' équation de la surface est un escalier YHt, uL = cHuHtL, vHtLL + u †lHtL§ cNHuHtL, vHtLL
où lHtL = 1 est une fonction scalaire et cNHuHtL, vHtLL est la normale à la surface du cylindre restreinte à a
si t œ I1, YHt, uL = ICosHtL H1 + uL, SinHtL H1 + uL,
1
2
I2 t -
0
3
2 pMM,
si t œ I2, YHt, uL = ICosHtL H1 + uL, SinHtL H1 + uL,
1
2
I
1
3
2 pMM
si t œ I3, YHt, uL = ICosHtL H1 + uL, SinHtL H1 + uL,
1
2
I2 t -
1
3
2 pMM,
si t œ I4, YHt, uL = ICosHtL H1 + uL, SinHtL H1 + uL,
1
2
I
2
3
2 pMM
si t œ I5, YHt, uL = ICosHtL H1 + uL, SinHtL H1 + uL,
1
2
I2 t -
2
3
2 pMM,
si t œ I6, YHt, uL = ICosHtL H1 + uL, SinHtL H1 + uL,
1
2
I
2
3
2 pMM
Représentation de l’élément de circulation verticale
| 227ü
7.1.1.2. Séparation et la division de l’espace
Après l’escalier, nous allons définir les murs et les sols qui divise l’espace interne
l’équation de la surface de base est donnée par
c : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3
cHu, vL = I
3
2
ICosHuL +
5
2
CosI
u
2
M
8
M I2 +
35
100 CosI
v
2
MM I1 - CosI
v
2
M
6
+ SinI
v
2
MM,
3 SinHuL I2 +
35
100 CosI
v
2
MM I1 - CosI
v
2
M
6
+ SinI
v
2
MM, v - SinHvLM
les points dans le domaine % Õ [0, 2 p]ä[0, 2 p]
q1 = I0, 3 p
5
M, q2 = I0, 11 p
10 M, q3 = Ip,
3 p
5
M, q4 = Ip,
11 p
10 M, q5 =
q2+q4
2
, q6 = I2 p,
3 p
5
M, q7 =
q3+q6
2
les équations des courbes dans le domaine
d : U Õ @0, 2 pD Õ !ö!2
, dHtL = q2 +
t
2 p
Hq5 - q2L = Hd1HtL, d2HtLL
s : U Õ @0, 2 pD Õ !ö!2
, sHtL = q4 +
t
2 p
Hq5 - q4L = Hs1HtL, s2HtLL
h : U Õ @0, 2 pD Õ !ö!2
, hHtL = q3 +
t
2 p
Hq7 - q3L = Hh1HtL, h2HtLL
q : U Õ @0, 2 pD Õ !ö!2
, qHtL = q6 +
t
2 p
Hq7 - q6L = Hq1HtL, q2HtLL
g : U Õ @0, 2 pD Õ !ö!2
, gHtL = q1 +
t
2 p
Hq2 - q1L = Hg1HtL, g2HtLL
b : U Õ @0, 2 pD Õ !ö!2
, bHtL = q3 +
t
2 p
Hq4 - q3L = Hb1HtL, b2HtLL
les équations des éléments de séparation (murs et sols)
cw : % Õ @0, 2 pDä@0, 1D Õ !2ö!3
, cwHt, uL = cHg1HtL, g2HtLL + u HcHb1HtL, b2HtLL - cHg1HtL, g2HtLLL
cf1
: % Õ @0, 2 pDä@0, 1D Õ !2ö!3
, cf1
Ht, uL = cHd1HtL, d2HtLL + u HcHs1HtL, s2HtLL - cHd1HtL, d2HtLLL
cf2
: % Õ @0, 2 pDä@0, 1D Õ !2ö!3
, cf2
Ht, uL = cHh1HtL, h2HtLL + u HcHq1HtL, q2HtLL - cHh1HtL, h2HtLLL
Représentation des éléments de séparation et de division de l’espace
228 | ü
7.1.1.3. Renflement et transition douce
Après les murs et les sols qui divise l’espace intérieur, nous allons définir une manière plus fluide pour
désigner les différentes zones de l’espace, un peu comme un paysage avec des renflements.
l’équation de la surface de base est donnée par
c : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3
cHu, vL = Iv CosHuL I 13
10 + CosHuL
5
M I1 +
1
2
SinH2 uL
3
M, v SinHuL I 13
10+ CosHuL
5
M I1 +
1
2
SinH2 uL
3
M, 3 SinI
v
2
MM
l’équation de la surface renflée
h1, h2 : U Õ @0, 2 pD Õ !ö!, h1HuL = SinI
Hp+uL
2
M
10 and h2HvL = SinI
v
2
M
10
cL : % Õ @0, 2 pDä@0, 2 pD Õ !2ö!3
cLHu, vL = Jv CosHuL J 13
10
+ CosHuL
5
N J1 +
1
2
SinH2 uL
3
N, v SinHuL J 13
10
+ CosHuL
5
N J1 +
1
2
SinH2 uL
3
N, 3 SinI
v
2
M h1HuL h2HvLN
Représentation de la surface renflée
Maintenant, nous allons montrer un exemple concret où la fonction de renflement a été utilisé pour générer
des variations de la surface du sol qui peuvent être utilisés à différentes fins architecturales par exemple des
éléments de sièges.
Représentation de l’utilisation architecturale de la fonction de renflement
| 229ü
7.1.2. Tâches répétitives
ü
7.1.2.1. Opération géométrique répétée
Une autre forme de dessin automatisé est faire des tâches répétitives, nous démontrons dans l’exemple suivant:
le calcul de l’intersection d’un ensemble de droites et les plans d’un cube; ici ces droites sont tangentes à
une courbe spirale contenue dans le cube.
k = 4; max = 10; b = 81, 1, 1<; a = 8max ê 2, max ê 2, 0< + b;
Tmin = -0.5; Tmax = 1.; ndiv = 200; Ts = 0.0;
Tstep = HTmax - TminL ê ndiv;
F@T_D := a + 8Exp@TD Cos@8 TD, Exp@TD Sin@8 TD, 4 Exp@TD<;
G@T_D := 8Cos@8 TD - 8 Sin@8 TD, Sin@8 TD + 8 Cos@8 TD, 4<;
L@T_, t_D := F@TD + t G@TD;
cPlnorth@u_, v_D := 8u, max, v<;
cPlsouth@u_, v_D := 8u, 0, v<;
cPleast@u_, v_D := 8max, u, v<;
cPlwest@u_, v_D := 80, u, v<;
cPlbottom@u_, v_D := 8u, v, 0<;
cPlup@u_, v_D := 8u, v, max<;
TabL = Table@L@T, tD, 8T, Tmin, Tmax, Tstep 0, RandomInteger@81, ia 0, RandomInteger@81, ib 0, RandomInteger@81, ic,
MeshStyle Ø 88Thickness@0.002D, White<, 8Thickness@0.002D, White<<, BoundaryStyle Ø 8Thickness@0.008D, White<,
PlotRange Ø All, PlotLabel Ø 9"n°" , p=, Boxed Ø False, Axes Ø FalseF;
ParamVal@@pDD = 99"n°" , p=, 8JT, !r, ia, ixa, ib, ixb, ic, ixc, !b, !o, !a, !c, !d, ra, rb, rc, ha, !r, rr, hr<=;
, 8p, 1, Apocalypse 1, If@WinDist < Test, Chosen = WinDist; ChosenT = WinPt, Chosen = Test; ChosenT = 8Ps@@kDD, s@@kDD 1, If@WDist < Dees@@k, 1DD, kozen = WDist; kozenI = WI, kozen = Dees@@k, 1DD; kozenI = kDD;
WDist = kozen; WI = kozenI;
, 8k, 1, n est un groupe cyclique sousla multiplication de l' ordre n
Groupe dièdre [3]
pour tout polygone régulier à n arête,
il possède 2 n différent symétriesHn symétries de rotation et n symétries de réflexionL
Dn = Xr, s\ = 9r
k
s
l
r
n = 1, s
2 = 1 et s
-1
r s = r
-1
= lesrotations et lesréflexions des ce polygone associés
Groupe «wallpaper» [4]
E2 groupe de symétrie du plan euclidien, L Õ !2
est un réseau à 2 dimensions
W Õ E2 est un groupe de «wallpaper» sison sous - groupe de translation
H est engendré par deux translation indépendant etson groupe ponctuel J est fini
L = 9y œ !2 h œ H , y = hH0"2 L = = 9n t1 + m t2 n, m œ Z , H t1, t2L une base de !2
=
il n' y a que 5 types de réseaux : obliques, rectangulaire, rectangulaire centrée, carrées et hexagonales
Théorème de restriction cristallographique [4]
L’ordre de rotation dans un groupe de «wallpaper» ne peut être que 2,3,4 ou 6
On note les groupes «wallpaper» avec la notation cristallographique, le nom complet est composé de quatre
symboles: le premier symbole représente le type de réseau, p pour pour primitive et c centrée. Ceci est suivi
par un chiffre n indiquant les symétrie de rotation: 1 (aucun), 2, 3, 4 ou 6, les deux symboles suivants sont soit
m, g ou 1. Un m Hou gL à la place de la troisième symbole signifie qu’il y a une ligne de réflexion (ou une
ligne de réflexion glissée) perpendiculaire à l’axe x, tandis que 1 signifie qu’il n’y a pas de ligne de n’importe
quel type. Enfin, le dernier symbole m Hou gL représente une ligne de réflexion (ou une ligne de réflexion
glissée) à un angle a avec l’axe x, l’angle dépend du plus grand ordre de rotation comme suit: a = 90°
pour
n = 1, 2; a = 60°
pour n = 3, 6; a = 45°
pour n = 4. La courte notation supprime des chiffres ou un m qui peut
être déduit. Par exemple, le groupe p 3 m 1 représente un groupe avec 120°
rotation, une ligne de réflexion
perpendiculaire à l’axe x, et aucune réflexion ou ligne de réflexion glissée à un angle de 60°
. Les opérateurs de
chaque groupe de «wallpaper» utilisent le symboles bien établis présentés dans le tableau suivant.
248 | Les groupes de «wallpaper»
Représentation des opérateurs des groupes de «wallpaper»
Dans les groupes de «wallpaper», nous avons trois types de réseaux: obliques, carrées et hexagonales, ce qui
est naturel parce que nous l’avons mentionné plus tôt que les seuls pavages réguliers du plan sont carré,
triangulaire et hexagonale, et chacun des groupes de «wallpaper» en avoir un de ces pavages réguliers comme
son réseau.
Wallpaper group crytallographic shortened point group underneath lattice
1 p1 1 C1 oblique
2 p2 2 C2 oblique
3 pm m D1 rectangular
4 pg m D1 rectangular
5 cm m D1 rectangular
6 p2mm 2 mm D2 rectangular
7 p2mg 2 mm D2 rectangular
8 p2gg 2 mm D2 rectangular
9 c2mm 2 mm D2 rectangular
10 p4 4 C4 square
11 p4mm 4 mm D4 square
12 p4gm 4 mm D4 square
13 p3 3 C3 hexagonal
14 p3m1 3 m D3 hexagonal
15 p31m 3 m D3 hexagonal
16 p6 6 C6 hexagonal
17 p6mm 6 mm D6 hexagonal
Représentation des 17 groupes de «wallpaper» avec leurs notations et réseaux
| 249ü
7.1.4.3. Conception en utilisant le groupe de «wallpaper»
Nous allons maintenant mettre l’accent sur l’un de ces groupes afin de montrer comment l’utiliser dans la
conception architecturale, le groupe, nous allons étudier est p 3 m 1. Ce groupe a un groupe ponctuel D3, un
réseau hexagonal, trois centres rotation différentes d’ordre 3 et trois réflexions dans les trois côtés d’un
triangle équilatéral, et trois réflexions de glissées dans trois directions distinctes, dont les axes sont situés en
mi-chemin entre les axes parallèles adjacents de réflexion. Le réseau hexagonal est construite par les vecteurs
8t1, t2< où t1est un vecteur de longueur minimum et t2 = RHt1L, avec R une rotation de 120°
. si J = D3, alors
groupe ponctuel contient trois réflexions; avec les lignes de réflexions séparées par des angles de 60°
, comme
M est une réflexion dans D3, alors M R est une réflexion dont la ligne de réflexion fait un angle de 60°
avec
celle de M. Les lignes de réflexion pour D3 doivent être des lignes de réflexion pour D6 car D3 est un sousgroupe
de D6; cela indique que D3 peut agir de deux façons par rapport à un réseau hexagonal proposée. Les
lignes de réflexion peuvent être 30°
, 90°
et 150°par rapport au t1. La rotation par 120°
et la ligne de réflexion
sur 30°
génèrent le groupe D3,l
, où l signifie longue. Ce groupe contient une ligne de réflexion sur 150°
, qui est
la grande diagonale du parallélogramme et le groupe de «wallpaper» associé à D3,l
est p 3 m 1. De même, les
lignes de réflexion peuvent être 0
°
, 60°
et 120°
par rapport au t1. La rotation par 120°
et la ligne de réflexion
sur 0
°
génèrent le groupe D3,s
, où s signifie court. Ce groupe contient une réflexion sur 60°
, qui est la petite
diagonale du parallélogramme et le groupe de «wallpaper» associé à D3,s
est p 3 1 m.
Représentation d’un pavage utilisant le groupe de «wallpaper» p 3 m 1 et montrent la domaine fondamental
Les paramètres de l' option choisie
JT = 0.3, !r = 1,
ia = 0, ix a = 1, ib = 3, ix b = 1, ic = 2, ix c = 2,
!b = 0.08, !o = 1,
!a = 0.9, !c = -0.6, !d = 0.3,
ra = 2.5, rb = 2.9, rc = 2,
ha = 2, !r = 0.11, rr = 1, hr = 2
250 | Même que nous avons fait pour générer un grand nombre de surfaces qui sont candidats à la forme générale
d’une conception à l’aide d’un petit algorithme, nous pouvons utiliser un autre algorithme pour automatiser le
processus de dessin des éléments répétitifs. Par exemple, si nous tenons à couvrir la surface de la robe avec le
pavage ci-dessus, nous aimerions écrire les instructions pour dessiner un élément, puis un processus itératif
pour dessiner le reste.
L’algorithme de pavage de la surface
Un = 2 p ; Vn = p J 3 N;
A = 7 H6L; ndu = A; ndv = A; us = Un ê ndu; vs = Vn ê ndv;
F@u_, v_D := FocBu,
2 v
3
F;
p = Table@F@u, vD, 8u, 0, Un, us<, 8v, 0, Vn, vs 0 " x œ A avec °x - x
*
¥ § d ï f Hx
*
L § f HxL
x
*
est un maximum local si $ d > 0 " x œ A avec °x - x
*
¥ § d ï f Hx
*
L ¥ f HxL
Un grand nombre d’algorithmes proposés pour résoudre des problèmes non convexes ne sont pas capables de
faire la distinction entre les solutions optimales locales et la solution optimale globale, les algorithmes et les
méthodes utilisées dans la résolution de ces problèmes non convexes (c’est à dire la convergence vers une
solution optimale en un temps fini) appartiennent à la domaine de l’optimisation globale. Il existe trois
approches principales pour les problèmes d’optimisation globale: méthodes déterministes comme les méthodes
de plan de coupe, les méthodes stochastiques comme les méthodes de Monte Carlo et (méta) heuristiques
comme les algorithmes évolutionnaires. Dans cette recherche, nous allons nous concentrer principalement sur
stochastiques et (méta) heuristiques, spécialement les algorithmes évolutionnaires.
La méthode de Newton [6]
f : !n Ø !n C
1
et f ' HxL ! 0, x œ !n
supposons f HxL = x
2 - a ï f ' HxL = 2 x ï xn +1 = xn -
f Hxn L
f ' Hxn L
=
1
2
Ixn -
a
xn
M avec xn Ø
nض
a
l' équation de la limite : x = x - C f HxL, avec C =
1
f ' HxL
, nous allonsl' utiliser pour trouver la solution de f HxL = x
2 - 3
f@x_D := x
2 - 3; df@f_D@x_D := Evaluate@!x f@xDD xo = 10.0; xp = xo;
DoBxc = xp -
f@xpD
df@fD@xpD
; If@xc == xp, x! = xc; Break@D, xp = xcD;, 8i, 1, 20 OP, OP = OC; Hom@@kDD = OC; NInd = NInd + 1;
ODess@@kDD = Table@Graphics@Comp@@iDDD, 8i, 1, ndu OP,
OP = OC;
OV@@pDD = OC;
OF@@pDD = ParametricPlot3DBcScarlet@a, r, m, b, n, k, c, d, eD@u, vD,
8u, 0, 2 p<, 8v, 0, 2 p<, PlotStyle Ø 8Black<, Mesh Ø :RangeB0, 2 p,
2
20
pF, RangeB0, 2 p,
2
10
pF>,
MeshStyle Ø 88Thickness@0.001D, White<, 8Thickness@0.001D, White<<, BoundaryStyle Ø 8Thickness@0.008D, White<,
PlotRange Ø All, PlotLabel Ø 9"n°" , p=, Boxed Ø False, Axes Ø FalseF;
RGraph@@pDD = 8p, OC<;
NInd = NInd + 1;
, OP = OP;
OV@@pDD = 0;
F;
, 8p, 1, Apocalypse.
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’eort d’une part et de la pertinence de leurs remarques d’autre part. D’autant
que Carsten l’a fait dans une langue étrangère et Yves avec bienveillance.
Les discussions avec Hugo m’ont toujours énormément éclairé sur comment aborder une
question en conservant ma manière de penser ; vision, il me semble, que nous partageons.
Ce manuscrit n’est « pas si pire » grâce à Pierre Letouzey qui m’a oert un peu de la
rigueur qui fait tenir Coq debout pour relire exhaustivement ma thèse. Le reste de l’équipe
πr 2 Yann, Matthieu, Alexis, Pierre-Louis, Pierre-Marie, Lourdes, Guillaume, Matthias, Sté-
phane, Vincent ont tous joué un rôle dans l’écriture et/ou la conception de cette thèse et de
sa soutenance. Christine, Frédérique et Thomas ont aussi beaucoup aidé à la genèse de ce
document.
Fernand Deligny (pédagogue) disait « Soit surtout présent lorsque tu n’es pas là. » C’est
le tour de force que réussit Christine Paulin-Mohring avec l’équipe de développement de
Coq ! Bien que nos échanges directs soient récents, son inuence ne l’est pas et je la remercie
chaleureusement d’évaluer mon travail.
Mon cerveau a été scientiquement façonné par Conor McBride. Mes quelques idées originales
trouvent leur source dans sa folie. Avant lui, Daniel Hirschko (avec l’ensemble
de l’équipe PLUME) m’avait dénitivement fait tomber dans les bras de la programmation
comme support du raisonnement. Daniel fut aussi ma boussole aux moments clés de mon
cheminement scientique.
Daniel et Roberto Di Cosmo, qui m’honore de la présidence de mon jury, furent, de mes
enseignants d’informatique, ceux qui m’ont le plus marqué. J’estime que l’enseignement fut
une part importante de mon travail de thèse et je pense que si elle fut si plaisante, c’est grâce
à leur modèle auxquel j’ai pu me raccrocher.
Mes études supérieures doivent énormément au cadre dans lequel elles ont eu lieu. Il me
faut donc remercier l’ENS Lyon et le Lycée Fenelon (et donc ceux qui les font ainsi) pour
m’avoir d’abord séduit au premier regard, puis pour m’être fait me dire que même rentré
par la fenêtre, l’année d’après j’y serai et enn pour ne m’avoir, mais alors pas du tout, déçu
ensuite !
A tous les niveaux, les établissements que j’ai fréquentés tenaient debout grâce à leur
responsable administratif. Merci pour tout ce travail de l’ombre !
Ma famille m’a donné la possibilité d’un épanouissement personnel rare. Mes parents ont
réussi le tour de force de toujours m’encourager à être moi-même sans jamais abandonner
l’idée d’améliorer mes torts. Je me suis construit grâce à leur persévérance. Toute la famille
5m’a énormément soutenu et me dire « nis ta thèse pour qu’ils puissent un peu se dire que tu
n’as pas gâché toute la liberté qu’ils t’ont ménagée » a été l’un des moteurs irrationnels forts
pour mener l’aventure au bout. Sneusneur est aussi à un tournant qu’elle devrait surmonter
très fort, nous avons toujours fonctionné en symbiose.
Ma thèse et beaucoup plus doivent quotidiennement énormément à Maud.
6Table des matières
Introduction 9
Logiques constructives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Quantication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
La généralisation : les inductifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Correspondance preuves/programmes . . . . . . . . . . . . . . . . . . . . . . . . . 11
Machines universelles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Programmation fonctionnelle avec types algébriques . . . . . . . . . . . . . . . . . 12
Types riches . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Utilisation des données inductives . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Réduction des points xes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1 Un langage fonctionnel avec types riches 17
1.1 Conventions d’écriture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2 Le cœur fonctionnel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2.1 Syntaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.2.3 Typage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3 Déclarations globales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3.1 Syntaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.3.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.3.3 Typage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.4 Types de données algébriques strictement positifs . . . . . . . . . . . . . . . 21
1.4.1 Syntaxe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.4.2 Evaluation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.4.3 Typage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
1.5 Des structures de données d’exemple . . . . . . . . . . . . . . . . . . . . . . 24
1.6 Digression sur la représentation des constructeurs et des branches . . . . . . 26
1.7 Expressivité de l’analyse de cas . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2 Le filtrage en programmation fonctionnelle 29
2.1 Principe du ltrage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2 Reconnaitre un motif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.3 Construire un arbre de décision . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.1 Arbre de décision . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.2 Mécanique d’atomisation . . . . . . . . . . . . . . . . . . . . . . . . 34
7Table des matières
3 Encodage du filtrage dans l’analyse de cas 37
3.1 Le ltrage dépendant primitif . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.2 Encodage du ltrage par des analyses de cas . . . . . . . . . . . . . . . . . . 38
3.2.1 Des types riches exprimant les problèmes d’unication . . . . . . . . 39
3.2.2 Manipulation des égalités d’index . . . . . . . . . . . . . . . . . . . . 40
3.3 Utilisabilité de l’encodage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4 Constructions génériques autour d’une analyse de cas dépendante . . . . . . 42
3.4.1 Coupures entrelacées . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.4.2 Elimination des branches impossibles . . . . . . . . . . . . . . . . . . 43
4 Du filtrage à l’analyse de cas structurellement 45
4.1 Squelette d’index . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.2 Quand les égalités sont inutiles . . . . . . . . . . . . . . . . . . . . . . . . . . 45
4.3 Diagonalisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
4.4 Quand le diagonaliseur en dit trop . . . . . . . . . . . . . . . . . . . . . . . . 52
4.5 Des clauses de retour pour éliminer tous les termes . . . . . . . . . . . . . . 53
4.5.1 Les index du type ne contiennent que des variables et des constructeurs 53
4.5.2 Hors du cadre pseudo-motif . . . . . . . . . . . . . . . . . . . . . . . 54
4.6 Digression sur les cas impossibles dans des points xes . . . . . . . . . . . . 55
4.7 Mécaniser la diagonalisation et compiler le ltrage . . . . . . . . . . . . . . . 56
4.7.1 Construire une analyse de cas à partir de sa clause de retour . . . . . 56
4.7.2 D’un arbre de décision à des analyses de cas . . . . . . . . . . . . . . 57
4.7.3 Extraire un diagonaliseur . . . . . . . . . . . . . . . . . . . . . . . . 59
4.8 Eléments de correction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5 Simplifier un terme 63
5.1 Normalisation en appel par nom . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.2 Trace des constantes dépliées . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.3 Refolding Algebraic Krivine Abstract Machine . . . . . . . . . . . . . . . . . 69
5.4 Congurabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
5.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6 Etablir qu’un point fixe ne produit pas de calcul infini 75
6.1 Décroissance structurelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
6.2 Ranement lié à l’induction . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
6.3 Ranement lié aux coupures entrelacées . . . . . . . . . . . . . . . . . . . . 81
6.4 Ranement lié à la réduction . . . . . . . . . . . . . . . . . . . . . . . . . . 82
6.4.1 Garder la forme βιδ normale . . . . . . . . . . . . . . . . . . . . . . . 82
6.4.2 Retrouver la réduction forte . . . . . . . . . . . . . . . . . . . . . . . 84
6.4.3 Questions d’ecacité . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.5 La règle ϕ de réduction impose une garde structurelle . . . . . . . . . . . . . 86
Conclusion et perspectives 89
8Introduction
Aucune tâche n’est atomique. Toute action se décompose en opérations plus élémentaires.
Agir demande en permanence de concevoir des algorithmes an de réaliser des activités complexes.
Le concept de programme et son exécution ou calcul est bien antérieur à l’apparition
des ordinateurs. L’informatique, la science qui les étudie, n’a donc pas attendu des machines
aussi complexes pour susciter l’intérêt. La mécanisation n’a fait que démultiplier le besoin
d’y rééchir formellement.
L’humain a le souci de l’optimisation. Dès qu’il trouve un algorithme, il se demande comment
faire la même chose en moins d’étapes ou par d’autres moyens.
Pourtant, après modications, l’algorithme réalise-t-il eectivement toujours « la même
chose » ?
Nos cousins shadocks arment que « Plus un ordinateur va vite, plus il donne de bons
résultats. . . ». Laissons-leur l’ambiguïté sur la notion de bon résultat et le pied de nez que
j’y vois à mon ministère de tutelle. Cette introduction établit un cadre mathématique qui
aborde formellement la question de la correction (le fait d’être correct) d’un résultat. Ce manuscrit
n’y répond pas ; il aborde des problématiques pour faciliter l’utilisation de systèmes
qui permettent d’y répondre.
Nous allons d’abord énumérer des systèmes logiques dans lesquels prouver revient de plus
en plus à manipuler des données et des fonctions. Il est légitime de parler de logique pour
aborder la programmation et d’utiliser des structures de données pour appuyer un raisonnement
logique. Nous basculerons en eet dans l’informatique en décrivant les découvertes
qui ont identié les deux problématiques en donnant, suivant le point de vue, aux preuves un
corps ou aux programmes une description de leur comportement. Ainsi, nous aboutirons à un
langage de programmation pratique qui apporte des garanties fortes sur la bonne formation
des programmes qu’il permet d’écrire. Nous aurons alors le socle nécessaire pour discuter
nos problématiques.
Logiques constructives
Formaliser la logique est apparu comme un champ des mathématiques au cours du 19e
siècle. Des primitives autour desquelles s’articule le raisonnement ont émergé. Parmi ces
connecteurs :
l’implication exprime la possibilité d’obtenir une propriété B à partir d’une propriété A et
s’écrit A → B. Elle vient avec l’axiome que pour toute propriété A, A → A.
la conjonction fait de deux propriétés une propriété.
la disjonction introduit la notion de choix. Elle se construit en donnant l’une des deux
possibilités. Elle demande de savoir agir dans les deux cas pour être détruite.
9Introduction
faux n’a pas de règle d’obtention. Elle permet de nier toute proposition.
Par ailleurs, les premiers systèmes formels venaient avec la supposition toujours faite
jusque là que l’on peut toujours considérer qu’une propriété est soit vraie soit fausse (principe
du tiers exclu). On parle aujourd’hui de logique classique.
Dans les logiques classiques, prouver l’impossibilité qu’il n’existe pas revient à prouver
qu’il existe. L’objet dont la non existence a été niée n’est pas pour autant construit. Un mouvement
s’est constitué pour établir des logiques dans lesquelles prouver qu’il existe impose
d’exhiber un témoin d’existence. Ce schéma de pensée appelé constructivisme a un intérêt
particulier pour voir les preuves d’existence comme des algorithmes de construction.
Quelles que soient les structures de données utilisées et les règles de raisonnement autorisées,
il existe plusieurs manières de structurer un raisonnement. Parmi elles, la déduction
naturelle dénit les connecteurs par deux types de règles : des règles pour les construire ou
introduire et des règles pour les détruire ou utiliser. Cette manière de faire est assez intuitive
lors de la construction de preuves par l’esprit humain.
Le calcul des séquents est lui ecace lors du traitement mécanique des preuves. Pour
chaque connecteur, il s’articule autour de règles dites gauches si on suppose avoir la donnée
et de règles dites droites si on veut l’obtenir.
antification
Le type des entiers naturels, déni par l’arithmétique de Peano, représente une classe d’objet
contenant une innité d’habitants distincts directement manipulables dans la logique.
Les nombres sont construits à l’aide de deux primitives : une constante nommée zéro et une
fonction injective successeur qui à tout entier associe l’entier suivant. Surtout, un nouveau
concept arrive pour utiliser les nombres entiers : le raisonnement par récurrence. Il permet
de prouver des propriétés qui dépendent d’un entier par un raisonnement potentiellement
inni. Ce raisonnement est en réalité ni pour tout entier ni car il donne un comportement
à adopter ni pour l’entier zéro et un comportement ni pour passer de la propriété pour un
entier à cette propriété pour son successeur.
L’arithmétique permet d’énoncer des propriétés qui parlent d’entiers naturels. Elle dispose
en plus de l’implication d’une notion de quantication : une propriété peut parler des valeurs
des objets qu’elle suppose. On peut écrire, pour tout entier naturel n, la propriété P dans
laquelle n apparaît.
La quantication est aussi utilisable pour permettre à une propriété de dépendre d’une
autre propriété. Par ce biais, une propriété peut parler de toutes les propriétés (y compris ellemême).
Un tel système est dit imprédicatif. Le système F de Girard est obtenu en ajoutant la
quantication sur les propriétés à la logique minimale. Il forme ainsi le système d’expressivité
minimale où les raisonnements imprédicatifs sont permis.
L’imprédicativité est extrêmement expressive. En système F, les structures de données
n’ont pas besoin d’être dénies. Elles sont toutes encodables au moyen de quantications
et d’implications (voir les travaux de Böhm etBerarducci [9]).
La puissance de l’imprédicativité cause des suspicions chez certains constructivistes quant
à son admissibilité. Par contre, l’idée de ne pas se cantonner à un nombre ni de structures
10La généralisation : les inductifs
de données a été réexploitée.
De même, exprimer des propriétés qui varient selon la valeur des données dont elles dé-
pendent s’est révélée une brique élémentaire des systèmes logiques constructifs. Le logical
framework (LF) [48] ou λπ [20] est le langage générique pour raisonner sur ces systèmes.
La généralisation : les inductifs
Martin-Löf a proposé un système logique prédicatif disposant des structures de données
de la logique intuitionniste et de quantications sur les valeurs.
Pourtant, toutes les structures de données vues jusqu’ici ont toutes un canevas similaire.
Elles sont engendrées par un nombre ni de constructeurs et les utiliser revient à énumérer
le comportement à adopter dans le cas de chacun des constructeurs. De plus, prouver une
propriété dans les cas récursifs peut se faire grâce à cette même propriété sur les sous-parties
récursives.
De cette constatation, Dybjer [22] a proposé une généralisation de la théorie des types
de Martin-Löf avec un monde ouvert. Toute structure de données qui respecte un canevas
assurant sa bonne formation est dénissable puis utilisable directement.
Les systèmes logiques sont d’une importance fondamentale pour l’informatique. Ces recherches
sont en réalité développées non pas seules mais en interaction avec l’informatique
grâce à deux découvertes fondamentales du vingtième siècle. Pour poursuivre continûment
le déroulé de cette introduction, elles sont présentées ici dans l’ordre antichronologique.
Correspondance preuves/programmes
Pour tenter d’assurer la correction des programmes, on a cherché à les classier. Pour
cela, on leur a associé un type, une spécication construite par des règles d’inférence à partir
de la syntaxe du programme qui spécie son comportement. Si l’on sait qu’un morceau de
programme est une fonction qui prend un entier et renvoie une liste de vrai ou faux, nous
savons qu’il est impossible de l’élever au carré ou de lui donner en entrée un tableau de
nombres à virgule.
L’intérêt premier des types est de signaler tôt et systématiquement au programmeur toute
une classe d’erreurs qu’il a pu commettre, sans attendre que ce programme plante lors de
son exécution. Mais avec leur introduction intervient une révolution. Les types ont donné
corps au travail des logiciens constructivistes. Prouver que la propriété que A et B implique
A ou B est identique à écrire une fonction qui prend la paire d’un élément de type A et d’un
élément de B et qui renvoie un élément soit de type A soit de type B. C’est la correspondance
de Curry-DeBruijn-Howard ; la logique nourrit l’informatique.
Prouver des théorèmes est isomorphe à écrire des programmes si l’on est capable de donner
un contenu calculatoire aux axiomes et aux constructeurs de notre logique. Le coeur de ce
dispositif est la correspondance entre la fonction et l’implication logique. Autrement dit la
logique minimale a pour langage correspondant le λ-calcul simplement typé.
11Introduction
Le bloc de données et la conjonction de propriétés sont les deux facettes du même objet.
Le choix et disjonction aussi.
Derrière la récurrence, il y a un programme clair : les fonctions récursives, c’est-à-dire
celles qui se rappellent elles-même. L’arithmétique de Péano a donc un langage de programmation
correspondant dont le comportement calculatoire est basé sur le système T de Gödel.
Burstall propose avec Hope [15] un langage de programmation ayant un mécanisme de
ltrage pour raisonner par cas et la possibilité de dénir des types algébriques. Cette idée a
mené à la dénition de la famille de langages fonctionnels ML ainsi qu’à Haskell [31] et a
donné le support nécessaire à la dénition de la théorie des types de Martin-Löf.
Machines universelles
Avant la découverte de cette correspondance entre calculs qui terminent et preuves de
théorème, les diérentes manières de calculer avait été prouvées équivalentes.
Alan Turing cherchant à modéliser le comportement mécanique du mathématicien en le
représentant comme une machine munie d’états d’esprits, d’un alphabet, d’un crayon,
d’une gomme, de règles pour changer d’état d’esprit et agir localement sur le papier à
partir de son état d’esprit et de ce qu’il lit et d’inniment de feuilles de papiers ;
John von Neumann réalisant concrètement une machine capable de réaliser quelques opé-
rations de lecture et d’écriture dans un dispositif de stockage d’informations qu’il nomme
mémoire. Cette machine lisant quelles opérations elle doit faire à partir de sa mémoire ;
Alonzo Church construisant le λ-calcul, un langage élémentaire pour parler des preuves
mathématiques ;
peuvent tous trois calculer les mêmes résultats !
Les preuves qu’un mathématicien peut écrire, il peut les manipuler mécaniquement. Ce
qu’il peut faire mécaniquement en concevant un programme, une machine peut le faire. Voici
la révolution qui créa l’informatique théorique : raisonner, c’est eectivement programmer,
l’informatique peut nourrir la logique.
Avec ces formalismes, il est facile de montrer que ces machines ne peuvent pas tout. Elles
ne peuvent par exemple pas prédire dans tous les cas si un algorithme donné s’arrête après
un nombre ni d’étapes de calcul. Cette question est plus élémentaire que savoir si deux
algorithmes ont les même sorties pour les même entrées. Il n’y a aucune chance de répondre
en toute généralité au problème de l’équivalence de programmes.
Programmation fonctionnelle avec types algébriques
La théorie des types de Martin-Löf généralisée propose sur le versant informatique un langage
avec un monde ouvert où l’utilisateur peut introduire de nouvelles structures de données
à la condition qu’elles soient correctement formées. Ces données sont ensuite utilisables
grâce à des fonctions récursives ou du raisonnement par induction. On parle naturellement
de structure de données inductives.
12Types riches
Pour l’utilisateur, travailler avec des structures de données qu’il a dénies exactement pour
son besoin lui permet d’écrire des programmes suivant son intuition sans se soucier d’encodage.
L’étude mathématique justie la correction des programmes typés dans ce formalisme.
Ce paradigme de programmation permet d’utiliser de manière sûre et simple les primitives
des processeurs.
Réaliser un choix est une des opérations élémentaires mises à la disposition du programmeur.
Cette action consiste à exécuter une partie ou une autre d’un programme suivant la
valeur d’une entrée. De manière primitive dans un processeur, l’opération de branchement
conditionnel saute à une instruction plus lointaine en fonction du résultat d’une comparaison
d’entiers.
Historiquement, les langages impératifs (C, Java, . . .) proposent un opérateur de sélection
de cas à partir de cette primitive. La commande switch n inspecte la valeur de l’entier n puis
exécute le code situé entre case k: et break; si n = k. Un comportement par défaut, pour
les k n’apparaissant pas, est spécié grâce à default:.
Si un ordinateur ne manipule que des séquence de bits, ce n’est pas le cas de l’intuition humaine.
Il est donc communément possible d’associer un nom à un nombre par #define FLEUR
12 an de clarier les programmes en écrivant switch (plante) { case FLEUR: cueillir;
break; default: arroser}. Par contre, il n’existe aucune garantie sur l’exhaustivité
ou la cohérence des choix donnés. Le programme switch (animal) { case FLEUR:
promener; break; default: carresser} se révélera aberrant à l’exécution mais il est
accepté par le logiciel chargé d’en permettre l’exécution : l’interpréteur ou le compilateur.
De même, réserver un bloc de mémoire est primitif. L’accès aux champs d’un bloc dans
les langages impératifs n’a par contre aucune garantie. Rien n’empèche donc de lire une
mauvaise zone de mémoire. Ces problèmes sont pris en charge par les disciplines de typage.
Types riches
Les systèmes de type qui permettent le plus de contrôle sur les programmes autorisent
les types à dépendre de valeurs. Ce gain entraîne deux complications : l’apparition d’annotation
de type dans les termes et l’apparition de calculs dans les types (l’impossibilité de ne
considérer que l’égalité syntaxique de types).
Le modèle où l’utilisateur donne tout d’abord intégralement un programme ou une preuve,
puis la machine le/la vérie dans un second temps n’est plus satisfaisant. Des annotations
sont fastidieuses à écrire alors qu’il est possible d’écrire une fois pour toutes un programme
permettant à l’ordinateur de les deviner. De longs calculs que l’utilisateur ne veut pas faire
de tête sont parfois nécessaire pour connaître le type que doit avoir un terme. La machine et
son utilisateur doivent interagir an de construire et vérier incrémentalement les termes.
Les assistants de preuve sont des logiciels permettant de construire interactivement preuves
ou programmes. Ce domaine de recherche prolique a généré de nombreuses tentatives aux
objectifs multiples.
Prouver des théorèmes avec des programmes simplement typés est par exemple permis
par Isabelle [54], HOL-light [27] ou ACL2 [32]. On retrouve également des systèmes où la
programmation peut être aussi dépendante que la preuve, par exemple Lego [51], Matita [1]
13Introduction
ou Coq. Cayenne [3] puis Epigram [39] et Agda [14] orent par exemple des systèmes tournés
en premier lieu vers la programmation. Twelf [49] (ou Dedukti [13]) tentent d’extraire
l’universalité des systèmes logiques an de générer d’autres systèmes.
Ces systèmes orent à l’utilisateur un langage de surface qui lui évite d’écrire exhaustivement
les termes. L’interactivité minimale est une présentation par la machine du type
du terme attendu en un point donné. Le choix de la forme à présenter est cruciale pour la
compréhension humaine.
Utilisation des données inductives
Dans la diérentiation du langage de surface et de celui sur laquelle s’appuie la logique, ce
manuscrit distingue des concepts qui sont confondus dans la littérature. Nous employerons
des mots synonymes dans des sens distincts car notre propos est précisément de montrer les
distinctions et les passerelles des uns aux autres.
Intuitivement et en anticipant légèrement sur la suite qui dénit plus formellement chacun
des termes, nous distinguons :
— l’analyse de cas élémentaire, cette réécriture du principe d’élimination d’un inductif
qui donne le comportement pour chacun des constructeurs et que l’on peut qualier de
ltrage atomique.
— le typage de l’analyse de cas, justement par étude de cas, qui assure que pour chacun
des constructeurs, une réponse bien typée est apportée. Cette primitive est identique
pour tous les éléments d’un type inductif.
— le ltrage complexe, qui correspond au ltrage généralisé, celui que l’on retrouve dans
les langages fonctionnels. Son exécution nécessite alors une phase de compilation vers
une forme plus élémentaire.
— et le typage par analyse de couverture, celui qui travaille sur une instance du type
inductif spéciquement et permet de typer un ltrage (généralisé) directement.
Dans le λ-calcul simplement typé ou paramétrique, les deux typages sont équivalents car
tous les constructeurs ont le même type. Il n’y a donc pas réellement besoin de s’attarder
sur la version élémentaire de l’opération qui n’est qu’un point de passage au cours de la
compilation.
Avec des types dépendants, la confusion a perduré alors que le ltrage (l’opération non
atomique) n’est pas typable directement dans un système comme le notre qui n’a à disposition
qu’un principe d’élimination générique. Qui plus est, l’opération complexe considérée
primitive apporte avec elle un axiome supplémentaire (voir 1.7).
Ce manuscrit parlera donc d’analyse de cas (élémentaire) et de ltrage (généralisé) en
omettant les qualicatifs. Sa première contribution originale est de proposer une nouvelle
compilation du second dans le premier.
Cette première partie du manuscrit est décomposée en trois chapitres. Dans un premier
temps, l’algorithme pour atomiser un ltrage complexe sans considération de typage est rappelé.
Dans un deuxième temps, le système de typage direct du ltrage complexe tel qu’imaginé
par Coquand est décrit. Nous présenterons le plongement que McBride a proposé dans
les CCI en utilisant un axiome supplémentaire. Le chapitre 4 de ce manuscrit décrit une com-
14Réduction des points xes
pilation d’un sous-ensemble signicatif des ltrages dans le CCI pur. C’est la continuité du
travail réalisé par Herbelin et Cornes [18].
Réduction des points fixes
Au lieu de dénir les récurseurs des types inductifs primitivement, un mécanisme géné-
rique de point xe est proposé. Bien sûr, il faut s’assurer que les points xes ne peuvent
pas produire de calculs innis. Avec un véricateur de terminaison, cette formulation est
équivalente aux principes de récurrence [23].
Ces points xes sont dénissables par le biais de constantes globales autorisées à s’appeler
elles-mêmes ou par des constructions locales aux systèmes. La seconde contribution originale
de ce manuscrit est de simuler au niveau de l’utilisateur le premier système dans le second.
La description de se mécanisme constitue le chapitre 5.
Le véricateur de terminaison doit pouvoir interagir au mieux avec la volonté de l’utilisateur.
Par exemple, il doit permettre la réutilisation de code. Il doit aussi ne pas être perturbé
par les constructions dont le système a besoin pour assurer le typage du terme. La troisième
contribution originale de ce manuscrit est un algorithme présenté chapitre 6 qui va dans ce
sens. Il se base sur un critère syntaxique de décroissance structurelle.
151 Un langage fonctionnel avec types riches
Le langage formel utilisé dans ce manuscrit est un λ-calcul à la Church avec des types
algébriques et des constantes globales écrit en déduction naturelle. Il va être décrit progressivement
dans ce chapitre.
1.1 Conventions d’écriture
Des listes sont utilisées tout au long de ce manuscrit. L’écriture adoptée pour représenter
la liste de n "x" est x1 · · · xn. Par convention, l’indice s dans x1 · · · xs est utilisé quand le
nombre d’éléments n’importe pas.
Les déclarations sont notées (x : T) où T est le type de la variable x. Les listes de déclarations
(x : X) (y : Y) (z : Z) . . . dans lesquels x apparaît dans Y, x et y apparaissent dans Z, . . .
seront intensivement utilisées. Elles sont appelées des télescopes et disposent d’une notation
spécique :
−−−−−−→
(ai
: Ai
) désigne (a1 : A1) · · · (ai
: Ai
).
Remarque Dans l’assistant de preuve Coq, des dénitions (let z : Z := t in u) peuvent entrecroiser
des déclarations au sein des télescopes pour obtenir (x : X) (y : Y) (z : Z := t) . . .. Il
est néanmoins toujours possible de remplacer les variables dénies par leur dénition et de
traiter des listes de déclarations uniquement. Ceci simplie la présentation.
Le langage déni ici se traduit symbole pour symbole en une structure de données utilisables
en pratique pour une implantation 1
, mis à part la représentation des variables. Une
machine utilise des indices de Bruijn pour avoir une représentation canonique des variables,
ce qui évite les problèmes de capture. Ce manuscrit utilise par souci de lisibilité des variables
nommées en respectant les conventions usuelles. La convention de Barendregt évite les problèmes
de capture en imposant des noms de variable tous distincts et l’α-équivalence identie
les termes égaux à renommage des variables liées près.
La syntaxe utilisée est une réminiscence de celle des versions 8 de Coq.
Lors de dénitions abstraites, les couleurs et les noms tenteront de faciliter la lecture. Il
sera par exemple question de termes t, de types T, de constantes globales c et de variables x.
1. Elle est exactement déduite de la structure Constr.t du code de Coq v8.5.
171 Un langage fonctionnel avec types riches
1.2 Le cœur fonctionnel
1.2.1 Syntaxe
Le λ-calcul est un modèle de calcul qui permet de manipuler aisément des lieurs. Tous les
programmes dans ce modèle sont construits à partir de fonctions. Le mot terme est communément
employé pour désigner un de ces programmes.
Il existe plusieurs formulations du λ-calcul. Ce manuscrit utilise une variante typée : le λ-
calcul à la Church. Le but du typage est ici d’interdire les calculs innis. Certaines annotations
de type sont explicites an que le typage reste décidable malgré des types très expressifs.
Stefano Berardi et Jan Terlouw ont proposé un cadre très générique pour étudier les systèmes
de type : les systèmes de types purs. Ce cadre est une généralisation du λ-cube de
Barendregt ([4]) où chaque dimension représente une possibilité de dépendance en plus et
chaque sommet un système de type connu.
Le système de type utilisé ici est le sommet du λ-cube. Termes et types partagent la même
syntaxe an de dépendre les uns des autres. Il a été introduit par Thierry Coquand [16] sous
le nom de calcul des constructions. Sa syntaxe est donnée gure 1.1
u, t, S, T : := x | λ(x : T) ⇒ t | t u | ∀(x : S), T | Set | Type
Figure 1.1 – Grammaire du cœur fonctionnel (CoC)
L’abstraction de la variable x de type T dans le terme t s’écrit λ(x : T) ⇒ t. Par souci de
concision, λ(x : X) ⇒ λ(y : Y) ⇒ t est noté λ(x : X) (y : Y) ⇒ t et λ(x : X) (y : X) ⇒
t est noté λ(x y : X) ⇒ t.
L’application du terme u au terme t est noté t u sans symbole explicite. Elle est conventionnellement
associative à gauche.
Au niveau des types, le produit jouit des même facilités d’écriture que l’abstraction. Le
terme ∀(x y : S) (z : T), s désigne ∀(x : S), ∀(y : S), ∀(z : T), s.
Deux constantes, les sortes Set et Type sont aussi données.
Le caractère _ est utilisé pour désigner une variable liée qui n’apparaît pas dans le corps
du lieur. Ainsi dans le cas d’une abstraction sur une variable non utilisée, on écrit λ(_ : T)
⇒ t.
Dans le cas du produit, A → B est une notation pour ∀(_ : A), B.
1.2.2 Evaluation
Le calcul intervient lorsqu’un argument est appliqué à une abstraction. Une telle situation
est appelée un rédex. Le terme se réduit alors vers le corps de la fonction dans lequel l’argument
remplace la variable de l’abstraction. Cette opération s’appelle une β-contraction et se
note formellement
(λ(x : T) ⇒ t) u 7→β
t[u/x]
La notation t[u/x] désigne la substitution de la variable x par le terme u dans le terme t.
181.3 Déclarations globales
La clôture par congruence 2
, réexivité et transitivité de cette réécriture est appelée réduction.
Dans la suite, 7→β
ferra référence à la réduction.
Deux termes t et t’ sont convertibles (noté t ≡ t’) s’ils se réduisent sur un même terme :
t 7→β v et t’ 7→β v.
L’ordre dans lequel sont réalisées les réécritures n’a pas d’incidence sur la convertibilité.
La réduction est conuante : quelle que soit la manière dont les réécritures sont réalisées à
partir d’un terme, les termes obtenus restent toujours convertibles.
En dénissant une réduction parallèle qui réalise la réécriture sur toutes les partie du terme
en une seule étape, on obtient une réduction que l’on peut simuler à l’aide des règles dénies
au-dessus. Cette réduction parallèle réduit les deux termes issus d’une paire critique sur le
même terme en une étape (propriété du diamant).
Les stratégies de réduction (discutées chapitre 5) n’auront donc pas d’eet sur l’expressivité.
L’autre point important de la réduction est sa terminaison. Une valeur ou forme normale est
un terme sur lequel aucune réécriture β n’est applicable sur aucune partie. Il est indispensable
que tous les termes du langage se réduisent sur une valeur (unique par conséquence de la
conuence). Le typage l’impose. La preuve passe par la construction d’un modèle et a fait en
particulier l’objet de travaux par Coquand [16], Werner - Miquel [42], Lee [35], Barras [5], . . .
1.2.3 Typage
Le système de type du calcul des constructions est présenté gure 1.2. La sorte s désigne
indiéremment Set ou Type.
Il est décrit sous la forme de jugements qui donne le type d’un terme à partir du type des
variables apparaissant dans ce terme. Le type des variables est stocké dans un environnement
(conventionnement nommé Γ) qui est soit vide (∅) soit composé de la déclaration de la
variable x de type T suivi du sous contexte Γ (Γ, (x : T)).
1.3 Déclarations globales
1.3.1 Syntaxe
L’utilisateur n’écrit pas un terme monolithique mais une succession de dénitions globales
notées (c : T := t) qui forment un environnement ∆. Par réminiscence de la syntaxe de Coq,
la syntaxe pour dénir la constante c dans les exemples de ce manuscrit est
Definition c : T := t.
Il est aussi possible de déclarer des axiomes. Ce sont des constantes sans valeur notée (x :
T).
Pour éviter les répétitions, Definition c : ∀(x : S), T := λ(x : S) ⇒ t. peut être écrit
Definition c (x : S) : T := t.
2. Par congruence, nous entendons les règles de la forme t 7→β
t’ et T 7→β
T’ implique λ(x : T) ⇒
t 7→β
λ(x : T’) ⇒ t’.
191 Un langage fonctionnel avec types riches
Γ ⊢ t ∈ T
Γ, (x : T) ⊢ x ∈ T
Γ ⊢ S ∈ s Γ ⊢ y ∈ T
Γ, (x : S) ⊢ y ∈ T
Γ, (x : S) ⊢ t ∈ T Γ ⊢ ∀(x : S), T ∈ s
Γ ⊢ λ(x : S) ⇒ t ∈ ∀(x : S), T Γ ⊢ Set ∈ Type
Γ ⊢ t ∈ ∀(x : S),T Γ ⊢ u ∈ S T[u/x] ≡ T’ Γ ⊢ T’ ∈ s
Γ ⊢ t u ∈ T’
Γ ⊢ S ∈ Set Γ, (x : S) ⊢ T ∈ Set
Γ ⊢ ∀(x : S), T ∈ Set
Γ ⊢ S ∈ s Γ, (x : S) ⊢ T ∈ Type
Γ ⊢ ∀(x : S), T ∈ Type
Figure 1.2 – Typage du calcul des constructions
Les termes peuvent faire référence à des constantes globales précédemment dénies. Une
constante est un constructeur de terme (gure 1.3).
u, t, S, T : := x | λ(x : T) ⇒ t | t u | ∀(x : S), T | Set | Type | c
Figure 1.3 – Grammaire de CoC avec dénition
1.3.2 Evaluation
Au cours d’un calcul, une constante est remplacée par le corps de sa dénition donnée par
l’environnement global (communément appelé ∆). Cette opération est appelée δ-expansion
et se note :
∆, (c : T := t), ∆’ ⊢ c 7→δ
t
La réduction intègre maintenant cette règle de réécriture et est notée ∆ ⊢ 7→βδ . La
conuence reste valable. La réduction parallèle conserve la propriété du diamant. Le dépliage
de constante n’a pas d’incidence sur la terminaison.
1.3.3 Typage
Le jugement de typage est maintenant paramétré par l’environnement des constantes dé-
nies. Le type d’une constante est donné par cet environnement.
∆, (c : T := t), ∆’ ;Γ ⊢ c ∈ T ∆, (c : T), ∆’ ;Γ ⊢ c ∈ T
201.4 Types de données algébriques strictement positifs
.
L’environnement global doit être bien formé, c’est-à-dire vide ou obtenu par ajout de
constantes aux noms frais et bien typées.
∆ ⊣
∅ ⊣
∆ ⊣ ∆ ;∅ ⊢ T ∈ s ∆ ;∅ ⊢ t ∈ T c < ∆
∆, (c : T := t) ⊣
∆ ⊣ ∆ ;∅ ⊢ T ∈ s c < ∆
∆, (c : T) ⊣
Figure 1.4 – Environnements bien formés
1.4 Types de données algébriques strictement positifs
1.4.1 Syntaxe
Le langage considéré jusqu’à maintenant permet de dénir des structures de données par
codage imprédicatif.
Néanmoins, comme suggéré dans l’introduction, manipuler des données de manière primitive
est plus naturel. Les constructions utilisées pour rendre cela possible sont les structures
inductives. L’ajout des types inductifs primitifs décrit ci dessous donne le Calcul des Constructions
Inductives dû à Christine Paulin et Thierry Coquand [17].
Les structures de données sont dénies uniquement au sein de l’environnement global. La
syntaxe des contextes globaux est enrichie de l’entrée
(C1 : T1)
· · ·
(Ci
: Ti
)
@
−−−−−−−−→
(am : Am) →
I : T
.
Les exemples du manuscrit ainsi que la syntaxe de Coq v8 utilisent une syntaxe diérente
plus lisible où le bloc ci-dessus est écrit Inductive I
−−−−−−−−→
(am : Am): T := |(C1 : T1) · · · |(Ci
: Ti
).
La gure 1.5 montre une déclarations d’inductifs écrite en forme normale an d’introduire
la terminologie employée pour les manipuler.
Inductive I
−−−−−−−−→
(am : Am) : ∀
−−−−−−−→
(bn : Bn), Set :=
| C1 : ∀
−−−−−−−−→
(x1s
: T1s
), I a1 · · · am t11
· · · t1n
· · ·
| Ci
: ∀
−−−−−−−→
(xis
: Tis
), I a1 · · · am ti1
· · · tin.
Figure 1.5 – Squelette d’un inductif du CCI
C1 · · · Cs sont les constructeurs du type inductif I.
211 Un langage fonctionnel avec types riches
a1 · · · am sont les paramètres de l’inductif.
b1 · · · bn forment la signature d’index de l’inductif.
x1 · · · xs sont les arguments du constructeur C.
t1 · · · tn sont les index du constructeur C.
Par construction,
— Le type des constructeurs doit être en forme constructeur par rapport à I. La syntaxe
des forme constructeur par rapport à X est Co : := X t1 · · · ts
| ∀(x : T), Co avec T =
X u1 · · · us ou X n’apparaît dans T et X n’apparaît pas dans les termes t et u1 · · · us
.
L’occurrence nale de X est la conclusion du type du constructeur.
— Les paramètres sont des constantes d’une dénition. Il doivent rester identiques dans
la conclusion du type des constructeurs et dans la dénition de l’inductif.
Un exemple d’inductif est la dénition de l’égalité donnée gure 1.6.
Inductive eq (A : Set) (a : A) : A → Set := | eq_re :eq A a a.
Lorsque l’on écrit eq T t u, la valeur du type T est imposée par les termes t et u. Par consé-
quent, lorsque le type T n’est pas le point clé de l’explication, eq T t u est noté par la suite t
= u.
Figure 1.6 – Dénition de l’égalité
Une fois dénis, inductifs et constructeurs sont utilisables dans les termes comme des
constantes. Les constructeurs ont un statut particulier. Deux constructeurs sont prouvablement
distincts et l’ensemble des habitants d’un type inductif est statiquement connu par
l’environnement global. Grâce à cela, Christine Paulin a déni une règle d’élimination des
données par analyse de cas. La syntaxe employée est donnée gure 1.7.
case t predicate P of | br1 · · · | bri end
Figure 1.7 – Analyse par cas sur t de type I u1 · · · um v1 · · · vn
Le terme t inspecté par l’analyse de cas est appelé terme inspecté. L’annotation de typage
P est appelée clause de retour ou prédicat de retour. Le terme brj appelé branche du constructeur
Cj correspond au comportement du programme si le terme inspecté débute par le j-ième
constructeur. An de fournir des noms pour représenter les arguments du constructeurs,
une branche débute par autant d’abstractions que le constructeur lui correspondant a d’arguments.
Le langage Gallina fournit une primitive plus haut niveau qui sera l’objet d’étude des
chapitres suivants. Néanmoins, l’analyse de cas écrite en forme dite η-longue (où il y a un λ
pour toutes les abstractions) s’injecte dans la syntaxe de Gallina en écrivant
Terme de Constr.t
case t predicate λ
−−−−−−−→
(bn : B’n) (x : I u1 · · · um b1 · · · bn) ⇒ T of
|λ
−−−−−−−−−→
(x1s
: T’1s
) ⇒ br1 · · · |λ
−−−−−−−−→
(xis
: T’is
) ⇒ bri
end
où T’jk
:= Tjk
[u1 · · · um/a1 · · · am] et B’k
:= Bk
[u1 · · · um/a1 · · · am]
221.4 Types de données algébriques strictement positifs
Terme de Gallina
match t as x in I b1 · · · bn return T with
| C1 x11
· · · x1s => br1
· · ·
| Ci xi1 · · · xis => bri
end
L’analyse de cas n’est pas susante pour dénir des fonctions par analyse de cas récursives.
Une notion de point xe est nécessaire. La syntaxe employée est fixi
(f : T := t) où f est
une variable libre dans t. L’indice i est appelé l’argument récursif du point xe. Il désigne le
numéro de l’argument à inspecter pour savoir s’il faut déplier le point xe (comme expliqué
section suivante).
Fixpoint f (x_1 : S_1) · · · (x_i : S_i) : T := t. est un alias plus concis pour
Definition f : ∀(x_1 : S_1) · · · (x_i : S_i), T := fixi
(f : ∀(x_1 : S_1) · · · (x_i : S_i), T := λ(x_1 :
S_1) · · · (x_i : S_i) ⇒t).
En résumé, la grammaire exhaustive des termes est écrite gure 1.8. Elle est nommée minicalcul
des constructions inductives car le calcul des constructions inductives à proprement
parler inclus par exemple une hiérarchie innie de sortes avec sous-typage ou des structures
de données coinductives qui sont hors du champ de l’étude réalisée dans ce manuscrit.
u, t, S, T : := x | c | ∀(x : S), T | s | λ(x : T) ⇒ t | t u | C | I
| case t predicate P of t1 · · · ts end
| fixi
(f : T := t)
Figure 1.8 – Grammaire des termes utilisés (mini-CCI)
1.4.2 Evaluation
Une analyse de cas dont le terme inspecté est le constructeur Cj appliqué à des arguments
u1 · · · us se réduit vers la branche de Cj appliquée aux termes u1 · · · us
. C’est la ι-contraction.
∆ ⊢ case Ci u1 · · · un predicate T of |t1
· · · |tm end 7→ι ti u1 · · · un
La dernière règle est la ϕ-expansion. Un point xe se déplie si son argument récursif commence
par un constructeur. Ce conditionnement du dépliage à la forme de l’un des arguments
est indispensable. Remplacer systématique la variable représentant le point xe par le corps
du point xe amène des dépliages innis lorsque la règle est appliquée sur des sous-termes
ayant des variables libres.
∆ ⊢ (fixi
(f : T := t)) u1 · · · ui-1 (C v1 · · · vn) 7→ϕ
t[fixi
(f : T := t)/f] u1 · · · ui-1 (C v1 · · · vn)
La réduction enrichie de ces deux règles est notée ∆ ⊢ 7→βιϕδ . Sa conuence est toujours
prouvable grâce à une réduction parallèle vériant la propriété du diamant. La terminaison
demande la construction de nouveaux modèles qui furent par exemple l’objet du
travail de Coquand - Paulin [46], Luo [37], Barras [6], . . .
231 Un langage fonctionnel avec types riches
1.4.3 Typage
Un type algébrique I est un inductif si les occurrences de I dans les télescopes des arguments
des constructeurs sont en positions strictement positives. Elles ne doivent jamais
apparaître à gauche d’un produit dans un type.
Pour le reste, on étend la règle de bonne formation des environnements globaux (gure
1.4) par la déclaration d’un type inductif :
∆ ⊣ ∆ ;∅ ⊢ ∀
−−−−−−−−→
(am : Am), T ∈ Type ∆ ;(I : ∀
−−−−−−−−→
(am : Am), T), ∅ ⊢ ∀
−−−−−−−−→
(am : Am), T1 ∈ Set
· · · ∆ ;(I : ∀
−−−−−−−−→
(am : Am), T), ∅ ⊢ ∀
−−−−−−−−→
(am : Am), Ti ∈ Set
∆,
(C1 : T1)
· · ·
(Ci
: Ti
)
@
−−−−−−−−→
(am : Am) →
I : T
⊣
Dans notre restriction mini-CCI, le type de l’inductif (Type) et de ses constructeurs (Set)
sont xes alors qu’en Coq ils pourraient varier.
L’extension du typage des termes est donné gure 1.9.
Une fois un inductif déclaré dans l’environnement global, son type et le type de ses constructeurs
sont directement donnés par cet environnement.
Une analyse de cas est une écriture particulière du schéma d’élimination
d’un inductif. ( Ce schéma correspond à l’encodage imprédicatif d’un inductif
[47]).
Lors d’une élimination dépendante, chaque branche attend un type diérent. Puisque les
types dépendent des termes, le type d’une branche dépend du constructeur auquel il correspond.
Le type global de la réponse renvoyée par l’analyse de cas est lui fonction du terme
inspecté.
Le typage d’un point xe n’est pas surprenant. L’originalité de la règle présentée est la
condition Decr(∆,t,f,i). Il correspond à une condition de bonne formation appelée condition
de garde qui interdit les points xes divergents. Son étude précise est l’objet du chapitre 6. Son
principe général est de garantir que "le nombre de constructeurs en tête de l’argument récursif"
est une grandeur strictement décroissante. Cette propriété garantit que seul un nombre
ni d’appels récursifs peut avoir lieu si l’argument est un terme clos.
1.5 Des structures de données d’exemple
Ce manuscrit réalise pour chaque partie une présentation incrémentale informelle des problématiques
avant d’exposer la réponse formelle apportée. En plus des structures de données
ayant des rôles très particuliers en théorie des types comme l’égalité déjà présentée gure 1.6,
ces descriptions pédagogiques s’appuient sur des structures de données courantes.
En premier lieu vient la représentation unaire des entiers naturels (gure 1.10) qui fournit
une structure de donnée récursive élémentaire.
241.5 Des structures de données d’exemple
∆ ;Γ ⊢ t ∈ T
∆,
(C1 : T1)
· · ·
(Ci
: Ti
)
@
−−−−−−−−→
(am : Am) →
I : T
, ∆
′
;Γ ⊢ I ∈ ∀
−−−−−−−−→
(am : Am), T
∆,
(C1 : T1)
· · ·
(Ci
: Ti
)
@
−−−−−−−−→
(am : Am) →
I : T
, ∆
′
;Γ ⊢ Cj ∈ ∀
−−−−−−−−→
(am : Am), Tj
∆ ;Γ ⊢ z ∈ I u1 · · · um v1 · · · vn
∆ := ∆
′
,
(C1 : ∀
−−−−−−−→
(x1 : T1), I a1 · · · am t11
· · · t1n
)
· · ·
(Ci
: ∀
−−−−−−→
(xi
: Ti
), I a1 · · · am ti1 · · · tin)
@
−−−−−−−−→
(am : Am) →
I : ∀
−−−−−−−→
(bn : Bn), Set
, ∆
′′
B
′
k
:= Bk
[u1 · · · um/a1 · · · am] T
′
jk
:= Tjk
[u1 · · · um/a1 · · · am]
∆ ;Γ ⊢ P ∈ ∀
−−−−−−−→
(bn : B
′
n) (x : I u1 · · · um b1 · · · bn), s
∆ ;Γ ⊢ brk ∈ ∀
−−−−−−−→
(xk
: T
′
k
), P tk 1
· · · tkn
(Ck u1 · · · um xk1
· · · xks
)
∆ ;Γ ⊢ case z predicate P of | br1 · · · | bri end ∈ P v1 · · · vn z
∆ ;Γ ⊢ T ∈ s ∆ ;Γ, (f : T) ⊢ t ∈ T Decr(∆,t,f,i)
∆ ;Γ ⊢ fixi
(f : T := t) ∈ T
Figure 1.9 – Typage des inductifs du mini-calcul des constructions inductives
251 Un langage fonctionnel avec types riches
Inductive nat : Set := | O :nat | S :nat → nat.
Figure 1.10 – Les entiers naturels unaires (zéro ou le successeur d’un entier)
Les listes simplement chaînées (gure 1.11) prennent un paramètre de type qui indique
la nature des éléments qu’elles contiennent. Néanmoins, tous les constructeurs ont le même
type. Si t est une liste d’entier, t peut aussi bien être nil que cons a b. Les deux constructeurs
créent des listes d’entiers. Nous insistons ici car cette propriété n’est pas vrai pour les familles
inductive ayant un index.
Inductive list (A : Set) : Set :=
| nil :list A
| cons :∀(t : A) (q : list A), list A.
Figure 1.11 – Type avec paramètre : Les listes simplement chaînées
Le prédicat de parité d’un entier naturel (gure 1.12) fournit une structure de données avec
un index donc réellement dépendant. Il sera l’exemple canonique pour faire apparaître des
branches impossibles.
Inductive even : nat → Set :=
| even_O :even O
| even_SS :∀(n : nat) (_ : even n), even (S (S n)).
Figure 1.12 – Prédicat de parité sur les entiers
Des structures plus compliquées ou ad hoc serviront ponctuellement par la suite.
1.6 Digression sur la représentation des constructeurs et des
branches
Des abstractions sont utilisées pour représenter les arguments du constructeur dans les
branches d’une analyse de cas. Les constructeurs sont vus comme des constantes dont le
type est fonctionnel. Ceci n’est pas conventionnel en programmation.
Les langages qui ont le soucis de s’exécuter vite voient un constructeur comme un bloc et
ces arguments comme des champs de ce bloc. L’analyse de cas n’introduit qu’une variable :
celle qui représente le terme inspecté. Par contre, les branches disposent d’une primitive
supplémentaire field i t qui donne le ième champs de t (à supposer qu’il s’agisse bien d’un
bloc).
La première solution simplie l’étude théorique et en particulier l’écriture de la règle de
typage, tandis que l’intérêt intrinsèque de la seconde solution est le partage de code. Par
exemple, si un utilisateur dénit la structure de donnée
Inductive I : Set := | A :I → I | B :I | C :nat → I.
puis écrit (en anticipant très légèrement la syntaxe présentée chapitre 2)
261.7 Expressivité de l’analyse de cas
Definition destA (x : I) : I := match x with | A y => y | _ => x end.
Les branches de B et de C devraient être identiques et donc pouvoir pointer vers le même
code.
En se souvenant que la machine utilise des indices de de Bruijn pour représenter les variables,
c’est eectivement le cas avec
λI
. case 1 predicate λI
. I of | field 1 1 | 1 | 1 end
mais pas dans le formalisme du calcul des constructions inductives qui donne
λI
. case 1 predicate λI
. I of | λI
. 1 | 1 | λnat. 2 end
Il est par ailleurs notable qu’une primitive de projection allégerait aussi les termes issus de
l’utilisation d’inductifs à un seul constructeur. Il est bien sûr possible de dénir les projections
de tels objets (par exemple proj1 nat even x). Néanmoins, la projection dénie comme une
constante prend en argument les arguments de l’inductif (dans l’exemple nat et even alors
qu’une projection primitive (ici field 1 x) n’en a pas besoin. Elle peut être typée directement
au moyen de la dénition de l’inductif au sein de l’environnement global.
1.7 Expressivité de l’analyse de cas
La clause de retour est explicite, elle peut donc être arbitrairement complexe. Elle est la clé
de la grande expressivité de l’élimination dépendante.
Une clause de retour débute par des abstractions représentant des généralisations des index
du terme éliminé ainsi que le terme éliminé. Par exemple, supposons avoir un inductif K qui a
un argument et au moins un constructeur H de type ∀(z : S), K z, la clause de retour pour un
terme inspecté u de type K t a la forme λ(x : S) (y : K x) ⇒ T. Rien n’oblige le type attendu
en retour à utiliser ces abstractions. Dans l’exemple, cela donnerait λ(x : S) (y : K x) ⇒ P
avec t et u apparaissant dans P mais ni x ni y. Néanmoins, le type demandé dans chacune
des branches est alors constant (exactement P) et décorrelé des index du constructeur de la
branche (z dans le cas de H). On ne peut plus raner le type grâce aux informations fournies
par le constructeur. De plus, les arguments du constructeur sont le plus souvent inutilisables
car de types incompatibles. Dans le cas de la branche de H, le type attendu est ∀(z : S),
(λ(x : S) (y : K x) ⇒ P) z (H z). Puisque x et y ne sont pas libres dans P, ce type ce réduit
à ∀(z : S), P où z n’est pas libre dans P. Il est donc peu crédible de pouvoir utiliser z pour
fournir du P.
Pour rendre l’élimination utile, la clause de retour doit utiliser au maximum ces généralisations.
Des contraintes de typage que nous allons expliciter limitent cette possibilité.
Le type des abstractions découle uniquement de la dénition de l’inductif et non pas du
type, plus précis, du terme éliminé. Or, généraliser les termes signie nécessairement géné-
raliser parallèlement les types. Il existe alors des situations où il est impossible d’écrire un
terme de type T k par analyse sur (k : K v) car il n’est pas possible de trouver (P : ∀(a : A)
(b : K a), Set) tel que P v k ≡ T k.
Au lieu d’une quantication universelle sur A, il serait souhaitable de pouvoir exprimer
une propriété existentielle disant a doit être v. Comme si une analyse de cas dépendante demandait
de pouvoir écrire en ce qui concerne des types des motifs où des égalités de variables
sont exprimables. La section 3.2 revient sur cette considération.
271 Un langage fonctionnel avec types riches
Une perte d’expressivité découle de cette contrainte. L’égalité de deux termes peut être
exprimée comme un type de donnée du langage au moyen de la dénition gure 1.6. Elle est
ainsi manipulable directement au sein du langage. Il est cependant impossible de dénir un
terme ayant le type de la gure 1.13 par analyse sur e. La clause de retour qu’il faudrait :
∀(b : A) (e’ : eq A a b), eq (eq A a b) e’ (eq_re A a) est mal typée car eq_re A a a le
type eq A a a et non pas eq A a b (le type de e’).
Axiom UIP_re :
∀(A : Set) (a : A) (e : eq A a a), eq (eq A a a) e eq_re.
Figure 1.13 – Unicité des preuves d’égalité
Cet exemple n’est pas articiel et limite la programmation dépendante. Dans [28], Thomas
Streicher et Martin Hofmann ont nommé K une formulation équivalente (gure 1.14) de cet
axiome. Ils ont montré que K est indépendant du CCI. Il est en eet admissible mais il existe
des modèles qui ne le réalisent pas.
Axiom StreitherK (U : Set) :
∀(x : U) (P : x = x → Prop), P (eq_re x) → ∀(p : x = x), P p.
Figure 1.14 – Axiome K
Puisqu’il est compatible avec le calcul des constructions inductives, K peut être supposé.
Un axiome étant une hypothèse globale qui n’a pas de dénition, il n’a jamais la possibilité
de se réduire. Calculatoirement, un tel axiome est donc extrêmement préjudiciable à moins
d’amener avec lui une forme faible d’irrelevance des preuves. En eet, la réduction peut être
modiée pour ignorer la preuve d’égalité t = u qui bloque une réécriture. Si u et tsont convertibles,
la réécriture est eacée.
De plus, la section 3.2 montre que K est supposé lorsque l’élimination des inductifs est
vu comme une couverture de tous les cas possibles. Il a longtemps été considéré comme
regrettable qu’introduire K de manière externe au CCI bloque toutes les réductions de termes.
Une règle d’élimination par cas des inductifs vériant K a donc été proposée dans [7].
L’apparition de la théorie homotopique des types [52] dans lesquels K n’est pas valable
mais qui présente d’autres intérêts tempère ce point de vue et justie le travail présenté
chapitre 4.
282 Le filtrage en programmation
fonctionnelle
Dans ce manuscrit, nous cherchons à exhiber que la présence de types dépendant rend
profondément diérents l’analyse de cas élémentaire telle qu’elle est dénie dans le CCI et le
ltrage généralisé tel qu’il apparaît dans les langages fonctionnels depuis HOPE (le premier
langage avec des types algébriques).
L’amalgame entre les deux notions est entretenu car Coq ore à l’utilisateur une primitive
de ltrage généralisé. En réalité, ce ltrage est compilé par le système et cette première partie
explique ce procédé de compilation.
Dans les langages avec types algébriques paramétriques (comme par exemple Haskell,
OCaml ou SML), il n’y pas besoin d’isoler l’analyse de cas élémentaire du point de vue du typage.
Il est néanmoins nécessaire dans le processus de compilation vers un langage machine
d’atomiser les tests. Ce travail a été décrit une première fois par Augustsson [2] puis étudié
et optimisé de diérentes manières, par exemple, par Le Fessant, Maranget[34], Wadler[30,
Chapitre 5].
Ce chapitre décrit ces travaux, vu que la structure intermédiaire qu’ils introduisent pour
leur compilation est la structure intermédiaire que nous utilisons pour la nôtre.
La compilation proposée par la littérature est optimisante. Des heuristiques permettent de
réduire le nombre d’analyse des cas à réaliser pour simuler un ltrage. Ce manuscrit ne discute
pas d’optimisation et se contente de décrire la compilation naïve. Néanmoins, il dénit la
construction optimisante de la structure intermédiaire car il peut ainsi proter gratuitement
du travail sur les optimisations fait dans la littérature.
ltrage arbre de décision
sauts conditionnels
analyses de cas + encodage par égalités
Chap 3
analyses de cas + encodage structurel
Chap 4
Chap 2
Figure 2.1 – Plan de la première partie du manuscrit
Les chapitres suivants expliquent les constructions nécessaire pour aller de la structure
intermédiaire qui décrit les choix élémentaires à des analyses de cas du CCI bien typées.
292 Le ltrage en programmation fonctionnelle
Ces chapitres sont successivement la description de la littérature et l’algorithme original que
propose ce manuscrit. Ces chapitres s’occupent seulement de problèmes de types, mais ne
reviendront plus sur l’atomisation qui est l’objet de l’étude qui suit.
2.1 Principe du filtrage
Le ltrage (généralisé) n’analyse pas un seul terme mais une liste de termes en parallèle.
Pour choisir le comportement à adopter, il peut inspecter les arguments d’un constructeur
puis les arguments d’un constructeur argument d’un constructeur et ainsi de suite. Il n’est
pas limité à discriminer selon le premier constructeur en tête du terme.
Le ltrage permet de factoriser le comportement à adopter quand il est identique dans
plusieurs cas, il permet par exemple d’écrire un cas par défaut.
Enn, le ltrage permet de nommer des morceaux des termes inspectés an de s’en resservir
pour décrire le comportement que la suite du calcul doit avoir.
Fixpoint beq_half (m n : nat) : bool :=
match m, n with
| O, O => true
| S (S i), S j => beq_half i j
| _ , _ => false
end.
Figure 2.2 – Exemple d’inspection en parallèle et en profondeur : n est il la moitié de m ?
Un ltrage est constitué de la liste des termes à inspecter que nous appellerons les termes
ltrés et d’une énumération de possibilités qui sont communément appelées les branches.
Une branche de ltrage n’est pas composée que d’un terme comme l’est une branche d’analyse
de cas. Une branche de ltrage est une paire d’un membre gauche composé d’une liste
de motifs et d’un membre droit qui est un terme. Chaque branche a autant de motifs que le
ltrage a de termes ltrés.
La syntaxe des motifs (gure 2.3) permet d’établir une empreinte pour la tête d’un terme.
Si un terme respecte la forme de cette empreinte, il coïncide avec le motif.
La sémantique du ltrage est d’exécuter le membre droit de la première branche pour
laquelle les membres gauches coïncident avec les termes inspectés en ayant eectué les substitutions
nécessaires.
Formellement, la sémantique est déni grâce à
— Une opération ◦ de composition de « peut être substitution ». L’absence de substitution
(⊥) est un élément absorbant.
— une opération de substitution généralisée [p ← t] décrite gure 2.4 qui prend en argument
un motif p et un terme t et renvoie peut être une substitution ; celle à appliquer si
le terme coïncide avec le motif.
— une opération ⊕ qui sélectionne le premier succès d’une liste de « peut être ».
Elle s’écrit alors
match t1 · · · tn with |p11
· · · p1n → u1 · · · |ps1
· · · psn → us end 7→ ⊕i
(◦j[pij ← tj])ui
.
302.1 Principe du ltrage
Exemple Le terme cons O (cons (S (S O)) nil) coïncide avec le motif cons _ (cons (S _)) _
mais pas cons (S (S O)) nil ou cons (S O) (cons O nil)
p : := C p1
· · · ps
| _ | ( p1 | p2 ) | ( p as x )
Figure 2.3 – Syntaxe des motifs
Le motif "_" est appelé joker, n’importe quel terme coïncide avec lui. Un terme coïncide
avec le motif C p1
· · · ps
si, une fois réduit, il est le constructeur C appliqué à des arguments
coïncidant avec les motifs p1
· · · ps
. Un terme coïncide avec ( p1 | p2 ) s’il coïncide avec p1
ou avec p2. Enn, un alias ( p as x ) est un lieur. Il associe le nom x au sous-terme coïncidant
avec le motif p. Le motif ( _ as x ) est noté par simplicité x.
[p ← t]
[( p as x ) ← t]
def
= [t/x] ◦ [p ← t] [_ ← t]
def
= ∅
[( p | q ) ← t]
def
= [p ← t] ⊕ [q ← t]
[Ci p1
· · · ps ← Ci
t1 · · · ts]
def
= ◦k
[pk ← tk
] [Ci p1
· · · ps ← Cj
t1 · · · ts]
def
= ⊥
Figure 2.4 – Substitution généralisée pour un motif
Il est notable que les motifs ne peuvent parler que de constructeurs et non pas de n’importe
quelle déclaration de l’environnement global. L’avantage de ne traiter que des données à
la structure statiquement dénie est de connaître l’espace inspecté. Il est par conséquent
possible de vérier la bonne formation des ltrages en contrôlant l’exhaustivité et la non
redondance des motifs.
Il existe une autre forme de ltrage, non déterministe cette fois, en programmation logique.
La problématique est alors diérente et les motifs sont moins contraints. Une branche de
ltrage en programmation logique utilise des variables existentielles : "S’ il existe x tel que
p(x) = t, exécute u" alors que les variables des motifs de la programmation fonctionnelle sont
universelles : "pour tout x tel que p(x) = t, exécute u".
Les motifs en programmation logique peuvent être non linéaires : une variable peut apparaître
plusieurs fois, signiant que plusieurs parties d’un terme inspecté doivent être identiques.
Il n’est alors plus question de savoir si un terme coïncide avec un motif mais de dé-
terminer les classes d’équivalence auxquelles appartiennent les variables des motifs au sein
des termes. Ce calcul est coûteux. Il repose sur un algorithme d’unication.
Ce besoin de propriété existentielle au sein du typage de l’élimination dépendante des
données a été exhibée section 1.7. C’est pourquoi cette autre forme de ltrage va apparaître
section 3.2. Elle est donc mentionnée ici an de bien la diérencier de notre objet d’étude.
312 Le ltrage en programmation fonctionnelle
2.2 Reconnaitre un motif
Au niveau du processeur, l’unique primitive qui permet le branchement est le saut conditionnel.
Reconnaître un constructeur modélisé par un entier ne demande qu’une instruction
de comparaison. L’analyse de cas se traduit aisément en sauts conditionnels.
Reconnaître un motif n’est pas aussi immédiat. Pour exécuter un ltrage, la coïncidence
avec un motif doit être décomposée en la vérication d’une succession de contraintes élé-
mentaires. Un protocole doit donc être établi an de compiler le ltrage.
Cette étape de compilation n’est pas nécessaire uniquement à l’exécution mais sert aussi
aux contrôles de bonne formation du ltrage. Avec des types de données paramétriques, tous
les motifs et toutes les branches ont le même type. Cette partie du typage est réalisable avant
compilation. Par contre, contrôler la bonne formation des motifs consiste aussi à s’assurer
que tous les cas possibles ont été traité et qu’il n’y a pas de redondance et donc de branches
jamais exécutée. Cela revient à exhiber la complétude et la non surcharge de l’arbre des
choix à réaliser pour déterminer la branche à suivre, c’est-à-dire travailler exactement sur la
structure intermédiaire de la compilation du ltrage.
La littérature propose deux langages intermédiaires pour la compilation : les automates
bracktrackant [2, 34] et les arbres de décision [38].
Tous deux utilisent l’analyse de cas comme primitive mais le premier langage maximise
la concision du code produit en reposant sur l’usage d’un cas par défaut et d’exceptions
alors que le second minimise le nombre de comparaison et s’exprime uniquement par une
succession d’analyses de cas telle que présentée section 1.4.
A titre d’exemple, le résultat de la compilation de beq_half (gure 2.2) vers un automate
backtrackant est donné gure 2.5.1 et vers un arbre de décision gure 2.5.2. Précisément, la
syntaxe utilisée est celle du langage intermédiaire de la compilation d’OCaml dlambda.
catch (case m of
|O: case n of |O: true |_: exit 1 end
|S: let k := (eld 1 m) in (case k of
|S: case n of
|S: beq_half (eld 1 k) (eld 1 n)
|_: exit 1 end
|_: exit 1
end)
end
with 1: false)
(1) par backtraking automata
case m of
|O: case n of |O: true |S: false end
|S: let k := (eld 1 m) in (case k of
|O: false
|S: case n of
|O: false
|S: beq_half (eld 1 k) (eld 1 n) end
end)
end
(2) par arbre de décision
Figure 2.5 – Compilation de beq_half
Comme elle ne requiert pas d’autres primitives que des analyses de cas, la transformation
d’un ltrage vers une succession d’analyses de cas au moyen d’un arbre de décision ouvre la
porte au ltrage en calcul des constructions inductives.
322.3 Construire un arbre de décision
Avec des types dépendants, chaque branche a un type diérent dépendant du cas considéré.
Deux approches existent pour le typage du ltrage.
— La première est un typage avant compilation grâce à une nouvelle théorie logique. Cette
approche est décrite dans la section 3.1.
— La seconde est de s’appuyer sur le typage de l’analyse de cas en CCI après compilation
du ltrage vers ces derniers. Il faut alors non seulement trouver un arbre de décision
mais aussi ajouter les annotations et les constructions nécessaires an de typer les analyses
de cas générées. Ceci revient à trouver un algorithme pour créer des clauses de
retour et des termes en tête de branche qui applique les coercions de type nécessaires.
Le chapitre 3 décrit un algorithme pour encoder le typage primitif du ltrage que propose
la section 3.1. Le chapitre 4 montre une manière alternative et inédite de concevoir
des annotations qui ne demandent pas d’étendre la théorie. Ces deux chapitres considéreront
qu’un arbre de décision non typé a déjà été construit à partir du ltrage à
encoder.
La n de ce chapitre se concentre justement sur cette étape ne parlant pas de types et donc
pas de dépendance : comment transformer un ltrage en un arbre de décision.
2.3 Construire un arbre de décision
2.3.1 Arbre de décision
Formellement, un arbre de décision est un terme dans la grammaire donnée en gure 2.6
agissant sur une pile de termes ltrés.
p : := Tail (t) | Leafx : : p | Nodex(p1
· · · ps
) | Swapi
j1
··· j
s
: : p
Figure 2.6 – Grammaire des arbres de décisions
Tail (t) représente la n d’un arbre de décision. A condition que la pile des termes à ltrer
soit bien vide, t est la réponse apportée.
Leafx : : p est une feuille, c’est-à-dire que le terme en tête de pile n’est pas inspecté plus
profondément et p indique comment se comporter pour la queue de la pile. La variable
x est l’alias du terme ltré dépilé.
Nodex(p1
· · · ps
) signie que le terme en tête de pile est inspecté et que le ieme p donne
le comportement à suivre s’il s’agit du i
e constructeur. Des variables correspondant
aux arguments du constructeur sont empilées sur les termes à ltrer dans toutes les
branches. Le terme ltré inspecté a pour alias x.
Swapi
j1
··· js
: : p est une opération d’optimisation. Elle extrude en tête le ième élément de
la pile an de lui appliquer le traitement dicté par p. Cette opération n’est pas rigoureusement
identique en présence de types dépendants ou non. D’une liste de termes ltrés
réordonnable à souhait, nous passons à la manipulation de télescopes de termes, c’est-
à-dire de liste ordonnée du point de vue du typage (les premiers termes apparaissent
332 Le ltrage en programmation fonctionnelle
dans les types des suivants). Donner la priorité à un terme n’est donc pas uniquement
retarder le traitement des autres, c’est aussi annuler le traitement des dépendances du
terme choisi. La liste j1 · · · js donne les numéros des éléments de la liste à jeter car ils
sont déterminés par l’analyse du terme sélectionné.
hσ(Tail (t)) | i = σ(t)
σ(Leafx : : p) | t, q
=
{x := t, σ }(p) | q
D
σ(Nodex(p1
· · · ps
)) | Ci
t1 · · · tn, qE
=
{x := Ci
t1 · · · tn, σ }(pi
) | t1 · · · tn, q
σ(Swapi
j1
··· js
: : p) | t1 · · · ti
, q
=
σ(p) | ti
, tk1
· · · tki’, q
avec
tk1
· · · tki’
= {t1 · · · ti
} -
(
tj1
· · · tj
s
)
Figure 2.7 – Sémantique des arbres de décisions (σ est une substitution qui donne le terme
correspondant à chaque alias)
2.3.2 Mécanique d’atomisation
La liste des branches (appelée matrice des clauses) est transformée en un arbre de décision
à l’aide d’une fonction qui travaille sur les colonnes de la matrice.
motifs
branches
corps
Figure 2.8 – Structure d’une matrice de clauses
Les colonnes de la matrice peuvent être considérées comme une pile. Le travail est systé-
matiquement eectué sur la première. L’algorithme présenté ici traite ce cas minimal.
Optimiser la compilation du ltrage, c’est échanger l’ordre des colonnes an de réduire
le nombre d’analyse de cas nécessaires en traitant les colonnes clés d’abord. Cela revient à
introduire des constructeurs Swapi
j1
··· js
: : p dans l’arbre de décision.
L’algorithme minimal est le suivant :
Quand la matrice n’a plus de colonne de motifs, il doit y avoir exactement une ligne. Moins
révèle un ltrage non exhaustif, plus des motifs redondants. La réponse est alors Tail (t) avec
t le terme de cette branche restante.
Dans les autres cas, les alias de la première colonne sont uniés par α-renommage, soit x
le nom de l’alias commun.
( p0 as x0 )
( p1 as x1 )
( p2 as x2 )
p0
p1
p2 [x/x0]
[x/x1]
[x/x2]
342.3 Construire un arbre de décision
Ensuite, les disjonctions de la première colonne sont supprimées en dupliquant la ligne
avec pour premier motif les deux cas de la disjonction.
( q1 | q2 ) p1
· · · ps
t
q1 p1
· · · ps
q2 p1
· · · ps t
t
Enn, si tous les éléments de la première colonne sont des jokers, la réponse est Leafx : : p
où p est l’arbre de décision correspondant à la matrice privée de sa première colonne.
Sinon, il est temps d’analyser réellement le premier terme ltré. L’arbre de décision débute
par Nodex(p1
· · · ps
). Pour obtenir la réponse pi
au sous problème associé au constructeur
Ci
, on utilise une opération S qui renvoie la nouvelle matrice regroupant les motifs à traiter
si le premier terme ltré commence par Ci
.
La fonction S Ci va transformer la première colonne de motifs en k nouvelles colonnes,
avec k le nombre d’arguments de Ci
. Pour cela, elle parcourt les lignes en regardant le motif
de tête.
— S’il s’agit du même Ci appliqué aux sous motifs m1 · · · mk
, elle ajoute à la réponse une
ligne constitué des m1 · · · mk
concaténés au reste de la ligne.
(Ci m1 · · · mk
) m1 · · · mk
— Si le premier motif commence par un autre constructeur Cj
, la ligne disparaît.
(Cj m’1 · · · m’k’) ∅
— Un joker est transformé en k jokers tout en gardant le reste de la ligne.
_ _1 · · · _k
Cette procédure est décrite par Luc Maranget dans [38]. L’objet de son article est de réduire
la taille de l’arbre de décision en permutant des colonnes. Il décrit des heuristiques de choix
de la colonne à casser en priorité qui permettent d’égaler les performances de la compilation
par automates backtrackant en utilisant des arbres de décisions.
Dans un cadre avec types dépendant, l’étude de la correction et de la pertinence des heuristiques
reste à traiter, ainsi que la proposition de nouvelles heuristiques spécialisées.
353 Encodage du filtrage dans l’analyse de
cas
3.1 Le filtrage dépendant primitif
Il existe des systèmes logiques dans lesquels le ltrage est l’élimination primitive des inductifs.
Les langages Agda [45] et Beluga [50] sont basés sur un tel ltrage primitif dont le
typage est assuré par analyse de couverture suivant les idées de Thierry Coquand dans [44].
Le principe est de garantir que l’ensemble des motifs membres gauche des branches couvrent
l’ensemble des valeurs que peuvent prendre les termes ltrés.
Le typage du ltrage par analyse de couverture présuppose trois classes de propriétés sur
les constructeurs d’inductifs.
discrimination Deux constructeurs syntaxiquement distincts sont nécessairement dié-
rents. Par exemple, pour les entiers : ∀(P : Set) (n : nat), S n = O → P
inversibilité Deux instances d’un constructeur sont identiques si et seulement si leurs arguments
sont identiques. Pour les entiers : ∀(m n : nat), S m = S n → m = n
acyclicité L’argument d’un constructeur d’inductif ne peut pas être égal au terme entier.
Par exemple, pour les entiers naturels, ∀(P : Set) (n : nat), S n = n → P, ce qui est
vrai également pour tous les S (S . . . (S n)) = n.
Lors du typage d’une branche, la correspondance entre les index des termes ltrés et ceux
du motif considéré ainsi qu’entre les termes ltrés et le cas considéré se ramène à un problème
d’unication ayant pour règles les énoncés ci-dessus. Si t de type even u est éliminé,
dans la branche de even_SS x y de type even (S (S x)), les problèmes d’unication sont u
?
=
(S (S x)) au niveau des index et t
?
= (even_SS x y) pour le terme ltré. L’algorithme cherche une
substitution des variables apparaissant dans les contraintes telle que les contraintes soient
satisfaites. Les variables des motifs peuvent donc être métamorphosées au besoin en des variables
existentielles qu’il faut substituer par un terme pour satisfaire les contraintes de type.
— S’il existe une telle substitution, elle est appliquée aux types des variables libres et au
type attendu en retour. Elle est aussi appliquée aux variables du motif qui ont été transformées
ainsi qu’aux types des variables du motif. Dans l’exemple, le type de y contient
x qui pourrait être part de la substitution.
— S’il n’existe aucune substitution satisfaisant le problème, la branche est déclarée impossible
et est eacée.
Les variables du contexte sont ici vues comme des variables existentielles et non universelles.
Le type UIP_re, l’axiome indépendant du CIC et équivalent à K déni gure 1.13, est
373 Encodage du ltrage dans l’analyse de cas
de ce fait habité par le terme Agda 1
UIP_re : ∀ (A : Set) (a : A) (e : eq A a a) 7→ eq (eq A a a) e (eq_re A a)
UIP_re .B .b (eq_re B b) = eq_re (eq B b b) (eq_re B b)
Il est valide car il existe la substitution A := B, a := b telle que la branche eq_re soit bien
typée.
Toutes les éliminations ne peuvent pas être réalisées. Le comportement problématique apparaît
quand les arguments du terme ltré sont autre chose que des variables et des constructeurs.
Un terme ayant pour type (plus x y) = O ne peut pas être éliminé directement, l’algorithme
d’unication ne sait ni inférer une substitution la plus générale telle que x + y ≡ 0
ni décréter qu’il n’y en a aucune et que ce cas est impossible. En eet, l’unication d’ordre
supérieur en λ-calcul est indécidable (voir [29]).
Cette restriction est nuancée en Agda en travaillant après réduction et en autorisant des
termes quelconques mais syntaxiquement égaux après application de la substitution trouvée
par ailleurs. Il est par exemple possible d’éliminer un terme de type (even (S (S O))) = (even
(plus (S O) (S O))).
3.2 Encodage du filtrage par des analyses de cas
Le ltrage est une manière concise et facile à relire de présenter des programmes. Cette
concision est encore plus vraie avec des types dépendants quand les branches impossibles
peuvent être omises. L’exemple systématique pour illustrer ce fait est de pouvoir écrire
even_map2 : ∀ (n : nat) 7→ even n 7→ even n 7→ _
even_map2 .O even_O even_O = ?
even_map2 .(S (S m)) (even_SS .m e1) (even_SS m e2) = ?
sans rien dire des cas mixtes even_O/even_SS impossibles par typage. Il est donc souhaitable
d’orir à l’utilisateur cette syntaxe de surface même si la logique sous-jacente ne traite
que d’analyse de cas élémentaire.
Conor McBride et James McKinna ont démontré dans [24] que l’expressivité de l’analyse
par cas était celle du ltrage par analyse de couverture si l’on suppose l’axiome UIP de la -
gure 1.13. La démonstration revient à construire une clause de retour et un entête de branche
après avoir obtenu l’arbre de décision pour tous les ltrages typables par analyse de couverture
[40].
Cristina Cornes [19] puis Matthieu Sozeau [53] ont mécanisé pour Coq la génération de
telles clauses de retour et preuves en tête de branche. L’utilisateur dispose de la commande
"Program" pour écrire des termes et des tactiques case_eq, inversion et dependent_destruction
par échelle croissante d’automatisation dans les preuves. Sur des exemples fortement
dépendants, ces techniques sont puissantes mais sourent des limitations de l’axiome
K décrites section 1.7.
1. En Agda, .t signie justement que les contraintes de typage imposent de substituer cette variable de motif
par le terme t.
383.2 Encodage du ltrage par des analyses de cas
3.2.1 Des types riches exprimant les problèmes d’unification
L’encodage repose sur l’obtention et la manipulation explicite d’égalités dans le langage.
Ces égalités correspondent aux problèmes d’unication entre les index des termes ltrés et
ceux des constructeurs. Les propriétés précédentes des constructeurs (discrimination, inversibilité
et acyclicité) doivent être ensuite bâties explicitement.
Pour obtenir l’information, la solution est d’utiliser le prédicat de retour de l’analyse de
cas. Lors de l’élimination d’un entier n pour produire un terme de type T, on rajoute arti-
ciellement une égalité ce qui donne le prédicat de retour λ(m : nat) ⇒ m = n → T. L’analyse
de cas dans son ensemble a maintenant le type n = n → T, ce qui peut bien redonner T quand
on lui applique eq_re nat n. L’avantage est que la branche O attend maintenant un terme
de type O = n → T, ce qui fournit l’égalité recherchée. De telles constructions avec la clause
de retour jouent un rôle fondamental pour le typage de l’analyse de cas qui sera discuté plus
amplement section 3.4.1.
Dans l’exemple précédent, l’égalité ajoutée relie des objets de type xe (nat). L’encodage
complet du ltrage exposé section précédente nécessite de poser des égalités sur des objets
dont les types sont eux-même concernés par d’autres égalités. L’égalité simple dénie
gure 1.6 ne sut plus, on a alors besoin de dénir une égalité hétérogène (gure 3.1).
Inductive JMeq (A : Set) (a : A) : ∀(B : Set) (b : B), Set :=
| JMeq_re :JMeq A a A a.
Figure 3.1 – Dénition de l’égalité hétérogène
Par exemple, la gure 3.2 qui décrit l’inversion d’un double successeur d’un entier a besoin
d’égalité hétérogène. En eet, E a le type even 2 alors que H a le type even m. L’hypothèse
2 = m ne sut pas à rendre ces deux types convertibles, ce qui empêche de typer E = H.
Definition even_inv (E : even 2) : eq (even 2) E (even_SS O even_O) :=
case E predicate λ(m : nat) (H : even m) ⇒ 2 = m → JMeq (even 2) E (even m) H →
eq (even 2) E (even_SS O even_O) of
|even_O:λ(e1 : 2 = O) (e2 : JMeq (even 2) E (even O) even_O) ⇒ . . .
|even_SS:λ(n : nat) (E’ : even n) ⇒ λ(e1 : 2 = (S (S n)))
(e2 : JMeq (even 2) E (even (S (S n))) (even_SS n E’)) ⇒ . . .
end (eq_re 2) (JMeq_re (even 2) E).
2 représente (S (S O))
Figure 3.2 – Exemple d’inversion avec égalité
Même une fois exploitée l’égalité de 2 et m, il est impossible d’exploiter l’égalité hétérogène.
Le problème de généralisation mal typée mais indispensable pour écrire une clause de
retour apparaît pour réaliser le type de la gure 3.3 (il faudrait pouvoir dissocier les 2 instances
de p dans les arguments de la constante rew (formellement dénie gure 3.7) pour pouvoir
éliminer l’égalité h) exactement comme celui de la gure 1.13. Tous deux sont d’ailleurs
logiquement équivalents à K.
Une fois muni de cet axiome, l’encodage est mécaniquement réalisable.
393 Encodage du ltrage dans l’analyse de cas
Axiom eq_rect_eq :
∀(U : Set) (p : U) (Q : U → Set) (x : Q p) (h : p = p),
x = rew U Q p p x h.
Figure 3.3 – Egalité modulo réécriture de type
3.2.2 Manipulation des égalités d’index
Les règles utilisées par l’unication durant le typage du ltrage par analyse de couverture
deviennent des lemmes utilisés pour réaliser des réécritures en tête de branches. Nous allons
détailler comment ces lemmes sont construits et utilisés.
An d’exprimer une propriété triviale mais qui n’apporte aucune information, on dénit
la propriété True (gure 3.4). Pour exprimer une impossibilité dont tout se déduit, on utilise
la propriété False (gure 3.5).
Inductive True : Set := | I :True.
Figure 3.4 – La propriété vraie
Inductive False : Set :=.
Figure 3.5 – La propriété fausse
Puisque False n’a pas de constructeurs, son schéma d’élimination (gure 3.6) qui sera
réutilisé section 4.6 permet toutes les folies.
La gure 3.7 donne le schéma d’élimination de l’égalité. La possibilité qu’il ore d’avoir
une propriété pour le terme de droite si on peut la prouver pour celui de gauche est non
seulement le moyen de réaliser les réécritures mais aussi une pierre angulaire de l’élaboration
des lemmes d’injectivité eux-mêmes.
On peut remarquer qu’il est équivalent d’écrire m = O et case m predicate λ(_ : nat)
⇒ Set of |O:True |S:λ(_ : nat) ⇒ False end. En eet, si m est eectivement O nous
n’avons aucune information supplémentaire. En revanche, si m n’est pas O, on obtient une
preuve de faux qui nous donne la possibilité de fournir une preuve de T pour tout T en
utilisant false_rect.
L’analyse par cas constitue une forme d’égalité pour les termes dans lesquels
seuls des variables et des constructeurs apparaissent, ceux visibles
comme des motifs.
Cette remarque et rew sont des outils susants pour discriminer les constructeurs. Pour
deux constructeurs distincts Ci et Cj alors le terme de la gure 3.8 a le type C_j = C_i →
False 2
. Ce terme permet de conclure dans les cas absurdes.
De manière moins intuitive mais tout aussi systématique, le type ∀(n : nat), m = S n → T
n peut se reformuler case m predicate λ(_ : nat) ⇒ Set of |O:True |S:λ(n : nat) ⇒
2. ceci est couramment noté Ci , Cj
403.3 Utilisabilité de l’encodage
Definition false_rect (P : Set) (x : False) : P :=
case x predicate λ(_ : False) ⇒ P of end.
Figure 3.6 – ex falso quolibet
Definition rew (A : Set) (P : A → Set) (a b : A)
(p : P a) (e : eq A a b) : P b :=
case e predicate λ(c : A) (e’ : eq A a c) ⇒ P c of
|eq_re:p
end.
Figure 3.7 – Brique élémentaire de la réécriture (équivalente au eq_rect de Coq)
T n end. La correspondance entre m et S n est assurée. Si m s’avère être autre chose qu’un S
dans une branche, la branche est une branche impossible. Il sut de fournir I comme preuve
triviale (et inutile pour toute exécution).
La preuve d’inversibilité écrite gure 3.9 utilise cette méthodologie.
Pour les preuves d’acyclicité, on utilise des inductions sur la variable apparaissant des
2 cotés. Tous les cas sauf celui du constructeur qui apparaît en tête dans l’égalité cyclique
utilisent une discrimination. Ce dernier cas est exactement l’appel récursif après usage d’un
lemme d’inversibilité.
3.3 Utilisabilité de l’encodage
Sur la face logique de la correspondance de Curry-deBruijn-Howard, un lemme de mathématique
est rarement démontré pour être évalué. Les termes engendrés par une preuve
non triviale sont volumineux. Coq propose pour des questions d’ecacité et de modularité
de les masquer une fois qu’ils ont été vériés. L’utilisateur utilise de fait ses lemmes comme
des constantes opaques la majorité du temps. Ceci rend anodin d’utiliser l’axiome K. De plus,
les égalités explicitement introduites autorisent un raisonnement équationnel arbitrairement
complexe et plus expressif que n’importe quelle théorie décidable. Par exemple, il peut s’agir
d’exploiter l’arithmétique de Peano sur des égalités d’entiers impliquant addition et multiplication.
De plus, si aucune égalité hétérogène n’est utilisée et que l’utilisation des égalités fournies
dans les branches se limite à instancier des lemmes de discrimination et d’inversibilité
similaires à ceux de la section précédente, le comportement calculatoire du ltrage n’est pas
altéré.
L’élimination d’un inductif au moyen de cette méthodologie est utile et utilisée. Un algorithme
alternatif partiel mais ne nécessitant pas K sera néanmoins proposé dans le chapitre
suivant. En eet, d’une part ce manuscrit met l’accent sur l’écriture de programmes et ses
problématiques, d’autre part, un tel algorithme représente un support de réexion sur l’expressivité
d’une analyse de cas sans K.
413 Encodage du ltrage dans l’analyse de cas
Definition C_i_C_j_discr : C_i = C_j → False :=
λ(e : eq . . . C_j C_i) ⇒
rew . . .
(λ(x : . . .) ⇒ case x predicate λ
−−−−→
(_ : _) ⇒ Set of |C_j:True |C_s:False end)
C_i C_j I e.
Figure 3.8 – Discrimination en action
Definition C_i_inj (a b : . . .) : C_i a = C_i b → a = b :=
λ(e : eq . . . (C_i a) (C_i b)) ⇒
rew . . .
(λ(x : . . .) ⇒ case x predicate λ
−−−−→
(_ : _) ⇒ Set of
|C_i:λ(y : . . .) ⇒ eq . . . a y
|_:λ
−−−−→
(_ : _) ⇒ True end)
(C_i a) (C_i b) (eq_re _ a) e.
Figure 3.9 – Injection en action
3.4 Constructions génériques autour d’une analyse de cas
dépendante
3.4.1 Coupures entrelacées
Concevoir intelligemment des clauses de retour implique d’entrelacer l’élimination d’un
inductif avec des redex de fonction.
Sans considération de typage, il est plus naturel d’écrire le terme (1) que (2) de la gure 3.10.
Les deux termes sont néanmoins équivalents et on parle de coupure commutative car il serait
possible de réduire (2) vers (1).
Fixpoint plus (m n : nat) : nat :=
case n
predicate λ(_ : nat) ⇒ nat of
|O:m
|S:λ(n’ : nat) ⇒ S (plus m n’)
end.
Fixpoint plus (m n : nat) : nat :=
case n
predicate λ(_ : nat) ⇒ nat → nat of
|O:λ(m’ : nat) ⇒ m’
|S:λ(n’ m’ : nat) ⇒ S (plus m’ n’)
end m.
(1) (2)
Figure 3.10 – Exemple de coupure commutative
Pour raisonner sur des prédicats de parité d’entier dénis gure 1.12, les expressions (1) et
(2) de la gure 3.11 sont radicalement diérentes. Dans (1), la correspondance de type entre
les deux variables est perdue alors que dans (2), le type de e1’ est modié simultanément à
e2 dans chaque branche.
En eet, l’analyse par cas ne modie pas les types des variables libres (comme e1 qui est de
type even n). Les types dans le contexte et les types des constructeurs sont désynchronisés
423.4 Constructions génériques autour d’une analyse de cas dépendante
Definition even_inv (n : nat)
(e1 e2 : even n) : . . . :=
case e2
predicate λ(m : nat) (_ : even m) ⇒
. . . of
|even_0:. . .
|even_SS:λ(m’ : nat)
(e : even (S (S m’))) ⇒ . . .
end.
Definition even_inv (n : nat)
(e1 e2 : even n) : . . . :=
case e2
predicate λ(m : nat) (_ : even m) ⇒ even
m → . . . of
|even_0:λ(e1’ : even O) ⇒ . . .
|even_SS:λ(m’ : nat)
(e e1’ : even (S (S m’))) ⇒ . . .
end e1.
(1) (2)
Figure 3.11 – Coupure entrelacée sur les prédicats de parité
dans les branches (La première branche indique que e2 est even_0 de type even O mais e1 n’a
pas changé de type pour autant). Par contre, en abstrayant une variable, elle passe du contexte
à la conclusion. Son type est réécrit dans la clause de retour (e1’ est cette copie de e1 au type
plus précis). L’utilisation des abstractions permet la conservation des correspondances dans
l’analyse par cas.
Sur l’exemple, en inversant l’ordre d’introduction de e1 et e2, la coupure commutative aurait
été inutile. L’introduction partielle de e2 uniquement pour laisser e1 dans la conclusion
aurait su parce qu’alors on peut faire une η-réduction. Cette possibilité n’est pas systématique
comme nous le verrons dans la section 4.3.
Introduire une coupure pour obtenir une copie d’un terme dans un type en adéquation
avec le type du constructeur de la branche considérée n’est pas utile uniquement pour les
variables libres. La mémorisation de la valeur des index du type éliminé se fait de la même
manière.
Cette technique est par exemple décrite par Bertot et Castéran dans [11] avec des preuves
d’égalité. Pour éliminer (p : even(plus (S x) O)) ecacement, mieux vaut savoir que plus
(S x) O = O dans le premier cas (an d’éliminer ce cas) et plus (S x) O = S (S m’) dans le
second. Nous plaçons pour cela le terme eq_re (plus (S x) O) comme argument du ltrage
et réécrivons son type grâce à la clause de retour λ(m : nat) (e : even m) ⇒ eq nat (plus
(S x) O) m → . . . an d’obtenir exactement les égalités recherchées. Elles peuvent ainsi servir
à montrer que la branche est impossible ou à obtenir des correspondances entre les types des
arguments du constructeur et ceux du contexte et de la conclusion.
3.4.2 Elimination des branches impossibles
Si un inductif n’a pas d’index, la clause de retour de l’élimination d’un terme de ce type n’a
qu’une unique variable, celle qui généralise le terme ltré. Le type attendu dans les branches
est le type demandé en retour du ltrage dans lequel le terme éliminé est remplacé par le
constructeur de la branche. Sur le cas des listes, la gure 3.12 montre que les termes PN et
433 Encodage du ltrage dans l’analyse de cas
PC ont des types ranés.
Definition case_list (A : Set) (P : list A → Set) (PN : P nil)
(PC : ∀ (t : A) (q : list A) , P (cons t q)) (l : list A): P l :=
case l predicate λ(l’ : list A) ⇒ P l’ of
|nil:PN
|cons:λ(t : A) (q : list A) ⇒ PC t q
end.
Figure 3.12 – Principe d’élimination d’une liste
La valeur de l’objet ltré est ranée dans les branches mais son type n’est pas modié. Le
typage de la clause de retour ne pose pas de diculté.
Un inductif ayant un ou des arguments comme Inductive I : ∀(a : A),Set := . . .. est
fondamentalement diérent d’un inductif tel que Inductive J (a : A) : Set := . . .. n’ayant
que des paramètres. Tous les constructeurs de J ont en eet le type J a alors que les constructeurs
de I ont un type I t avec t quelconque et dépendant du constructeur.
Alors que l’élimination de (j : J u) ne peut produire que des constructeurs de type J u, l’élimination
de (k : I v) peut produire des constructeurs de type I t (où t dépend du constructeur).
Une clause de retour sur J n’a donc pas besoin de dépendre de a. C’est pourquoi il n’y a pas
de lieur pour les paramètres. Dans la syntaxe de Gallina, ils doivent apparaître comme des
_. Une clause de retour sur I doit par contre avoir un type de la forme ∀(a : A) (b : I a),
Set an que P v k et P t (C x y) soient simultanément typables.
Le type des branches dépend des index du constructeur en même temps que du constructeur.
Le type varie d’un constructeur à l’autre.
L’élimination de k doit avoir une branche pour tous les constructeurs C de l’inductif I. Il
est donc nécessaire de fournir un terme de type P t (C x y) même si t est incompatible avec v
et qu’il est impossible que k soit le constructeur C. L’abstraction sur l’argument de l’inductif
donne un moyen de parler de v dans la clause de retour. Par conséquent, l’incompatibilité de
t et v est exprimable dans la clause de retour an que n’importe quel terme soit admis dans
la branche C. C’est alors une branche impossible.
Si un index débute par un constructeur CC, la clause de retour va faire une analyse de cas
sur cet index qui revoit le type demandé dans le cas de CC et le type choisi pour peupler
les branches impossibles dans les autres cas. Nous verrons avec précision à la section 4.3
comment écrire une clause de retour exhibant les incompatibilités. Dans le cadre présenté ici
toutes les branches impossibles contiennent une preuve de discrimination.
444 Du filtrage à l’analyse de cas
structurellement
L’originalité de ce chapitre est de proposer une traduction des arbres de décision vers des
analyses de cas sans utiliser la structure de données eq (et JMeq). Cette construction réduit
le préjudice induit par l’absence de l’axiome K en éliminant des situations où l’encodage
de la section 3.2 introduit inutilement des égalités hétérogènes. Elle ne tire pas avantage
de l’acyclicyté des types de données. Néanmoins, sans axiome ni preuve par récurrence en
tête de branche, le comportement calculatoire n’est jamais entravé. La taille syntaxique des
termes est aussi potentiellement moindre et leur typage s’avère plus rapide.
4.1 Squelee d’index
Les constructeurs en tête des index du type des termes inspectés jouent un rôle particulier.
Ils sont distingués des autres termes en introduisant la notion de squelette d’index. Tout
d’abord, nous notons p(t1 · · · ts
) le motif p vu comme un terme dans lequel le ième joker est
remplacé par le terme ti
. Le squelette du terme u est alors la paire d’un motif p et de termes
t1 · · · ts ne débutant pas par un constructeur tels que u = p(t1 · · · ts
). Le motif p exprime alors
ce sur quoi on peut ltrer. Les termes t1 · · · ts sont dénommés les feuilles du squelette.
Les motifs de squelette utilisent une restriction de la syntaxe présentée gure 2.3 puisqu’ils
ne contiennent ni alias ni choix.
Par exemple, le squelette du terme even_SS (S (S n)) (even_SS n t) est (even_SS (S (S _))
(even_SS _ _), [n ;n ;t]).
Deux squelettes sont compatibles si il existe une substitution des jokers de la partie motif
de l’un qui permet d’obtenir la partie motif de l’autre.
Pour tout terme u dans une famille inductive, le squelette d’index du type
de u est la liste des squelettes des index de son type.
4.2 and les égalités sont inutiles
Considérons l’élimination d’un terme x de type I a1 · · · as an d’obtenir un terme de type
P.
Dans le cas le plus simple, les a1 · · · as sont des variables deux à deux distinctes et de types
identiques à ceux des index de I lors de sa dénition. Le terme x a dans ce cas un type aussi
général que la signature de I. Il est alors inutile de recourir à des égalités pour éliminer x. La
454 Du ltrage à l’analyse de cas structurellement
clause de retour s’écrit directement λ
−−−−−→
(a’ : A) (x’ : I a’1 · · · a’s
) ⇒ P’ où P’ est P dans lequel
sont réalisés les α-renommages ai -> a’i et x -> x’.
Remarque Le terme P’ est une généralisation de P, les termes a1 · · · as
, x (qui se trouvent
être des variables) sont des objets immuables alors que les variables a’1 · · · a’s
, x’ sont des
abstractions pour diérents termes suivant les cas. Ce sont les outils du ranement des types
dans les branches.
Par rapport au typage direct du ltrage généralisé (chapitre 3), le sens dans lequel la correspondance
entre les type est faite dans les branches est en quelque sorte inversé. Alors que
l’unication ou les réécritures qui la simulent plongent les types des arguments du constructeur
dans les types du contexte, c’est maintenant le type de retour qui est réécrit en correspondance
avec le type du constructeur. En conséquence, si le type du constructeur est trop
général, le type attendu est trop général (voir section 4.4).
Si maintenant les index a1 · · · as de x ne sont plus nécessairement des variables, un deuxième
cas favorable peut se produire. Les feuilles du squelette d’index du type de x peuvent
être des variables deux à deux distinctes et de types découlant de la dénition de I. Les constatations
pour écrire des lemmes d’injection (gure 3.9) sont alors réemployables. Une clause
de retour avec égalité (section 3.2.2) x = C a b → P a b peut s’écrire case x predicate Set
of |λ. . . ⇒ Q . . . |λ(a’ : _) (b’ : _) ⇒ P a’ b’ . . . |λ. . . ⇒ Q end.
Les branches correspondant à des constructeurs dont l’index ne commence pas par C sont
des branches impossibles. Comme expliqué section 3.4.2, le type Q peut donc a priori être
choisi arbitrairement mais il est judicieux qu’il soit un type trivialement habité an d’avoir un
terme de type Q canonique. Tous les cas d’une élimination d’un inductif doivent en eet être
donnés, y compris ceux qui sont impossibles pour toute exécution car de type incompatible.
Nous utiliserons dans un premier temps True (et I) (dénis gure 3.4) avant de raner
ce choix section 4.6 pour une raison d’inférence de la terminaison des points xes, problème
indépendant de celui considéré ici.
Une clause de retour du ltrage d’un terme dont le type est un motif est donc caractérisé
par une formulation comme match t as x’ in I p1
· · · pn return P with ... end
avec les p1
· · · pn
des motifs. Coq autorise d’ailleurs directement cette syntaxe. La structure
pour donner le prédicat de retour in I p1
· · · pn return P est transformée en interne en
λy1
· · · yn ⇒ « match y1
· · · yn with
| p1
· · · pn => P
| _ => True end »
Le ltrage est entre guillemets car il s’agit d’un ltrage généralisé à compiler à son tour.
Intuitivement, les termes qui composent ces clauses de retour sont un ltrage à un seul
cas intéressant, celui qui isole le squelette d’index du terme ltré. Jean Francois Monin et
Xiaomu Shi ont introduit le terme diagonaliseur pour parler d’eux dans [43].
La diérence d’expressivité entre le ltrage par couverture et le ltrage par analyse de cas
est assez explicite avec les clauses de retour mises sous cette forme. Le motif utilisé ici est un
motif de la programmation fonctionnelle, il doit être linéaire. Le motif de l’analyse de couverture
est un motif de la programmation logique qui n’a pas cette contrainte. L’identication
de deux types est exactement ce qui nécessite K.
464.3 Diagonalisation
4.3 Diagonalisation
Pour pouvoir construire une clause de retour, il faut savoir :
— extraire le squelette d’index, mais aussi,
— abstraire les variables libres dont le type interfère avec l’objet ltré ou ses index.
Conserver les liens avec les types des variables libres introduit les coupures entrelacées.
Spécialiser la clause de retour suivant le squelette d’index élimine les branches impossibles.
Cela demande du ltrage dans le diagonaliseur. Il y a donc du ltrage dans la clause de retour
du ltrage. Cependant le ltrage dans la clause de retour a lieu sur le type d’un index
du terme ltré. Il a donc lieu sur un inductif déni strictement plus tôt dans le contexte global.
La terminaison est assurée, la lisibilité du résultat par contre ne l’est pas. Nos exemples
explicatifs sont incrémentaux pour ne pas noyer le lecteur.
Commençons par illustrer l’utilisation d’un squelette d’index et la reconnaissance de branches
impossibles. Fournir un habitant du type False est et doit rester impossible. Il est pourtant
possible d’écrire une preuve de ∀(H : even 1), False (pour even déni gure 1.12) par
ltrage sur H.
La clause de retour de l’élimination d’un terme de type even u a la forme λ(n : nat)
(e : even n) ⇒ P n e. Les constructeurs S et O sont des constantes injectives. Le diagonaliseur
de la gure 4.1 permet en ltrant sur n de montrer que P 1 _ renvoie False comme
attendu mais que P (S (S m)) (even_SS m) et P O even_O demandent des termes de type
True faciles à construire.
Definition diag_even1 (n : nat) (e : even n) : Set :=
case n predicate λ(_ : nat) ⇒ Set of
|O:True
|S:λ(m : nat) ⇒ case m predicate λ(_ : nat) ⇒ Set of
|O:False
|S:λ(_ : nat) ⇒ True
end
end.
Definition even1 (H : even (S O)) : False :=
case H
predicate λ(n : nat) (e : even n) ⇒ diag_even1 n e of
|even_O:I
|even_SS:λ(m : nat) ⇒ I
end.
Figure 4.1 – Diagonaliseur pour even 1
La section précédente a illustré deux techniques : généraliser le type attendu en retour de
l’analyse de cas et incorporer aux clauses de retour la séparation des constructeurs. Mettons
maintenant en œuvre pleinement ces constructions. Dans l’exemple précédent (x = C a b → P
a b) les variables a b sont devenues a’ b’ à l’intérieur du case. Plus généralement, les variables
qui apparaissent en feuilles du squelette d’index sont substituées autant que possible par les
variables issues de l’analyse de cas. Une telle substitution n’est pas une opération sûre : si la
474 Du ltrage à l’analyse de cas structurellement
variable substituée apparaît dans les paramètres de l’inductif ou apparaît à plusieurs feuilles,
le terme construit est mal typé. La n de ce chapitre détaille notre heuristique (section 4.5).
Ecrire un terme de type ∀(n : nat) (e : even (S (S n))), even n par analyse de cas sur
e met en application ce principe. Le cas even_O est une branche impossible car O , S(S _) .
L’argument m de even_SS est utilisé lui dans le type attendu. Le prédicat de diagonalisation
est
Definition diag_SS (n : nat) (e : even (S (S n))) : Set :=
case n predicate λ(_ : nat) ⇒ Set of
|O:True
|S:λ(x : nat) ⇒ case x predicate λ(_ : nat) ⇒ Set of
|O:True |S:λ(m : nat) ⇒ even m end
end.
Figure 4.2 – Diagonaliseur pour inverser evenSS
Nous n’utilisons ici que la feuille du squelette d’index dont le type n’est pas dépendant. Dès
qu’est utilisée une variable dont le type évolue au cours du ranement du squelette d’index,
une coupure entrelacée est nécessaire. En particulier, le type de la variable représentant la
généralisation du terme ltré doit se raner au fur et à mesure que les index du terme ltré
sont ranés.
An d’illustrer cette armation, nous introduisons une nouvelle structure de données
dépendante. La gure 4.3 déni la famille des ensembles nis. Le type Fin n représente l’ensemble
[|1 .. n|]. Le constructeur F1 m représente le premier élément d’un ensemble à S m
éléments alors que FS m f représente le (k + 1)-ième élément d’un ensemble à S m éléments
si f représente le k-ième élément d’un ensemble à m éléments. Par exemple, Fin O est vide,
Fin (S (S O)) contient F1 (S O) et FS (S O) (F1 O), etc.
Inductive Fin : nat → Set :=
| F1 :∀(n : nat), Fin (S n)
| FS :∀(n : nat), Fin n → Fin (S n).
Figure 4.3 – Famille inductive des ensembles de taille xée
Avec cette dénition, comment raisonner par cas sur un élément quelconque d’un ensemble
non vide ? Supposons par exemple que t a le type Fin (S n) pour n xé et que l’on
souhaite raisonner par cas dessus. Le but est alors d’écrire un terme de type ∀(n : nat)
(f : Fin (S n)), P n f. Son diagonaliseur va nécessairement débuter par les abstractions issues
de la dénition de la famille inductive : λ(k : nat) (f’ : Fin k) ⇒ . . .. il faut ensuite
ltrer sur k pour retrouver qu’il est non nul sans perdre le fait que f’ a k éléments. La variable
f’ est dans le contexte, une coupure entrelacée la remet dans la conclusion. La gure 4.4
montre le résultat.
Les diagonaliseurs réalisent pour l’instant des ltrages sur nat, un inductif non dépendant.
Les diagonaliseurs des analyses de cas du diagonaliseur étaient implicites car simples. Dans
le cas général, il faut de nouveau prendre en considération dans le diagonaliseur les branches
484.3 Diagonalisation
Definition diag_nS (k : nat) (f’ : Fin k) : Set :=
case k predicate λ(k’ : nat) ⇒ Fin k’ → Set of
|O:λ(fo : Fin O) ⇒ True
|S:λ(k’ : nat) (fs : Fin (S k’)) ⇒ P k’ fs
end f’.
λ(n : nat) (f : Fin n) ⇒ case f predicate diag_nS of
|F1:λ(m : nat) ⇒ . . . : P m (F1 m)
|FS:λ(m : nat) (f’ : Fin m) ⇒ . . . : P m (FS m f’)
end
Figure 4.4 – Diagonaliseur pour ensemble non vide
impossibles, généraliser suivant les index et le terme éliminé mais aussi prévenir les désynchronisations
des types des variables du contexte avec ceux des arguments du constructeur
dans la branches. Bref, bâtir récursivement nos diagonaliseurs.
Considérons par exemple l’élimination d’un prédicat (H : FLast (S n) (FS n f)) où FLast
exprime la propriété d’être le dernier élément d’un ensemble non élémentaire (gure 4.5)
pour conclure P n f H . Il faudra construire successivement trois diagonaliseurs.
Inductive FLast : ∀(n : nat) (f : Fin n), Set :=
| FL1 :FLast (S O) (F1 O)
| FLS :∀(n : nat) (f : Fin n), FLast n f → FLast (S n) (FS n f).
Figure 4.5 – Dernier élément d’un ensemble
Le prédicat de diagonalisation gure 4.7 débute par un ltrage sur l’entier. L’ensemble et le
prédicat ne doivent pas être introduits an de conserver les dépendances de type. Le prédicat
(diag_Fin : ∀(k : nat) (f : Fin (S k)) (H : Flast (S k) f), Set) doit ensuite par ltrage sur
f être égal à P appliqué aux variables du dernier ltrage dans le cas FS et à True sinon. Pour
conserver les correspondances de type alors qu’un constructeur apparaît dans le type de f,
l’élimination a pour clause de retour le diagonaliseur diag_nat.
Ici il existe un diagonaliseur bien plus simple donné gure 4.8 qui économise l’analyse
de cas sur les entiers vu qu’ils sont arguments de l’ensemble. Néanmoins, la présence de
diagonaliseurs dans les diagonaliseurs est générique et absolument nécessaire en général.
Pour preuve, voici notre dernier exemple : l’inversion du prédicat d’égalité sur deux ensembles
de même taille déni gure 4.6. Il met en oeuvre tous les mécanismes expliqués.
Cette fois, tous sont nécessaires. Le résultat est indigeste, il est heureux que la section 4.7
donne l’algorithme formel pour le générer an que plus jamais il ne soit écrit manuellement.
Inductive FinEq : ∀(n : nat), Fin n → Fin n → Set :=
| F1Eq :∀(n : nat), FinEq (S n) (F1 n) (F1 n)
| FSEq :∀(n : nat) (f1 f2 : Fin n), FinEq n f1 f2 → FinEq (S n) (FS n f1) (FS n f2).
Figure 4.6 – Prédicat d’égalité sur les éléments dans des ensembles de même taille
494 Du ltrage à l’analyse de cas structurellement
Definition diag_FLS (m : nat) : ∀(f : Fin m) (H : FLast m f), Set :=
case m predicate λ(m’ : nat) ⇒
∀(f : Fin m’) (H : FLast m’ f), Set of
|O:λ(f’ : Fin O) (_ : FLast O f’) ⇒ True
|S:λ(k : nat) ⇒ diag_Fin k
end.
where
Definition diag_Fin (k : nat) (f : Fin (S k)) : ∀(H : FLast (S k) f), Set :=
case f predicate diag_nat of
|FS:λ(j : nat) (f0 : Fin j) ⇒
λ(H : FLast (S j) (FS j f0)) ⇒ P j f0 H
|F1:λ(j : nat) ⇒ λ(_ : FLast (S j) (F1 j)) ⇒ True
end.
and
Definition diag_nat (i : nat) : ∀(f : Fin i), Set :=
case i predicate λ(i’ : nat) ⇒ ∀(f : Fin i’), Set of
|O:λ(_ : Fin O) ⇒ True
|S:λ(j : nat) ⇒ λ(f’ : Fin (S j)) ⇒
∀(H : FLast (S j) f’), Set
end.
Figure 4.7 – Diagonaliseur pour ∀(H : FLast (S n) (FS n f)), P n f H
λ(m : nat) (f : Fin m) ⇒
case f predicate λ(i : nat) (f’ : Fin i) ⇒ FLast i f’ → Set of
|F1:λ(i : nat) (H : FLast (S i) (F1 i)) ⇒ True
|FS:λ(i : nat) (f0 : Fin i) (H : FLast (S i) (FS i f0)) ⇒ P i f0
end
Figure 4.8 – Diagonaliseur optimisé pour ∀(H : FLast (S n) (FS n f)), P n f H
504.3 Diagonalisation
Definition diag_x1 (x1 : nat) : Fin x1 → Set :=
case x1 predicate λ(n2 : nat) ⇒ Fin n2 → Set of
|O:λ(_ : Fin O) ⇒ True
|S:λ(x0 : nat) ⇒ λ(f1’ : Fin (S x0)) ⇒
∀(f2 : Fin (S x0)), FinEq (S x0) f1’ f2 → Set
end.
Definition diag_x2 (x2 : nat) : Fin x2 → Set :=
case x2 predicate λ(n3 : nat) ⇒ Fin n3 → Set of
|O:λ(_ : Fin O) ⇒ True
|S:λ(x0 : nat) ⇒ λ(f2’ : Fin (S x0)) ⇒ ∀(f1’’ : Fin x0),
FinEq (S x0) (FS x0 f1’’) f2’ → Set
end.
Definition diag_H (n0 : nat) : ∀(f1 f2 : Fin n), FinEq n f1 f2 → Set :=
case n0 predicate λ(n1 : nat) ⇒ ∀(f4 f5 : Fin n1), FinEq n1 f4 f5 → Set of
|O:λ(f4 f5 : Fin O) (_ : FinEq O f4 f5) ⇒ True
|S:λ(x : nat) ⇒ λ(f4 : Fin (S x)) ⇒
case f4 predicate diag_x1 of
|F1:λ(n1 : nat) ⇒ λ(f5 : Fin (S n1))
(_ : FinEq (S n1) (F1 n1) f5) ⇒ True
|FS:λ(n1 : nat) (f5 : Fin (S n1)) ⇒ λ(f6 : Fin (S n1)) ⇒
(case f6 predicate diag_x2 of
|F1:λ(n2 : nat) ⇒ λ(f7 : Fin n2)
(_ : FinEq (S n2) (FS n2 f7) (F1 n2)) ⇒ True
|FS:λ(n2 : nat) (f7 : Fin n2) ⇒ λ(f8 : Fin n2)
(_ : FinEq (S n2) (FS n2 f8) (FS n2 f7)) ⇒
FinEq n2 f8 f7
end f5)
end
end.
Definition invert_H (n : nat) (f1 f2 : Fin n)
(H : FinEq (S n) (FS n f1) (FS n f2)) : FinEq n f1 f2 :=
case H predicate λ(n0 : nat) (f f0 : Fin n0) (H’ : FinEq n0 f f0) ⇒ diag_n f f0 H’ of
|F1Eq:λ(_ : nat) ⇒ I
|FSEq:λ(m : nat) (f’ f’’ : Fin m) (H0 : FinEq m f’ f’’) ⇒ H0
end.
Figure 4.9 – Inversion du prédicat d’égalité sur deux ensembles non élémentaires
514 Du ltrage à l’analyse de cas structurellement
4.4 and le diagonaliseur en dit trop
La construction du diagonaliseur est réalisée suivant l’intégralité du squelette d’index de
l’objet ltré. Maintenant, il faut aussi se préoccuper des constructeurs de l’inductif correspondant
et de leurs squelettes d’index.
Jusqu’à maintenant, ces squelettes étaient soit égaux soit incompatibles avec le squelette
de l’objet ltré. En réalité, ils peuvent être plus généraux. La forme normale du type attendu
dans la branche est alors une analyse de cas sur l’un des arguments du constructeur. Pour
habiter le type voulu, la branche commence par l’élimination de cet argument.
Pour caricaturer, dénissons un inductif ayant un prédicat comme paramètre et un entier
comme index et dont l’unique constructeur n’a pour but que d’empaqueter un habitant du
prédicat pour un entier donné (gure 4.10). Supposons ensuite que l’on souhaite détruire
un terme de type boite P (S n) pour P et n donnés. L’élimination a la structure indiquée en
gure 4.11. Il a fallu raisonner par cas sur l’argument de contenu an de peupler le type
demandé dans la branche puisque lui aussi est un raisonnement par cas sur cet argument.
Inductive boite (D : nat → Set) : nat → Set :=
| contenu :∀(n : nat), D n → boite D n.
Figure 4.10 – Une boite à D
Definition ouvre_boite (D : nat → Set) (n : nat) (B : boite D (S n)) : T :=
let diag_boite := λ(m : nat) ⇒
case m predicate λ(m’ : nat) ⇒ Set of
|O:True
|S:λ(k : nat) ⇒ T
end
in case B predicate λ(m : nat) (_ : boite D m) ⇒ diag_boite m of
|contenu:λ(n : nat) (x : P n) ⇒
case n predicate λ(n’ : nat) ⇒ diag_boite n’ of
|O:True
|S:λ(k : nat) ⇒ t
end
end.
Figure 4.11 – Éliminer une grosse boite
Voilà tout le nécessaire pour construire des clauses de retours et peupler les parties impossibles
des branches si les index des termes ltrés peuvent être écrits sous la forme d’une
liste de motifs du ltrage à la ML.
Des situations hors de ce cadre peuvent néanmoins apparaître à tout moment, y compris
dans les index des index soit dans des appels récursifs. Trouver un comportement le plus
conservatif possible quand les termes sont trop généraux est indispensable pour écrire un
algorithme générique utilisable en pratique.
524.5 Des clauses de retour pour éliminer tous les termes
4.5 Des clauses de retour pour éliminer tous les termes
Nous venons de voir sur des exemples les méthodes que la compilation structurelle du
ltrage utilise. Au-delà de ces exemples, quels sont les ltrages pour lesquels ces méthodes
s’appliquent convenablement et sont susantes ? La diculté de construire une analyse de
cas dépend du type de l’objet ltré.
4.5.1 Les index du type ne contiennent que des variables et des
constructeurs
Pour éliminer une structure de données n’ayant pas d’index, la section 1.7 a déjà remarqué
qu’aucun type n’était variable dans la clause de retour et que le problème ne posait pas de
diculté.
En présence d’index mais pas de paramètres, la question est de savoir si ces index peuvent
être vus comme des motifs. Construire une clause de retour structurellement se fait en eet
au moyen d’un diagonaliseur et un diagonaliseur est construit par analyse de cas sur les
index. Dans un motif de la programmation fonctionnelle, les variables sont des lieurs tous
distincts. En renommant toutes les occurrences de ces variables dans le type attendu en retour
de l’analyse de cas, on conserve un terme correctement typé. Construire des clauses de retour
ne comporte alors pas de diculté.
En présence de paramètre et d’index simultanément, les variables apparaissant à la fois
dans les index et les paramètres sont problématiques. L’occurrence dans les index prend part
au diagonaliseur et va donc être α-renommé dans la clause de retour alors que celle dans les
paramètres n’y prend pas part et reste constante. Comment savoir alors quelles occurrences
de la variable dans le type attendu en retour de l’analyse de cas renommer et ne pas renommer
pour écrire la clause de retour ?
Que se soit suite au problème d’occurrence simultané dans un paramètre d’une variable
apparaissant dans un index ou de l’occurrence multiple dans les index, supposons que la
condition de linéarité d’occurrence des variables ne soit pas satisfaite pour la variable o. Il
faut alors réintroduire des degrés de liberté pour écrire un prédicat de retour. Nous voulons
dissocier les occurrences de o dans Q (le type attendu en retour) en fonction de l’occurrence
de o dans t’1 · · · t’s ou w’1 · · · w’s dont elles proviennent. Le problème se ramène concrè-
tement à dénir (Q0 : ∀. . . (o1 : _) . . . (o2 : _) . . ., Set) dont le type suit la signature de
l’inductif et tel que Q0 . . . o . . . o . . . = Q.
Notre heuristique fait le choix d’utiliser autant que le typage le permet o2 puis autant que le
typage le permet o1 puis o en dernier recourt. Elle est choisie pour maximiser la « typabilité »
des termes générés. Quand ni o1 ni o2 ne peuvent être choisis mais qu’un o’ imaginaire
uniable à la fois à o1, o2 et o le pourrait, nous avons aaire à un ltrage qui implique
l’axiome K sur le type de o. o1 et o2 ne sont pas dissociables. Notre algorithme n’utilise lui
que o. Il fournit ainsi un type qui ne varie pas suivant les branches et rend inexploitable
l’élimination. L’information que o1 = o2 = o est perdue.
Avant d’atteindre les feuilles du squelette d’index et les problèmes de généralisation, il a
fallu extraire le motif du diagonaliseur. Pour cela :
534 Du ltrage à l’analyse de cas structurellement
1. Nous commençons par une phase conservative :
— Quand une feuille du squelette d’index est une variable qui n’apparaît ni dans le type
attendu en retour ni dans les types des feuilles suivantes, il est remplaçable par un _
(le joker des motifs). Par exemple, pour détruire (f : even m) an d’obtenir un entier,
puisque m n’apparaît pas dans nat, il est parfaitement admissible d’écrire case f
predicate λ(_ : nat) (_ : even _) ⇒ nat of . . . end
— Dans la dénition d’un inductif, un index peut en déterminer un autre. Par exemple,
dans FLast, l’entier est déterminé par l’ensemble car il en est la taille. Plus géné-
ralement, à chaque fois que le type de l’inductif est de la forme ∀. . . (x : . . .) . . .
(y : I t1 · · · ts
), Set et que x est l’une des feuilles du squelette d’index d’un des
t1 · · · ts
, y détermine x. Un index déterminé par ailleurs grâce à la dénition de l’inductif
est remplaçable par un joker si, dans le type de l’objet ltré, il s’agit d’une
variable ou que l’un des index le déterminant commence par un constructeur.
— Un index déterminé par ailleurs ne l’est pas nécessairement qu’une seule fois. Dans
la dénition de FinEq le premier index est déterminé par le second et/ou le troisième
car les deux ensembles sont de même taille : l’entier donné.
Lorsque deux index déterminant un même troisième commencent tous deux par un
constructeur, le terme t correspondant à l’index déterminé apparaît comme argument
des deux constructeurs. Une occurrence déterminant l’autre, t est remplaçable
par un joker dans l’un des deux index déterminant en plus de remplacer l’index dé-
terminé par _.
2. Si après cette phase, nous n’avons plus que des constructeurs, des jokers et des variables
apparaissant linéairement, et hors des paramètres du type de l’objet ltré, nous voilà
dans la situation optimale. Voici un motif caractérisant le problème qui va permettre la
construction d’un diagonaliseur.
4.5.2 Hors du cadre pseudo-motif
Nous allons maintenant nous attarder sur des ltrages qui ne sont pas couverts par le
typage primitif. Comment éliminer une donnée dont les index du type sont des termes quelconques
(des sortes, des produits des analyses de cas, . . .) ?
Deux altermatives existent : perdre de l’information ou réintroduire les égalités explicites
que nous souhaitions éviter.
—
On ramène le problème de générer une annotation de type pour une analyse
de cas à un problème d’unication d’ordre supérieur
Si l’un des t’ n’est pas une variable. L’algorithme tente d’abstraire t’ par une variable
fraîche du type de l’argument correspondant dans la dénition de l’inductif. Les chances
de résultat concluant sont minces et la correspondance de cet argument avec t’ est
perdue. Quasi systématiquement, aucune occurrence substituable n’est trouvée et le
type de retour demandé est constant suivant les branches. L’information est perdue par
désynchronisation entre les types comme nous l’avons expliqué lorsque nous avons
étudier les conséquence de ne pas utiliser les abstractions de la clause de retour section
3.4.2.
544.6 Digression sur les cas impossibles dans des points xes
Si ces index n’apparaissent ni dans le type d’autres index non jokerisés ni dans le type
attendu en retour de l’analyse de cas, il n’y aura pas de problème de typage mais il
peut néanmoins appaitre des branches impossibles non reconnues comme telles. Prenons
l’exemple de (x : nat) et (f : even (plus x (S O))). En détruisant f pour obtenir un
nouvel entier (nat), il est tout-à-fait possible d’écrire la clause de retour λ(_ : nat) ⇒
nat. Nous n’avons pas l’information que la branche d’even_O est impossible même si
eectivement x + 1 , 0.
Les désagréments ont tendance à s’accumuler. Si une variable x apparaissant pourtant
linéairement dans les index a un type contenant un autre index t’, x ne sera pas convenablement
systématiquement renommée. Dans ∀(m n : nat) (f1 : Fin m) (f2 : Fin n)
(f3 : Fin (plus n m)) (H : FLast (plus m n) f3), eq (Fin (plus m n)) (append m f1 n
f2) f3, il est impossible d’éliminer H car la clause de retour est mauvaise que l’on écrive
λ(x : nat) (y : Fin x) ⇒ x = plus m n → eq (Fin x) (append m f1 n f2) y ou eq (Fin
(plus m n)) (append m f1 n f2) y
— L’alternative est de réappliquer la stratégie des égalités explicites du chapitre précédent.
Au lieu d’eacer ces termes u1 · · · us
, on réalise une coupure entrelacée sur l’égalité en
appliquant l’analyse de cas à eq_re ... y1
· · · eq_re ... ys
an de se souvenir dans les
branches à quoi sont égales les feuilles du squelette d’index. Il n’y a pas moyen de tirer
avantage automatiquement des ces égalités car elles n’ont pas de constructeur en tête.
Lorsque le terme de preuve est construit interactivement par tactique, l’utilisateur peut
réagir manuellement aux informations retournées pour construire les branches après
une élimination d’une inductif. La stratégie adoptable est diérente. Mieux vaut conserver
toutes les informations de correspondance quitte à utiliser pour se faire des égalités
(potentiellement hétérogènes) explicitement.
4.6 Digression sur les cas impossibles dans des points fixes
Il doit être fait une remarque maintenant qui ne prend du sens qu’une fois les questions
du contrôle de la bonne formation des points xes abordée (Chapitre 6)
Une analyse de cas est considérée comme un argument admissible d’un appel récursif si
toutes ses branches le sont. En particulier, si un inductif n’a, comme False, aucun constructeur,
toutes les zéros branches d’un ltrage d’un terme de ce type sont des appels récursifs
admissibles. An que les branches impossibles soient le plus invisibles possible, il faut les
peupler par des termes qui sont des appels récursifs admissibles. C’est pourquoi, plutôt que
I : True, Coq utilise dans les cas impossibles λ(x : False) ⇒ case x predicate λ(_ : False)
⇒ True of end : False → True.
Ainsi, si v est un sous terme d’un argument récursif dans la dénition du point xe f, le
terme f (Vhd v) est un appel récursif admissible pour la dénition
Definition Vhd (A : Set) (n : nat) (v : vector A (S n)) : A :=
let diag := λ(n : nat) ⇒
case n predicate λ(n’ : nat) ⇒ vector A n’ → Set of
|O:λ(_ : vector O) ⇒ False → True
|S:λ(m : nat) ⇒ λ(_ : vector (S m)) ⇒ A
554 Du ltrage à l’analyse de cas structurellement
end in
case v predicate diag of
|Vnil:λ(x : False) ⇒ case x predicate λ(_ : False) ⇒ True of end
|Vcons:λ(n : nat) (h : A) (t : vector A n) ⇒ h
end.
mais pas pour la dénition
Definition Vhd (A : Set) (n : nat) (v : vector A (S n)) : A :=
let diag := λ(n : nat) ⇒
case n predicate λ(n’ : nat) ⇒ vector A n’ → Set of
|O:λ(_ : vector O) ⇒ True
|S:λ(m : nat) ⇒ λ(_ : vector (S m)) ⇒ A
end in
case v predicate diag of |Vnil:I |Vcons:λ(n : nat) (h : A) (t : vector A n) ⇒ h
end.
car I n’est pas un sous terme !
4.7 Mécaniser la diagonalisation et compiler le filtrage
Le chapitre 2 indique comment obtenir un arbre de décision et une pile d’objet à ltrer
à partir d’un ltrage. Cette partie va indiquer comment aller mécaniquement d’un arbre de
décision à une succession d’analyse de cas. Toute la diculté est de gérer les types.
Les opérations élémentaires sont toutes mutuellement récursives, c’est pourquoi l’exposé
est nécessairement incrémental et non parallèle.
Les fonctions impliquées sont
— env ⊢ decl_branchenuméro_branche
continuation_corps_branche type_branche = résultat pour construire
une branche,
— env ⊢ construire_case terme_éliminé clause_de_retour continuation_corps_branche
= résultat pour construire une analyse de cas,
— env ⊢ (type_terme_éliminé 7→ type_attendu_retour) ց résultat, variables_à_généraliser
pour aller du type de l’objet analysé à un diagonaliseur,
— env ⊢ || (terme_éliminé : index_type_terme_eliminé) 7→ [substitution]type_attendu_retour
|| = arbre_decision, variables_à_généraliser pour construire l’arbre de décision associé
au type d’un terme éliminé,
— et env ⊢ arbre_décision : type_attendu_retour ց résultat pour aller d’un arbre de décision
à un terme du CCI.
4.7.1 Construire une analyse de cas à partir de sa clause de retour
La première opération nécessaire est la construction d’une branche dirigée par son type.
Il s’agit de la fonction decl_branche déclarée gure 4.12. On part du type que doit avoir la
branche et d’une fonction de continuation pour construire la branche. Le système regarde le
type :
564.7 Mécaniser la diagonalisation et compiler le ltrage
— S’il reconnaît une branche impossible, il peuple la branche automatiquement et n’utilise
pas la continuation.
— Si le type est une analyse de cas sur l’un des arguments du constructeur, nous sommes
dans la situation de la section 4.4. Le système fait une analyse de cas sur cette variable
pour n’appeler la fonction de l’utilisateur que lorsque toutes les informations de typage
auront été récupérées.
— Dans les autres cas, c’est à la continuation d’agir.
Γ ⊢ decl_branchei
k
T = t
Γ ⊢ decl_branchei
k
(∀
−−−−→
(x : S), False → T) = (λ
−−−−→
(x : S) (b : False) ⇒ ex_falso T b)
Γ,
−−−−→
(z : S) ⊢ (x 7→
*
.
,
case x predicate P
of |b1
· · · |bs
end
u1 · · · uj
+
/
-
) ց diag, y1
· · · yn
Γ,
−−−−→
(z : S) ⊢ construire_case x diag k_branche = t
Γ ⊢ decl_branchei
k
*
.
.
.
.
,
λ
−−−−→
(z : S) ⇒ case x
predicate P
of |b1
· · · |bs
end
u1 · · · uj
+
/
/
/
/
-
= λ
−−−−→
(z : S) ⇒ t y1
· · · yn
k_branche(Γ, T, i) = t ssi Γ ⊢ decl_branchei
k
T = t
Γ ⊢ decl_branchei
k
T = k Γ T i
Figure 4.12 – Dénition de la ième branche dirigée par son type T puis la continuation k
La fonction decl_branche peuple les parties non informatives de la branche, celles qui
sont issues d’un type de branche fourni par un diagonaliseur pour ne demander à l’utilisateur
que les branches utiles lors de réductions. Grâce à elle, nous dénissons construire_case,
la fonction décrite gure 4.13 qui construit une analyse de cas à partir d’un diagonaliseur et
d’une continuation fournissant les habitants des branches utiles.
4.7.2 D’un arbre de décision à des analyses de cas
Nous n’avons pas encore dit comment écrire une clause de retour mais nous savons ré-
pondre aux artefacs qu’elle induit dans les termes. Il est alors possible de décrire gure 4.14
comment aller d’un arbre de décision à un terme. Cette procédure a besoin du type T du
574 Du ltrage à l’analyse de cas structurellement
Γ ⊢ construire_case t diag k = o
Γ ⊢ C1 ∈ ∀
−−−−−−−−−→
(z1n : S1n), I u11
· · · u1j
· · · Γ ⊢ Cs ∈ ∀
−−−−−−−−→
(zsn : Ssn), I us1 · · · usj
Γ ⊢ decl_branchei
k
(∀
−−−−−−−−−→
(z1n : S1n), T u11
· · · u1j
(C1 z11
· · · z1n)) = b1
· · · Γ ⊢ decl_branchei
k
(∀
−−−−−−−−→
(zsn : Ssn), T us1 · · · usj
(Cs zs1 · · · zsn)) = bs
Γ ⊢ construire_case t T k = case t predicate T of |b1 · · · |bs end
Figure 4.13 – Dénition de l’élimination de t à partir du prédicat de retour diag suivant la
continuation k
terme à construire et de l’environnement de typage Γ. Les alias présents dans les noeuds de
l’arbre de décision doivent être des variables deux à deux distinctes et diérentes des variables
de l’environnement. Cet invariant est garanti par les fonctions qui construisent un
arbre de décision au moment où elles prennent en compte les alias donnés par l’utilisateur.
Γ ⊢ st : T ց t
Γ ⊢ Tail (t) : T ց t
Γ, (x : S) ⊢ p : T ց t
Γ ⊢ Leafx : : p : ∀ (x : S), T ց λ (x : S) ⇒ t
Γ, (x : S) ⊢ (x 7→ T) ց diag, y1
· · · ys
Γ, (x : S) ⊢ construire_case x diag k_case = t
Γ ⊢ Nodex(st1 · · · stn) : ∀ (x : S), T ց λ (x : S) ⇒ t y1
· · · ys
k_case(Γ, T, i) = t ssi Γ ⊢ sti
: T ց t
Figure 4.14 – D’un arbre de décision à un terme
La générations des analyses de cas suit exactement la structure de l’arbre de décision :
— A la n la substitution des alias par des variables est appliquée au membre droit de la
branche
— Une feuille est une abstraction. La substitution est enrichie du nouveau nom pour l’alias.
— Si l’on sait obtenir les variables du contexte qu’il faut généraliser et le diagonaliseur qui
correspondent à une élimination, nous savons construire l’analyse de cas qui correspond
à un noeud.
— Un échange introduit par des abstractions les éléments de la pile jusqu’à l’élément recherché,
retire des éléments introduits ceux à oublier car ils sont imposés par le typage
de l’élément recherché puis réapplique l’élément recherché suivi des éléments restants.
L’échange introduit comme le noeud des coupures entrelacées mais avec des termes à
ltrer plus tard et non des variables libres.
584.7 Mécaniser la diagonalisation et compiler le ltrage
4.7.3 Extraire un diagonaliseur
Il reste à construire le diagonaliseur (gure 4.16), c’est-à-dire à extraire le squelette d’index
d’un terme ltré, la généralisation des variables libres dont le type dépend des feuilles de ce
squelette et à tenter la meilleurs abstraction possible du type attendu en retour en fonction
de ces feuilles.
Γ ⊢ || (t : u1 · · · us
) 7→ [σ]c || = p, x1 · · · xs
Γ ⊢ || (t : u1 · · · us
, q) 7→ [σ]T || = pi
,
−−−−−−−−→
(ym : Sm)
∀j , i,pj = Leafnj
+m
_
: : Tail (False → True)
Γ ⊢ || (t : Ci u1 · · · us
, q) 7→ [σ]T || = Nodex(p1
· · · pn
),
−−−−−−−−→
(ym : Sm)
{(a : A) ∈ Γ | u occurs_in A} =
−−−−−→
(z : S’)
x variable fraiche Γ ⊢ || (t : q, z1 · · · zs
) 7→ [σ, u 7→ x]T || = p,
−−−−→
(y : S)
Γ ⊢ || (t : u, q) 7→ [σ]T || = Leafx : : p,
−−−−→
(y : S),
−−−−−→
(z : S’)
{(a : A) ∈ Γ | t occurs_in A} =
−−−−→
(z : S) x et y1
· · · ys
variables fraiches
abstract_all_when_possible (σ, t 7→ x, z1 7→ y1
· · · zs
7→ ys
) T = v
Γ ⊢ || (t : ∅) 7→ [σ]T || = Leafx, y1
· · · ys
: : Tail (v),
−−−−→
(y : S)
Figure 4.15 – Construction du diagonaliseur
La méthode pour trouver la meilleure abstraction d’un terme suivant des termes donnés
est due à Chung-Kil Hur. Le problème est le suivant : Pour u1 · · · um une liste de termes de
types respectifs S1 · · · Sm et un terme t de type T, trouver t’ tel que t’ u1 · · · um = t. Le terme t’
doit être bien typé. 1 Les termes u1 · · · um doivent en outre apparaître le moins possible dans
t’. Nous ne chercherons pas à qualier formellement « le moins possible ». Celui-ci dissimule
en eet la caractérisation de l’expressivité du ltrage sans l’axiome K, problème fondamental
que ce manuscrit ne résout pas.
A l’origine de l’algorithme réside un judicieux détournement. Coq ore à l’utilisateur un
mécanisme d’arguments implicites. Si une constante attend par exemple comme argument
un entier n puis un Fin n, quand l’utilisateur donne l’ensemble, il donne sa taille. Le premier
argument étant nécessairement cette taille, l’utilisateur n’a pas besoin de la donner explicitement,
le système peut l’inférer. Le premier argument est dénissable comme implicite donc
non donné par l’utilisateur et le système remplace ce "trou" par le terme adéquat.
Si u de type S apparaît dans t, remplaçons toutes les occurrences de u dans t par des "trous"
qui se nomment en réalité des variables existentielles. Demandons au système de résoudre
ses variables existentielles. Là où u est indispensable par typage, le système va le remettre.
1. D’ailleurs, obtenir son type demande déjà du travail.
594 Du ltrage à l’analyse de cas structurellement
Ailleurs, remplaçons les variables restantes par une variable y fraîche pour obtenir t’. Le
terme λ(y : S) ⇒ t’ est bien typé et convertible à t quand il est appliqué à u.
Nous avons obtenu une solution d’abstraction sur un terme. Pour une liste de termes la
solution est similaire mais compliquée par les dépendances de type entres les termes à abstraire.
Il faut en eet commencer par le dernier élément du futur télescope an qu’ensuite
son type soit lui aussi généralisé selon les termes dont il dépend.
La fonction abstract_all_when_possible doit donner une réponse bien typée et telles
que si σ ◦ σ
′ = id (σ’ est une substitution standard des variables vers les termes) alors
σ’(abstract_all_when_possible σ T) = T.
Γ ⊢ (t 7→ c) ց out, x1 · · · xs
Γ ⊢ t ∈ I a1 · · · am u1 · · · us
Γ ⊢ I a1 · · · am ∈ ∀
−−−−→
(x : S), Set Γ ⊢ || (t : u1 · · · us
) 7→ [ε]c || = st,
−−−−−−−→
(yn
: Tn)
Γ ⊢ st : ∀
−−−−→
(x : S) (z : I a1 · · · am x1 · · · xs
)
−−−−−−−→
(yn
: Tn), Set ց o
Γ ⊢ (t 7→ c) ց o, y1
· · · yn
Figure 4.16 – Prédicat de retour out de l’élimination de t pour obtenir c
4.8 Eléments de correction
Notre algorithme génère-t-il des termes bien typés ? Nous ne pouvons pas réellement exprimer
cette propriété. Nous ne sommes pas capable de donner une règle de typage primitive
pour le ltrage généralisé n’impliquant pas l’axiome K. La recherche sur ce sujet est très
active au moment de l’écriture de ce manuscrit mais elle n’a pas encore abouti à une caractérisation.
Nous ne pouvons donc pas énoncer de propriété telle que « si le ltrage est bien
typé, le terme du CCI généré par l’algorithme ci-dessus est bien typé ». Or, si l’utilisateur
écrit un ltrage qui n’a pas de sens, le résultat de sa compilation sera mal-typé. Par ailleurs,
notre algorithme nissant par une phase heuristique, il y a peu d’espoir de pouvoir obtenir
un résultat général. Cette question n’est néanmoins pas critique. DeBruijn a introduit un
principe essentiel en informatique théorique : plutôt que certier la génération de témoins de
manière complexe, assurons de manière simple a posteriori la correction du témoin exhibé.
Nous adoptons exactement cette démarche car le noyau de Coq (un véricateur de type du
CCI) vérie le bon typage de chacun des termes que nous générons. Il n’y a pas besoin de
faire conance à notre algorithme du point de vu du typage.
Le contrôle du terme généré par le véricateur de type n’exonère pas de toute vérication.
L’utilisateur souhaite que le comportement calculatoire de la chaîne d’analyse de cas soit celui
du ltrage généralisé dont elle découle. Cette adéquation entre le terme généré et son origine
est correcte si la règle de réduction donné section 2.1 est simulable sur le terme compilé au
moyen de βι-réductions du CCI.
Cette preuve est réalisée en deux étapes :
604.8 Eléments de correction
— La simulation du ltrage par des réductions d’arbres de décision (gure 2.7). Cette
preuve est identique au cas de ML traité par [38].
— La simulation des réduction d’arbres de décisions par les analyses de cas construites. Le
lemme cruciale est le suivant : lorsqu’une analyse de cas supplémentaire sur l’un des
arguments a été générée dans une branche pour raner son type (la situation expliquée
section 4.4), cette analyse de cas va être systématiquement réduite lorsqu’elle arrive
en tête. Ce lemme se prouve en raisonnant sur la forme de l’argument : l’argument a
nécessairement une forme qui va réduire l’analyse de cas pour que le terme éliminé
ait le bon type. Pour les autres situations, nos manipulations n’ont concerné que les
annotations de types et la preuve est immédiate.
Jean-François Monin avait montré l’apport d’une telle manière d’écrire des termes en Coq.
Nous apportons la possibilité de les écrire automatiquement. En ce sens, cette partie constitue
un pas en avant sur le chemin de la programmation certiée.
615 Simplifier un terme
Écrire sans assistance un terme complexe dans un langage à types riches est une chose
ardue. Des systèmes pour guider l’écriture de programmes ont donc été réalisés. Que ce soit
au moyen de tactiques [21] ou d’un mode d’édition interactif [41], une fonctionnalité clé est
de pouvoir écrire des termes « à trous » puis de demander au système quel doit être le type
des termes à mettre dans ces trous.
L’utilisateur n’a pas à fournir un terme de type syntaxiquement égal à celui attendu mais
un type qui lui est convertible. Pour faciliter la compréhension, il est même souhaitable que
le système n’ache pas le type qu’il a inféré pour le trou mais plutôt une forme réduite.
Ce chapitre propose un algorithme pour obtenir une forme réduite d’un terme. Nous parlons
de forme réduite et non de forme normale car la forme normale n’est pas le représentant
le plus lisible d’une classe d’équivalence pour la conversion.
En eet, pour un humain, une constante (au nom bien choisie) est plus explicite que sa
dénition. Une δ-expansion ne doit avoir lieu que si elle induit d’autres réductions.
Definition plus : nat → nat → nat :=
fix2 (pl : nat → nat → nat := λ(m n : nat) ⇒
case n predicate λ(_ : nat) ⇒ nat of
|O:m |S:λ(n’ : nat) ⇒ S (pl m n’)
end).
Definition succ : nat → nat := plus (S O).
Figure 5.1 – L’addition et le successeur
De plus, dans le CCI tel qu’il est déni actuellement, lors de normalisations impliquant des
points xes, déplier puis replier une constante est nécessaire. Considérons par exemple la
dénition de plus donnée gure 5.1. La forme normale de plus (S (S x)) y n’est pas S (S (plus
x y)) mais :
S (S (fix1 (pl : nat → nat → nat := λ(m n : nat) ⇒ case m predicate λ(_ : nat)
⇒ nat of |O:n |S:λ(m’ : nat) ⇒ S (pl m’ n) end) x y))
Après une présentation de la méthode de normalisation utilisée, nous détaillerons un
moyen d’obtenir la forme escomptée.
5.1 Normalisation en appel par nom
Suivant les schéma de compilation usuels (voir par exemple [26, 36]), la réduction d’un
terme est réalisée en le traduisant vers un langage particulier (l’évaluation), en calculant
635 Simplier un terme
dans ce langage (le calcul) puis en retraduisant le résultat vers un terme (la réication). Notre
langage cible est un état de machine abstraite. Un état de machine abstraite est la paire d’un
terme et d’une pile où sont stockés les destructeurs de type à appliquer au terme.
La syntaxe des piles est donnée par
sk : := ∅ | ◦ t, sk | ZcaseT(u1 · · · us
), sk | Zx (i, (f : T := t) : : u1 · · · us
), sk
◦ t représente un argument attendant d’obtenir la fonction à laquelle il est appliqué.
ZcaseT(u1 · · · us) stocke les branches d’une analyse de cas en attendant de connaître le
constructeur par lequel débute le terme ltré.
Zfix (i, (f : T := t) : : u1 · · · us) est un point xe attendant de savoir si son argument récursif
s’évalue sur un constructeur appliqué pour se déplier.
L’évaluation débute en plaçant le terme à réduire en face de la pile vide (∅). Les destructeurs
de termes sont empilés. Lorsqu’un constructeur de type est atteint, la tête de la pile est
inspectée pour déclencher si possible un calcul.
Les règles de calcul pour la β-réduction de λ(x : T) ⇒ t sont :
◦ u, sk –[t] →
(x : T)
k
k t[u/x] sk
∅ –[t] →
(x : T)
k
hλ(x : T) ⇒ t | ∅i
La continuation k du calcul sera la fonction d’évaluation.
Pour les règles ι et ϕ, il faut extraire de la tête de pile les arguments du constructeur (les
nœuds ◦ t). Nous notons t1 · · · tn⊕sk une pile constituée des nœuds applications ◦ t1 · · · ◦ tn
puis de sk (ne débutant pas par une application). Les règles de calcul pour le ie constructeur
Cisont
t1 · · · ts ⊕ ZcaseT(u1 · · · un), sk i
→k k ui
(◦ t1 · · · ◦ ts
, sk)
t1 · · · ts⊕
i
→k k v[fixj
(f : T := v)/f]
Zx (j, (f : T := v) : : u1 · · · uj-1), sk (◦ u1 · · · ◦ uj-1, ◦ (Ci
t1 · · · ts
), sk)
t1 · · · ts ⊕ ∅ i
→k
hCi
| ◦ t1 · · · ◦ ts
, ∅i
Le calcul prend encore une fois sa continuation k en argument an que tous les appels de
fonction dans la machine abstraite soient récursifs terminaux.
L’évaluation suit les règles de réécriture de la gure 5.2. La continuation k attendue par
les opérations de calculs est la vision fonctionnelle des règles d’évaluations. Formellement,
k t sk = hv | sk’i si et seulement si ∆ ⊢ ht | ski ↓CBN hv | sk’i.
Une fois qu’il n’y a plus de coupure en tête du terme, l’état de machine abstraite est réié
pour retrouver un terme en replaçant autour de la valeur obtenue les destructeurs de termes
restant. Le processus est décrit gure 5.3
Ce procédé permet d’obtenir la forme normale de tête faible d’un terme par un calcul en
appel par nom. Pour obtenir la forme normale forte, il faut traverser les fonctions et les
645.1 Normalisation en appel par nom
∆ ⊢ htmi
| ski
i ↓CBN htmo | skoi
∆ ⊢ ht | ◦ u, ski ↓CBN hv | sk’i
∆ ⊢ ht u | ski ↓CBN hv | sk’i
sk –[t] →
(x : T)
k
hv | sk’i
∆ ⊢ hλ(x : T) ⇒ t | ski ↓CBN hv | sk’i
∆ ⊢ ht | ZcaseP(u1 · · · us
), ski ↓CBN hv | sk’i
∆ ⊢ hcase t predicate P of u1 · · · us end | ski ↓CBN hv | sk’i
∆ ⊢ hui
| Zx (i, (f : T := t) : : u1 · · · ui-1), ski ↓CBN hv | sk’i
∆ ⊢ hfixi
(f : T := t) | ◦ u1 · · · ◦ ui
, ski ↓CBN hv | sk’i
∆ ⊢
fixi
(f : T := t) | u1 · · · ui-k⊕∅
↓CBN
fixi
(f : T := t) | u1 · · · ui-k⊕∅
k ≤ i
∆ ⊢ hx | ski ↓CBN hx | ski ∆ ⊢ hI | ◦ t1 · · · ◦ ts
, ∅i ↓CBN hI | ◦ t1 · · · ◦ ts
, ∅i
∆, (c : T := t), ∆’ ⊢ ht | ski ↓CBN hv | sk’i
∆, (c : T := t), ∆’ ⊢ hc | ski ↓CBN hv | sk’i ∆ ⊢ hS | ∅i ↓CBN hS | ∅i
∆ ⊢ h∀(x : S), T | ∅i ↓CBN h∀(x : S), T | ∅i
sk i
→k
hv | sk’i
∆ ⊢ hCi
| ski ↓CBN hv | sk’i
Figure 5.2 – Call By Name abstract machine
hu | ski ↑ v
ht | ∅i ↑ t
hcase t predicate T of u1 · · · us end | ski ↑ v
ht | ZcaseT(u1 · · · us
), ski ↑ v
ht u | ski ↑ v
ht | ◦ u, ski ↑ v
hfixi
(f : T := u) t1 · · · ti-1 t | ski ↑ v
ht | Zx (i, (f : T := u) : : t1 · · · ti-1), ski ↑ v
Figure 5.3 – Réinterprétation d’un état comme une valeur
655 Simplier un terme
produits an de normaliser leur corps puis appliquer récursivement le même processus aux
termes qui apparaissent dans les éléments de la pile avant de réaliser la réication.
Notre machine est inecace car elle réalise les substitutions une par une au lieu d’utiliser
un environnement. Cette machine avec des environnements est une machine de Krivine [33]
ou plutôt une machine de Krivine avec types algébriques [6] puisqu’elle manipule des inductifs.
Nous la présenterons section 5.3. Avant cela, traitons le cœur de notre contribution, les
repliages de constante.
5.2 Trace des constantes dépliées
Nous ajoutons aux états de machine de la section précédente une liste des constantes dé-
pliées convertibles au terme de l’état. Cette liste va permettre de savoir quelle constante
replier.
Nous utilisons une liste car nous souhaitons traiter ce que nous nommons une cascade de
constantes. Il s’agit d’une situation où une constante est dénie grâce à une autre constante.
Par exemple, nombre de fonctions (telles que incr_ids gure 5.1) sur les listes (celle du langage
dénie gure 1.11) sont dénies grâce aux itérateurs sur les listes (comme list_map) qui eux
sont dénis par point xe et analyse de cas .
Definition list_map (A B : Set) (f : A → B) : list A → list B :=
fix1 (map : list A → list B := λ(l : list A) ⇒ case l
predicate λ(_ : list A) ⇒ list B of
|nil:nil B
|cons:λ(h : A) (t : list A) ⇒ cons (f h) (map t)
end).
Definition incr_ids : list nat → list nat :=
list_map nat nat succ.
Figure 5.4 – Exemple d’itérateur et d’une de ses instances
Formellement, un dépliage est un triplet constitué d’un nom de constante et de deux listes
de termes appelées les paramètres et les arguments.
Une liste de dépliage p est un repliage du terme t noté t p si pour tous ses éléments la
constante appliquée aux paramètres est convertible à t appliqué aux arguments.
Le point xe pl a pour dépliage (plus,[],[]) qui n’a ni argument ni paramètre mais on comprend
le sens des paramètres pour donner un dépliage du point xe map : (list_map,[S, T,
t],[]) (avec S, T et t les valeurs de A, B et f dans le cas considéré). L’intérêt des arguments est
illustré par : pl a pour dépliage alternatif (succ,[],[S O])
Les primitives dont nous avons besoin sur les listes de dépliages sont dénies telles que
— Si t u p alors t add_arg u p.
— Pour u donné, si λ(x : T) ⇒ t p et pour tout (c,params,args) ∈ p, on a soit (args =
u, _) soit (args = ∅), alors t[u/x] add_param u p.
— Si c p et ∆(c) = t alors t add_cst c p.
665.2 Trace des constantes dépliées
par
(** val add_arg : term → cst_stk → cst_stk *)
let add_arg arg = List.map (fun (a,b,c) → (a,b,c @ [arg]))
(** val add_param : term → cst_stk → cst_stk *)
let add_param param p = List.map (fun (a,b,c) →
match c with |[] → (a,b @ [param],c) |_ : :q → (a,b,q)) p
(** val add_cst : cst → cst_stk → cst_stk *)
let add_cst cst p = (c,[],[]) : : p
Les noeuds de la pile qui détruisent un inductif sont modiés. Une liste de dépliage est
ajoutée. Elle représente un repliage de la réication du terme et de la pile jusqu’à ce noeud
inclus. Il existe une fonction eacement triviale qui permet de retrouver une pile de machine
appel par nom à partir d’une pile avec les traces en supprimant ces annotations.
sk : := ∅ | ◦ t, sk | ZcaseT(u1 · · · us/p), sk | Zx (i, (f : T := t)/p : : u1 · · · us
), sk
Les étapes de calcul et d’évaluation (gure 5.5) sont modiées de telle sorte à maintenir
un repliage du terme de l’état de la machine. Nous nommons RN cette nouvelle machine.
L’évaluation enregistre aussi les repliages des destructeurs d’inductif lorsqu’elle les empile.
◦ u, sk p –[t] →
(x : T)
k
k (add_param u p) (t[u/x]) sk
∅
p –[t] →
(x : T)
k
hλ(x : T) ⇒ t | ∅i
Maintenant que la machinerie est en place, le calcul sur les inductifs et la réication peuvent
en tirer avantage. Pour cela, nous dénissons la notion de meilleur repliage.
Lors du calcul de succ (S m), le repliage du point xe à l’intérieur de sa dénition est
[(plus,[],[]) ;(succ,[],[S O])]. La constante dépliée en premier, le premier élément de la cascade,
est en fond de repliage. Nous voulons l’utiliser autant que possible pour remplacer le terme
déplié. C’est possible si le terme à replier est appliqué aux arguments du dépliage (c’est bon
pour succ si le premier argument de pl est S O). Si ce n’est pas le cas, nous essayons avec le
dépliage suivant (plus dans notre exemple). Les fonctions qui choisissent le meilleur repliage
sont refold_term et refold_state. La fonction refold_term travaille comme une substitution
qui regarde les arguments de la variable à substituer pour choisir par quoi substituer. La
fonction refold_state travaille elle sur un état de machine abstraite. Elle inspecte les termes
en tête de pile pour choisir par quoi elle va remplacer le terme.
Par construction, le nombre d’arguments des dépliages dans un repliage est une fonction
croissante. Un dépliage n’ayant pas d’argument peut toujours être utilisé car il n’y a alors aucune
condition sur le contexte. Nous ne conservons donc en pratique qu’un seul dépliage sans
argument en tête du dépliage. Lors du calcul de incr_ids (cons x y), le repliage du point xe
est [(map_list, [nat;nat;succ], []) ;(incr_ids,[],[])] mais nous ne gardons que [(incr_ids,[],[])]
qui est toujours utilisable.
Lors du dépliage d’un point xe, le meilleur repliage du point xe est utilisé dans la substitution
plutôt que la dénition du point xe.
675 Simplier un terme
∆ ⊢p htmi
| ski
i ↓RN htmo | skoi
s
p –[t] →
(x : T)
k
hv | s’i
∆ ⊢p hλ(x : T) ⇒ t | si ↓RN hv | s’i
∆ ⊢add_arg u p
ht | ◦ u, si ↓RN hv | s’i
∆ ⊢p ht u | si ↓RN hv | s’i
∆ ⊢p h∀(x : S), T | ∅i ↓RN h∀(x : S), T | ∅i
sk i
→k
hv | sk’i
∆ ⊢p hCi
| ski ↓RN hv | sk’i
∆ ⊢∅
t | ZcaseT(u1 · · · us/p), sk
↓RN hv | sk’i
∆ ⊢p hcase t predicate T of u1 · · · us end | ski ↓RN hv | sk’i
∆ ⊢∅
ui
| Zx (i, (f : T := t)/p : : u1 · · · ui-1), sk
↓RN hv | sk’i
∆ ⊢p hfixi
(f : T := t) | ◦ u1 · · · ◦ ui
, ski ↓RN hv | sk’i
∆ ⊢p
fixi
(f : T := t) | u1 · · · ui-k⊕∅
↓RN
fixi
(f : T := t) | u1 · · · ui-k⊕∅
∆ ⊢p hx | ski ↓RN hx | ski ∆ ⊢p hI | ◦ t1 · · · ◦ ts
, ∅i ↓RN hI | ◦ t1 · · · ◦ ts
, ∅i
∆, (c : T := t), ∆’ ⊢add_cst c p
ht | ski ↓RN hv | sk’i
∆, (c : T := t), ∆’ ⊢p hc | ski ↓RN hv | sk’i ∆ ⊢p hs | ∅i ↓RN hs | ∅i
Figure 5.5 – Refoldant Call By Name abstract machine
685.3 Refolding Algebraic Krivine Abstract Machine
t1 · · · ts ⊕ ZcaseT(u1 · · · us/p), sk i
→k k ∅ ui
(◦ t1 · · · ◦ ts
, sk)
t1 · · · ts⊕
i
→k k ∅ v[refold_term p/f]
Zx (j, (f : T := v)/p : : u1 · · · uj-1), sk (◦ u1 · · · ◦ uj-1, ◦ (Ci
t1 · · · ts
), sk)
t1 · · · ts ⊕ ∅ i
→k
hCi
| ◦ t1 · · · ◦ ts
, ∅i
Lorsqu’un éliminateur d’inductif est replié, le meilleur repliage est utilisé plutôt que la
construction elle-même (gure 5.6).
hu | ski ↑ v
ht | ∅i ↑ t
refold_state p (case t predicate T of u1 · · · us end) | sk
↑ v
t | ZcaseT(u1 · · · us/p), sk
↑ v
ht u | ski ↑ v
ht | ◦ u, ski ↑ v
refold_state p (fixi
(f : T := u) t1 · · · ti-1 t) | sk
↑ v
t | Zx (i, (f : T := u)/p : : t1 · · · ti-1), sk
↑ v
Figure 5.6 – Réication du repliage d’une valeur
La correction de notre machine est garantie par le théorème : Pour tout terme t et toute pile
de machine sk, si ∆ ⊢p ht | ski ↓RN hv | si, t p et ∆ ⊢ ht | eacement(sk)i ↓CBN hv’ | s’i alors
∆ ⊢ v 7→βδ v’ et les termes apparaissant dans l’eacement de s se réduisent modulo βδ
vers le terme à la même place dans s’. Toutes les réductions ι et ϕ possibles ont été réalisées.
5.3 Refolding Algebraic Krivine Abstract Machine
La machine présentée jusqu’ici fonctionne mais elle est inecace. Elle est calculatoirement
inecace comme nous l’avons déjà remarqué section 5.1. Pire, sa capacité à réaliser les
repliages est limitée. Ces deux sous-optimalitées se corrigent en améliorant les substitutions.
Pour comprendre le problème avec les repliages, revenons sur l’exemple succ (S m).
Le système répond S (plus (S O) n) et non S (succ n) car le dépliage du point xe a lieu
avant la substitution de m par S O dans le corps du point xe. L’argument de l’appel récursif
au moment de la substitution ne correspond pas à l’argument demandé pour replier par succ,
ce choix est donc éliminé.
D’autre part, en repliant par la meilleure constante à chaque fois, les δ-réductions ont lieu
à chaque fois. Lors de la réduction de plus m (S (S n)), la constante plus est dépliée deux fois.
En retardant la substitution, les alternatives peuvent toutes deux être conservées an que
dans un calcul, le point xe soit utilisé et que durant la réication, la constante donne un
terme concis.
Nous modions notre machine pour qu’elle manipule non plus des termes mais des clô-
tures, c’est-à- dire des paires (terme, substitution).
La grammaire des substitutions est constituée de trois types de noeuds, le premier pour les
termes non évalués, le deuxième pour les constructeurs déjà calculés (car ils sont l’argument
695 Simplier un terme
récursif d’un point xe) et le troisième pour les points xes dépliés qui stockent la cascade
de constantes dont ils sont issus.
σ : := ∅ |
x := Sapp σ’(t), σ
|
(
x := Scstrj σ1(t1) · · · σs
(ts
), σ
)
| {x := Sxi σ’(f : T := t)/cst, σ }
La pile est modiée car tous les termes deviennent des clôtures. Comme dans les substitutions,
un noeud particulier est ajouté pour des valeurs déjà calculées. Une fois réduit sur
un constructeur, l’argument récursif d’un point xe doit en eet être réempilé an de procéder
au dépliage du point xe. La fonction l⊕sk doit maintenant aussi extraire ces noeuds
spéciaux.
Remarque Avec des valeurs qui sont des clôtures et non plus des termes, un comportement
remarquable de la machine apparaît. Le calcul de l’argument récursif pour autoriser le dé-
pliage d’un point xe introduit de l’appel par valeur au sein de notre machine en appel par
nom. Avant d’avoir des substitutions, nous réions implicitement cette valeur avant de la
remettre dans la pile.
sk : := ∅ | ◦ σ(t), sk | ZcaseT(σ(u1 · · · us
)/cst), sk | Zx (i, σ(f : T := t)/cst : :
σ1(u1) · · · σi-1(ui-1)), sk | Zcstri σ1(t1) · · · σs
(ts
), sk
Les repliages ne sont pas profondément diérents hormis qu’ils manipulent des clôtures.
(** val add_arg : term → subst → cst_stk → cst_stk *)
let add_arg arg sigma p = List.map (fun (a,b,c) → (a,b,c @ [arg, sigma])) p
(** val add_param : term → subst → cst_stk → cst_stk *)
let add_param param sigma p = List.map (fun (a,b,c) →
match c with |[] → (a,b @ [param, sigma],c) |_ : :q → (a,b,q)) p
(** val add_cst : cst → cst_stk → cst_stk *)
let add_cst cst p = (c,[],[]) : : p
Le calcul ne fait plus de substitution, il enrichit la substitution de la clôture.
Les règles de réécriture sont moins claires du fait des clôtures mais seul change réellement
le fait d’interroger la substitution quand une variable est atteinte.
A la n de l’évaluation, il faut retourner d’une clôture à un terme en appliquant eectivement
la substitution avant de réier l’état de la machine. La propagation d’une substitution
σ dans un terme t pour obtenir u est notée u ⋉ σ.
Cette nouvelle machine est meilleure que la précédente si elle réalise plus de repliage tout
en calculant toujours toutes les ϕ expansions et les ι réductions possibles. Le théorème le
garantissant serait qu’en appliquant les substitutions à la sortie de la machine, on ait un
terme qui se βδ réduise sur la sortie de la machine appel par nom avec repliage.
5.4 Configurabilité
Trouver la manière optimale de réduire une constante n’est pas du ressort d’un ordinateur
car la notion elle-même n’est pas dénie. Certaines constantes masquent des preuves sans
705.4 Congurabilité
◦ σ(u), sk
p –[t]
σ’ →
(x : T)
k k (add_param u σ p) t
(
x := Sapp σ(u), σ’
) sk
Zcstri σ1(t1) · · · σs
(ts
), sk
∅ –[t]
σ→
(x : T)
k
k ∅ t
({x := Scstri σ1(t1) · · · σs
(ts
), σ }) sk
∅
p –[t]
σ→
(x : T)
k
hσ(λ(x : T) ⇒ t) | ∅i
σ1(t1) · · · σs
(ts
) ⊕ ZcaseT(σ(u1 · · · us
)/p), sk i
→k k ∅ ui σ (◦ σ1(t1) · · · ◦ σs
(ts
), sk)
σ1(t1) · · · σs
(ts
)⊕
i
→k k ∅ v (
(
f := Sxj σ(f : T := v)/p, σ
)
)
Zx (j, σ(f : T := v)/p : : σ’1(u1) · · · σ’j-1(uj-1)), (σ’1(u1) · · · σ’j-1(uj-1),
sk Zcstri σ1(t1) · · · σs
(ts
), sk)
σ1(t1) · · · σs
(ts
) ⊕ ∅ i
→k
hCi
| σ1(t1) · · · σs
(ts
), ∅i
contenu calculatoire et qu’en général on ne souhaite pas déplier. Certaines constantes sont
des applications partielles d’autres constantes que l’on ne souhaite déplier que si elles ont
elles-même un nombre susant d’arguments pour poursuivre des calculs. Enn les constantes
représentant des point xes construits non pas à partir d’une analyse de cas élémentaire sur
leur argument récursif mais à l’aide d’un ltrage complexe ne doivent se déplier que si les
arguments permettent d’atteindre une feuille de l’arbre de décision du ltrage et non pas
uniquement si l’argument récursif commence par un constructeur. D’autres situations sont
imaginables. Bref, il faut orir à l’utilisateur de congurer pour chaque constante globale son
comportement vis à vis du dépliage.
Notre machine peut en tout cas comprendre ces directives :
— Ne jamais se déplier, c’est ne pas se déplier !
— Ne pas se replier, c’est ne pas être mis dans la trace des constantes dépliées.
— Contrôler le nombre d’arguments, c’est compter le nombre de noeuds ◦ t en tête de pile.
— Nous savons déjà geler le dépliage d’un point xe en attendant de savoir si son argument
récursif se réduit sur un constructeur. Nous pouvons similairement ajouter le
nécessaire pour réduire les arguments d’une constante an de contrôler s’ils permettent
d’atteindre une feuille d’un arbre de décision donné.
En pratique, une table stockant les arbres de décision sous-jacents pour toutes les constantes
est dénie. Elle est interrogée lorsque le terme de l’état de la machine est une constante.
Le premier argument sur lequel travaille l’arbre de décision est placé en tête de machine
et on empile un noeud Zconst (cst, arg1
· · · args
, split_tree) qui stocke la constante, les
arguments déjà traités et l’arbre de décision qui reste à parcourir. Le calcul dans le cas
des constructeurs est enn étendu pour gérer ces noeuds Zconst (cst, arg1
· · · args
, st).
Si l’arbre de décision restant à considérer (st) est vide, la constante cst’ est eectivement
dépliée. Sinon, le prochain argument argsk
qu’il faut évaluer est mis en tête.
715 Simplier un terme
∆ ⊢p hσ(tmi
) | ski
i ↓RK hσ’(tmo) | skoi
∆ ⊢add_arg u σ p
hσ(t) | ◦ σ(u), ski ↓RK hσ’(v) | sk’i
∆ ⊢p hσ(t u) | ski ↓RK hσ’(v) | sk’i
∆ ⊢p hσ(s) | ∅i ↓RK hσ(s) | ∅i ∆ ⊢p hσ(∀(x : S), T) | ∅i ↓RK hσ(∀(x : S), T) | ∅i
∆ ⊢∅
σ(t) | ZcaseT(σ(u1 · · · us
)/p), sk
↓RK hσ’(v) | sk’i
∆ ⊢p hσ(case t predicate T of u1 · · · us end) | ski ↓RK hσ’(v) | sk’i
sk i
→k
hσ’(v) | sk’i
∆ ⊢p hσ(Ci
) | ski ↓RK hσ’(v) | sk’i
skp –[t]
σ→
(x : T)
k
hσ’(v) | sk’i
∆ ⊢p hσ(λ(x : T) ⇒ t) | ski ↓RK hσ’(v) | sk’i
∆ ⊢∅
σi
(ui
) | Zx (i, σ(f : T := t)/p : : σ1(u1) · · · σi-1(ui-1)), sk
↓RK hσ’(v) | sk’i
∆ ⊢p hσ(fixi
(f : T := t)) | ◦ σ1(u1) · · · ◦ σi
(ui
), ski ↓RK hσ’(v) | sk’i
sk = ◦ σ1(u1) · · · ◦ σi-k(ui-k), ∅
∆ ⊢p hσ(fixi
(f : T := t)) | ski ↓RK hσ(fixi
(f : T := t)) | ski
∆ ⊢p hσ(t) | ski ↓RK hσ’(v) | sk’i
∆ ⊢p
(σ”,
x := Sapp σ(t), σ”’
)(x) | sk
↓RK hσ’(v) | sk’i
(◦ σ1(u)1
· · · ◦ σs
(u)
s
, sk) i
→k
hσ’(v) | sk’i
∆ ⊢p’ h(σ”, {x := Scstri σ1(u1) · · · σs
(us
), σ”’})(x) | ski ↓RK hσ’(v) | sk’i
∆ ⊢p
D
σ(fixj
(f : T := t)) | skE
↓RK hσ’(v) | sk’i
∆ ⊢p
D
(σ”, (
x := Sxj σ(f : T := t)/p’, σ”’)
)(x) | skE
↓RK hσ’(v) | sk’i
∆ ⊢p
σ(I) | ◦ σ1(t)1
· · · ◦ σs
(t)
s
, ∅
↓RK
σ(I) | ◦ σ1(t)1
· · · ◦ σs
(t)
s
, ∅
∆, (c : T := t), ∆’ ⊢add_cst c p h∅(t) | ski ↓RK hσ’(v) | sk’i
∆, (c : T := t), ∆’ ⊢p hσ(c) | ski ↓RK hσ’(v) | sk’i
Figure 5.7 – Refoldant Krivine Abstract Machine
725.5 Discussion
5.5 Discussion
La congurabilité ne sut pas à orir toutes les possibilités. Dans notre implantation,
certains choix sont codés en dur, d’autres sont impossibles. Nous les discutons ici.
Cascade de constante Il existe des systèmes logiques comme Agda [14] ou Matita [1] dont
les points xes sont « génératifs ». Les points xes n’y sont pas des objets locaux mais
des constantes globales capables de s’appeler elles-mêmes. Le problème des repliages
est alors bien moins critique.
Par contre, dans le cas d’une constante dénie comme list_map appliquée à une fonction
particulière, exprimer les appels récursifs en fonction de cette constante plutôt que de
l’itérateur est un gain. Notre système est donc plus qu’une simulation du cas génératif
en présence de cascade de constantes.
Pour autant, la réponse apportée n’est pas idéale. Elle est extrêmement sensible à la syntaxe
et suppose une expertise de l’utilisateur an d’être exploitable. Un simple échange
d’argument et le système est perdu. Par exemple, en dénissant plus par récurrence sur
son premier argument puis succ m par plus m (S O), l’information conservée au cours
de la réduction de succ (S n) est que pl (S n) (S O) est repliable en succ (S n), ce qui est
vrai mais inutile. Le résultat obtenu est alors seulement S (plus n (S O)).
Points fixes mutuels Nous n’en avons pas parlé car ils ne changeaient jusqu’ici rien à notre
étude mais Coq ore la possibilité de dénir des types de donnée et des points xes
mutuellement récursifs. La machine abstraite ne conserve que les noms des constantes
qu’elle a dépliées au cours de la réduction. Il n’y a donc aucun moyen direct de connaître
le nom de la constante globale qui correspond à un appel récursif à un autre point xe
du paquet !
Replier ou réduire Les constantes dénies à partir de list_map sont toujours convenablement
repliables car la fonction est un paramètre de la dénition. Dans le cas de list_fold,
par contre, l’accumulateur évolue et les appels récursifs ne s’expriment pas forcément
en fonction de la première constante. Nous choisissons de privilégier la réduction (et
donc le repliage utilisant list_fold) sur la conservation de la constante haut niveau.
L’autre choix peut avoir des usages.
Contrôler le nombre de dépliages Supposons qu’un utilisateur ait un type impliquant plus
n (S (S O)) qu’il souhaite exprimer en fonction de plus n (S O) et non n. Il ne peut ni dire
de ne pas déplier plus ni se contenter d’en autoriser le dépliage. Il lui faut un moyen
d’autoriser un unique dépliage. L’implantation eective permet ce comportement en
ranant le moment où elle autorise certaines réductions.
736 Etablir qu’un point fixe ne produit pas de
calcul infini
Prenons le point xe fix1 (f : ∀(n : nat), False := λ(n : nat) ⇒ f O). D’après les règles
de la gure 1.9 section 1.4, si on oublie la condition Decr, ce terme du CCI est bien typé.
Pourtant, f (S O), par exemple, est une preuve close de False. Ainsi, pour toute proposition
logique P, il existe une preuve de P (cf gure 3.6). Cette preuve est case (fix1 (f : ∀(n : nat),
False := f O)) (S O) predicate λ(_ : False) ⇒ P of end.
Le programmeur n’est pas plus satisfait que le mathématicien. Ce point xe n’est pas autre
chose qu’une boucle innie qui ne répondra jamais de valeur. Toutes les garanties que nous
souhaitons apporter sur les preuves/programmes s’écroulent donc si nous ne nous assurons
pas que la réduction des point xes termine. C’est justement le rôle du jugement qui demande,
dans l’exemple, Decr(∆,λ(n : nat) ⇒ f O,f,1) (La syntaxe qui nous allons introduire
est ∆ ;{f := STRICT, ∅} #
1
f
hλ(n : nat) ⇒ f O | ARGi). Son objectif est d’imposer la terminaison
par décroissance structurelle de f suivant son 1
er argument. Un point xe dont le corps
vérie cette propriété est dit gardé.
Ce chapitre décrit comment le jugement de garde est déni. Partant du principe de base
de décroissance structurelle, nous introduirons une à une quelques subtilités permettant de
traiter un nombre toujours plus grand de cas de décroissance structurelle. Les premiers ra-
nements, qui concernent les branches impossibles ou les points-xes imbriqués, existent dans
Coq depuis le travail de Gimenez [23]. Nous introduirons et justierons ensuite les nouveaux
ranements suivants : propagation des conditions de décroissance à travers les coupures entrelacées,
propagation des conditions de décroissance à travers les βιϕ-rédex garantissant la
réduction forte, prise en compte de questions d’ecacité.
6.1 Décroissance structurelle
Les points xes ont été introduits en CCI an de manipuler les structures de données ré-
cursives. Ils ne permettent que cela. La construction d’un point xe est structurée autour
d’un argument de type inductif explicitement nommé. Il est appelé argument récursif. L’argument
i dans fixi
(f : T := t) est le numéro de l’argument récursif. Le principe de la garantie
de terminaison des points xes est :
A chaque dépliage d’un point xe, au moins un des constructeurs de tête
de l’argument récursif est consommé
.
756 Etablir qu’un point xe ne produit pas de calcul inni
Par exemple, un point xe f appliqué à S (S O) ne peut faire des appels récursifs qu’à f (S
O) ou f O. Il consomme un ou deux constructeurs.
La description de l’algorithme qui assure que l’argument récursif d’un point xe décroît
structurellement repose sur les concepts énumérés ici.
La vérication de la propriété se base sur une classication des variables libres apparaissant
dans la dénition du corps du point xe.
NO signie que la variable n’est pas sous-terme de l’argument récursif.
STRICT signie qu’elle est sous terme de l’argument récursif.
ARG qu’elle est l’argument récursif lui-même.
La catégorie à laquelle appartient chaque variable libre est stockée au sein d’un environnement
que nous noterons Ψ. L’environnement ∆ contient lui les dénitions des constantes
globales.
Deux phases distinctes se succèdent. D’abord
∆ ;Ψ #
i
f
ht | πi , le jugement principal, parcourt un terme t (le corps du point xe) à la
recherche des appels récursifs à f pour les vérier. Cette tâche comporte deux aspects :
— Quand un lieur est traversé, le statut de sous-terme de la nouvelle variable libre
introduite est déterminé et mémorisé dans l’environnement.
— Quand un appel récursif à f est atteint, son i-ième argument est contrôlé. Le second
jugement vérie que ce terme est sous-terme. Il utilise pour cela les valeurs de sousterme
des variables libres collectées dans l’environnement au fur et à mesure du
parcours du corps du point xe.
∆ ;Ψ ⋄ ht | πi = spec donne la spécication de sous-terme spec d’un terme t (l’argument
en position récursive d’un appel récursif) grâce aux spécications de sous-terme de ses
variables libres. Ce jugement est appelé par le premier à chaque fois qu’il atteint un
appel récursif.
Calculer une valeur de sous-terme
Le dernier argument (π) des jugements est une pile. Comme une pile de machine abstraite,
elle donne la valeur des variables correspondant aux lieurs en tête du terme à inspecter. La
diérence est que c’est ici une valeur de sous-terme et non un terme qui est associé à une
variable.
En réalité, le deuxième jugement décrit gure 6.1 est eectivement une machine abstraite
pour la β-réduction en appel par valeur. Il s’agit d’une machine qui calcule des spécications
de sous-terme.
Le premier jugement embarque cette machine abstraite an de lancer des calculs avec un
environnement correct.
Ces machines ont une règle particulière :
∆ ;Ψ ⋄ hu | ∅i = c ∆ ;Ψ ⋄
t1 | renforce1(c)1
· · · renforce1(c)s
= o1
· · · ∆ ;Ψ ⋄
tn | renforcen(c)1
· · · renforcen(c)s
= on
Yn
k = 1ok = o
∆ ;Ψ ⋄ hcase u predicate T of t1 · · · tn end | πi = o
766.1 Décroissance structurelle
∆ ;Ψ ⋄ ht | πi = out
∆ ;Ψ ⋄ hx | πi = Ψ(x)
∆ ;Ψ ⋄ h∆(c) | πi = o
∆ ;Ψ ⋄ hc | πi = o ∆ ;Ψ ⋄ hs | ∅i = NO
∆ ;{x := s, Ψ} ⋄ ht | πi = out
∆ ;Ψ ⋄ hλ(x : S) ⇒ t | s, πi = out
∆ ;{x := NO, Ψ} ⋄ ht | ∅i = out
∆ ;Ψ ⋄ hλ(x : S) ⇒ t | ∅i = out
∆ ;Ψ ⋄ hu | ∅i = s ∆ ;Ψ ⋄ ht | s, πi = out
∆ ;Ψ ⋄ ht u | πi = out ∆ ;Ψ ⋄ h∀(x : S), T | ∅i = NO
∆ ;Ψ ⋄ hC | πi = NO ∆ ;Ψ ⋄ hI | πi = NO
∆ ;
g := NO, Ψ
⋄
t | NO1 · · · NOk
= o
∆ ;Ψ ⋄
D
fixj
(g : T := t) | s1 · · · sk
E
= o
∆ ;Ψ ⋄ hu | ∅i = c ∆ ;Ψ ⋄
t1 | renforce1(c)1
· · · renforce1(c)s
= o1
· · · ∆ ;Ψ ⋄
tn | renforcen(c)1
· · · renforcen(c)s
= on
Yn
k = 1ok = o
∆ ;Ψ ⋄ hcase u predicate T of t1 · · · tn end | πi = o
Figure 6.1 – Calcul de la spécication de sous terme d’un terme
776 Etablir qu’un point xe ne produit pas de calcul inni
Cette règle est la clé de voûte de la garantie de la terminaison. Elle utilise deux fonctions
sur les valeurs de sous-terme à expliquer.
— Nous souhaitons que n soit un sous-terme si t de type nat est l’argument récursif ou
déjà un sous-terme dans case t predicate λ(m : nat) ⇒ T of |O:a |S:λ(n : nat)
⇒ b end.
Plus génériquement, la spécication STRICT est assignée aux variables représentant les
arguments des constructeurs dans les branche lorsque le terme ltré a la spécication
ARG. Pas à toutes les variables, si le terme ltré a le type I t1 · · · ts
, uniquement aux
variables de type ∀
−−−−→
(x : S), I u1 · · · us
. Les autres ont la spécication NO.
En eet, le CCI autorise la dénition de constructeurs dont le type est polymorphe
comme par exemple
Inductive I : Set := | C :(∀(P : Set), P → P) → I.
La condition sur les types des arguments du constructeur est donc indispensable an
que ne puisse pas être admise la dénition non terminante :
Definition Paradox : False :=
(fix1 (ni : I → False := λ(i : I) ⇒
case i predicate λ(_ : I) ⇒ False of
|C:λ(f : ∀ (P : Set) , P → P) ⇒ ni (f _ i)
end)) (C (λ(P : Set) (x : P) ⇒ x)).
Formellement, la description de la machine utilise une fonction qui donne la caractéristique
de sous-terme des arguments d’un constructeur "du bon type" dans une branche
en fonction de la caractéristique de sous-terme de l’objet ltré. Sa spécication est bien
plus complexe que sa dénition car il s’agit de dire
renforcei
(NO) = NO1 · · · NOs et
renforcei
(ARG) = STRICT1 · · · STRICTs pour les arguments de Ci non polymorphes
(NO1 · · · NOs sinon).
renforcei
(STRICT) = STRICT1 · · · STRICTs
— L’autre problématique est de fusionner les valeurs de sous-terme de chacune des branches
an de répondre la valeur de sous-terme de l’ensemble d’une analyse de cas.
C’est objet de l’opération × dénie gure 6.2. Cette opération se doit d’être associative
commutative an de ne pas être inuencée par l’ordre des branches. L’assistant de
preuve de votre choix le garantit très facilement.
Il faut de plus une caractéristique pour l’analyse de cas à zéro cas. Un inductif à zéro cas
ne pouvant jamais être construit dans un contexte cohérent, son élimination ne peut
avoir lieu que dans des cas d’absurdité, c’est-à-dire dans du code mort. Nous introduisons
donc une spécication de sous-terme DEAD qui caractérise du code mort et qui
est l’élément absorbant de l’opération ×. Une analyse de cas qui analyse du code mort
est nécessairement du code mort. Il est donc admissible de faire un appel récursif sur un
terme de spécication DEAD. Il n’arrivera en eet pas ! De même, renforcei
(DEAD)
= DEAD1 · · · DEADs
, une analyse de cas de code mort a des branches qui sont du code
mort donc jamais les arguments des constructeurs ne seront habités.
Il ne reste alors plus qu’à donner le premier jugement, celui qui fait le contrôle des appels
récursifs, dans la gure 6.3. La garantie de la terminaison de l’évaluation de fixi
(f : T := t) est
786.2 Ranement lié à l’induction
× STRICT ARG DEAD NO
NO NO NO NO NO
DEAD STRICT ARG DEAD
ARG ARG ARG
STRICT STRICT
Figure 6.2 – Fusion de la valeur de sous termes de deux branches
le jugement ∆ ;{f := NO, ∅} #
i
f
ht | ∅i.
La correction de cette condition de garde a été démontrée par Eduardo Gimenez [23] grâce
à un algorithme qui, pour tout point xe dénissable dans ce système, dénit un inductif dont
le principe de récurrence simule le point xe.
Retour sur les branches impossibles d’une analyse de cas
Nous sommes à présent en pleine mesure de comprendre la section 4.6. Si v est l’argument
récursif, quelle est la valeur de sous-terme de Vhd v ?
L’astuce est que, grâce aux constructions que nous venons de faire, False_rect a la spéci-
cation de sous-terme DEAD. La branche impossible de nil n’est donc pas un handicap au
fait que la spécication du code suivant soit bien STRICT :
case v predicate diag of
|nil:False_rect True |cons:λ(n : nat) (h : A) (t : vect A n) ⇒ h
end
6.2 Rainement lié à l’induction
Dans le corps t d’un point xe f peut apparaître la dénition d’un autre point xe g. On
parle alors de points xes imbriqués.
La garde des point xes imbriqués n’est pas contrôlée simultanément. D’abord, t est typé.
Comme la dénition de g est dans t, le fait que g est gardé est contrôlé durant cette phase.
Ensuite, on vérie la terminaison de f et seulement de f.
Par contre, durant la vérication de f, g apparaît bel et bien. Il faut alors attribuer une
valeur de sous-terme à g. Il faut de même attribuer une valeur de sous-terme à f. La prudence
dicte que la spécication de sous-terme de f et g soit NO. De même, ce n’est pas parce que le ie
argument de g est un STRICT quand f appelle g que le ie argument de g lors d’un appel récursif
dans la dénition de g restera un argument de spécication STRICT. Il est donc indispensable
que tous les arguments de g aient la spécication NO.
Voilà justiée la règle
∆ ;Ψ #
i
f
hT | ∅i ∆ ;
g := NO, Ψ
#
i
f
t | NO1 · · · NOk
∆ ;Ψ #
i
f
D
fixj
(g : T := t) | s1 · · · sk
E
et l’appel initial ∆ ;{f := NO, ∅} #
i
f
ht | ∅i.
796 Etablir qu’un point xe ne produit pas de calcul inni
∆ ;Ψ #
i
f
ht | πi
∆ ;Ψ #
i
f
hx | πi ∆ ;Ψ #
i
f
hI | πi
∆ ;Ψ #
i
f
hS | ∅i ∆ ;{x := s, Ψ} #
i
f
ht | πi
∆ ;Ψ #
i
f
hλ(x : S) ⇒ t | s, πi
∆ ;Ψ #
i
f
hs | ∅i ∆ ;Ψ #
i
f
hC | πi
∆ ;Ψ #
i
f
hS | ∅i ∆ ;{x := NO, Ψ} #
i
f
ht | ∅i
∆ ;Ψ #
i
f
hλ(x : S) ⇒ t | ∅i
∆ ;Ψ #
i
f
hu | ∅i ∆ ;Ψ ⋄ hu | ∅i = s ∆ ;Ψ #
i
f
ht | s, πi
∆ ;Ψ #
i
f
ht u | πi ∆ ;Ψ #
i
f
hc | πi
si = STRICT ∨ si = DEAD
∆ ;Ψ #
i
f
f | s1 · · · sk
∆ ;Ψ #
i
f
hS | ∅i ∆ ;{x := NO, Ψ} #
i
f
hT | ∅i
∆ ;Ψ #
i
f
h∀(x : S), T | ∅i
∆ ;Ψ #
i
f
hT | ∅i ∆ ;
g := NO, Ψ
#
i
f
t | NO1 · · · NOk
∆ ;Ψ #
i
f
D
fixj
(g : T := t) | s1 · · · sk
E
∆ ;Ψ #
i
f
hu | ∅i ∆ ;Ψ #
i
f
hT | ∅i ∆ ;Ψ ⋄ hu | ∅i = c
∆ ;Ψ #
i
f
ht1 | renforce1(c)i · · · ∆ ;Ψ #
i
f
htn | renforcen(c)i
∆ ;Ψ #
i
f
hcase u predicate T of t1 · · · tn end | πi
Figure 6.3 – Contrôle de la décroissance structurelle de f selon son i-ème argument.
806.3 Ranement lié aux coupures entrelacées
Pourtant, deux considérations peuvent améliorer l’expressivité :
1. Même si les arguments de g en général peuvent devenir complètement quelconques au
fur et à mesure des appels récursifs, l’argument récursif a lui l’obligation de décroître.
Ainsi, si g est appelé avec un argument STRICT en position récursive, cet argument ne
peut que rapetisser lors d’appels récursifs et rester donc forcément STRICT.
La pile des arguments peut ne pas être complètement réinitialisée ; l’argument récursif
a le droit de garder sa valeur.
2. Les variables représentant les points xes peuvent avoir la spécication STRICT. Il y
a alors une forme de raisonnement par récurrence : Pour calculer si l’ensemble de la
dénition d’un point xe est sous-terme, supposons que les appels récursifs qui apparaissent
dans cette dénition sont sous-terme.
La règle implémentée est donc
∆ ;Ψ #
i
f
hT | ∅i ∆ ;
g := STRICT, Ψ
#
i
f
D
t | NO1 · · · NOj-1, sj
, NO1 · · · NOk-jE
∆ ;Ψ #
i
f
D
fixj
(g : T := t) | s1 · · · sk
E
et l’appel initial ∆ ;{f := STRICT, ∅} #
i
f
ht | ∅i.
Cette optimisation est présente dans les versions précédant la version 8.4 de Coq. La condition
de garde jusque la version 8.3 de Coq est strictement composée des règles présentées
jusqu’ici appliquées à la forme normale du corps du point xe.
Nous abordons maintenant les ranements postérieurs qui constituent la contribution
originale de ce manuscrit.
6.3 Rainement lié aux coupures entrelacées
Le chapitre 4 a montré que les coupures entrelacées étaient essentielles à l’écriture d’analyse
de cas dépendant.
La contre-partie regrettable est que sont perdues en chemin les valeurs de sous-terme
des arguments de l’analyse de cas. Avec les jugements des gures 6.3 et 6.1 fix1 (f : . . . :=
λ(x : nat) ⇒ . . . case . . . predicate . . . of . . . |λ(. . . : . . .) (x’ : nat) ⇒ f (pred x’) . . . end x . . .)
est refusé car x’ n’est pas vu comme ARG.
Une solution de contournement est simple. La pile des arguments construite avant d’atteindre
une analyse de cas est transmise à chacune des branches de cette analyse de cas.
Néanmoins, cette manoeuvre est mal typée. Les branches impossibles peuvent donc ne pas
être en adéquation avec leur pile. Un invariant ne tient plus. La pile en regard d’un produit
ou d’une sorte n’est plus forcément vide.
La règle qui assure la terminaison d’une analyse de cas devient
∆ ;Ψ #
i
f
hu | ∅i ∆ ;Ψ #
i
f
hT | ∅i ∆ ;Ψ ⋄ hu | ∅i = c
∆ ;Ψ #
i
f
ht1 | renforce1(c), πi · · · ∆ ;Ψ #
i
f
htn | renforcen(c), πi
∆ ;Ψ #
i
f
hcase u predicate T of t1 · · · tn end | πi
816 Etablir qu’un point xe ne produit pas de calcul inni
An de gérer la terminaison des branches impossibles (et donc d’un type incompatible
avec la pile qui leur est présentée), nous modions les règles à propos des constructeurs de
type (sorte et produit) pour qu’elles acceptent une pile :
∆ ;Ψ #
i
f
hs | πi
6.4 Rainement lié à la réduction
6.4.1 Garder la forme βιδ normale
Pour partager du code en utilisant par exemple des constantes globales, il arrive d’écrire
des points xes dont le corps contient des coupures. Or, la présence de coupure perturbe
la vérication de la terminaison. Un exemple extrême est de dénir la constante app qui
applique une fonction à son argument. Si f est le point xe que l’on contrôle, app f x n’est
pas gardé car f n’est appliqué directement à aucun argument donc pas à un sous-terme alors
que f x peut être gardé si x est STRICT.
Nous devons donc vérier non pas le corps du point xe mais la forme normale du corps du
point xe. Pour le faire, nous simulons les β, lesι et les ϕ réductions au sein de nos jugements.
Pour réaliser les ι réductions, le plus simple est d’ajouter une spécication de sous-terme
qui signie : être le ie constructeur dont les arguments ont les spécications de sous-terme
s1 · · · sn. Pour cela la règle qui donne la spécication d’un constructeur est modiée pour
devenir
∆ ;Ψ ⋄
D
Cj
| c1 · · · cs
E
= CONSTRj
(c1 · · · cs
)
Parallèlement, la fonction renforce est enrichie d’une règle qui simule la ι-reduction en
rendant leur spécication aux arguments du constructeur et rendant les autres branches code
mort : renforcei
(CONSTRj
(o1 · · · os
)) = o1 · · · os si i = j et DEAD1 · · · DEADs sinon.
Pour réaliser les β-réductions, nous allons retrouver une pile et un environnement de machine
abstraite standard où des termes sont stockés. Les nœuds qui stockent un terme sont
notées WEAK(Ψ,t). Ils seront aussi notés STRONG(Ψ,t) dans certains cas. Cette deuxième
construction est la conséquence d’une optimisation qui va être détaillée à la n de cette section.
Le calcul des valeurs de sous-terme est identique dans les 2 cas. La vérication des appels
récursifs pourrait être réalisée en n’utilisant que WEAK(Ψ,t).
Des nœuds "variables libres dont la spécication de sous-terme est s" restent nécessaires.
Nous les notons ⊤s.
La fonction renforcei
(s) est elle aussi modiée suite au changement de type des éléments
de la pile. Si elle renvoyait o1 · · · os
, elle renvoie maintenant ⊤o1 · · · ⊤os
.
Puisque l’environnement stocke parfois des termes et non des valeurs de sous-terme directement,
la fonction ∆ ⇓ hs | πi = o présentée gure 6.4 permet de recalculer cette spécication
de sous-terme.
La description exhaustive de la machine qui normalise un terme et en calcule sa spécication
de sous-terme en appel par nom est donnée gure 6.5.
826.4 Ranement lié à la réduction
∆ ⇓ hs | πi = o
∆ ⇓ h⊤s | πi = s
∆ ;Ψ ⋄ ht | πi = o
∆ ⇓ hSTRONG(Ψ,t) | πi = o
∆ ;Ψ ⋄ ht | πi = o
∆ ⇓ hWEAK(Ψ,t) | πi = o
Figure 6.4 – Forcer le calcul d’une valeur de sous terme
∆ ;Ψ ⋄ ht | πi = out
∆ ⇓ hΨ(x) | πi = out
∆ ;Ψ ⋄ hx | πi = out
∆ ;{x := s, Ψ} ⋄ ht | πi = out
∆ ;Ψ ⋄ hλ(x : S) ⇒ t | s, πi = out
∆ ;{x := ⊤NO, Ψ} ⋄ ht | ∅i = out
∆ ;Ψ ⋄ hλ(x : S) ⇒ t | ∅i = out
∆ ;Ψ ⋄ hu | ∅i = c ∆ ;Ψ ⋄ ht | ⊤c, πi = out
∆ ;Ψ ⋄ ht u | πi = out
∆ ;Ψ ⋄ hs | πi = NO ∆ ;Ψ ⋄ h∀(x : S), T | πi = NO
∆ ⇓ hc1 | ∅i = o1 · · · ∆ ⇓ hcs
| ∅i = os
∆ ;Ψ ⋄
D
Cj
| c1 · · · cs
E
= CONSTRj
(o1 · · · os
) ∆ ;Ψ ⋄ hI | πi = NO
∆ ⇓
D
sj
| ∅E
= CONSTRk
(c1 · · · cs
)
∆ ;
(
g := WEAK(Ψ,fixj
(g : T := t)), Ψ
)
⋄
t | s1 · · · sk
= o
∆ ;Ψ ⋄
D
fixj
(g : T := t) | s1 · · · sk
E
= o
∆ ;Ψ ⋄ h∆(c) | πi = o
∆ ;Ψ ⋄ hc | πi = o
∆ ⇓
D
sj
| ∅E
= o’
∆ ;
g := ⊤STRICT, Ψ
⋄
D
t | ⊤NO1
· · · ⊤NOj-1, ⊤o’, ⊤NO1
· · · ⊤NOk-jE
= o
∆ ;Ψ ⋄
D
fixj
(g : T := t) | s1 · · · sk
E
= o
∆ ;Ψ ⋄ hu | ∅i = c ∆ ;Ψ ⋄ ht1 | renforce1(c), πi = o1
· · · ∆ ;Ψ ⋄ htn | renforcen(c), πi = on
Yn
k = 1ok = o
∆ ;Ψ ⋄ hcase u predicate T of t1 · · · tn end | πi = o
Figure 6.5 – Calcul de la spécication de sous terme d’un terme
836 Etablir qu’un point xe ne produit pas de calcul inni
Cette description donne une seconde règle pour le point xe an de réaliser la ϕ réduction
en protant de la même machinerie.
6.4.2 Retrouver la réduction forte
Vérier que la forme normale du corps d’un point xe vérie la condition de garde est
insusant à assurer la normalisation forte. Prenons l’exemple Fixpoint aie (n : nat) :
nat := (λ(x : nat) ⇒ O) (aie O)., la forme normale du corps : λ(n : nat) ⇒ O est bien
évidemment gardée. Son évaluation en appel par valeur, par contre, rentre dans une boucle
innie !
Il faut donc vérier quand même les arguments des applications avant de les mettre dans
la pile. La vérication à faire est un peu plus faible. Les arguments sont systématiquement
évalués dans un contexte vide lors d’un calcul en appel par valeur. De ce fait, des variables
libres en position d’argument récursif ne peuvent jamais déclencher de ϕ-réductions.
La règle qui vérie une application est donc
∆ ;Ψ
i
f
hu | ∅i ∆ ;Ψ #
i
f
ht | WEAK(Ψ,u), πi
∆ ;Ψ #
i
f
ht u | πi
Une nouvelle valeur de sous terme NEUTRAL est ajoutée qui stipule qu’une variable est
une variable libre.
Les fonctions sur les valeurs de sous-terme sont enrichies par
renforcei
(NEUTRAL) = NEUTRAL1 · · · NEUTRALs
et la table du produit des valeurs de sous-terme est complétée par rapport à la gure 6.2
par
× CONSTRi
(c1 · · · cs
) NEUTRAL
NO NO NO
DEAD CONSTRi
(c1 · · · cs
) NEUTRAL
ARG NO* ARG but WEAK
STRICT NO* NEUTRAL
NEUTRAL CONSTRi
(c1 · · · cs
) but WEAK NEUTRAL
CONSTRj
(c’1 · · · c’s
) CONSTRi
(c1 × c’1 · · · cs × c’s
)
Nous appelons garde faible le jugement ∆ ;Ψ
i
f
hu | πi. Il assure que t en position d’argument
est gardé. Il est déni par les règles :
Vérier faiblement les arguments des valeurs (constructeurs, inductifs, variables libres)
n’est pas susant. Les jugements correspondants doivent contrôler "normalement" les corps
des arguments qui ont été mis dans la pile.
6.4.3 estions d’eicacité
Les règles de déduction du jugement de vérication de la garde présenté gure 6.6 ne
sont pas dirigées par la syntaxe puisque les constantes globales et les applications apparaissent
toutes deux dans deux jugements diérents. L’introduction des éléments de pile
84
Ing´enierie des applications Web : r´eduire la complexit´e
sans diminuer le contrˆole
Julien Richard-Foy
To cite this version:
Julien Richard-Foy. Ing´enierie des applications Web : r´eduire la complexit´e sans diminuer le
contrˆole. Software Engineering. Universit´e de Rennes 1, France, 2014. French.
HAL Id: tel-01087372
https://hal.inria.fr/tel-01087372
Submitted on 5 Jan 2015
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of scientific
research documents, whether they are published
or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est
destin´ee au d´epˆot et `a la diffusion de documents
scientifiques de niveau recherche, publi´es ou non,
´emanant des ´etablissements d’enseignement et de
recherche fran¸cais ou ´etrangers, des laboratoires
publics ou priv´es.N
o d’ordre : 00000 ANNÉE 2014
THÈSE / UNIVERSITÉ DE RENNES 1
sous le sceau de l’Université Européenne de Bretagne
pour le grade de
DOCTEUR DE L’UNIVERSITÉ DE RENNES 1
Mention : Informatique
École doctorale Matisse
présentée par
Julien RICHARD-FOY
préparée à l’unité de recherche IRISA – UMR6074
Institut de Recherche en Informatique et Système Aléatoires ISTIC
Ingénierie des applications
Web : ré-
duire la complexité
sans diminuer le
contrôle
Thèse soutenue à Rennes
le 9 décembre 2014
devant le jury composé de :
Lionel SEINTURIER
Professeur à l’université de Lille 1 / Rapporteur
Manuel SERRANO
Directeur de recherche à Sophia Antipolis / Rapporteur
Erwan LOISANT
Consultant à Zengularity / Examinateur
François BODIN
Professeur à l’IRISA / Examinateur
Jean-Marc JÉZÉQUEL
Directeur de l’IRISA / Directeur de thèse
Olivier BARAIS
Maître de conférence à l’IRISA / Co-directeur de thèse■❧ s❡♠❜❧❡ q✉❡ ❧❛ ♣❡r❢❡❝t✐♦♥ s♦✐t ❛tt❡✐♥t❡✱ ♥♦♥ q✉❛♥❞ ✐❧ ♥✬② ❛ ♣❧✉s r✐❡♥ à ❛❥♦✉t❡r ♠❛✐s
q✉❛♥❞ ✐❧ ♥✬② ❛ ♣❧✉s r✐❡♥ à r❡tr❛♥❝❤❡r
par Antoine de Saint-Exupéry
❊❛❝❤ s✐❣♥✐✜❝❛♥t ♣✐❡❝❡ ♦❢ ❢✉♥❝t✐♦♥❛❧✐t② ✐♥ ❛ ♣r♦❣r❛♠ s❤♦✉❧❞ ❜❡ ✐♠♣❧❡♠❡♥t❡❞ ✐♥ ❥✉st ♦♥❡
♣❧❛❝❡ ✐♥ t❤❡ s♦✉r❝❡ ❝♦❞❡✳ ❲❤❡r❡ s✐♠✐❧❛r ❢✉♥❝t✐♦♥s ❛r❡ ❝❛rr✐❡❞ ♦✉t ❜② ❞✐st✐♥❝t ♣✐❡❝❡s ♦❢
❝♦❞❡✱ ✐t ✐s ❣❡♥❡r❛❧❧② ❜❡♥❡✜❝✐❛❧ t♦ ❝♦♠❜✐♥❡ t❤❡♠ ✐♥t♦ ♦♥❡ ❜② ❛❜str❛❝t✐♥❣ ♦✉t t❤❡ ✈❛r②✐♥❣
♣❛rts✳
par Benjamin PierceRemerciements
Je remercie Lionel ❙❡✐♥t✉r✐❡r, Professeur à l’université de Lille 1, et Manuel ❙❡r✲
r❛♥♦, Directeur de recherche à Sophia Antipolis, d’avoir bien voulu accepter la charge
de rapporteur.
Je remercie Erwan ▲♦✐s❛♥t, Consultant à Zengularity, et François ❇♦❞✐♥, Professeur
à l’IRISA, d’avoir bien voulu juger ce travail.
Je remercie enfin Olivier ❇❛r❛✐s et Jean-Marc ❏é③éq✉❡❧, qui ont dirigé ma thèse.Table des matières
❚❛❜❧❡ ❞❡s ♠❛t✐èr❡s ✶
■♥tr♦❞✉❝t✐♦♥ ✺
■ ❈♦♥t❡①t❡ ❡t ét❛t ❞❡ ❧✬❛rt ✾
✶ ❈♦♥t❡①t❡ ❡t ♣♦rté❡ ❞❡ ❧❛ t❤ès❡ ✶✶
1.1 Architecture des applications Web . . . . . . . . . . . . . . . . . . . . . 11
1.2 Partage de code entre les parties client et serveur d’une application Web 13
1.3 Sûreté du typage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.4 Portée de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
✷ ➱t❛t ❞❡ ❧✬❛rt ✶✾
2.1 Styles d’architecture pour les applications Web résilientes . . . . . . . . 19
2.1.1 Architecture des applications Web interactives . . . . . . . . . . 20
2.1.2 Prise en charge du mode déconnecté . . . . . . . . . . . . . . . . 23
2.1.3 Travail coopératif assisté par ordinateur . . . . . . . . . . . . . . 24
2.1.4 ❊✈❡♥t s♦✉r❝✐♥❣ . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.2 Partage de code . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
2.2.1 Langages dédiés implémentés comme une bibliothèque . . . . . 27
2.2.2 Langages lourds . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2.3 Ingénierie dirigée par les modèles . . . . . . . . . . . . . . . . . . 30
2.2.4 Pouvoir d’expression des langages dédiés externes . . . . . . . . 31
2.2.5 Langages dédiés compilés et implémentés comme une bibliothèque
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.2.6 Méta-programmation et évaluation partielle . . . . . . . . . . . . 35
2.2.7 ▲✐❣❤t✇❡✐❣❤t ▼♦❞✉❧❛r ❙t❛❣✐♥❣ et ❥s✲s❝❛❧❛ . . . . . . . . . . . . . . . 35
2.3 Sûreté du typage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
■■ ❈♦♥tr✐❜✉t✐♦♥s ✹✶
✸ P❛rt❛❣❡ ❞❡ ❝♦❞❡ ✹✸
12 Table des matières
3.1 API des sélécteurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.2 Manipulation de valeurs optionnelles . . . . . . . . . . . . . . . . . . . . 46
3.3 Définition de fragments de HTML . . . . . . . . . . . . . . . . . . . . . . 48
3.3.1 Représentation statiquement typée de chaînes de caractères contenant
des expressions JavaScript . . . . . . . . . . . . . . . . . . . 50
3.4 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.4.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.4.2 Expérience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.4.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
✹ ❙ûr❡té ❞✉ t②♣❛❣❡ ✻✶
4.1 Inventaire des fonctions problématiques . . . . . . . . . . . . . . . . . . 61
4.1.1 createElement . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
4.1.2 getElementsByTagName . . . . . . . . . . . . . . . . . . . . . . . 62
4.1.3 addEventListener . . . . . . . . . . . . . . . . . . . . . . . . . . 63
4.1.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.2 Solutions bien typés et conservant le même pouvoir d’expression . . . . 65
4.2.1 Généralisation des solutions existantes . . . . . . . . . . . . . . . 65
4.2.2 Utilisation des types paramétrés . . . . . . . . . . . . . . . . . . 66
4.2.3 Utilisation des types dépendants . . . . . . . . . . . . . . . . . . 67
4.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.3.1 Analyse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.3.2 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
✺ ❯♥ st②❧❡ ❞✬❛r❝❤✐t❡❝t✉r❡ ♣♦✉r ❧❡s ❛♣♣❧✐❝❛t✐♦♥s ❲❡❜ rés✐❧✐❡♥t❡s ✼✸
5.1 Présentation générale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.2 Fonctionnement du système de synchronisation . . . . . . . . . . . . . . 74
5.2.1 Scénario mono-utilisateur . . . . . . . . . . . . . . . . . . . . . . 75
5.2.2 Scénario multi-utilisateur . . . . . . . . . . . . . . . . . . . . . . 76
5.3 Généralisation du composant de synchronisation . . . . . . . . . . . . . 77
5.4 Évolution : fonctionnement complètement hors-ligne . . . . . . . . . . . 77
5.5 Validation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.5.1 Objectifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
5.5.2 Expérience . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.5.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
■■■ ❈♦♥❝❧✉s✐♦♥ ❡t ♣❡rs♣❡❝t✐✈❡s ✽✸
✻ ❈♦♥❝❧✉s✐♦♥ ❡t ♣❡rs♣❡❝t✐✈❡s ✽✺
6.1 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85Table des matières 3
6.2 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
❇✐❜❧✐♦❣r❛♣❤✐❡ ✾✹
❚❛❜❧❡ ❞❡s ✜❣✉r❡s ✾✺4 Table des matièresIntroduction
En automatisant certaines tâches et traitements d’informations, les technologies
de l’information et de la communication (TIC) permettent de réaliser des économies
considérables sur nos activités. Elles sont une importante source d’activités économiques,
parfois qualifiée de « troisième révolution industrielle »[Rif08].
Illustrons ce propos par un exemple concret : le co-voiturage. Ce système vise à
diminuer le nombre de véhicules sur les routes, et, par voie de conséquence, leurs
émissions de gaz à effet de serre, en maximisant leur taux d’occupation par la mutualisation
des voyages de différentes personnes. Le co-voiturage nécessite la collecte
d’informations sur les trajets proposés par les conducteurs et les passagers, leur mise
en relation ainsi qu’un processus de paiement. Les outils numériques, en automatisant
ces tâches et traitements d’informations, facilitent considérablement la pratique
du co-voiturage. En effet, utiliser, par exemple, des petites annonces dans la presse
pour informer les passagers potentiels des trajets proposés par un conducteur, puis
utiliser des courriers postaux pour organiser le voyage entre les personnes intéressées
serait beaucoup plus contraignant (par exemple, chercher un trajet nécessiterait de
parcourir manuellement l’intégralité des annonces, et les délais de mise en relation
entre les personnes leur imposeraient de s’organiser très en avance). L’essor des TIC
a permis au leader français du co-voiturage, BlaBlaCar, de rendre service à plus de 6
millions d’usagers.
Ces outils numériques sont utilisés depuis des machines telles qu’un ordinateur,
un téléphone ou une tablette. Les échanges d’information entre ces machines nécessitent
qu’elles soient reliées en réseau. Dans ce contexte, le Web offre un environnement
propice à la mise en place d’outils numériques : ceux-ci sont hébergés par des
s❡r✈❡✉rs, qui centralisent les informations et coordonnent les utilisateurs. Ces derniers
accèdent aux outils depuis leurs terminaux ❝❧✐❡♥ts, quels qu’ils soient (ordinateur, té-
léphone ou tablette), en utilisant un navigateur Web, sans aucune étape d’installation.
Lorsqu’un utilisateur interagit avec un tel outil, les actions qu’il effectue depuis sa
machine sont éventuellement transmises au serveur. Par exemple, lorsqu’un passager
décrit, depuis son ordinateur personnel, le voyage qu’il souhaite effectuer, cette information
est transmise au serveur hébergeant l’application de co-voiturage qui lui
indique, en retour, quels conducteurs prévoient de faire un voyage similaire.
Toutefois, la réalisation de ces applications Web présente des difficultés pour les
développeurs. La principale difficulté vient de la ❞✐st❛♥❝❡ entre les postes client et
serveur.
56 Introduction
D’une part, la distance physique (ou distance ♠❛tér✐❡❧❧❡) entre les machines nécessite
qu’une connexion réseau soit toujours établie entre elles pour que l’application
fonctionne correctement. Cela pose plusieurs problèmes : comment gérer les effets de
latence lors des échanges d’information entre machines ? Comment assurer une qualité
de service même lorsque la connexion réseau est interrompue ? Comment choisir
quelle part de l’application s’exécute sur le client et quelle part s’exécute sur le
serveur ? Des travaux ont proposé de prendre en charge le mode déconnecté en s’appuyant
sur un système de persistence des données, côté client, capable de se synchroniser
automatiquement lorsque la connexion réseau le permet [KLYY12, MGPW13].
Cependant, cette approche n’offre aucun moyen de régler les conflits dus à des modi-
fications concurrentes des données. La gestion de ces conflits, quant à elle, a fait l’objet
de nombreuses recherches, et un algorithme adapté aux spécificités du Web a été proposé
en 2011 [SLLG11]. Bien que ces technologies apportent isolément des éléments
de solutions, elles ne fournissent pas aux développeurs un cadre architectural pour
que leurs applications soient, par construction, résilientes aux pannes de réseau.
D’autre part, l’environnement d’exécution est différent entre les clients et serveurs,
produisant une distance ❧♦❣✐❝✐❡❧❧❡. En effet, côté client c’est un navigateur Web qui
exécute le code du programme, lequel est généralement écrit en JavaScript. De l’autre
côté, c’est un serveur Web, éventuellement implémenté avec un autre langage que JavaScript,
qui traite les requêtes des clients. Certains aspects d’une application Web
peuvent être communs aux parties client et serveur, par exemple la construction de
morceaux de pages Web, la validation des données saisies dans un formulaire ou certains
calculs métier. En effet, construire les pages Web depuis le serveur facilite le
référencement de leur contenu par les moteurs de recherche, mais les construire depuis
le client produit une meilleure expérience utilisateur. De même, effectuer la validation
des données des formulaires depuis le client offre une meilleure expérience
utilisateur mais cette validation doit être effectuée de nouveau sur le serveur pour
des raisons de sécurité. Cependant les langages de programmation et, surtout, les interfaces
de programmation (API) étant différentes entre les deux parties, cela entrave
les possibilités de réutilisation de code entre elles. Par conséquent, les développeurs
dupliquent des concepts entre les parties client et serveur, bien que cela soit plus coû-
teux à maintenir. Certaines technologies permettent le partage de code entre clients
et serveurs [JW07, Can08], mais ce code partagé n’est pas capable de tirer parti des
spécificités des environnements client et serveur, il nécessite une couche d’adaptation
coûteuse en performance. En intégrant directement dans le langage les aspects
communs aux parties client et serveur [RT10], le compilateur peut produire du code
exécutable tirant parti des spécifités des plateformes cibles, mais cette approche demande
un effort d’implémentation beaucoup plus important.
Pour faciliter le processus d’ingénierie des applications Web, un challenge consiste
à raccourcir cette distance, tant matérielle que logicielle. Cela signifie offrir un modèle
de développement permettant aux développeurs de ne pas avoir à gérer ces difficultés
sans pour autant masquer l’aspect distribué des architectures Web ni les spécificités
de chaque environnement d’exécution. En effet, masquer complètement l’aspect
distribué d’un système diminuerait la capacité à bénéficier des avantages de cette ar-Introduction 7
chitecture [GF99] (e.g. ubiquité des données). De même, masquer les spécificités des
environnements client et serveur diminuerait les performances d’exécution [RFBJ13a].
Les travaux de cette thèse cherchent à raccourcir cette distance entre les parties
client et serveur des applications Web, tout en préservant la capacité à tirer parti de
cette distance, c’est-à-dire en donnant autant de contrôle aux développeurs.
Le premier axe de travail est la réduction de la distance matérielle : comment
concevoir une application Web de telle sorte qu’elle fonctionne aussi bien, quelle que
soit la latence due à la distance entre les machines reliées en réseau, voire quand la
connexion est rompue ? Nous répondons à cette question en proposant un modèle
d’architecture découpant le code de l’application de façon à isoler la préoccupation de
communication client-serveur et la logique métier. Grâce à ce modèle d’architecture
nous avons été capables de capitaliser la logique de synchronisation entre clients et
serveurs sous forme d’une bibliothèque réutilisable.
Le deuxième axe de travail complète le premier. En effet, notre modèle d’architecture
conduit à partager certains concepts côtés client et serveur. En particulier, les
types de données décrivant les actions du système existent des deux côtés. Le besoin
de partager des concepts entre clients et serveurs n’est, cependant, pas caractéristique
de notre modèle d’architecture, et l’on observe plusieurs initiatives visant à faciliter la
réutilisation de code entre clients et serveurs. Notre solution réutilise la bibliothèque
js-scala, qui fournit un mécanisme d’évaluation retardée permettant à un même programme
d’être évalué dans un navigateur Web ou dans l’environnement d’exécution
du serveur (une JVM) [KARO12]. Notre contribution consiste en un ensemble de bibliothèques
bâties sur js-scala, fournissant des API de haut niveau pour traiter certains
aspects des applications Web, et produisant du code tirant parti des spécificités des
environnements client et serveur. En particulier, ❉♦♠❖♣s pour la manipulation du
DOM d’une page Web et ❢♦r❡st pour la définition de fragments de pages Web. En pratique,
nous avons observé que la taille du code écrit avec nos outils est du même ordre
de grandeur que celle d’un code utilisant des bibliothèques haut-niveau existantes et
35% à 50% plus petite que celle d’un code bas-niveau, mais que les performances
d’exécution du programme obtenu sont du même ordre de grandeur que celles d’un
code bas-niveau et 39% à 972% meilleures qu’un code haut-niveau.
Nos travaux sont basés sur le langage Scala, qui est statiquement typé. Bien que
le typage dynamique apporte aussi des avantages, des travaux ont rapporté que le typage
statique peut jouer un rôle important pour faciliter la gestion de la complexité
d’un programme [KHR+12, MHR+
]. Cependant, l’utilisation d’un langage statiquement
typé pour écrire du code s’exécutant sur les navigateurs Web a soulevé un nouveau
problème : ce code fait appel aux API du navigateur, dont les fonctions sont destinées
à être utilisées depuis le langage dynamiquement typé JavaScript, et auxquelles il
peut être difficile de faire correspondre une signature typée sans perte d’information.
En effet, certaines fonctions fondamentales de l’API du navigateur exposent des types
de données trop généraux, contraignant le développeur à écrire des conversions descendantes
de type (❞♦✇♥❝❛st✐♥❣), contournant ainsi le système de vérification de types,
donc le conduisant éventuellement à écrire du code incorrect. En nous appuyant sur
les mécanismes de paramètres de type ou de types membres des langages de pro-8 Introduction
grammation, notre troisième contribution est une façon d’exposer des signatures de
type pour ces fonctions, de telle sorte qu’elles fournissent suffisamment d’information
pour éviter aux développeurs de réaliser des conversions de types, tout en conservant
le même pouvoir d’expression. Comparée aux autres approches utilisées pour exposer
l’API du navigateur dans un langage statiquement typé, notre approche permet de
réduire le nombre de fonctions tout en préservant le même pouvoir d’expression.
Ainsi, nos trois contributions permettent de diminuer la complexité du développement
d’applications Web tout en donnant autant de contrôle aux développeurs.Première partie
Contexte et état de l’art
9Chapitre 1
Contexte et portée de la thèse
Ce chapitre détaille les problèmes d’ingénierie des applications Web dus aux distances
matérielle et logicielle entre les postes client et serveur.
Nous présentons d’abord les enjeux architecturaux découlant de la distance maté-
rielle entre clients et serveurs, puis les obstacles au partage de code entre les environnements
client et serveur à cause de leur distance logicielle. Ensuite, nous soulignons
les difficultés à exposer l’interface de programmation des navigateurs Web dans un
langage de programmation statiquement typé. Enfin, nous terminons ce chapitre en
exposant les questions de recherche adressées par nos travaux.
1.1 Architecture des applications Web
L’architecture d’un système peut supprimer certains problèmes techniques ou isoler
certaines préoccupations, rendant le système moins complexe, donc plus facile à
comprendre et faire évoluer. Dans le cas des applications Web, nous distinguons deux
niveaux d’architecture : matériel et logiciel.
L’architecture matérielle correspond à la disposition matérielle des machines reliées
entre elles. Dans le cas des applications Web, il s’agit d’une architecture centralisée
: plusieurs clients se connecte à un même serveur pour accéder à ses services.
L’architecture logicielle correspond à l’organisation du code d’une application donnée,
elle décrit la façon dont les différentes parties du code s’assemblent et leur responsabilités
respectives.
L’architecture matérielle du Web a pour avantage de permettre un accès ubiquitaire
aux données : celles-ci étant stockées sur un serveur distant, l’utilisateur peut
les consulter depuis plusieurs postes clients (par exemple depuis son ordinateur de
bureau et son téléphone). En outre, si plusieurs utilisateurs accèdent à un même document,
ils peuvent collaborer bien plus facilement que s’ils devaient s’envoyer, à tour
de rôle, une copie modifiée d’un même document. Enfin, un dernier avantage est que
le stockage des données est mutualisé : les postes clients n’ont pas besoin de disposer
d’une grande quantité de mémoire pour utiliser une application.
Toutefois, les architectures Web ont également certains désavantages. Par exemple,
1112 Contexte et portée de la thèse
les utilisateurs peuvent percevoir de la latence due aux échanges d’information entre
les postes clients et serveurs. De plus, la nature centralisée des architectures Web peut
poser des problèmes de gestion de montée en charge pour les serveurs, si le trafic
est irrégulier et intense. Enfin, une application Web ne peut être utilisée que si une
connexion réseau est établie entre les postes client et serveur, or certains appareils (par
exemple les téléphones mobiles) ne disposent que d’une connexion intermittente.
L’objectif de cette thèse est de proposer des moyens logiciels pour construire des
applications Web bénéficiant des avantages présentés précédemment sans souffrir des
inconvénients dus à la distance matérielle entre clients et serveurs.
En particulier, un aspect qui nous préoccupe est la rés✐❧✐❡♥❝❡ aux aléas du réseau :
comment faire pour que la qualité de l’expérience utilisateur soit le moins possible
affectée par une coupure de la connexion réseau ? Une telle coupure rend impossibles
les échanges d’information entre le client et le serveur. Par conséquent, la préservation
de l’expérience utilisateur n’est possible que si le client a déjà téléchargé suffisamment
d’information pour pourvoir les fonctionnalités utilisées.
Illustrons cela par un cas pratique. Imaginons une application permettant de gérer
une liste de tâches à effectuer : les utilisateurs peuvent ajouter des tâches et indiquer
quand elles sont réalisées. Le fonctionnement traditionnel des applications Web est
le suivant : lorsqu’un utilisateur crée une nouvelle tâche ou indique qu’une tâche est
réalisée, cette demande est transmise au serveur, celui-ci met à jour l’état du système
en lui ajoutant la tâche créée, puis il envoie au client les informations lui permettant
de mettre à jour l’interface utilisateur de façon à montrer à l’utilisateur qu’une tâche a
été ajoutée. Maintenir les fonctionnalités de cette application lorsque le client est dé-
connecté du serveur nécessite de faire évoluer et afficher l’état du système localement,
sur le poste client, sans solliciter le serveur.
Cependant, le fait de permettre à l’utilisateur d’utiliser le système en étant déconnecté
induit un nouveau problème : l’état du système sur son poste client diverge de
l’état du système sur le serveur, il devient alors nécessaire de synchroniser l’état du
système du client vers le serveur, lorsque la connexion est de nouveau établie. Dans le
cas d’un système permettant le travail collaboratif, la synchronisation doit prendre en
compte le fait que deux utilisateurs peuvent effectuer des modifications concurrentes
et parfois conflictuelles sur une même ressource.
Reprenons notre exemple d’application de gestion de tâches. Lorsque la connexion
est de nouveau établie, le client doit transmettre au serveur le nouvel état du système,
tel qu’il a évolué suite à son utilisation. Cependant, si deux utilisateurs, Alice et Bob,
utilisent le système en étant déconnecté, ils partent du même état et le font chacun
évoluer différemment. Par exemple, Alice peut créer une nouvelle tâche, et Bob indiquer
qu’une autre tâche a été réalisée. Quand ils se reconnectent, le processus de
synchronisation doit faire converger les trois états (celui du serveur et ceux des clients
d’Alice et Bob). En outre, si, en mode déconnecté, Alice supprime une tâche et Bob
indique que cette même tâche a été réalisée, puis qu’Alice se reconnecte et se synchronise
avec le serveur avant Bob, quand Bob se synchronise avec le serveur, celui-ci doit
gérer le fait que la tâche que Bob a indiqué être réalisée a entretemps été supprimée
par Alice.Partage de code entre les parties client et serveur d’une application Web 13
Plusieurs approches sont possibles dans ce cas. La plus simple pour les développeurs
est aussi la moins satisfaisante pour les utilisateurs, elle consiste à ne rien faire
de particulier sur le serveur en cas de modifications conflictuelles. Dans notre cas, cela
peut se traduire par la levée d’une erreur lors de la synchronisation de Bob, car il demande
au serveur de modifier une tâche qui n’existe pas. Cette approche conduit, dans
le meilleur des cas, à l’affichage d’erreurs chez les clients, mais elle peut également ne
pas détecter les conflits et faire converger le système vers un état qui ne reflète pas l’intention
initiale des utilisateurs. Par exemple, si, en mode déconnecté, Alice demande
de supprimer toutes les tâches réalisées pendant que Bob indique qu’une nouvelle
tâche a été réalisée. Si Bob se synchronise avant Alice, la synchronisation de cette dernière
peut conduire à ne pas supprimer la tâche nouvellement indiquée comme étant
réalisée, alors qu’Alice avait initialement l’intention de supprimer toutes les tâches
réalisées.
Nous ne souhaitons par remettre en cause l’architecture matérielle des applications
Web, car elle fournit de nombreux avantages. Notre objectif est de trouver une
solution au niveau logiciel. Un style d’architecture pour construire des applications
Web résilientes est un style d’architecture qui isole la préoccupation de résilience ou
réduit le travail à effectuer par les développeurs pour parvenir à construire des applications
résilientes.
Une conséquence du fait que les côtés client et serveur soient tous les deux amenés
à exécuter les traitements métiers (côté client, pour obtenir la propriété de résilience,
côté serveur pour maintenir l’état de référence du système) est que la logique métier
risque de se trouver dupliquée dans le code des programmes client et serveur. Cette
duplication n’est pas souhaitable par l’ingénieur logiciel qui doit alors maintenir deux
bases de code cohérentes entre elles. Un moyen d’éviter la duplication consiste à partager
le même code. Cette idée est détaillée dans la section suivante.
1.2 Partage de code entre les parties client et serveur d’une
application Web
En fait, plusieurs aspects d’une application Web gagnent à être partagés entre
clients et serveurs. Par exemple, vérifier, côté client, que les données saisies dans un
formulaire sont valides contribue à améliorer l’expérience utilisateur car celui-ci n’a
pas besoin d’attendre de soumettre l’intégralité d’un formulaire pour voir apparaître
les erreurs. Cependant, ces règles de validation doivent également être appliquées
côté serveur, au cas où un utilisateur mal intentionné contournerait la validation côté
client. De même, la construction des pages HTML a intérêt à être réalisée côté serveur,
pour obtenir un meilleur référencement du contenu par les moteurs de recherche,
mais elle a aussi intérêt à être réalisée côté client, là encore, pour améliorer l’expé-
rience utilisateur, en n’actualisant qu’une partie du document plutôt qu’en rechargeant
la page entière. En outre, il est intéressant de gérer la navigation (la relation
entre une URL et le contenu de la page correspondante) côté serveur, toujours pour
des raisons de référencement par les moteurs de recherche, mais également côté client,14 Contexte et portée de la thèse
encore pour des raisons d’exérience utilisateur. Enfin, certains calculs effectués sur le
domaine métier d’un système peuvent également être exécutés côtés client et serveur.
Tous ces exemples illustrent un besoin général, dans les applications Web, d’être
capable de partager des concepts entre clients et serveurs. Cependant, ce besoin est
difficile à satisfaire car les environnements d’exécution des programmes client et serveur
ne sont pas les mêmes. Premièrement, les langages de programmation peuvent
être différents : côté client le langage supporté par tous les navigateurs est JavaScript,
tandis que côté serveur le choix du langage peut être déterminé par des raisons techniques
(inter-opérabilité avec l’existant, compétences des collaborateurs, etc.). Mais
surtout, le contexte d’exécution n’est pas le même. Côté client, le programme s’exé-
cute dans un navigateur et est associé à un contexte local au client (document HTML,
stockage local, etc.). Côté serveur, le programme s’exécute derrière un serveur HTTP
et est associé à l’état global du système.
Illustrons ces différences par un exemple concret : la construction de fragments
HTML. Côté client, celle-ci aboutit à la construction d’un fragment de DOM, c’est-à-
dire un arbre d’éléments HTML sur lequel il est possible d’effectuer des manipulations
(e.g. ajout, suppression, déplacement de nœuds) ou de réagir à des événements produits
par l’utilisateur sur certains nœuds (e.g. clic de souris). Côté serveur, elle aboutit
à un un texte représentant la structure des éléments HTML. Ces différences sont illustrés
figure 1.1. Le listing 1.1 donne le code JavaScript qui permet de construire cet
arbre, côté client, et le listing 1.2 donne le code Scala qui permet de construire le fragment
de HTML, côté serveur. Ces deux exemples illustrent le fait que construire un
même fragment de HTML, côté client ou côté serveur, ne se fait pas de la même façon.
1.3 Sûreté du typage
Nous avons réalisé nos travaux en nous appuyant sur le langage Scala, qui a la particularité
d’être statiquement typé. Bien que le typage dynamique ait également ses
avantages, nous observons que l’utilisation d’un langage à typage statique pour écrire
la partie client d’une application Web n’est pas marginale : GWT [JW07], Dart [WL12],
TypeScript [Fen12] 1
, Kotlin [Kot], Opa [RT10], SharpKit [Sha], HaXe [Can08], Ocsigen
[Bal06], Elm [Cza12], Idris [Bra13] ou PureScript [Pur] sont autant d’exemples de
langages à typage statique utilisés pour écrire la partie client d’applications Web.
La partie client d’une application Web a pour rôle de réagir aux actions de l’utilisateur
et de mettre à jour le document affiché. Cela s’effectue en utilisant des fonctions
fournies par l’interface de programmation (API) du navigateur Web.
Or, cette API a été conçue pour être utilisée depuis le langage JavaScript, qui est
dynamiquement typé, et il est parfois difficile de définir une signature de type correcte
pour certaines fonctions.
1. Soulignons toutefois que, dans le cas de Dart et TypeScript, le système de types n’est pas aussi
contraignant que les systèmes de types statiques habituels. En effet, les erreurs de typage produisent
seulement des avertissements plutôt que des erreurs de compilation. Ce comportement est voulu et a
vocation à faciliter une migration d’une base de code non typée vers du code typé [BAT14, EMSS].Sûreté du typage 15
Figure 1.1 – Un formulaire tel qu’il est perçu par l’utilisateur (en haut), est représenté
par un arbre d’éléments HTML côté client, et par un texte côté serveur.
var ui = function (emailValue) {
var email = document.createElement(’input’);
email.name = ’email’;
email.placeholder = ’Email’;
email.value = emailValue;
var pwd = document.createElement(’input’);
pwd.name = ’pwd’;
pwd.placeholder = ’Password ’;
var button = document.createElement(’button ’);
button.appendChild(document.createTextNode(’Sign in’));
var form = document.createElement(’form’);
form.action = ’/authenticate ’;
form.method = ’POST’;
form.appendChild(email);
form.appendChild(pwd);
form.appendChild(button );
return form
}
Listing 1.1 – Définition du fragment de HTML représentant le formulaire montré dans
la figure 1.1, côté client, en JavaScript : un arbre est construit progressivement, par
ajout successif de nœuds.16 Contexte et portée de la thèse
def ui(email: String ): Html =
html"""
"""
Listing 1.2 – Définition du fragment de HTML représentant le formulaire montré dans
la figure 1.1, côté serveur, en Scala : une chaîne de caractères utilise une représentation
textuelle du fragment de HTML. Le préfixe html permet une interpolation sûre de la
valeur email
var img = createElement("img");
img.src = "/icon.png";
var input = createElement("input");
input.value = "foo";
Listing 1.3 – Utilisation de la fonction createElement en JavaScript
Par exemple, la fonction createElement a la signature de type suivante, d’après sa
spécification standard [HTM] :
Element createElement(String name);
Notons que le type de retour indiqué est Element. Néanmoins, l’appel createElement(’input’)
retourne plus précisément un nœud de type InputElement représentant un champ
de formulaire. De même, l’appel createElement(’img’) retourne plus précisément un
nœud de type ImageElement représentant une image.
Ces deux types, InputElement et ImageElement, n’ont pas les mêmes propriétés.
Par exemple, le type InputElement possède une propriété value contenant la valeur
du champ du formulaire. De même, le type ImageElement possède une propriété src
contenant l’URL de l’image. Ce détail n’a aucune importance pour les développeurs
utilisant le langage JavaScript mais est problématique dans un langage statiquement
typé.
En effet, considérons le listing 1.3, écrit en JavaScript et créant une image et un
champ de formulaire. Dans cet exemple, nous accédons à la propriété src de l’image
et à la propriété value du champ de formulaire.
Dans un monde statiquement typé, ce listing, bien que correct, produirait une erreur
de typage car les propriétés src et value ne sont pas définies pour le type général
Element. Ainsi, la signature de type standard de la fonction createElement ne convient
pas, telle quelle, aux langages statiquement typés.
Notons enfin, que le langage JavaScript permet d’écrire le listing 1.3 mais il permet
également d’écrire des programmes incorrects. Par exemple, il est possible, en
JavaScript, d’écrire un programme accédant à une propriété src d’un objet de typePortée de la thèse 17
InputElement bien que ce type ne possède pas de telle propriété.
Idéalement, on aimerait avoir une signature de type telle que le listing suivant, en
Scala, compile sans problème, sauf la dernière ligne :
val img = createElement("img")
img.src = "/icon.png" // Ok
img.value = "foo" // Erreur: propriete ’value’ non definie
De même, le listing suivant doit compiler, sauf la dernière ligne :
val input = createElement("input")
input.value = "foo" // Ok
input.src = "/icon.png" // Erreur: propriete ’src’ non definie
Autrement dit, après avoir créé un élément, il doit être possible d’utiliser toutes ses
propriétés. Par contre, l’utilisation d’une propriété non définie pour ce type d’élément
doit provoquer une erreur de typage. Dès lors, quelle signature de type définir pour
la fonction createElement ? Plus généralement, y a-t-il d’autres fonctions qui souffrent
d’un problème similaire, et comment le résoudre ?
1.4 Portée de la thèse
Les sections précédentes ont soulevé plusieurs problèmes. Nos travaux s’intéressent
en particulier aux questions de recherche suivantes :
RQ1 Quel style d’architecture logicielle adopter pour isoler les problèmes dus à
la distance matérielle entre clients et serveurs (latence, indisponibilité de l’application
en mode déconnecté) ?
RQ2 Comment partager du code entre les parties client et serveur malgré leurs
différences ?
RQ3 Comment interfacer le monde dynamiquement typé des navigateurs avec un
langage statiquement typé en préservant la sûreté du typage et sans perdre de
pouvoir d’expression ?
Le reste de ce document est organisé comme suit. Le prochain chapitre détaille
l’état de l’art relatif aux trois questions de recherches formulées. Le chapitre 3 montre
comment nous avons défini des abstractions qui, bien qu’elles soient utilisables côtés
client et serveur, ne souffrent pas de problèmes de performance (RQ2). Dans le chapitre
4 nous montrons qu’il est possible de définir, pour certaines fonctions de l’API
du navigateur, des signatures de type garantissant une sûreté du typage et préservant
le même pouvoir d’expression que l’API native (RQ3). Le chapitre 5 présente un sytle
d’architecture ainsi que l’implémentation d’un composant logiciel réutilisable pour
construire des applications Web résilientes (RQ1). Enfin, le chapitre 6 présente une
synthèse des contributions ainsi que des perspectives de recherche.18 Contexte et portée de la thèseChapitre 2
État de l’art
Ce chapitre présente les réponses que des travaux antérieurs apportent aux questions
de recherche traitées par cette thèse.
La préoccupation de résilience étant une préoccupation technique transverse, la
section 2.1 s’intéresse aux styles d’architecture logicielle permettant d’isoler cette pré-
occupation.
La section 2.2 compare les méthodes existantes pour partager du code entre les
parties client et serveur.
Enfin, la section 2.3 recense les travaux visant à interfacer les langages statiquement
typés et dynamiquement typés.
2.1 Styles d’architecture pour les applications Web résilientes
L’ingénierie des applications Web a fait l’objet de nombreuses recherches. En 2002,
Roy T. Fielding ❡t✳ ❛❧✳ ont proposé le style d’architecture ❘❊♣r❡s❡♥t❛t✐♦♥❛❧ ❙t❛t❡ ❚r❛♥s✲
❢❡r (REST) [FT02]. Ce style d’architecture définit un ensemble de contraintes sur le
fonctionnement et l’interaction des services Web, de façon à minimiser les problèmes
de latence tout en minimisant le couplage des services Web. Cependant, REST se limite
au côté serveur des applications Web : il ne donne aucune préconisation sur la
façon d’intégrer les parties client et serveur des applications Web.
En effet, les applications Web ont, entretemps, évolué. Notamment, la partie client
est devenue beaucoup plus riche : elle ne se contente plus simplement d’afficher le
contenu des pages et de naviguer entre les liens hypertextes, mais elle permet des interactions
riches (déroulement de menus, etc.) et, surtout, une navigation asynchrone
(quand l’utilisateur clique sur un lien hypertexte, le client ne remplace pas la page
actuelle par la nouvelle, mais met à jour une partie du document actuel). Cette évolution
se traduit par une plus grande quantité de code et de nouvelles responsabilités
pour la partie client d’une application Web [Mar09].
Ainsi, une application Web comporte désormais deux applications : une application
côté serveur, chargée de traiter les actions des clients et d’exposer les données du
système, et une application côté client, chargée de répondre aux interactions de l’uti-
1920 État de l’art
Figure 2.1 – Les modèles MVC (à gauche) et PAC (à droite)
lisateur, éventuellement en transmettant ses actions à l’application côté serveur, et
en actualisant l’affichage en fonction de l’évolution de l’état du système. L’utilisateur
final utilise l’application côté client, qui elle-même utilise l’application côté serveur.
2.1.1 Architecture des applications Web interactives
Cette section présente les styles d’architectures utilisés dans les applications interactives
et leurs évolutions conduisant aux applications Web interactives.
2.1.1.1 Architecture des applications interactives
Les deux principaux styles d’architcture pour les applications interactives sont
▼♦❞❡❧✲❱✐❡✇✲❈♦♥tr♦❧❧❡r [KP88] et Pr❡s❡♥t❛t✐♦♥✲❆❜str❛❝t✐♦♥✲❈♦♥tr♦❧ [Cou87]. Dans les
deux cas, les préoccupations identifiées sont la logique métier (▼♦❞❡❧ ou ❆❜str❛❝t✐♦♥),
l’interface utilisateur (❱✐❡✇ ou Pr❡s❡♥t❛t✐♦♥) et le lien entre les deux (❈♦♥tr♦❧❧❡r ou
❈♦♥tr♦❧).
La principale différence entre les deux modèle, illustrée figure 2.1, est que, dans le
cas du modèle PAC, la responsabilité de l’❆❜str❛❝t✐♦♥ s’arrête à la logique métier : elle
ne communique pas avec l’interface utilisateur, contrairement au modèle MVC, et elle
ne fait même pas l’hypothèse qu’une interface utilisateur existe. Notons également
que la littérature mentionne aussi l’architecture ▼♦❞❡❧✲❱✐❡✇✲Pr❡s❡♥t❡r (MVP), qui est
en réalité complètement équivalente au modèle PAC.
Ainsi, le modèle PAC isole mieux les différents aspects des applications interactives
: la partie ❆❜str❛❝t✐♦♥ contient la logique métier et est réutilisable dans une application
non interactive. La partie Pr❡s❡♥t❛t✐♦♥ contient tout ce qui est spécifique à
la technologie d’affichage choisie. Elle n’est pas liée à une application en particulier.
Enfin, la partie ❈♦♥tr♦❧ rend l’❆❜str❛❝t✐♦♥ interactive en l’affichant à l’aide d’une Pr❡✲
s❡♥t❛t✐♦♥ et en interprétant les actions de l’utilisateur en termes d’actions métier.
2.1.1.2 Architecture des applications collaboratives interactives
Les modèles PAC et MVC sont adaptés aux applications mono-utilisateur. Dans
le cas où plusieurs utilisateurs manipulent en même temps une même ressource, de
nouveaux problèmes se posent, notamment de gestion de la cohérence de l’information
entre les différents utilisateurs.
Duval ❡t✳ ❛❧✳ ont montré comment adapter le modèle PAC aux applications collaboratives.
Ils proposent de dupliquer des instances de modèle PAC sur chaque clientStyles d’architecture pour les applications Web résilientes 21
Figure 2.2 – Le modèle PAC-C3D
et de les faire communiquer entre elles au niveau des composants ❈♦♥tr♦❧. Ces composants
se voient infliger une nouvelle responsabilité : gérer la cohérence des données
entre les différents clients. Cette responsabilité est coordonnée par un serveur, maintenant
l’état de référence du système. La figure 2.2 illustre le modèle PAC-C3D dans le
cas d’un serveur et un client. Le serveur n’a pas de composant de Pr❡s❡♥t❛t✐♦♥ puisque
son rôle se limite à de la synchronisation d’information : il reçoit les modifications effectuées
par un client et les transmet aux autres clients.
Le modèle PAC-C3D a l’avantage d’être simple et bien découpé : chaque composant
n’a que peu de responsabilités. Cependant, il fait l’hypothèse d’une connexion
réseau fiable et ne gère pas les conflits dues à des modifications concurrentes par des
utilisateurs distants.
2.1.1.3 Architecture des applications Web interactives
En 2007, Morales-Chaparro ❡t✳❛❧✳ ont proposé un ensemble de modèles d’architecture
pour les applications Web. Ces modèles sont tous des variations du modèle
▼♦❞❡❧✲❱✐❡✇✲❈♦♥tr♦❧❧❡r (MVC), couramment utilisé pour la conception d’applications
interactives. Les variantes proposées par ces auteurs s’adaptent à l’importance de l’application
côté client. Dans une première variante, ils suggèrent d’utiliser MVC côté
serveur seulement. C’est-à-dire que c’est le serveur qui est responsable de la construction
de la page HTML affichée par le serveur (partie ❱✐❡✇), d’interpréter les requêtes
HTTP en termes d’actions métier (partie ❈♦♥tr♦❧❧❡r ) et de mettre à jour l’état du système
en fonction des actions métier (partie ▼♦❞❡❧). Dans cette variante, il n’y a pas
d’application côté client, cela correspond donc au cas des applications Web d’antan.
Une autre variante consiste à utiliser MVC côté client seulement. C’est-à-dire que c’est
le client qui est responsable de la construction de la page HTML qu’il affiche (partie
❱✐❡✇), d’interpréter les interactions de l’utilisateur (e.g. clics sur des boutons) en
termes d’actions métier (partie ❈♦♥tr♦❧❧❡r ), et de mettre à jour l’état du système en
fonction des actions métier (partie ▼♦❞❡❧). Dans leur modèle, cette dernière partie
est également responsable de transmettre l’évolution de l’état du système à un ▼♦❞❡❧
analogue, côté serveur. Dans cette variante, l’application est plus maigre sur le serveur
que sur le client. Néanmoins, la partie ▼♦❞❡❧ existe des deux côtés, client et serveur.
Enfin, les auteurs ont également proposé des modèles hybrides, où les trois parties22 État de l’art
a)
b)
c)
Figure 2.3 – Trois variantes d’architectures dérivées du modèle Model-View-Controller.
a) MVC côté serveur ; b) MVC côté client ; et c) MVC hybride côtés client et serveur.
(▼♦❞❡❧, ❱✐❡✇ et ❈♦♥tr♦❧❧❡r ) existent côtés client ❡t serveur. La figure 2.3 illustre ces
variantes. Notons que dans tous les cas les applications client et serveur sont reliées
entre elles par leur composant ▼♦❞❡❧, contrairement au modèle PAC-C3D présenté
dans la section précédente, où les applications client et serveur sont reliées par leur
composant ❈♦♥tr♦❧.
Ces modèles d’architecture permettent de découper le code d’une application complète
en parties correspondant à différents aspects (l’interface utilisateur, la logique
métier et le lien entre les deux). Ce découpage a des avantages pour le développeur,
qui peut plus facilement raisonner sur chaque aspect indépendamment des autres,
mais il a également des avantages structurels : par exemple, la logique métier peut
être utilisée indépendamment de l’interface utilisateur, elle est donc plus facilement
testable.
Par ailleurs, ces modèles d’architecture ont chacun des caractéristiques techniques
qui les rendent plus ou moins appropriés selon les usages attendus de l’application.
Le premier modèle est le plus simple à mettre en œuvre car il comporte peu de
composants. Il comporte également un aspect technique intéressant : les pages étant
construites sur le serveur, leur contenu est mieux référencé par les moteurs de recherche.
Son inconvénient est qu’une application bâtie sur ce modèle n’offre pas une
expérience utilisateur agréable (navigation synchrone). Le modèle où l’essentiel du
code de l’application est côté client permet d’offrir une meilleur expérience utilisateur,
mais il nécessite de dupliquer la partie ▼♦❞❡❧ côtés client et serveur. Ce modèle,
contrairement au précédent, ne permet pas au contenu des pages d’être bien référencé
par les moteurs de recherche. Les modèles hybrides permettent d’avoir à la fois une
bonne expérience utilisateur et un bon référencement du contenu par les moteurs de
recherche, au prix d’une duplication des parties ▼♦❞❡❧ et ❱✐❡✇ côtés client et serveur.Styles d’architecture pour les applications Web résilientes 23
Ce panel de modèles d’architecture témoigne surtout d’un aspect caractéristique
des applications Web : le code de l’application doit être réparti entre le client et le serveur.
Selon le type d’application on peut choisir de mettre plus de code sur le serveur
que sur le client, ou inversement. Roberto Rodríguez-Echeverría a d’ailleurs identi-
fié que cet aspect est, avec le processus de synchronisation client-serveur, une source
majeure de complexité dans l’ingénierie des applications Web [RE09]. Il a également
souligné que les méthodes d’ingénierie des applications Web devraient prendre en
compte le fait que la connexion réseau peut être intermittente.
À ce jour, personne n’a encore proposé de style d’architecture permettant le travail
en mode déconnecté et automatisant la synchronisation au retour de la connexion. Intégrer
la préoccupation de résilience nécessite de surveiller les échanges d’information
entre clients et serveurs afin de choisir une stratégie de secours au cas où une requête
échouerait. Les modèles d’architecture présentés précédemment font tous l’hypothèse
d’une connexion réseau fiable. Si une interruption survient, l’effet d’une action de
l’utilisateur sur l’état du système ne peut plus être transmis au serveur. Il est alors
nécessaire de détecter le problème, d’en avertir l’utilisateur par une notification et, si
possible, d’essayer d’envoyer à nouveau, un peu plus tard, la requête ayant échoué.
De telles modifications impacteraient tant la partie interface utilisateur que la partie
métier. En particulier, l’ensemble de la couche métier serait affectée car toutes les modifications
des données doivent être transmises au serveur. Nous voyons ainsi que la
préoccupation de résilience est une préoccupation transverse.
2.1.2 Prise en charge du mode déconnecté
Dès 2000, Yun Yang a formulé l’essentiels des besoins auxquels doivent répondre
les applications Web pour permettre le travail collaboratif en mode déconnecté : notamment
le fait que la partie client doit contenir suffisamment d’information pour
pourvoir les fonctionnalités de l’application, et la nécessité de synchroniser l’état du
système avec le serveur au retour de la connexion [Yan00].
Plus récemment, Marco ❡t✳ ❛❧✳ ont proposé un modèle de description de site Web
prenant en charge le mode déconnecté [MGPW13]. Leur modèle permet de définir
comment l’utilisateur peut naviguer à travers les pages d’un site contenant de l’information
et leur système génère un site Web utilisable en mode déconnecté. Cependant
leur modèle se limite aux systèmes dont l’état n’évolue pas, il n’est donc pas approprié
pour représenter une application dont l’état évolue suite aux actions de l’utilisateur.
Kao ❡t✳ ❛❧✳ [KLYY12] ont implémenté une plateforme d’exécution d’applications
Web prenant en charge le mode déconnecté et capable d’adapter le contenu des pages
aux appareils mobiles (✐✳❡✳ téléphones). Leur plateforme fournit des bibliothèques
pour stocker des données sur les postes clients et les synchroniser avec le serveur.
Cependant, leur contribution se limite à une infrastructure logicielle : ils n’indiquent
pas comment concevoir une application bénéficiant de cette infrastructure. Cet effort
de conception reste donc à faire par les développeurs. En outre, leur solution de synchronisation
ne gère pas les conflits.24 État de l’art
2.1.3 Travail coopératif assisté par ordinateur
Indépendamment des recherches sur les architectures des applications Web, dans
le domaine du travail coopératif assisté par ordinateur des travaux se sont intéressés
spécifiquement aux méthodes de synchronisation de l’état d’un système distribué.
Une méthode de synchronisation a pour but de faire converger les multiples répliques
du système qui existent sur chaque client, après qu’elles ont évolué indépendamment
les unes des autres.
2.1.3.1 Synchronisation basée sur les données
Une première approche consiste à observer la façon dont les données évoluent sur
les différentes répliques et à transmettre les changements aux autres répliques.
Ainsi, Brett Cannon ❡t✳ ❛❧✳ ont rendu résilient un système de persistence en le
dotant d’un mécanisme de synchronisation qui observe les modifications et les synchronise
dès que possible avec le serveur [CW10]. L’intégration d’une telle technologie
de persistence avec les modèles d’architectures présentés précédemment devrait permettre
de traiter la préoccupation de résilience de façon transparente et isolée : la
couche métier s’appuierait sur cette technologie de persistence résiliente, les autres
parties du code n’auraient pas besoin d’être modifiées.
Les ❈♦♥✢✐❝t✲❢r❡❡ ❘❡♣❧✐❝❛t❡❞ ❉❛t❛ ❚②♣❡s (CRDT) sont une approche similaire [SPBZ11].
L’idée est de modéliser le domaine du système à l’aide de types de données dont les
opérations sont toutes commutatives, par construction. Ainsi, les effets de deux opé-
rations concurrentes convergent toujours, sans générer de conflit. L’inconvénient de
cette approche c’est que l’utilisation d’un tel type de données est contraignant, pour
les développeurs, pour modéliser le domaine du système.
L’inconvénient des approches basées sur les données est leur mauvaise gestion de
la résolution des conflits. Illustrons cela à l’aide de l’exemple d’application de gestion
de tâches donné en section 1.1.
Prenons une situation où Alice supprime une tâche donnée, et Bob, de façon concurrente,
fait passer l’état de cette même tâche de l’état réalisée à non réalisée. Un système
de synchronisation placé sur le serveur et basé sur les données recevrait les modifications
du système dues aux clients l’une après l’autre. S’il reçoit d’abord la modification
de Bob, puis la suppression d’Alice, il applique les mêmes modifications sur son système,
dans cet ordre, et termine dans un état où la tâche est supprimée. S’il reçoit
d’abord la suppression d’Alice, puis la modification de Bob, il se retrouve dans une
situation où il doit appliquer une modification sur une donnée qui a été supprimée.
Dans ce cas, une solution simple consiste à ignorer la modification, et l’état d’arrivée
est le même que précédemment : la tâche est supprimée.
Prenons maintenant une situation où Alice supprime toutes les tâche réalisées et
Bob fait passer une tâche de l’état réalisée à non réalisée. Si l’algorithme de synchronisation
reçoit d’abord la modification de Bob puis la suppression d’Alice, il modifie
la tâche puis la supprime car elle faisait partie des tâches réalisées dans la réplique
d’Alice. En revanche, s’il reçoit d’abord la suppression d’Alice puis la modificationStyles d’architecture pour les applications Web résilientes 25
de Bob, il se retrouve dans une situation similaire à celle du pragraphe précédent : il
doit appliquer une modification sur une tâche qui a été supprimée. S’il applique la
stratégie décrite au paragraphe précédent, qui consiste à ignorer la modification sur
la tâche supprimée, celle-ci est supprimée. Dans les deux cas il n’est pas certain que
l’état du système corresponde vraiment à ce qu’attendent Alice et Bob. En effet, au
final l’action d’Alice supprime une tâche dans l’état non réalisée alors que son action
initiale consistait justement à supprimer les tâches réalisées.
Le problème vient du fait que généralement il n’est pas possible de déduire l’intention
initiale d’un utilisateur en fonction de l’évolution des données de sa réplique du
système. En effet, différentes actions, correspondant à différentes intentions, peuvent
conduire à des modifications de données similaires. Dans notre exemple, une tâche
peut être supprimée parce qu’un utilisateur veut supprimer cette tâche en particulier,
ou parce qu’elle fait partie des tâches réalisées et que son intention est de supprimer
toutes les tâches réalisées.
2.1.3.2 Synchronisation basée sur les actions
En fait, dès 1992 Ernst Lippe ❡t✳ ❛❧✳ distinguaient l’approche précédente, basée
sur les données, d’une approche basée sur les actions [LV92]. La seconde approche
consiste à comparer les suites d’actions qui ont été effectuées par les différents clients.
Les auteurs notent que cette approche donne plus d’opportunités pour résoudre les
éventuels conflits car elle permet de préserver l’intention de l’utilisateur.
Dans le domaine des systèmes distribués, des algorithmes de convergence basés
sur les actions existent depuis plus de 25 ans [EG89, SE98]. Ceux-ci sont en général
conçus pour des architectures décentralisées et ont un coût important en espace, né-
cessitant généralement des horloges vectorielles (ou quelque chose d’équivalent), ne
permettant pas de passage à l’échelle.
Un algorithme centralisé, Jupiter OT, a été proposé en 1995 par David Nichols [NCDL95].
Cet algorithme tire parti des spécificités des architectures client-serveur pour réduire
sa complexité en espace : il n’est plus nécessaire, pour un client, de connaître les horloges
de tous les autres clients, l’horloge du serveur suffit. Un autre avantage de cet
algorithme est qu’il permet d’exécuter l’application d’opérations concurrentes de fa-
çon optimiste : il n’est pas nécessaire d’attendre une réponse du serveur pour exécuter
une opération sur un client. En effet, celui-ci peut exécuter l’opération directement
sur sa machine, modifiant ainsi sa réplique de l’état du système. Si d’autres clients
effectuent une modification de façon concurrente, l’algorithme crée une nouvelle opé-
ration permettant de compenser les changements de façon à ce que les états de toutes
les répliques convergent. Cependant l’algorithme de résolution de conflits n’est pas dé-
terministe : l’état final du système obtenu côté serveur dépend de l’ordre dans lequel
il reçoit les mises à jour des clients. Autrement dit, les actions concurrentes effectuées
par plusieurs utilisateurs ne conduisent pas toujours à une convergence de l’état du
système entre clients et serveurs. En outre, l’algorithme fait l’hypothèse d’un canal de
communication fiable et ordonné, ce qui n’est pas le cas du protocole HTTP.
Cette limitation a été résolue par Bin Shao ❡t✳ ❛❧✳ avec TIPS, un autre algorithme26 État de l’art
de synchronisation basée sur une architecture centralisée [SLLG11]. Les auteurs introduisent
une notion de relation d’effets rendant déterministe l’évolution de l’état du
système, quel que soit l’ordre dans lequel les opérations sont reçues par le serveur. En
outre, leur algorithme est conçu pour être particulièrement adapté aux architectures
Web : de nouveaux clients peuvent joindre ou quitter la session de travail collaboratif
à n’importe quel moment, les clients peuvent décider indépendamment les uns
des autres quand se synchroniser auprès du serveur et le serveur peut décider quand
traiter les opérations transmises par les clients.
Un point commun à tous les algorithmes de synchronisation optimistes basés sur
les actions est qu’ils s’appuient sur une fonction de transformation des actions, propre
à chaque application. Dans le cas de Jupiter OT cette fonction a la forme suivante :
f(c, s) = (c’, s’)
Son implémentation doit satisfaire la propriété suivante : si c est une commande
issue d’un client et s une commande issue du serveur, alors l’application des commandes
s puis c’ par le serveur et c puis s’ par le client doivent produire le même
effet. C’est cette fonction, spécifique à chaque application, qui permet de compenser
les effets relatifs des commandes appliquées de façon concurrente.
C’est cette fonction de transformation des actions qui permet de propager l’intention
initiale des utilisateurs. Ainsi, dans le cas de notre exemple d’application de
gestion de tâches, l’implémentation de cette fonction peut être différente pour traiter
la suppression d’une tâche en particulier ou la suppression de toutes les tâches
réalisées. Par conséquent, dans les situations données dans la section précédente, le
système conserverait effectivement la suppression d’Alice dans le premier cas mais
pas dans le second, correspondant à une intention de suppression de toutes les tâches
réalisées.
2.1.4 Event sourcing
Enfin, terminons cette section de l’état de l’art en reliant les approches de synchronisation
basées sur les actions et l’❡✈❡♥t s♦✉r❝✐♥❣. L’❡✈❡♥t s♦✉r❝✐♥❣ décrit un style
d’architecture dans lequel l’état d’un système est représenté par une succession d’évé-
nements plutôt qu’à l’aide de types de données [Fow05].
Ainsi, dans notre exemple de logiciel de gestion de tâches, les événements permettant
de représenter le système pourraient être :
Created(id, content, isCompleted) « une tâche a été créée, elle a pour identi-
fiant id, pour contenu content et comme état de complétion isCompleted » ;
Removed(id) « la tâche identifiée par id a été supprimée » ;
Edited(id, content, isCompleted) « la tâche identifiée par id a été modifiée ».
Un système contenant une tâche dont l’état a été modifié une fois pourrait être représenté
par la séquence d’événements suivante : Created(42, "Rédiger une thèse",
false), Edited(42, "Rédiger une thèse", true).Partage de code 27
def ui(email: String ): Html =
form(action := "/authenticate", method := "POST",
input(name := "email", placeholder := "Email", value := email),
input(name := "pwd", placeholder := "Password"),
button("Sign in")
)
Listing 2.1 – Définition de fragments de HTML à l’aide d’un langage dédié interne, en
Scala.
L’❡✈❡♥t s♦✉r❝✐♥❣ est surtout utilisé pour améliorer la montée en charge d’applications
comportant beaucoup d’utilisateurs en consultation mais peu d’utilisateurs
effectuant des modifications [BDM+13].
Notons que les algorithmes de synchronisation basés sur les actions correspondent
à une approche ❡✈❡♥t s♦✉r❝❡❞ : une action est l’équivalent d’un événement. L’algorithme
de synchronisation calcule l’état du système en fonction de l’application des
actions effectuées par les divers utilisateurs.
2.2 Partage de code
Cette section compare les différentes approches permettant de partager du code
entre les parties client et serveur d’une application Web.
2.2.1 Langages dédiés implémentés comme une bibliothèque
Une première approche consiste à utiliser un langage généraliste (p. ex. Scala), et à
le rendre exécutable côté client en implémentant un ❜❛❝❦❡♥❞ du compilateur générant
du JavaScript. Il devient alors possible d’écrire du code partagé entre les côtés client
et serveur. Par exemple, il devient envisageable de définir une abstraction pour représenter
les fragments de HTML. L’utilisation d’une telle bibliothèque, pour définir
un fragment de HTML correspondant à la figure 1.1, pourrait ressembler à ce qui est
donné dans le listing 2.1.
L’ensemble des fonctions de l’API de cette bibliothèque forme un vocabulaire dédié
à la construction de fragments de HTML. Comme le langage hôte sur lequel il s’appuie
(ici, Scala), est utilisable côtés client et serveur, ce langage dédié est également
utilisable côtés client et serveur.
Cette approche a été décrite par Paul Hudak [Hud96]. Son principal intérêt réside
dans son faible coût d’implémentation : une fois que le langage hôte peut être exécuté
côtés client et serveur, l’introduction de nouveaux éléments de langages dédiés à un
aspect particulier ne nécessite que l’implémentation d’une bibliothèque.
GWT est un projet populaire suivant cette approche : il compile du code Java vers
du JavaScript. Ainsi, il est possible d’écrire les parties client et serveur d’une application
Web en Java, et de partager du code commun aux deux parties. HaXe, Kotlin,
SharpKit, Ocsigen et ScalaJs [Doe13] sont d’autres projets similaires.28 État de l’art
Figure 2.4 – Exécution du programme indiqué dans le listing 2.1. Le programme est
compilé vers les environnements client et serveur. Dans chaque environnement, son
exécution produit une représentation abstraite d’un fragment HTML. Celle-ci est ensuite
convertie vers une représentation spécifique à chaque plateforme.
En général, les outils suivant cette approche fournissent un mécanisme permettant
d’interfacer les API du langage hôte (✐✳❡✳ Java, dans dans le cas de GWT) avec
l’environnement du navigateur Web. Un tel mécanisme, appelé ❢♦r❡✐❣♥ ❢✉♥❝t✐♦♥ ✐♥t❡r✲
❢❛❝❡ (FFI), permet d’utiliser les bibliothèques JavaScript existantes ou l’API native du
navigateur directement depuis le langage hôte. Cependant, toutes les API utilisant ce
mécanisme ne sont plus utilisables côté serveur. Par conséquent, il n’est pas possible
de définir une bibliothèque partagée par les côtés client et serveur, pour, par exemple,
construire des fragments de HTML, tout en exploitant directement les API natives des
deux côtés, client et serveur.
Plus généralement, le système de génération de code du compilateur n’a aucun
moyen de produire du code tirant parti des spécificités de chaque plateforme (client
ou serveur) pour une bibliothèque donnée. En effet, le compilateur n’a connaissance
que des concepts du langage hôte, dans lequel sont implémentées les bibliothèques.
En pratique, cela signifie qu’il n’est pas possible de faire en sorte que le listing 2.1
produise le code du listing 1.1 côté client et du listing 1.2 côté serveur. En effet, tout
ce que la fonction form, par exemple, peut retourner, c’est une description abstraite
d’un élément HTML
}
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}$name >\"\"\""
)
}
case Right(children) =>
emitValDef(sym ,
src"html \"\"\" < $name$attrsFormatted >$${$children}$name >\"\"\""
)
}
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.