Modélisation qualitative des agro-écosystèmes et aide à leur gestion par utilisation d'outils de model-checking - Thèse Informatique
Modélisation qualitative des agro-écosystèmes et aide à leur gestion par utilisation d'outils de model-checking - Thèse Informatique
- Revenir à l'accueil
De l’auto-´evaluation aux ´emotions : approche
neuromim´etique et bay´esienne de l’apprentissage de
comportements complexes impliquant des informations
multimodales
Adrien Jauffret
To cite this version:
Adrien Jauffret. De l’auto-´evaluation aux ´emotions : approche neuromim´etique et bay´esienne
de l’apprentissage de comportements complexes impliquant des informations multimodales.
Other. Universit´e Paris Sud - Paris XI, 2014. French. .
HAL Id: tel-01082116
https://tel.archives-ouvertes.fr/tel-01082116
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.Université Paris Sud - Ecole doctorale d’Informatique
THÈSE
présentée pour obtenir le titre de DOCTEUR en Informatique
DE L’AUTO-ÉVALUATION AUX ÉMOTIONS - APPROCHE
NEUROMIMÉTIQUE ET BAYESIENNE DE
L’APPRENTISSAGE DE COMPORTEMENTS COMPLEXES
IMPLIQUANT DES INFORMATIONS MULTIMODALES
par
Adrien Jauffret
LIMSI - CNRS / Université Paris Sud 11 / UPR3251
ETIS - ENSEA / Université de Cergy-Pontoise / CNRS UMR 8051
Soutenue le 11 juillet 2014 devant le jury composé de :
P. GAUSSIER, ETIS, ENSEA - Université de Cergy-Pontoise - CNRS Co-directeur de thèse
P. TARROUX, LMSI-CNRS, Université Paris-Sud Co-directeur de thèse
D. FILLIAT, INRIA/ENSTA ParisTech FLOWERS Rapporteur
N. ROUGIER, Mnemosyne, INRIA Bordeaux Rapporteur
P. BONNIFAIT, Heudiasyc, Université Technologique de Compiègne Examinateur
B. POUCET, LNC, CNRS - Université Aix-Marseille Examinateur
M. SEBAG, LRI, CNRS - Université Paris-Sud ExaminateurRemerciements
Je tiens tout d’abord à remercier les membres de mon jury pour avoir accepté d’évaluer la
valeur scientifique de mes travaux. J’aimerais exprimer toute mon estime à mes rapporteurs,
David Filliat et Nicolas Rougier, pour avoir accepté de lire et commenter mon manuscrit ainsi
que Philippe Bonnifait, Bruno Poucet et Michèle Sébag pour leur temps et pour les discussions
intéressantes que nous avons eu lors de ma soutenance.
Je remercie également mon encadrant, Nicolas Cuperlier, ainsi que mes directeurs de thèse,
Philippe Gaussier et Philippe Tarroux, pour m’avoir guidé tout au long de ces années. J’ai pris
plaisir à partager avec eux ma passion pour les créatures artificielles, la cybernétique et les
neurosciences. Leurs enseignements ont largement contribué à faire de moi le Jedi que je suis
devenu ainsi qu’à transformer peu à peu cette passion en une vocation.
Je tiens à remercier Inbar Fijalkow et Mathias Quoy, respectivement ex-directrice et directeur
du laboratoire ETIS, pour m’avoir accueilli pendant ces années de thèse.
Merci également à Astrid et Nelly pour leur humour et bonne humeur ainsi que pour avoir su
brillamment faire face avec moi à l’incroyable paperasse administrative que requiert une thèse
co-encadrée par deux universités très différentes.
Je remercie bien évidemment tous les membres du laboratoire pour l’indulgence dont ils
ont fait preuve face à mes nombreuses pirouettes linguistiques ainsi que pour l’effervescence
intellectuelle que nos débats éclectiques ont pu me procurer.
Merci à Pierre A., Cyril, Arnaud, Ghilès, Julien, Frederic, Christophe, Matthieu et Sofiane pour
m’avoir permis de m’intégrer au sein du laboratoire et me frotter au monde de la recherche alors
que je n’étais encore que stagiaire.
Merci également à la nouvelle génération : Abdelhak, Alexandre, David, Khursheed, Souheil,
Ali, Raphael, Moeed et Artem ainsi qu’à mes jeunes padawans, Marwen et Caroline.
Merci à Pierre D., Antoine, Sylvain, Joanna, Quang, Kasia, Loïc, Abdel, Rahima et bien
sur Ramesh pour l’esprit d’équipe dont ils font preuve et avec qui je construis jour après jour
l’avenir de Partnering-Robotics.
Je tiens également à remercier mes collègues artificiels au même titre que mes collègues
humains (bien que moins stimulants sur le plan conversationnel) : merci à Robulab, Roburoc,
Berenson, Alvex et finalement Diya One pour leur patience et leur dévouement face aux nombreuses
expériences que je leur ai fait subir.
Enfin, comment ne pas remercier mes parents, Chantal et Daniel, ainsi que ma soeur, Mathilde,
pour le soutien qu’ils m’ont offert tout au long de ces 27 années à leur côté.
J’aimerais également remercier, et surtout m’excuser auprès de Fabien et Léo ainsi que toutes
les personnes que je n’ai pas cité pour ces nombreuses soirées lors desquelles mon travail est
passé au premier plan.
Pour terminer, j’aimerais souligner le fait que cette thèse n’aurait sûrement pas été ce qu’elle
est sans la présence et le soutien inconditionnel de Charlotte, mon affordance émotionnelle et
ma moitié.
- 3 -Synopsis
Cette thèse a pour objectif la conception d’une architecture de contrôle bio-inspirée permettant
à un robot de naviguer de manière autonome sur de grandes distances. Du point de vue des
sciences cognitives, le modèle développé permet également d’améliorer la compréhension des
mécanismes biologiques impliqués. De précédents travaux ont montré qu’un modèle de cellules
de lieu, enregistrées chez le rat, permettait à un robot mobile d’apprendre des comportements de
navigation robustes, tels qu’une ronde ou un retour au nid, à partir d’associations entre lieu et
action. L’apprentissage et la reconnaissance d’un lieu ne reposaient alors que sur des informations
visuelles. L’ambiguïté de certaines situations visuelles (e.g. un long couloir) ne permettait
pas de naviguer dans de grands environnements.
L’ajout d’autres modalités constitue une solution efficace pour augmenter la robustesse de la
localisation dans des environnements complexes. Cette solution nous a permis d’identifier les
briques minimales nécessaires à la fusion d’informations multimodales, d’abord par le biais
d’un conditionnement simple entre 2 modalités sensorielles, puis par la formalisation d’un mod-
èle, plus générique, de prédictions inter-modales. Ce modèle générique permet à un ensemble
de modalités d’apprendre à s’inter-prédire dans des situations usuelles. C’est un mécanisme bas
niveau qui permet de générer une cohérence perceptive, en ce sens que l’ensemble des modalités
sensorielles s’entraident pour ne renvoyer qu’une perception claire et cohérente aux mécanismes
décisionnels de plus haut niveau. Les modalités les plus corrélées sont ainsi capables de
combler les informations manquantes d’une modalité défaillante (cas pathologique). Ce mod-
èle implique la mise en place d’un système de prédiction et donc une capacité à détecter de la
nouveauté dans ses perceptions. Ainsi, le modèle est également capable de détecter une situation
inattendue ou anormale et possède donc une capacité d’auto-évaluation : l’évaluation de ses
propres perceptions. Partant de ce modèle de prédictions inter-modales, capable d’une première
auto-évaluation, nous nous sommes ensuite mis à la recherche des propriétés fondamentales à
tout système pour l’évaluation de ses comportements.
La première propriété essentielle a été de constater qu’évaluer un comportement sensorimoteur
revient à reconnaître une dynamique entre sensation et action, plutôt que la simple reconnaissance
d’un pattern sensoriel. La première brique du modèle encapsule donc ce couplage entre
sensation et action, formant ainsi un modèle interne minimaliste des interactions du robot avec
son environnement. Ce modèle interne de la dynamique du comportement est la base sur laquelle
le système fera des prédictions.
La seconde propriété essentielle est la capacité à extraire l’information importante de ce modèle
interne par le biais de calculs statistiques. Il est nécessaire que le robot apprenne à capturer les
invariants statistiques en supprimant l’information incohérente. Nous avons donc montré qu’il
était possible d’estimer une densité de probabilité par le biais d’une réduction des erreurs quadratiques
moyennes, c’est à dire un simple conditionnement. Cet apprentissage statistique permet
de réaliser l’équivalent d’une inférence bayésienne, puisque le système estime la probabilité de
reconnaître un comportement à partir de la reconnaissance d’informations statistiques apprises
sur ce comportement. C’est donc par la mise en cascade de simples conditionnements que le
système peut apprendre à estimer les moments statistiques d’une dynamique comportementale
(moyenne, variance, asymétrie, etc...). La non-reconnaissance de cette dynamique lui permet de
détecter qu’une situation est anormale.
Mais détecter un comportement inhabituel ne nous renseigne pas pour autant sur son inefficacité.
Le système doit également surveiller l’évolution de cette anomalie dans le temps pour pouvoir
juger de la pertinence du comportement. Nous montrerons comment un contrôleur émotionnel
- 5 -Synopsis
peut faire usage de cette détection de nouveauté pour réguler le comportement et ainsi permettre
au robot d’utiliser la stratégie la plus adaptée à la situation rencontrée. Pour finir, nous avons mis
en place une procédure de frustration permettant au robot de lancer un appel à l’aide lorsqu’il
détecte qu’il se retrouve dans une impasse. Ce réseau de neurones permet au robot d’identifier
les situations qu’il ne maîtrise pas dans le but d’affiner son apprentissage, à l’instar de certains
processus développementaux.
Mots clés : robotique bio-inspirée, réseaux de neurones artificiels, navigation sensori-motrice,
auto-évaluation, meta-apprentissage, sélection de l’action.
- 6 -Abstract
The goal of this thesis is to build a bio-inspired architecture allowing a robot to autonomously
navigate over large distances. In a cognitive science point of view, the model also aim at improving
the understanding of the underlying biological mechanisms. Previous works showed that
a computational model of hippocampal place cells, based on neurobiological studies made on
rodent, allows a robot to learn robust navigation behaviors. The robot can learn a round or a
homing behavior from a few associations between places and actions. The learning and recognition
of a place were only defined by visual information and shows limitations for navigating
large environments.
Adding other sensorial modalities is an effective solution for improving the robustness of places
recognition in complex environments. This solution led us to the elementary blocks required
when trying to perform multimodal information merging. Such merging has been done, first,
by a simple conditioning between 2 modalities and next improved by a more generic model of
inter-modal prediction. In this model, each modality learns to predict the others in usual situations,
in order to be able to detect abnormal situations and to compensate missing information
of the others. Such a low level mechanism allows to keep a coherent perception even if one
modality is wrong. Moreover, the model can detect unexpected situations and thus exhibit some
self-assessment capabilities: the assessment of its own perception. Following this model of selfassessment,
we focus on the fundamental properties of a system for evaluating its behaviors.
The first fundamental property that pops out is the statement that evaluating a behavior is an
ability to recognize a dynamics between sensations and actions, rather than recognizing a simple
sensorial pattern. A first step was thus to take into account the sensation/action coupling
and build an internal minimalist model of the interaction between the agent and its environment.
Such of model defines the basis on which the system will build predictions and expectations.
The second fundamental property of self-assessment is the ability to extract relevant information
by the use of statistical processes to perform predictions. We show how a neural network
can estimate probability density functions through a simple conditioning rule. This probabilistic
learning allows to achieve bayesian inferences since the system estimates the probability of
observing a particular behavior from statistical information it recognizes about this behavior.
The robot estimates the different statistical momentums (mean, variance, skewness, etc...) of a
behavior dynamics by cascading few simple conditioning. Then, the non-recognition of such a
dynamics is interpreted as an abnormal behavior.
But detecting an abnormal behavior is not sufficient to conclude to its inefficiency. The system
must also monitor the temporal evolution of such an abnormality to judge the relevance of the
behavior. We show how an emotional meta-controller can use this novelty detection to regulate
behaviors and so select the best appropriate strategy in a given context. Finally, we show
how a simple frustration mechanism allows the robot to call for help when it detects potential
deadlocks. Such a mechanism highlights situations where a skills improvement is possible, so
as some developmental processes.
Keywords : bio-inspired robotics, artificial neural-networks, sensory-motor navigation, selfassessment,
metalearning, action selection.
- 7 -Table des matières
Introduction 13
1 Outils du cybernéticien 25
1.1 Une brève introduction aux réseaux de neurones artificiels . . . . . . . . . . . 26
1.2 Conditionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.3 Compétition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.3.1 Winner Takes All . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
1.4 Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
1.4.1 Champs de neurones dynamiques . . . . . . . . . . . . . . . . . . . . 33
1.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2 Modèles de navigation en robotique 41
2.1 Navigation nautique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.1.1 Navigation côtière . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.1.2 Navigation à l’estime . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.1.3 Navigation astronomique . . . . . . . . . . . . . . . . . . . . . . . . . 44
2.2 Navigation en robotique classique . . . . . . . . . . . . . . . . . . . . . . . . 44
2.3 Navigation animale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.3.1 Intégration de chemin . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.3.2 Région hippocampique et cellules de lieu . . . . . . . . . . . . . . . . 49
2.4 Navigation robotique bio-inspirée . . . . . . . . . . . . . . . . . . . . . . . . 53
2.4.1 Modèles inspirés des insectes . . . . . . . . . . . . . . . . . . . . . . 53
2.4.2 Modèles inspirés des mammifères . . . . . . . . . . . . . . . . . . . . 55
2.5 Per-Ac : un modèle de couplage sensori-moteur pour la perception . . . . . . . 56
2.5.1 Modèle de cellules de lieu visuelles . . . . . . . . . . . . . . . . . . . 56
2.5.2 Modèle d’intégration de chemin . . . . . . . . . . . . . . . . . . . . . 61
3 Un parallèle entre formalisme neuronal et bayésien 63
3.1 Limitations du modèle actuel . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.2 Approche bayésienne et notion d’inférence . . . . . . . . . . . . . . . . . . . 65
3.3 Notre modèle de cellules de lieu d’un point de vue bayésien . . . . . . . . . . . 68
3.3.1 Description générale du problème . . . . . . . . . . . . . . . . . . . . 69
3.3.2 Factorisation immédiate . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.3.3 Factorisation retardée . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
- 9 -TABLE DES MATIÈRES
3.4 Pondération statistique des amers . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.4.1 Un modèle neuronal de l’estimation de densité de probabilité . . . . . . 73
3.4.2 Expérience : estimons la dispersion de l’azimut de chaque amer : P(A/S) 75
3.4.3 Expérience : estimons la dispersion globale de l’azimut : P(A) . . . . . 76
3.5 Une approche statistique de la reconnaissance de lieu . . . . . . . . . . . . . . 79
3.5.1 Modèle de cellules de lieux probabilistes . . . . . . . . . . . . . . . . 79
3.5.2 Expérience : estimation de la probabilité d’être dans un lieu sachant les
observations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.6 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
4 Localisation à partir d’informations idiothétiques 87
4.1 Les cellules de grilles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
4.2 Un modèle plausible de cellules de grille . . . . . . . . . . . . . . . . . . . . . 91
4.2.1 Description du modèle . . . . . . . . . . . . . . . . . . . . . . . . . . 91
4.2.2 Structure des expériences . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.3 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
4.3.1 Expérience 1 - exploration aléatoire, sans recalibration . . . . . . . . . 94
4.3.2 Expérience 2 - recalibration de l’intégration de chemin à l’aide d’un
retour au nid périodique. . . . . . . . . . . . . . . . . . . . . . . . . . 96
4.3.3 Expérience 3 - De la cellule de grille à la cellule de lieu . . . . . . . . . 99
4.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
5 Fusion d’informations multimodales 105
5.1 Cohérence et conflits sensoriels . . . . . . . . . . . . . . . . . . . . . . . . . . 106
5.1.1 Conflits bénins entre modalités externes . . . . . . . . . . . . . . . . . 106
5.1.2 Conflits majeurs et ruptures perceptives . . . . . . . . . . . . . . . . . 108
5.2 Un couplage bi-modale par simple conditionnement . . . . . . . . . . . . . . . 109
5.3 Robustesse de la localisation : une expérience sur robot réel . . . . . . . . . . . 110
5.3.1 A propos de la topologie des cellules de grille . . . . . . . . . . . . . . 112
5.3.2 Robustesse de la reconnaissance des lieux aux ambiguïtés visuelles . . 114
5.3.3 A propos du problème du kidnapping . . . . . . . . . . . . . . . . . . 114
5.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
5.4.1 Vers un modèle générique de prédiction intermodale . . . . . . . . . . 117
6 Un modèle générique de détection de nouveauté pour l’auto-évaluation 119
6.1 Modèles computationnels de détection de nouveauté . . . . . . . . . . . . . . 121
6.2 Modèle des perceptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
6.3 Modèle de détection de nouveauté . . . . . . . . . . . . . . . . . . . . . . . . 125
6.4 Expériences et résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
6.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
7 De l’évaluation à la régulation 135
7.1 Un modèle de contrôleur émotionnel au second-ordre . . . . . . . . . . . . . . 137
7.2 Sélection et coopération de stratégie . . . . . . . . . . . . . . . . . . . . . . . 138
7.3 Expérience : La frustration et son rôle communicatif dans le développement de
l’autonomie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
- 10 -TABLE DES MATIÈRES
7.3.1 Résultats en simulations . . . . . . . . . . . . . . . . . . . . . . . . . 139
7.3.2 Expérience sur robot réel . . . . . . . . . . . . . . . . . . . . . . . . . 140
7.4 Expérience : Le stress et son rôle actif dans la régulation des comportements . . 143
7.4.1 Résultats en simulations . . . . . . . . . . . . . . . . . . . . . . . . . 143
7.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
Conclusion 149
A Strategie de suivi de route 181
A.1 Un algorithme minimaliste pour réaliser un comportement de suivi de route . . 181
B Outils de simulation de réseaux de neurones 185
B.1 Coeos : une interface graphique de conception d’architectures neuronales . . . 185
B.2 Promethe : un simulateur temps-réel et distribué de réseaux de neurones . . . . 186
C Plates-formes robotiques 189
C.1 Plate-forme d’intérieur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
C.2 Plate-forme d’extérieur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
C.3 Communication réseau . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
- 11 -People say to me, "Are you looking for the ultimate laws of physics ?"
No, I’m not. I’m just looking to find out more about the world. If it turns
out there is a simple ultimate law that explains everything, so be it, that
would be very nice to discover. If it turns out it’s like an onion with millions
of layers... then that’s the way it is. But either way, Nature is there
and she’s going to come out the way She is. So therefore when we go to
investigate we shouldn’t predecide what it is we’re trying to do, except to
find more about it.
– R. Feynman
Introduction
Les premiers jalons historiques de l’intelligence artificielle (IA) remontent à l’antiquité
et commencent avec "le vieux souhait de jouer à Dieu" [McCorduck, 2004]. Ainsi, les concepts
de machines pensantes et de créatures artificielles apparaissent déjà dans la mythologie
grecque, dont les légendes de Talos de Crete, le robot de bronze d’Héphaïstos ou encore
Galatée de Pygmalion sont de bons exemples. Entre le 19ème et le 20ème siècle, les êtres artifi-
ciels sont progressivement devenus des lieux communs de fiction comme en témoigne l’oeuvre
"Frankenstein" de [Shelley, 1823] ou "R.U.R."(Rossum’s Universal Robots) de [Apek and Wyllie,
2010] puis les romans précurseurs d’Asimov [Asimov, 2004] ou d’Arthur C. Clarke [Clarke
and Kubrick, 1999].
L’étude du raisonnement formel a lui aussi été développé par de nombreux philosophes et math-
ématiciens depuis l’antiquité (parmis les plus notables : Aristote, Euclide, Al-Khawarizmi puis
Leibniz). En se basant sur ces études, les fondateurs de l’IA ont proposé des algorithmes capables
d’imiter, étape par étape, le raisonnement permettant à l’être humain de résoudre des
puzzles et réaliser des déductions logiques [Hart et al., 1968; Poole et al., 1998; Nilsson, 1998].
Le champ de recherche de l’IA à été fondé en 1956 lors d’une conférence incluant notamment
John McCarthy, Marvin Minsky, Allen Newell et Herbert Simon qui devinrent leaders de ce domaine
plusieurs dizaines d’années durant [Crevier, 1993]. Ces pionniers étaient profondément
optimistes à propos de l’avenir de ce nouveau domaine. Simon avaient même prédit : "les machines
seront capables, d’ici une vingtaine d’années, d’accomplir toutes tâches qu’un humain
peut réaliser" [Simon, 1965] et Minsky écrivit : "dans une génération ... le problème de l’intelligence
artificielle sera globalement résolu" [Minsky, 1967].
Cette vision de l’intelligence a permis quelques avancées majeures dans la résolution automatique
de problèmes d’algèbre, la preuve de théorèmes logiques, la réalisation de systèmes experts
ou encore la création d’agents conversationnels. La victoire de Deep Blue contre le champion
d’echec Garry Kasparov en 1997 a marqué les esprits [Newborn and Newborn, 1997]. Mais
la capacité de cette approche a vite trouvé une limite dés lors qu’elle se confrontait au monde
réel continu, dynamique et incertain. La puissance de calcul limitée des machines et l’explosion
combinatoire engendrée par la résolution de tâches même triviales constituent les premières
limitations de l’approche [Moravec, 1988]. La comprehension par la machine du sens commun
associé aux concepts manipulés en est une autre. Ces programmes ne savent pas plus qu’ils effectuent
des démonstrations géométriques ou algébriques que Deep Blue ne savait qu’il jouait
aux échecs. Ces cas représentent plus des opérations intellectuelles assistées par ordinateur que
de l’intelligence à proprement parler.
La raison de cet echec est que la majeure partie des travaux effectués dans le domaine de l’IA
13INTRODUCTION
reposent sur une représentation symbolique du monde. Les symboles représentent des étiquettes
que l’on associe à des concepts, tel qu’une chaise ou un ballon. L’agent se voit attribuer une base
prédéfinies de symboles avec lesquels il peut jongler. Selon ce point de vue, l’intelligence d’un
agent se résume donc à la manipulation de symboles. Mais l’approche fait face à un problème
fondamental (le “Symbol Grounding Problem”) [Harnad, 1990] puisque manipuler des symboles
ne permet pas de comprendre pour autant leur sens dans le monde réel.
[Searle, 1999] eu l’idée d’une expérience de pensée démontrant l’echec de l’approche symbolique
: "Supposons que l’on soit dans une pièce fermée avec la possibilité de recevoir et d’envoyer
des symboles (via un clavier et un écran, par exemple). On dispose de caractères chinois et de
règles de travail (instructions) permettant de produire certaines suites de caractères en fonction
des caractères introduits dans la pièce, sur le modèle des organismes de vente par correspondance
qui traitent leur courrier client en plaçant des réponses préparées à l’avance, et déjà
imprimées, dans des enveloppes. Si l’on fournit une histoire suivie d’une question, toutes deux
écrites en chinois, l’application des règles ne peut que conduire à donner la bonne réponse,
mais sans que l’opérateur ait compris quoi que ce soit, puisqu’il ne connaît pas le chinois. Il
aura juste manipulé des symboles qui n’ont pour lui aucune signification."
FIGURE 1 – Schéma extrait de [Bierre, 1985] repris par [Varela, 1996], illustrant les différentes complexités
de représentation du monde en fonction des limites et des règles de ce monde : "Pour l’espace
« échecs», il est possible de dessiner un réseau de relations dont les noeuds représentent chaque élément
pertinent. Dans le cas de l’espace «conduite automobile», une semblable tentative montre bien qu’audelà
de quelques éléments isolés, le réseau évolue rapidement vers une masse non-circonscrite de sens
commun."
Comment définir, en des termes interprétables par un programme, le concept communément
associé au mot "chaise" ? De toute évidence, définir ce mot en associant le symbole "Chaise" à
un ensemble d’images représentant toutes les chaises existantes n’est pas une bonne solution.
En plus d’un apprentissage laborieux, l’agent n’est alors pas capable de reconnaitre une chaise
qui ne lui a pas été présentée auparavant puisqu’il n’a pas saisi le sens de ce mot.
- 14 -INTRODUCTION
Robotique comportementale
À la fin des années 1980, plusieurs chercheurs plaident pour une approche de l’intelligence artificielle
complètement inédite, centrée sur la robotique. La théorie de l’énaction, proposée par
[Mataruna and Varela, 1980] met ainsi en avant l’importance du corps physique pour acquérir
une compréhension sensée du monde. La machine doit percevoir, bouger, survivre et évoluer
dans un environnement réel pour parvenir à le comprendre. L’intelligence n’est plus vue comme
un processus de réflexion détaché de l’environnement mais bien un processus de cognition "incarné"
au sein d’un corps mobile à la morphologie particulière. On parle alors d’embodiment
[J. Haugeland, 1995; Scheier and Pfeifer, 1997]. Ces capacités sensori-motrices sont essentielles
aux capacités de plus haut niveau et le raisonnement abstrait est en fait la capacité humaine la
moins importante (cf. le paradoxe de Moravec [Russell and Cohn, 2012]).
Selon ce point de vue, reconnaître une chaise c’est avant tout reconnaître un objet sur lequel
on peut s’asseoir. Le sens naît de l’interaction de l’agent avec son monde. Reconnaître un objet
c’est reconnaître ce que l’on peut faire avec. On notera que le sens que l’on donne au mot
"chaise" n’est valable que pour l’être humain et sa morphologie spécifique. Ce même objet n’a
certainement pas le même sens pour l’éléphant ou pour la mouche par exemple.
Dans le même temps, quelques chercheurs tentaient de reproduire les comportements élé-
mentaires de certains animaux [Walter, 1953; Braitenberg, 1984]. Suivant la mouvance bioinspirée,
les roboticiens s’intéressent alors aux modèles que pouvaient représenter les insectes
dont la morphologie est particulièrement adaptée à une réalisation robotique. L’un des premiers
à s’interesser aux insectes en tant que modèle fut Rodney Brooks qui suggéra que les robots
devaient d’abord pouvoir se comporter comme le plus primitif des animaux, avant de prétendre
à des capacités cognitives plus élaborées [Brooks, 1986; Arkin, 1998]. Ces études donnent
naissance à l’approche animat introduite par [Wilson, 1991] et dont le but est la réalisation d’animaux
artificiels en étudiant la cognition animale au niveau le plus simple pour grimper progressivement
en complexité et atteindre un jour l’intelligence humaine par le bas. L’approche ravive
des concepts nés de la cybernétique et de la régulation qui avaient perdu de leur impact depuis
les années soixante. La cybernétique, popularisée en 1948 par [Wiener, 1948], est une science
des systèmes autorégulés, qui étudie le concept de "feedback", ou boucle de retour. La discipline
s’intéresse moins aux composantes d’un système qu’à leurs interactions. Le comportement globale
du système est pris en compte avant tout le reste.
Cette thèse s’inscrit dans cette démarche et considére le comportement émergeant du système
comme un miroir de son intellect. Aussi, nous nous éloignerons d’une représentation symbolique
pour adopter une approche dite "sensori-motrice". C’est le couplage entre sensation et
action qui permettra au robot de se construire une représentation de son environnement.
Nous implémenterons nos solutions sous la forme de réseaux de neurones artificiels. Ces
derniers représentent un outil cadrant parfaitement avec l’approche de la cybernétique. L’intéraction
d’un grand nombre de neurones modélisés par des équations simples peut faire émerger des
capacités de catégorisation et des comportements complexes. L’une des propriétés essentielles
de tels réseaux est la possibilité d’apprendre i.e. de modifier le comportement du système au
fur et à mesure de ses expériences. Ces propriétés permettent d’obtenir de bonnes capacités de
généralisation et facilite également l’adaptation du comportement du robot lorsque l’environnement
change.
Les solutions industrielles classiques s’appuient généralement sur la programmation spéci-
- 15 -INTRODUCTION
fique du robot pour réaliser les tâches désirées. Bien souvent, les robots ne sont programmés que
pour réaliser une seule tâche de manière optimale. Les ingénieurs sont forcés de programmer
entièrement le comportement du robot pour l’adapter à chaque nouvelle tâche. Cette opération
nécessite des humains experts et se révèle très coûteuse en temps de développement.
Selon l’approche que nous adopterons ici, la programmation spécifique de tâches est remplacée
par l’apprentissage de celles-ci. Cependant, nous irons plus loin encore en concevant le robot
non pas comme une machine introvertie mais comme un système capable d’intéragir naturellement
avec un utilisateur pour affiner son apprentissage avec le temps. L’utilisateur n’a alors plus
besoin d’être expert ni de programmer le système pour chaque nouvelle tâche à résoudre.
Pour aboutir à ce type de solution, une démarche ascendante (bottom-up) et constructive
est nécessaire [Mataruna and Varela, 1980; Varela et al., 1993]. Suivant cette démarche, il convient
de développer progressivement la complexité du robot pour avoir la possibilité d’étudier
ses capacités lorsque ce dernier est plongé dans son environnement. Cette démarche tente de
faire émerger des théories de la pratique, et non l’inverse. Les modèles proposés s’inspirent de
principes minimalistes que l’on trouve en biologie animale. A l’inverse d’approches descendantes
(top-down) contraignant l’espace des possibles pour aboutir à la solution désirée, nous
laisserons apparaitre des propriétés émergentes, que l’on ne saurait imaginer si le robot et l’environnement
étaient considérés indépendamment.
Problématique
Cette thèse s’inscrit dans le câdre de la navigation robotique bio-inspirée en environnement
réel et implique la capacité pour un système mobile à se déplacer de manière autonome dans un
monde a priori dynamique et inconnu.
Pour se localiser et naviguer, un robot autonome peut utiliser de multiples solutions. Mais que ce
soit pour la modélisation des processus visuels ou pour la localisation, la cartographie, la navigation
et la planification, les mesures nécessaires sont fortement bruitées, ce qui justifie le recours
à des méthodes probabilistes. Les approches bayésiennes ont la faveur de la communauté robotique
pour conserver le contrôle sur les incertitudes pesant sur les données. Les approches neuromimétiques
fournissent des solutions robustes et originales pour résoudre le même problème.
Des travaux récents suggèrent que des processus statistiques sont à l’oeuvre dans le cerveau
et montrent comment certains codages par population de neurones implémentent les principes
de bases de l’approche bayésienne [Deneve S, 2004]. L’équipe Neurocybernétique d’ETIS et
l’équipe "Cognition, Perception et Usages" du LIMSI ont travaillé à la mise au point de modèles
bio-inspirés neuronaux et de modèles bayésiens pour la localisation et la navigation en robotique
autonome.
Les travaux de [P. Gaussier, 1997] ont montré il y a maintenant plus d’une dizaine d’années
qu’un système bio-inspiré pouvait par exemple apprendre à retourner vers un lieu en apprenant
un nombre très réduit de couples lieu-action dans le voisinage de ce lieu-but. L’emploi de mé-
canismes de compétition entre ces couples lieu-action permet la création d’un bassin d’attraction
qui attire immanquablement le robot sur le lieu cible pour peu que le point de départ appartienne
au même voisinage visuel. Le comportement du robot démontre ainsi sa reconnaissance du lieu
cible alors même que ce lieu n’a pas été codé en temps que tel dans le réseau.
D’autres travaux ont permis de montrer que ce type d’approche pouvait se généraliser à l’apprentissage
de rondes [Giovannangeli and Gaussier, 2010] ou à la reconnaissance active d’objets
- 16 -INTRODUCTION
[S. Leprêtre, 1999]. Cependant, même si dans ces tâches la capacité de généralisation tenait la
première place, on peut se poser la question de la capacité de ces approches à traiter des problèmes
de très grande taille. Que se passe t’il lorsque le nombre d’amers visuels utilisés ne se
compte plus en centaines mais en centaines de milliers voire millions ? Il est clair que la capacité
d’un simple mécanisme de compétition à proposer une interprétation correcte s’effondre avec
l’augmentation du nombre de vues apprises.
De récents travaux [Cuperlier et al., 2008] ont montré qu’une information de contexte pouvait
être apprise en ligne et utilisée à la fois pour limiter la compétition (augmenter le rapport signal
à bruit) mais aussi pour limiter la puissance de calcul nécessaire en ne calculant que l’activité
des neurones associés au bon contexte. Mais même avec ce genre de mécanisme, le robot peut se
trouver trop loin des lieux appris pour être attiré dans le bassin d’attraction désiré. Il peut alors
se mettre à errer indéfiniment sans rejoindre le lieu cible.
Cependant, l’observation interne de l’évolution du niveau de reconnaissance des lieux traduit
clairement cet échec. Un "observateur" interne pourrait donc qualifier le comportement du système.
L’enjeu dans la construction d’un tel système complexe doté d’une autonomie comportementale
est double. D’une part il est nécessaire que les futurs systèmes de traitement de l’information
soient à la fois fiables et flexibles, capable d’extraire de manière active les informations
de l’environnement qu’ils jugent pertinentes pour adapter leur comportement. D’autre part, ces
systèmes devront être capables d’auto-évaluer leurs performances afin de détecter les situations
d’échec ou de dead-lock (boucle sans fin). Ces situations peuvent se produire au cours d’interactions
dynamiques complexes, alors même que les comportements élémentaires du système sont
corrects.
Pour un robot, l’autonomie peut alors se traduire par l’expression de comportements adaptatifs
et non supervisés, lui permettant de détecter mais aussi de corriger des situations d’échec afin de
mener à bien les tâches nécessaires à sa mission dans l’environnement dans lequel il se trouve.
Rendre réellement utilisable les systèmes robotiques sophistiqués que l’on voit apparaître ces
dernières années (cf la création de Cap robotique pour fédérer les nombreuses initiatives industrielles
concernant les robots de services, les robots ludiques, les robots interactifs voire
humanoïdes comme Asimo de Honda, HRP2, ICub ou Nao d’Aldebaran robotics à Paris) passe
par la maitrise de systèmes informatiques complexes relevant le défi de l’autonomie et de l’adaptation
comportementale nécessitant la capacité à détecter des situations critiques et la capacité
à les résoudre. Ces compétences sont cruciales pour le développement de nouveaux produits
robotiques destinés à évoluer de manière autonome dans des environnements dynamiques a priori
inconnus.
La robotique autonome se développe en particulier en direction de deux types d’applications
: le véhicule autonome et la robotique d’assistance. Une amélioration du transport urbain
pourrait passer par la mise au point de véhicules capables de se diriger de façon automatique
d’un point à un autre en gérant les situations complexes et inattendues qu’il rencontrera lors de
son parcours. Le fait de naviguer sur de longues distances est susceptible d’induire une instabilité
de localisation si des informations de type GPS ne sont pas accessibles sur l’ensemble du trajet.
Le système devra identifier ces situations d’erreur et y remédier. De la même façon, la robotique
d’assistance supposera une capacité de navigation autonome, d’apprentissage des situations nouvelles
et de reconnaissance de lieux et d’objets mais également la capacité à reconnaître les
situations d’échec et à y remédier. Enfin, la maitrise du passage à l’échelle des mécanismes per-
- 17 -INTRODUCTION
mettant de reconnaître des milliers voire des millions de formes en temps réel et d’auto-adapter
le comportement du robot en cas d’échec est un défi incontournable pour l’ingénierie des systèmes
intelligents de demain.
Ces questions sont aussi au centre des sciences cognitives avec notamment un nombre de
plus en plus important de recherches sur le rôle des émotions dans nos processus cognitifs. Ces
processus peuvent être assimilés à des contrôleurs au second ordre, capablent à la fois de remettre
en cause la priorité de nos stratégies, ou de réaliser la fusion d’informations multimodales
pour fabriquer une perception stable et robuste du monde.
L’autonomie globale d’un système passe par 4 axes principaux que nous développerons progressivement
tout au long de ces travaux, à savoir :
- La sélection d’informations pertinentes par l’extraction de régularités statistiques.
- L’intégration d’information multimodale pour obtenir une perception robuste et stable.
- L’auto-évaluation des comportements sensori-moteurs exhibés par le robot, par l’ajout d’un
méta-prédicteur générique.
- La sélection et la régulation de ces comportements par le biais de processus émotionnels.
Extraction de régularités statistiques
Afin de se construire une perception robuste de son environnement, un système nécessite la
capacité à extraire de celui-ci l’information importante pour la tâche à réaliser. Les approches
statistiques fournissent des solutions efficaces pour filtrer l’espace des données que le système
perçoit en mettant en avant les informations les plus stables. Il est nécessaire que le robot apprenne
à capturer ces invariants statistiques en supprimant l’information instable ou trop bruitée.
Dans l’architecture actuelle, tous les amers visuels sont traités de manière identique. Pourtant
ces amers peuvent avoir des caractéristiques différentes (proximaux ou distaux) et être plus ou
moins pertinents selon la tâche envisagée. Il est donc nécessaire d’introduire une capacité à
prédire le déplacement de ceux-ci afin de les caractériser. Ceux dont la position angulaire reste
invariante (sur une certaine distance) et dont la signature est unique peuvent servir à reconnaitre
des lieux de manière robuste. Au contraire, un même amer perçu sous différentes positions angulaires
reflète clairement la présence d’un objet ambigu, redondant ou encore mobile, et ne
devrait pas être pris en compte par le système.
Un mécanisme de méta-contrôle sera donc nécessaire ici pour apprendre à caractériser les amers
visuels et moduler leur influence dans la reconnaissance des lieux. La constitution d’un tel mé-
canisme sera abordée selon les deux paradigmes : neuronal et bayésien. L’exploitation de ces
prédictions devrait permettre d’une part d’améliorer les performances du système (adaptation) et
d’autre part de définir un détecteur de nouveauté (curiosité, surprise. . . ) réagissant à des données
sortant de l’épure déterminée par un prédicteur neuronal (après apprentissage de la distribution
des données).
Intégration d’information multimodale
Dans une deuxième phase, nous chercherons à utiliser ces mêmes techniques pour maitriser des
tâches plus complexes telles que l’intégration d’informations proprioceptives dans le codage des
lieux. La nature même de cette intégration étant méconnue, différentes stratégies de fusion entre
ces informations seront explorées.
D’un point de vue modèle neurobiologique, la fusion d’informations visuelles avec des informa-
- 18 -INTRODUCTION
tions idiothétiques devrait conduire à une amélioration notable de la stabilité des champs de lieu
multimodaux en comparaison de champs issus d’une seule modalité. Cette fusion devra permettre
la création de cellules de lieux plus robustes à des changements de l’environnement (variation
de luminosité, perte d’amers lointains, fonctionnement épisodique de la modalité visuelle ...).
La recalibration de l’odométrie par des informations visuelles devrait également permettre d’améliorer
la fiabilité de ces informations lors de navigations dans de grands environnements (limitation de
la dérive idiothétique, robustesse aux fermetures de boucles et au kidnapping...).
L’impact des mécanismes de fusion/compétition entre modalités sur la stabilité et l’exactitude
de l’information de position (lieux) sera étudiée dans le cadre de tâches de navigation sensorimotrices
(ronde, retour à un lieu appris).
Auto-évaluation
Les travaux présentés dans cette thèse visent à doter nos systèmes robotiques de propriétés leur
permettant de sélectionner les informations les plus pertinentes et d’adapter jusqu’à leurs comportements
et leurs buts en fonction de l’évaluation de la situation rencontrée. Nous ferons l’hypothèse
que les mécanismes de fusion impliquent la nécessité de prédire l’apport d’une modalité
pour la reconnaissance d’un état de la même manière que juger le succès ou l’échec d’un
comportement nécessite la prédiction de l’évolution d’un certain nombre de variables liées à la
reconnaissance des états cibles. Il est donc légitime de supposer que ces différents problèmes
pourraient reposer sur un système de prédiction générique capable de capturer rapidement les
informations statistiques caractérisant une situation donnée pour faire des prédictions sur l’évolution
de cet état. L’incapacité à prédire l’état courant pourrait alors être vue comme un signal de
renforcement négatif impliquant la remise en cause du comportement en cours et l’apprentissage
de nouveaux états [P. Andry, 2002].
Processus émotionnels
Dans ce cadre, la modélisation des émotions semble indispensable à la fois au méta-contrôle
de nos mécanismes cognitifs [Damasio, 1995; LeDoux, 1992; Panksepp, 1998] mais aussi pour
communiquer de manière pré-verbale nos états internes. Les travaux en psychologie et neurobiologie
montrent l’importance d’introduire des mécanismes émotionnels au coeur même des systèmes
d’Intelligence Artificielle [Damasio, 1995; Picard, 1997; Canamero and Gaussier, 2004].
On retrouve ainsi toute une gamme de modèles permettant aux robots de détecter de la nouveauté,
de prédire le rythme d’une interaction [Andry et al., 2001], de devenir curieux [Oudeyer
et al., 2007] afin qu’ils puissent développer de manière autonome de nouvelles compétences
dans un cadre "open ended" (à horizon temporel ouvert). L’approche bio-inspirée basée sur des
modèles émotionnels pour le méta-contrôle est encore peu explorée [Balkenius et al., 2009;
Canamero and Gaussier, 2004; Mannella et al., 2008]. Nous nous intéresserons ainsi à comprendre
comment les émotions peuvent moduler les motivations ou les «drives» contrôlant un
robot.
Chez les mammifères, la régulation des comportements est liée aux interactions entre différentes
structures dites limbiques. Nos émotions régulent nos comportements (ex. en cas de
danger, arrêt des taches en cours et déclenchement d’un comportement de fuite ou d’agression)
mais elles sont elles même régulées par d’autres processus cognitifs (la surprise liée à la détection
d’une nouveauté par exemple). Différents courants théoriques s’affrontent et opposent des
modèles d’émotions élémentaires [Ekman, 1984] à des modèles dimensionnels (passage continu
- 19 -INTRODUCTION
d’une émotion à une autre) [Spencer, 1870; Wundt and Judd, 1897] et discutent de la primauté
des mécanismes cognitifs ou viscéraux dans la genèse des émotions.
Dans ces travaux, nous ne tenterons pas de prendre parti au départ sur ces questions mais
chercherons à utiliser dans un cadre restreint les données et modèles computationnels disponibles
sur la détection de nouveauté et la gestion des comportements (modèles des ganglions de la
bases, de l’hippocampe, de l’amygdale et du cortex préfrontal) pour en déduire les règles de
régulation les plus simples possibles et tester leurs effets comportementaux dans des tâches de
navigation autonome.
Portrait-Robot
Les travaux réalisés dans cette thèse ont été menés sur 2 robots mobiles : la plateforme
mobile d’intérieur Robulab, et celle adpatée à la navigation en environnement extérieur Roburoc
de Robosoft.
FIGURE 2 – Plateforme robotique mobile Robulab de Robosoft. Le robot est composé d’une base mobile, d’un corps
contenant le pc embarqué et d’une tête supportant la caméra sur servomoteur. La boussole est positionnée au sommet
d’un mat afin d’empécher d’éventuelles interférences par l’électronique embarquée. Le système de localisation n’est
jamais utilisé par le robot. Il permet seulement d’enregistrer la trajectoire de celui-ci.
Les plateformes sont composées de 3 parties distinctes, à savoir une base mobile (Robulab
PC/104) qui permet au robot de se mouvoir, un corps comprenant un coffre au sein duquel se
trouve un ordinateur embarqué (Carte mini ITX i7), puis une "tête" composée d’une caméra
montée sur servomoteur. Les robots sont également munies de microcontroleurs (Arduino) pour
contrôler le matériel embarqué ainsi que d’un routeur WiFi pour communiquer avec une ma-
- 20 -INTRODUCTION
FIGURE 3 – Plateforme robotique mobile Roburoc de Robosoft. La base mobile est munie de 4 roues motrices tout
terrain adaptées aux environnements extérieurs. Le corps contient le pc embarqué protégé à l’intérieur d’un coffre, un
pc portable permettant un contrôle du robot. La caméra est soutenue par une plateforme stabilisatrice. L’électronique
est recouverte d’un film transparent et l’ensemble est surmonté d’un parapluie dépliable afin de resister à l’humidité.
Une bâche étanche est transporté dans le sac à dos du robot en cas d’averse.
chine distante si besoin. Les 2 plateformes sont munies de capteurs de proximité utilisés pour
l’évitement d’obstacle, d’une boussole magnétique ainsi que d’autres capteurs plus spécifiques.
Nous classerons ces capteurs en deux catégories selon qu’ils mesurent un état interne au robot
ou bien un état externe relatif à son environnement. Dans le premier cas, nous parlerons de proprioception
ou de modalité sensorielle idiothétique (e.g odométrie, accéléromètre, gyroscope,
indicateur de charge de la batterie). Dans le second cas, nous parlerons d’extéroception ou de
modalité sensorielle allothétique (e.g. caméra, capteurs ultra-son, capteurs infra-rouges, capteur
thermique, boussole magnétique). Pour une liste complète du matériel embarqué, on pourra se
référer à l’annexe C.
Les 2 plateformes que nous utiliserons sont des robots mobiles à roues non holonômes. Cette
contrainte implique que le robot ne peut effectuer de translation omnidirectionelle. La locomotion
à l’aide de roues exploite la friction de contact, dont la nature (régularité, matériaux) à une
forte influence sur les propriétés du mouvement.
Dans le cas du robot d’intérieur (fig. 2), les 2 roues sont pleines et disposées de part et d’autre
de la base. Le centre instantané de rotation est donc situé au milieu des 2 roues ce qui permet
un rayon de braquage nul (rotation sur place à vitesse nulle). En condition intérieure (sol plan),
nous considèrerons qu’il y a roulement sans glissement de la roue sur le sol. Pour vérifier cette
condition, il est nécessaire que le contact soit ponctuel et que les roues soit indéformables.
Dans le cas du robot d’extérieur (fig. 3), les 4 roues tout terrain sont parallèles 2 à 2, ce qui ne
permet pas un rayon de braquage nul. De plus, alors qu’il est raisonnable de dire que des roues
pleines sont indéformables, cette hypothèse est fausse si l’on considère des roues équipées de
pneus. Une telle contrainte, ajoutée a celle d’un sol accidenté en environnement extérieur, im-
- 21 -INTRODUCTION
plique des glissements qui ne sont cette fois plus négligeables.
Plan de la thèse
Ce manuscrit se décompose en 7 chapitres distincts.
Dans le chapitre 1, j’essaierai d’aborder de manière didactique les outils nécessaires à la compréhension
des modèles et méthodes que nous utiliserons tout au long de ces travaux. Nous
aborderons les bases du formalisme neuronal, de l’apprentissage par conditionnement, de la
catégorisation, de la décision ainsi que de l’importance de l’aspect dynamique dans les processus
neuronaux.
Dans le chapitre 2, nous passerons en revue un état de l’art des modèles permettant la navigation
autonome d’un robot mobile. Après un bref rapprochement entre les méthodes historiques
utilisées pour la navigation maritimes et celles utilisées en robotique mobile, nous comparerons
les méthodes dites "classiques" avec d’autres modèles inspirés du comportement animal. Nous
verrons que les techniques de SLAM (Simultaneous Localisation And Mapping) se basent principalement
sur l’idée de la construction d’une carte interne détaillée de l’environnement. Cette
carte doit permettre au système de naviguer de manière précise dans cet environnement. Ces
méthodes classiques montrent leurs limites face à des environnements dynamiques et/ou de
grandes tailles. Nous verrons comment des solutions simples et robustes, abordant le problème
sous un autre angle, ont pu émerger de la nature. Dans le cadre de l’approche bio-inspiré, je
présenterais le modèle de cellules de lieux hippocampiques que nous exploiterons comme base
du modèle de navigation visuelle dans la suite de ces travaux.
Dans le chapitre 3, je présenterai un parallèle entre l’approche neuronale et l’approche
bayésienne en appliquant cette comparaison au modèle de navigation visuelle présenté précédemment.
Après une description des limitations du modèle d’apprentissage figé précédent, nous
procéderons à une ré-écriture du modèle sous une forme probabiliste. Je proposerai ensuite une
reflexion et des solutions au problème de l’extraction de l’information pertinente pour la tâche.
A partir de cette comparaison, je montrerai comment un robot est capable d’apprendre à prédire
un amer visuel à partir de la perception de son azimut (sa position angulaire). De la même
manière, je montrerai comment construire des cellules de lieu "probabilistes" en apprenant à
prédire un lieu à partir de la perception d’une constellation d’amers-azimuts donnée. Pour cela,
je proposerai un modèle neuronal capable d’estimer des densités de probabilités à partir d’observations
statistiques de l’environnement. Ce modèle de prédiction uni-modal constituera la
première brique d’auto-évaluation du système (l’évaluation de la pertinence des informations
qu’il reçoit).
Dans le chapitre 4, nous implémenterons une nouvelle stratégie de navigation basée sur une
localisation idiothétique, c’est à dire une représentation des lieux construite à partir d’informations
proprioceptives. En partant d’un mécanisme simple d’intégration de chemin (présenté au
chapitre 2), nous proposerons un modèle de cellules de grille, enregistrées dans le cortex entorhinal
dorso-médian des rats [Hafting et al., 2005]. Nous analyserons les possibilités et limitations
de ces cellules pour la navigation. Nous proposerons un modèle permettant d’obtenir des cellules
de lieu idiothétiques uniquement alimentées par l’information de ces cellules de grilles.
Après avoir analysé en détails ce nouveau modèle de cellules de lieu idiothétiques, nous nous
intéresserons dans le chapitre 5, à la manière dont peuvent être fusionnées les représentations
issues du modèle visuel et du modèle idiothétique. Nous proposerons un modèle de fusion simple
afin de générer des cellules de lieu multimodales, c’est à dire des cellules dont l’activation
- 22 -INTRODUCTION
dépend à la fois d’informations allothétiques et idiothétiques. Plusieurs expériences sur robot
réel rendront compte de la capacité du modèle à conserver une reconnaissance cohérentes lors
de perturbations extérieures (ambiguités visuelles, kidnapping et fermeture de boucle).
Pour finir, nous ouvrirons la discussion sur la fusion de modalités en proposant un modèle
générique pour l’intégration d’informations multi-modales (ne se limitant pas à 2 modalités).
Ce modèle de prédictions intermodales constituera la seconde brique d’auto-évaluation du système
(l’évaluation de l’adéquation existant entre ces différentes sensations).
Le chapitre 6 se focalisera sur l’auto-évaluation des comportements exhibés par le système.
En partant d’un état de l’art sur les modèles de détection de nouveauté et les théories de la
perception, je proposerai un modèle capable d’apprendre à reconnaitre la dynamique résultante
du couplage entre sensations et actions. L’apprentisssage de cette dynamique forme un mod-
èle interne des interactions du robot avec son environnement : un modèle de ses perceptions.
La surprise (erreur de prédiction) engendrée par une dynamique sensori-motrice inhabituelle
renseigne alors le système sur d’éventuelles anomalies de son comportement. Ce modèle de dé-
tection de nouveauté constituera la troisième brique d’auto-évaluation du système, l’évaluation
de son comportement.
Dans le chapitre 7, nous verrons que le fait de détecter un comportement inhabituel ne nous
renseigne pas pour autant sur son inefficacité. Le système doit également surveiller l’évolution
de la surprise dans le temps pour pouvoir juger de la pertinence de celle-ci. Je montrerais comment
un contrôleur émotionnel au second ordre peut faire usage de cette détection de nouveauté
pour réguler le comportement et ainsi permettre au robot d’utiliser la stratégie la plus adaptée à
la situation rencontrée. Par ailleurs, un modèle simpliste de frustration poussera le robot à initier
une intéraction avec son professeur lorsqu’il détecte qu’il se retrouve dans une impasse. Ce
mécanisme permet au robot d’identifier les situations qu’il ne maitrise pas dans le but d’affiner
son apprentissage par le biais d’une intéraction qu’il à lui même initié, à l’instar de certains
processus développementaux.
Pour finir, nous discuterons des différentes problématiques abordées ainsi que des apports
de ces travaux relatifs à l’autonomie en robotique mobile.
- 23 -Une chose est particulièrement frappante dans le cas de la colonie d’insectes : contrairement
à ce qui se passe avec le cerveau, nous n’avons aucun mal à admettre
deux choses : a) la colonie est composée d’individus ; b) il n’y a pas de centre ou de
“moi” localisé. Pourtant, l’ensemble se comporte comme un tout unitaire et, vu de
l’extérieur, c’est comme si un agent coordinateur était “virtuellement” présent au
centre. C’est ce que j’entends lorsque je parle d’un moi dénudé de moi : une configuration
globale et cohérente qui émerge grâce à de simples constituants locaux, qui
semble avoir un centre alors qu’il n’y en a aucun [...] pp. 85-87
– F. Varela. “Quel savoir pour l’Éthique”
CHAPITRE 1
Outils du cybernéticien
Le but de ce chapitre est de fournir une vue d’ensemble des outils nécessaires à la compréhension
des modèles et méthodes développé(e)s tout au long de ce manuscrit. Les notions
présentées seront abordées de manière volontairement didactique afin de rendre la lecture de
cette thèse accessible au lecteur non-initié.
Nous aborderons brièvement les bases du formalisme neuronal en présentant le fonctionnement
d’un neurone biologique et de son homologue, le neurone formel. Nous parlerons de groupe
neuronal pour désigner une population de neurones partageant des caractéristiques communes :
une fonction et/ou une règle d’apprentissage identique.
Nous introduirons ensuite le concept d’apprentissage, concept clé pour l’ensemble des applications
utilisant des réseaux de neurones artificiels. Un réseau de neurones peut apprendre en
modifiant la valeur de ses poids synaptiques en fonction des entrées qu’il reçoit. La modification
de ces poids autorise l’apprentissage d’associations et la catégorisation des signaux d’entrées en
différentes classes. Un signal de neuromodulation permet de moduler la vitesse d’apprentissage
du réseau.
Ces capacités d’apprentissages sont cruciales pour rendre un agent autonome et capable de faire
face aux aspects dynamiques, changeants et complexes du monde réel. Elles permettent de capturer
les régularités statistiques du monde en filtrant naturellement le bruit présent. Elles permettent
aussi à l’animal de s’adapter au mieux à son environnement, par la capacité à reconnaître
des lieux pour se déplacer efficacement, la capacité d’apprendre de ses erreurs ou encore celle
de détecter une situation anormale et fuir en cas de danger.
Le signal de neuromodulation peut provenir de stimuli externes (renforcement positif ou négatif
de la part de l’environnement ou d’un autre animal), mais il peut aussi être généré en interne
par certains mécanismes compétitifs et l’usage de seuils liés aux niveaux physiologiques de
l’animal (faim, soif, émotions, etc...). Ces mécanismes générant des signaux de modulation de
l’apprentissage et/ou du comportement ne sont pas directement liés à l’environnement et sont
principalement issus de décisions internes. Cela pose la question de comment fonctionnent ces
processus décisionnels à l’oeuvre dans le cerveau. De tels mécanismes sont utilisés dans le cadre
de l’apprentissage non-supervisé, c’est à dire un apprentissage autonome. L’agent prend la dé-
cision d’apprendre ou non en fonction de ses propres motivations et non de facteurs extérieurs.
L’apprentissage n’est pas la seule caractéristique intéressante de l’approche neuronale. Nous
aborderons succinctement l’intérêt du codage en population et celui des réseaux récurrents. Plus
particulièrement, nous nous attarderons sur les mécanismes de compétition, très utilisés dans
251.1. UNE BRÈVE INTRODUCTION AUX RÉSEAUX DE NEURONES ARTIFICIELS
mes travaux. L’intérêt d’une compétition réside dans le fait que des neurones en rivalité réalisent
un processus décisionnel doté de propriétés intéressantes. La décision, nous le verrons, est également
une caractéristique essentielle pour la survie et l’autonomie d’un agent.
1.1 Une brève introduction aux réseaux de neurones artificiels
Un réseau de neurones artificiels est un modèle computationnel utilisé pour réaliser un ensemble
de traitements en certains points semblables à son homologue biologique. Le premier
modèle mathématique du neurone biologique a été proposé par McCulloch et Pitts en 1943 [McCulloch
et al., 1943] et a été repris en 1958 par Rosenblatt [Rosenblatt, 1958] dans son célèbre
modèle du Perceptron. Le perceptron est un classifieur linéaire composé de couche de neurones
formant un réseau. Chaque neurone du réseau est une unité computationnel effectuant une
somme pondérée de ses entrées. L’information en entrée peut provenir d’un capteur (e.g. rétine)
ou bien de la sortie d’autres neurones. Chaque entrée e est pondérée d’un poids synaptique w,
modulant l’importance de certaines entrées par rapport à d’autres dans le résultat en sortie (voir
fig. 1.1).
Pour n entrées, le calcul de l’activité (ou potentiel) Pi d’un neurone i est donc défini tel que :
Pi =
Xn
1
xn.wn (1.1)
Ce potentiel de sortie peut ensuite subir une transformation non-linéaire par le biais d’une
fonction d’activation, usuellement un seuillage ou bien une base radiale (e.g. base sigmoïdale),
prodiguant ainsi nombre de propriétés intéressantes. Il est important de bien choisir la fonction
d’activation pour obtenir un modèle utile en pratique. Dans la suite de ces travaux, nous utiliserons
principalement une fonction d’activation linéaire ou bien un seuillage binaire tel que :
Seuillage binaire : Sb(P) =
1 si P > S
0 sinon. (1.2)
Avec S, un seuil particulier.
Bien que la réponse réelle d’un neurone biologique soit souvent impulsionnelle (spike), le mod-
èle approxime l’activité de sortie par un potentiel d’activité, ou fréquence moyenne de décharge.
Certains modèles plus fins prennent en compte cet aspect impulsionnel (spiking neurons) dont
le premier a été introduit par [Hodgkin and Huxley, 1952].
Nous allons maintenant nous concentrer plus précisément sur les règles qui permettent à ces
réseaux d’apprendre par association.
1.2 Conditionnement
L’apprentissage associatif, ou apprentissage par conditionnement est une des techniques
d’apprentissage les plus simples observée chez l’animal. C’est le physiologiste Pavlov qui,
le premier, introduisit la notion de conditionnement classique [Pavlov, 1927] illustré dans sa
fameuse expérience de conditionnement du chien (voir fig. 1.2). Pavlov avait remarqué que la
vue ou l’odeur de la nourriture (stimulus inconditionnel (US)) activait de manière réflexe une
- 26 -CHAPITRE 1. OUTILS DU CYBERNÉTICIEN
FIGURE 1.1 – Comparaison entre neurone biologique et neurone formel. A - Le neurone biologique intègre l’activité
présente sur ses dendrites (entrées). La fréquence (ou potentiel) de décharge de l’axone (sortie) dépend de
cette activité dendritique. Les terminaisons neuronales viennent se connecter aux dendrites d’autres neurones via
des synapses. B - Le fonctionnement du neurone formel est assez similaire : la sortie est fonction de la somme des
entrées par les poids synaptiques. L’utilisation d’une fonction d’activation radiale permet de traiter des problèmes
non-linéaires.
salivation de la part du chien. Pavlov présentait ensuite, de manière répétée, le son d’une cloche
(stimulus conditionnel (CS)) à chaque fois que la nourriture est présentée au chien. Au bout
d’un certain temps, le son de la cloche est associé à la nourriture et active donc la salivation du
chien, et ce même lorsque la nourriture n’est pas présentée. L’apprentissage consiste donc en
l’association d’un stimulus nouveau à un stimulus réflexe (e.g. si une réaction réflexe R survient
suite à la perception d’un stimulus particulier (e.g. une odeur), il est possible d’apprendre à
déclencher cette même réaction R suite à la perception d’un son en faisant systématiquement
précéder l’odeur par le son).
Quelques années plus tard, Thorndike et Skinner ont introduit la notion de conditionnement
instrumental (ou opérant) [Skinner, 1938] qui rend compte de l’aptitude des animaux à apprendre
le lien entre 2 événements et ce quel que soit la nature de ces événements (stimulus externe,
action, etc..). Skinner distingue le conditionnement opérant du conditionnement classique par le
fait que la réponse ne soit pas une réaction réflexe de l’organisme.
L’animal est donc capable d’apprendre une association entre 2 stimuli présentant un lien
apparent. Ce lien apparent amène au concept clé de corrélation. 2 stimuli sont corrélés s’ils
sont liés d’une manière ou d’une autre. Le type le plus simple de liaison est la relation affine.
Dans le cas de deux variables, elle se calcule au travers d’une régression linéaire. La mesure
de la corrélation linéaire entre les deux se fait alors par le calcul du coefficient de corrélation
linéaire. Ce coefficient est égal au rapport de leur covariance et du produit de leurs écarts types.
Le coefficient de corrélation est compris entre -1 (anti-corrélation) et 1 (corrélation maximum).
Attention toutefois à ne pas confondre corrélation et causalité. Deux événements peuvent être
corrélés sans pour autant impliquer un rapport de cause à effet. Par exemple, la probabilité de
mourir n’augmente pas lorsque l’on se trouve dans un lit d’hôpital, mais on y est généralement
pour soigner une maladie, et lorsque l’on est malade la probabilité de mourir est plus grande.
Confondre ces 2 concepts peut amener à des raisonnements biaisés comme en joue l’humoriste
Coluche :
« 1/3 des accidents de la route étant dus à des conducteurs alcooliques, qu’attend-on pour punir
les 2/3 de conducteurs sobres responsables de la majorité des accidents ? »
L’un des algorithmes applicables pour modéliser un conditionnement classique est le principe
de réduction des erreurs quadratiques moyennes (Least Mean Square (LMS)) proposé en 1960
par [Widrow and Hoff, 1960]. Cet algorithme permet un apprentissage supervisé d’un flux d’ac-
- 27 -1.2. CONDITIONNEMENT
FIGURE 1.2 – Conditionnement classique : A - La vue de la nourriture (stimulus inconditionnel) fait saliver le chien
de façon réflexe (poids synaptique = 1). B - Le son d’une cloche (stimulus neutre) n’a au départ aucun effet sur la
salivation (poids synaptique nul). C - Pendant la phase de conditionnement, on présente de façon répétée la nourriture
et le son de cloche simultanément. Le poids synaptique liant la cloche et la salivation se renforce progressivement. D
- Une fois le conditionnement terminé, le son de la cloche activera la salivation même en l’absence de nourriture.
tivité d’entrée. C’est une méthode d’optimisation qui consiste en la modification des poids
synaptiques w jusqu’à trouver l’erreur quadratique moyenne minimale entre l’entrée e et la
sortie désirée Sd.
Dans l’exemple suivant, nous considérons un réseau à 3 neurones. Un neurone code pour le signal
d’entrée Ei
, un autre pour la sortie désirée Sdj et enfin un troisième représente la sortie Sj
du système. Ici il n’y a donc qu’un seul poids synaptique wij , reliant l’entrée Ei à la sortie Sj .
Le système commence à apprendre lorsque qu’il existe une différence de potentiel entre la sortie
réelle S et la sortie désirée Sd. Son unique but est de faire diminuer cette différence en modi-
fiant la valeur du poids wij . L’adaptation du poids wij est d’autant plus forte que la différence
Sdj − Sj est grande. Voici l’équation décrivant cette règle d’apprentissage :
∆wij = λEi
.(Sdj − Sj ) (1.3)
Le paramètre λ permet de contrôler la vitesse d’apprentissage (λ < 1). A chaque itération, l’algorithme
calcule également la nouvelle valeur du poids wij et de la sortie Sj :
- 28 -CHAPITRE 1. OUTILS DU CYBERNÉTICIEN
wij (t + 1) = wij (t) + ∆wij (t) (1.4)
Ces apprentissages par conditionnement ont été largement utilisés dans le cadre de recherches
impliquant des réseaux de neurones artificiels [Grossberg and Morahan, 1971; Grossberg, 1972a;
Rescorla, 1967]. Il existe également d’autres méthodes d’apprentissage associatif comme la rè-
gle de Hebb [Hebb et al., 1949] ou encore la classe des apprentissages par renforcement initiée
par [Klopf and Laboratory, 1972; Klopf, 1975] puis adapté par [Anderson et al., 1983]. L’apprentissage
par renforcement fait référence à une classe de problèmes dont le but est d’apprendre
à partir d’expériences, ce qu’il convient de faire en différentes situations de façon à optimiser
une récompense au fil du temps. On peut par exemple considérer un agent autonome, plongé
au sein d’un environnement, devant prendre des décisions en fonction de son état courant. En
retour, l’environnement procure à l’agent des récompenses, qui peuvent être positives ou négatives.
L’agent cherche un comportement décisionnel optimal appelé stratégie ou politique : une
fonction associant à l’état courant l’action à exécuter. Cette politique est optimale si elle permet
à l’agent de maximiser la somme des récompenses au cours du temps.
Parmi les premiers algorithmes d’apprentissage par renforcement, on compte le TD-learning
(Temporal Difference learning) initié par [Sutton, 1988] et une de ses variantes célèbre : le
Q-learning (Quality learning) proposé par [Watkins and Dayan, 1992]. On pourra se référer à
[Wiering and van Otterlo, 2012] pour un état de l’art sur les différentes méthodes d’apprentissage
par renforcement.
Formellement, la base du modèle d’apprentissage par renforcement consiste en :
1. un ensemble d’états S de l’agent dans l’environnement.
2. un ensemble d’actions A que l’agent peut effectuer.
3. un ensemble de valeurs scalaires "récompenses" R que l’agent peut obtenir.
À chaque pas de temps t, l’agent perçoit son état St et l’ensemble des actions possibles dans
cet état A(st). Il choisit une action qui implique un changement d’état et parfois une récompense.
L’algorithme doit permettre à l’agent de développer une politique Π : S → A qui lui permette
de maximiser le cumul de récompenses R =
P
t
λt
.rt (λt est un facteur compris entre 0 et 1
permettant de prendre en compte les récompenses plus ou moins loin dans le futur pour le choix
des actions de l’agent).
L’apprentissage par renforcement est particulièrement adaptée aux problèmes nécessitant un
compromis entre la quête de récompenses à court terme et celle de récompenses à long terme.
Nous allons nous intéresser maintenant aux mécanismes génériques de compétition qui
seront utilisés tout au long de ces travaux.
1.3 Compétition
Les mécanismes de compétition sont un type de réseaux dont la topologie caractéristique (la
façon dont les neurones sont connectés à leur voisins) permet à chaque neurone de se mesurer
aux autres pour le partage de l’activité neuronale. La compétition est le résultat d’une dynamique
d’inhibition réalisée par le biais de connections latérales inhibitrices. Ces processus naturels
de compétition permettent une prise de décision, à l’instar d’un système de vote. Prendre des
décisions s’avère bien souvent être une caractéristique indispensable pour assurer la survie de
l’animal.
- 29 -1.3. COMPÉTITION
1.3.1 Winner Takes All
L’idée de base du Winner Takes All (WTA) provient des modèles connexionistes [Grossberg,
1976, 1988; Kohonen, 1984; Feldman and Ballard, 1982]. Ils permettent de simuler les mécanismes
de compétition existant au sein d’une population de neurones. Des liaisons inhibitrices
latérales permettent de simuler le processus de compétition. Après convergence, seul le neurone
ayant la plus grande activité reste actif et inhibe tous les autres [Rumelhart and Zipser, 1986;
Lippmann, 1987; Carpenter and Grossberg, 1988; Lee et al., 1999].
Considérons deux neurones i et j possédant chacun une seule entrée et une seule sortie (voir fig.
1.3). Une excitation en entrée activera le neurone concerné qui déchargera à son tour (potentiel
d’activité sur sa sortie). Supposons que les 2 neurones soit connecté entre eux par des connections
inhibitrices, de telle sorte que lorsque i est activé, il tende à inhiber j, et réciproquement.
Une liaison inhibitrice sera représentée par un poids synaptique négatif. Supposons maintenant
FIGURE 1.3 – Principe d’un mécanisme de compétition. A - Réseau minimaliste de compétition entre 2 neurones i
et j. Chaque neurone possède une seule entrée et une seule sortie. Chaque neurone est relié à l’autre par une connexion
inhibitrice (-1). Au temps t1, i et j reçoivent une excitation très similaire (respectivement 0.6 et 0.5). Au fil du temps,
le neurone le plus actif prend le dessus sur l’autre (t2, t3 puis t4). A régime permanent (t4), le réseau est parvenu à
prendre une décision. B - Un réseau de compétition comportant plus de neurones fonctionne selon le même principe :
chaque neurone tente d’inhiber les autres via des connections inhibitrices. Pour une prise de décision plus rapide, les
neurones peuvent s’auto-exciter via une connexion récurrente.
que les 2 neurones soient excités par une activité très similaire (e.g. 0.5 et 0.6), alors au fil du
temps le réseau s’éloignera de cet état instable. L’unité la plus active au départ tendra vers une
activité maximum et la moins active vers une activité minimum. Ce principe peut se généraliser
à un plus grand nombre d’unités. Il suffit que chaque neurone inhibe l’ensemble des autres neu-
- 30 -CHAPITRE 1. OUTILS DU CYBERNÉTICIEN
rones par des connections latérales négatives/inhibitrices. En plus des connections inhibitrices,
chaque neurone peut également s’auto-exciter par le biais d’un lien récurrent, ce qui accélére le
processus de déséquilibre.
La variation du potentiel d’action d’un neurone xi du groupe est définie par :
dxi
dt = αxi − β
X
K
k6=i
xk + Ii (1.5)
Avec K le nombre de neurones du groupe, Ii
l’activité entrante du neurone i, α ∈ 0, 1 le poids
du lien récurrent autoexcitateur du neurone i et β ∈ 0, 1 le poids des liens inhibiteurs provenant
des autres neurones du groupe.
Un réseau possédant ce type de topologie inhibitrice assure qu’un seul et unique neurone possède
tout le potentiel d’activité lorsque le réseau à atteint un régime permanent.
Ce mécanisme très simple permet de faire émerger une fonction de prise de décision en utilisant
un nombre minimum de règles rudimentaires impliquant un équilibre instable, sans besoin de
prescrire une procédure complète.
Le fait de jouer sur la fonction d’activation des neurones permet d’obtenir une compétition plus
ou moins stricte. Plusieurs gagnants peuvent ainsi être conservés ("Soft WTA" ou "k-WTA")
[Maass, 2000].
1.4 Classification
Pour reconnaître, apprendre et agir dans un environnement aussi complexe que celui que
nous connaissons, un des aspects nécessaires est de recourir à des méthodes de classification.
Ces méthodes permettent de capturer les caractéristiques importantes des signaux sensoriels
pour en former des abstractions, c’est à dire des informations de plus haut niveau permettant à
l’animal de généraliser.
La classification est un domaine vaste qui propose des méthodes pour réaliser un partitionnement
de données (data clustering). Elle permet de diviser un ensemble de données en différents ensembles
homogènes, en ce sens que les données de chaque sous-ensemble partagent des caractéristiques
communes, qui correspondent le plus souvent à des critères de proximité que l’on
définit en introduisant des mesures de distances ou de similarités entre objets. La classification
peut être supervisée ou non. Ici nous nous limiterons au cas non-supervisé.
L’algorithme des k-moyennes (k-means) [MacQueen, 1967] est l’une des méthodes d’apprentissage
non-supervisé les plus simples qui illustre bien la façon dont il est possible de classifier
des données. Cette méthode propose de catégoriser un ensemble de données au sein d’un certain
nombre de classes (clusters), dont le nombre est fixé à priori. L’idée maîtresse est de définir k
centroïdes, un par classe. Ces centroïdes sont placés aléatoirement dans l’espace des données
tout en s’assurant qu’ils soient autant que possible loin les uns des autres (voir fig. 1.4). Chacune
des données est associée au centroïde le plus proche. A chaque itération, la position de
chaque centroïde est mise à jour en calculant le barycentre des données qui lui sont associées.
L’opération est répétée jusqu’a atteindre un état de convergence à partir duquel les positions des
centroïdes se sont stabilisées. Le but de l’algorithme est de minimiser la fonction de l’erreur
quadratique J.
- 31 -1.4. CLASSIFICATION
FIGURE 1.4 – Classification par la méthode des k-moyennes (k-means) : illustration du principe pour 5 classes
(k=5). A - A l’initialisation, k=5 classes (points noirs) sont réparties de manière aléatoire dans l’espace des données
(points colorés). 5 catégories (zones colorés) sont créées en associant chaque donnée à la classe la plus proche. Les
partitions représentent un diagramme de Voronoï [Voronoi, 1908]. B, C - A chaque itération, le centroïde de chaque
catégorie devient la nouvelle moyenne de la classe. Cette opération est répétée jusqu’a atteindre convergence. D -
Après convergence, les moyennes de chaque classe ne sont plus modifiées. Le système à atteint une catégorisation
optimale des données.
J =
X
k
j=1
Xn
i=1
||x
(j)
i − cj ||2
(1.6)
Où ||x
(j)
i − cj ||2
est une mesure de distance entre une donnée x
(j)
i
et le centroïde cj . Le
résultat est un partitionnement de l’espace des données en cellule de Voronoï [Voronoi, 1908].
Cet algorithme réalise la discrétisation de l’espace d’entrée en ne modifiant à chaque cycle
d’adaptation qu’un seul vecteur référent. Le processus d’apprentissage est donc très long. L’algorithme
de [Kohonen, 1984] propose une amélioration de la méthode des k-moyennes en tirant
profit des relations de voisinage pour réaliser une discrétisation dans un temps beaucoup plus
court.
Dans nos travaux, certains groupes de neurones seront utilisés en tant que groupe de caté-
gorisation, au sein desquels chaque neurone peut représenter une catégorie. Au départ, les poids
synaptiques sont initialisés avec des valeurs aléatoires permettant l’émergence d’un neurone
gagnant, élu représentant de la première catégorie codant pour l’entrée perçue. Un paramètre de
vigilance permet de définir la granularité des catégories. Lorsque l’entrée change, le groupe peut
être amené à recruter un nouveau neurone (nouvelle catégorie) si l’activité du neurone gagnant
devient inférieure à un paramètre de "vigilance". La modulation du seuil de vigilance par un signal
de neuromodulation permettra de modifier, à la volée, la granulatité des catégories apprises.
Une vigilance faible impliquera une granularité grossière, et réciproquement. L’apprentissage
est là aussi réalisé au sein des poids, dont la modification au fil du temps est définie par :
∆wij = δ
k
j
(aj (t).Ei) (1.7)
avec k l’indice du neurone le plus actif (k = ArgM ax(Cj )), δ
k
j
la fonction de Kronecker 1
1. Le symbole de Kronecker est une fonction à deux variables égale à 1 si celles-ci sont égales, et 0 sinon.
δ
k
i =
1 si i = k
0 sinon. (1.8)
- 32 -CHAPITRE 1. OUTILS DU CYBERNÉTICIEN
utilisée pour ne modifier les poids des liens que vers la catégorie gagnante. aj (t) est une fonction
qui vaut 1 lorsque le neurone j est recruté et 0 sinon. Afin d’éviter un désapprentissage, le
neurone est recruté aléatoirement mais seulement s’il ne code pas déjà pour une catégorie. Au
moment du recrutement, on suppose qu’un mécanisme de compétition permet de mettre à 1 son
activité (et les autres à 0), ce qui permet de ne modifier ensuite que les poids synaptiques des
liens entre la couche d’entrée et le neurone recruté. Les poids des liens entrant du neurone recruté
sont modifiés pour correspondre au motif présent en entrée (voir fig. 1.5). Intuitivement, la forme
d’entrée est imprimée (copiée) dans les poids, ce qui permet au neurone recruté de "se souvenir"
de cette forme ultérieurement. L’activité de ce neurone est ensuite directement dépendante de
la nouvelle entrée qu’il perçoit. Si la forme perçue (en entrée) est identique à la forme apprise
précédemment (dans les poids), alors l’activité du neurone est maximale (Ck = 1) : le neurone
reconnaît la forme. Au contraire, si la forme perçue est complètement différente de celle apprise,
l’activité du neurone est minimale (Cj = 0) : le neurone ne reconnaît en rien cette nouvelle
forme.
A chaque itération, l’activité Cj du neurone j d’un groupe de catégorisation est définie par :
Cj = 1 −
1
N
X
N
i=1
|wij − Ei
| (1.9)
avec N le nombre de neurones du groupe, Ei
l’entrée et wij le poids synaptique du lien entre Ei
et Cj .
1.4.1 Champs de neurones dynamiques
S’inspirant des mêmes principes, beaucoup de recherches se sont consacrées à l’étude d’une
population de neurones (champ de neurones) plutôt qu’à celle du neurone particulier. Le nombre
de neurones présents dans ne serait-ce qu’une petite portion du cortex est immense. Partant
de ce constat, une nouvelle approche est apparue pour étudier des réseaux de neurones au sein
desquels l’espace est considéré comme continu. La topologie est telle que des neurones voisins
partagent des caractéristiques et activités semblables et donc que l’espace neuronal possède une
certaine continuité. Cette notion de continuité peut être approximée par un codage en population,
par opposition au concept de neurone grand mère. Le neurone grand mère est un concept
populaire qui consiste à considérer chaque neurone comme susceptible d’encoder une idée abstraite
à lui tout seul. Selon ce principe, il existerait un neurone précis dans notre cerveau qui
s’active uniquement lorsque nous pensons à notre grand mère. De la même manière, un autre
neurone s’activerait lorsque l’on pense a un objet particulier ou un concept donné. Au vue du
caractère extrêmement distribué et redondant du cerveau, cette théorie est en fait peu plausible
même si elle présente l’intérêt certain d’être intuitive et accessible.
Le codage en population est, quant à lui, un moyen de coder l’information de manière distribuée
justement, au sein d’un groupe de neurones. Dans un tel codage, chaque neurone possède une
portion de l’information, mais l’information complète est uniquement accessible lorsque l’on
considère la réponse combinée d’un grand nombre de ces neurones. Un avantage de ce type
de codage pour la survie d’un animal est son caractère extrêmement redondant. Le réseau peut
alors se permettre la perte de quelques neurones sans que cela n’influe de manière dramatique
sur l’information globale traitée. Dans les chapitres suivants, nous utiliserons l’une ou l’autre de
- 33 -1.4. CLASSIFICATION
FIGURE 1.5 – Principe d’apprentissage et reconnaissance de formes. A - Suite à un signal de neuromodulation, un
neurone est choisi pour coder une nouvelle catégorie. La forme présente en entrée (la lettre A) est apprise en étant
mémorisée dans les poids synaptiques des liens entre la couche d’entrée et le neurone recruté. B - Un nouveau motif
est présent en entrée (la lettre C). De la même façon, la catégorie est apprise par un nouveau neurone dont les poids se
modifient. C - Après apprentissage, chaque neurone de sortie tente de reconnaître sa catégorie dans le nouveau motif
présent en entrée. Ici, le motif présenté est une version dégradée de la lettre A. Le neurone codant pour la catégorie A
est donc plus fortement activé que celui codant pour C.
ces représentations en fonction du problème à traiter.
A priori, la première tentative pour développer une théorie du continuum dans un champ neuronal
peut être attribuée à Beurle en 1956 [Beurle, 1956] qui observe des bulles d’activité dans
un tissu cérébrale. La théorie est reprise plus tard par Griffith [Griffith, 1963], puis par Wilson
et Cowan [Wilson and Cowan, 1973] qui ajoutent les concepts d’inhibitions et excitations du
voisinage ainsi que la notion de récurrence. Finalement, le modèle le plus utilisé actuellement
nous vient d’Amari [Amari, 1977] qui proposa sa théorie des champs de neurones dynamiques
quelques années plus tard. Selon cette théorie, les excitations sont locales tandis que les inhibitions
ne sont que distales. Le noyau d’interaction est un laplacien de gaussienne dont la forme
particulière rappelle celle d’un Chapeau Mexicain.
Le modèle d’Amari
L’intérêt du modèle d’Amari est qu’il possède quelques propriétés intéressantes de filtrage,
de stabilité ainsi qu’un compromis entre compétition et coopération, là ou un réseau de type
WTA reste sensible et seulement compétitif.
Considérons un champ de neurones (une population de neurones liés de proche en proche, formant
une carte de dimension x). Chaque neurone est connecté à ses voisins suivant une rè-
gle définie par le noyau d’interaction. Ce noyau est ici construit à l’aide d’une différence de
- 34 -CHAPITRE 1. OUTILS DU CYBERNÉTICIEN
gaussiennes (DoG), ce qui lui confère cet aspect reconnaissable de chapeau mexicain. Le centre
du noyau est excitateur, tandis que les bords sont inhibiteurs (voir fig. 1.6).
La dynamique du champ est modélisée par l’équation suivante :
FIGURE 1.6 – Principe du codage en population. 1 : Le noyau d’interaction est obtenu à partir d’une différence de
gaussiennes (DoG) centre-ON, donnant un profil en chapeau mexicain excitateur (+) en son centre et inhibiteur (-)
sur ses bords. 2 : Champ de neurones avec interactions latérales correspondantes. Chaque neurone excite ses voisins
proches et inhibe le voisinage lointain. L’information n’est pas encodée dans un unique neurone, mais est distribuée
au sein d’une population, formant ainsi une bulle d’activité.
τ.
u(x, t)
dt = −u(x, t) + I(x, t) + h +
Z
zǫVx
w(z).f(x − z, t)dz (1.10)
Où u(x, t) représente l’activité d’un neurone x au temps t. I(x, t) est l’entrée du système. h est
une constante négative qui assure la stabilité du réseau. τ est le taux de relaxation du système.
w est le noyau d’interaction utilisé pour l’activation du champ. Vx est l’intervalle d’interaction
qui définit le voisinage. Cette équation confère à l’ensemble de la population des propriétés
d’attracteurs qui correspondent à des maxima locaux du champ d’activité. Le réseau réalise
également un compromis entre compétition et coopération qui nous sera utile par la suite. Par
exemple, imaginons que 2 bulles d’activité soient présentes en entrée (voir fig. 1.7). Si les 2
bulles sont suffisamment éloignées, la dynamique du champ tendra à en sélectionner une seule
(mode compétition). Par contre, si les 2 entrées sont suffisamment proches (dépendant de la
largeur du noyau), le champ convergera vers une seule et unique bulle en sortie. Cette bulle
résulte de la moyenne des 2 entrées (mode coopération), et son amplitude est supérieure à celle
des entrées (se référer à [Schöner et al., 1995] pour une démonstration mathématique).
La forme du noyau d’interaction est importante et doit être paramétrée en fonction de la tâche
désirée. La largeur de la bulle d’excitation (partie positive du noyau) peut être modulée par
exemple. Notons qu’un réseau de type "Winner Takes All" est un cas particulier de champ de
neurones pour lequel la bulle d’excitation du noyau est réduite au minimum (1 seul neurone).
Le réseau comprend également des liens récurrents (un pour chaque neurone), qui ne sont pas
illustrés sur les figures. Cette récurrence permet un lissage temporel et donc un filtrage efficace
contre le bruit ou les oscillations présentes en entrée. Par exemple, si une entrée apparaît de
manière épisodique suite au disfonctionnement d’un capteur, la dynamique temporelle du réseau
ne lui laissera pas le temps de s’imposer. Il est nécessaire qu’une entrée reste stable et immobile
- 35 -1.4. CLASSIFICATION
pendant un certain temps pour être considérée comme digne de confiance et ainsi faire émerger
une bulle d’activité en sortie.
FIGURE 1.7 – Compromis sélection/coopération. A - 2 entrées distantes à t0 tentent de s’inhiber l’une l’autre
puisque les bords du noyau d’interaction sont inhibiteurs. Le réseau converge vers une unique bulle d’activité à t1.
Le champ se comporte alors comme un réseau de compétition (WTA). B - 2 entrées proches viennent à fusionner
grâce au centre excitateur du noyau d’interaction. La bulle résultante est une moyenne des bulles d’entrée.
Le contrôle moteur dynamique de Schöner
Les champs de neurones d’Amari ont été utilisés pour résoudre le problème du contrôle moteur,
notamment grâce à la théorie des champs dynamiques (Dynamic Neural Fields - DNF) de
[Schöner et al., 1995]. En conservant les propriétés intéressantes des champs de neurones citées
plus haut, Schöner propose un moyen d’utiliser la continuité des bulles d’activités comme un
gradient que le système peut remonter, en considérant comme sortie motrice la dérivée locale
du champ d’activité. Nous utiliserons cette théorie comme référence pour le contrôle moteur de
nos robots dans la suite de ces travaux, c’est pourquoi il convient d’entrer plus en détails dans la
manière dont nous faisons usage de celle-ci.
Prenons l’exemple d’un robot, à la morphologie minimaliste, constitué d’un corps circulaire et
de 2 roues motrices centrées de part et d’autre de ce corps. Les rotations sur place sont donc
possibles. Le robot est muni de capteurs divers (caméra(s), détecteurs ultra-son, capteurs infrarouge,
etc...) lui permettant de percevoir l’environnement tout autour de lui.
Nous nous intéressons à la manière idéale de représenter les informations provenant de ses capteurs
dans le but de réaliser une tâche de navigation. On partira de l’a priori que le robot est
non-holonome, naviguant dans un espace à 2 dimensions seulement (translation avant-arrière,
rotation gauche-droite). La troisième dimension spatiale sera négligée. Le comportement de
notre robot est donc soumis à 2 variables, qui sont la vitesse linéaire et la vitesse de rotation.
La vitesse linéaire pourra être constante (dans le cas le plus simple), ou bien modulée par la
proximité des obstacles alentours (plus l’obstacle est proche, plus le robot ralentit).
La vitesse de rotation devra être modulée par les motivations du robot. Par motivations nous
entendrons les objectifs internes du robot permettant de contrôler son comportement (drives).
Ceux-ci pourront être, par exemple, un cap à suivre pour rejoindre un but ou bien un obstacle à
éviter. L’utilisation de champs de neurones monodimensionnels semble tout indiquée pour encoder
les différentes motivations dans l’espace pericorporel du robot (voir fig.1.8).
Par soucis de simplicité, considérons un champ de 360 neurones encodant les motivations à va-
- 36 -CHAPITRE 1. OUTILS DU CYBERNÉTICIEN
FIGURE 1.8 – Contrôle moteur utilisant les principes des champs de neurones dynamiques. A - L’espace pericorporel
du robot est représenté par un champ d’attraction (1) et un champ de répulsion (2). Chaque neurone code
pour un angle particulier. La soustraction des 2 donne un champ Φ (3) contenant les valences motivationnelles de
l’agent (attraction pour les bulles positives, répulsion pour les négatives). Une dérivée du champ (4) forme des points
attracteurs et répulseurs. Une activité positive entraîne une rotation à droite tandis qu’une négative entraîne une rotation
à gauche. L’agent converge naturellement vers les attracteurs et diverge des répulseurs. Une lecture de valeur
analogique (5) permet de transformer le champ 4 en ordres moteurs. B - Vue de haut schématique du robot dans son
environnement. Chaque neurone du champ pericorporel code pour un angle particulier. Un but est perçu comme une
bulle positive (rouge) et un obstacle par une bulle négative (bleue).
lence positive (une source de nourriture, un chemin à suivre, une personne avec qui l’agent veut
interagir, etc...). Chacun des neurones de ce champ est le représentant d’une portion angulaire
de 1° autour du robot, de sorte que l’ensemble du champ couvre un panorama à 360 degrés. Une
bulle d’activité dans ce champ représente donc le cap à suivre vers un but, cap que le robot doit
essayer de maintenir.
De la même façon, un second champ similaire (360 neurones) représente les motivations à valence
négative (un obstacle, un danger, une zone interdite, etc...). Une bulle dans ce champ
représente un cap que le robot devra éviter.
Par la soustraction de ces 2 champs, nous obtenons un 3ème champ (que l’on nommera Φ). Ce
champ résume l’ensemble des motivations de l’agent, appétitives et aversives. Les activités de Φ
peuvent être positives (appétitives) comme négatives (aversives). Une simple dérivée du champ
Φ est réalisée au sein d’un 4ème champ. Elle permet de convertir ces potentiels de motivation en
potentiels de rotation, exploitable par le robot pour produire des mouvements. Une valeur négative
déclenchera une rotation à gauche tandis qu’une valeur positive déclenchera une rotation
à droite. La vitesse de rotation est directement proportionnelle à l’amplitude de la motivation.
- 37 -1.5. DISCUSSION
Ainsi la dérivée d’une bulle positive donne un point attracteur (en terme de rotation), et celle
d’une bulle négative donne un répulseur (voir [Cuperlier et al., 2006] pour plus de détails). La
dérivée de Φ est définie telle que :
dΦ
dt = fatt(Φ) + frep(Φ) (1.11)
Force attractive : fatt(Φ) = −λatt.sin(Φ − Φatt) (1.12)
Force répulsive : frep(Φ) = λrep.sin(Φ − Φrep) (1.13)
avec fatt(Φ) (respectivement frep(Φ)) la force de rotation correspondant à une motivation
appétitive (respectivement une motivation aversive). Et λatt (respectivement λrep) un coeffi-
cient d’amplitude associé à l’appétit (respectivement l’aversion). On notera que l’éventualité
d’un équilibre parfait n’est pas impossible. Si l’on imagine un obstacle séparant le robot de son
but dans un alignement parfait, alors les 2 bulles d’attraction et de répulsion s’annihileraient
mutuellement. En pratique, ce cas est peu probable dans un monde réel en raison du bruit résultant
de l’imperfection des capteurs et effecteurs (point d’équilibre instable).
L’intérêt d’adopter un codage par champ de neurones dynamique est triple. Il permet de
bénéficier des propriétés de filtrage et du compromis compétition/coopération. Le contrôle moteur
devient très intuitif et correspond à la dérivée du champ à la position considérée. Enfin, le
DNF prodigue une base au sein de laquelle peuvent être fusionnées les actions de stratégies de
natures très différentes, pourvu que ces actions adoptent le même codage et le même référentiel.
Nous utiliserons par la suite un champ de neurone dynamique de façon similaire pour représenter
l’espace pericorporel du robot et ainsi fusionner de manière efficace les orientations proposées
par différentes stratégies.
Malgré toutes leurs qualités indéniables, les champs de neurones dynamiques possèdent un inconvénient
de taille. Ils possèdent un nombre important de paramètres qui doivent être adaptés
pour chaque nouveau problème.
En d’autres termes, les champs de neurones dynamiques sont difficiles à paramétrer et peu enclins
à s’adapter au changement, mais ils permettent toutefois d’obtenir une solution efficace
pour la fusion/sélection de stratégie, tout en proposant un cadre directement adapté au contrôle
moteur.
1.5 Discussion
Les outils et notions présentés dans ce chapitre ont été abordé(e)s de manière volontairement
didactique pour rendre la lecture de cette thèse accessible au lecteur non-initié. Nous
avons abordé brièvement le fonctionnement du neurone formel, lequel sera l’unité de calcul
élémentaire de ses travaux. Nous avons pu voir que de telles unités sont capables d’apprendre
un stimulus d’entrée par la modification de leurs poids synaptiques. Même si le fonctionnement
physique reste le même, nous avons réalisé une distinction sémantique entre apprentissage par
association et apprentissage par catégorisation. Ainsi, nous parlerons de groupe de catégorisation
pour désigner une population de neurones entraînés à reconnaître des formes à partir de
stimuli présents sur leurs entrées. Nous parlerons également de conditionnement pour désigner
- 38 -CHAPITRE 1. OUTILS DU CYBERNÉTICIEN
un apprentissage de type conditionnement pavlovien.
Au delà de la notion d’apprentissage, nous avons pu voir le fonctionnement d’un codage en
population et son intérêt pour les processus de coopération et compétition dynamiques. Nous
exploiterons un tel codage au sein de champs de neurones dynamiques.
Enfin nous avons présenté les 2 plate-formes robotiques mobiles avec lesquels nous réaliserons
les différentes expériences. La plate-forme d’intérieur sera la plus utilisée.
Tout ces outils seront utilisés abondamment dans ces travaux et constituent donc une base nécessaire
à la compréhension de l’ensemble des chapitres qui vont suivre.
Dans le chapitre suivant, nous tenterons de situer notre approche dans la littérature existante sur
les modèles de navigation robotiques.
- 39 -The ability to navigate in a complex environment is one of the most challenging
skills for every animal on this planet. It is crucial for survival, and is even seen as
the evolutionary pressure to develop brains. The reason why plants do not have a
brain is that they do not have to move.
– Wolpert - Love is a many-moleculed thing.
CHAPITRE 2
Modèles de navigation en robotique
De manière générale, on regroupe sous l’appellation robots mobiles l’ensemble des robots
à base mobile, par opposition aux robots manipulateurs. En pratique, le terme robot mobile
désigne principalement les robots munies de roues. Ceux n’utilisant pas de roue sont généralement
désignés par leur type de locomotion (marcheurs, rampants, aériens ou sous-marins).
Historiquement, les robots mobiles autonomes à roues ont été étudiés dés le début des années
50 [Walter, 1953]. Leur faible complexité en fait de bons sujets pour l’étude des systèmes autonomes.
Cependant, malgré leur simplicité apparente (mécanisme plan, actionneurs linéaires),
ces plate-formes ont soulevé un grand nombre de problèmes difficiles, dont la plupart ne sont
toujours pas résolus. Ainsi, alors que les robots manipulateurs se sont aujourd’hui généralisés
dans l’industrie, rares sont les applications industrielles qui utilisent des robots pour résoudre
des tâches de navigation en totale autonomie. On a vu apparaître, au début des années 2000,
quelques plate-formes mobiles autonomes dans l’industrie (chariot guidés) et destinées au grand
public (aspirateurs autonomes), mais l’industrialisation de systèmes plus complexes dotés de capacités
d’apprentissage bute sur certains problèmes délicats. Contrairement aux robots manipulateurs
dont l’espace de travail est restreint et dont les tâches restent connues et répétitives, les
robots mobiles sont souvent destinés à évoluer de manière autonome dans des environnements
dynamiques, inconnus et peu ou pas structurés (les contrastes et la luminosité peuvent varier
fortement, certains objets sont mobiles et enfin la géométrie du monde physique n’est pas connue
à priori et peut être complexe).
Savoir se localiser et se déplacer de façon cohérente au sein d’un environnement à priori totalement
inconnu fait partie des compétences essentielles pour parvenir à naviguer de manière
autonome. Selon le point de vue "classique" en robotique, le principal défi provient du fait qu’il
soit complexe de construire un modèle interne du monde suffisamment précis pour permettre
au système d’opérer en temps réel de façon cohérente. L’un des problèmes majeurs bien connu
des roboticiens sous le nom de SLAM (Simultaneous Localization and Mapping) [Smith et al.,
1987; Leonard and Durrant-Whyte, 1991] est qu’il semble nécessaire de posséder une carte de
l’environnement afin de pouvoir se localiser alors même que cette carte doit être construite au fur
et à mesure des déplacements. Sans carte, pas d’estimation de position possible. Sans estimation
de position, pas de construction de carte possible. Le paradoxe est similaire à celui de l’oeuf et
de la poule. Nous aurons l’occasion de voir que la construction d’une carte n’est pas l’unique
solution, ni la meilleure, pour résoudre une grande part des problèmes de navigation autonome.
412.1. NAVIGATION NAUTIQUE
Dans ce chapitre nous aurons l’occasion d’appréhender un état de l’art non-exhaustif des
stratégies de navigation existantes. Les premières solutions envisagées pour résoudre ce problème
de manière générale nous viennent de la navigation maritime. Nous ferons donc un bref
parallèle avec ces méthodes historiques et nous noterons que la plupart d’entre elles restent valables
et très utilisées en robotique mobile encore de nos jours. Nous passerons ensuite en revue
les méthodes de navigation dites "classiques" et leur limitation face à des environnements inconnus
et dont les contraintes ne sont pas maîtrisées. Nous verrons comment les animaux sont
parvenus à proposer des solutions simples et robustes en abordant le problème sous un autre angle.
Le maintien d’invariants sensorimoteurs et la navigation topologique sont des méthodes qui
permettent de s’affranchir de manière élégante de problèmes qui semblent difficiles à résoudre
vus sous le prisme des méthodes classiques. Nous nous attarderons finalement sur les modèles
computationnels existants de la navigation animale. Notre démarche fait partie intégrante de
cette approche bio-inspirée de la navigation.
2.1 Navigation nautique
Au 15ème siècle, la carte du monde est encore en grande partie muette 1
. Les navigateurs
se lancent souvent dans l’inconnu tout en souhaitant à la fois reporter d’éventuelles découvertes
sur une carte mais également parvenir à revenir à bon port en fin de voyage. Pour cela, ils devaient
estimer leur position au cours de l’excursion. A l’époque, la navigation astronomique est
encore peu fiable par manque d’instruments précis (une erreur de mesure de seulement 1 degré
induit une différence de position d’environ 100km en Europe). Les navigateurs ont alors eut à
résoudre un problème de localisation et de cartographie simultanée, problème encore d’actualité
en robotique aujourd’hui (SLAM).
Selon Gallistel, la navigation est un processus par lequel on détermine et maintien une trajectoire
vers un but [Gallistel and Gelman, 1990]. Selon Levitt et Lawton [Levitt and Lawton, 1990], ce
processus se décompose en 3 étapes, ou plutôt 3 questions auxquelles répondre : "Où suis-je ?",
"Où se situent les autres lieux vis à vis de moi ?" et "Comment faire pour me rendre dans tel lieu
à partir de ma position ?".
2.1.1 Navigation côtière
Dans le cas le plus simple, le vaisseau navigue en bordure de côte, ce qui lui permet de se
localiser assez précisément grâce aux indices visuels environnants (voir fig. 2.1 - B). La base de
la navigation "observée" est le point par triangulation ou trilatération. Les marins utilisent les
points remarquables invariants de l’environnement pour pouvoir trianguler leur position, après
quoi ils peuvent estimer le cap à suivre vers un but à l’aide d’une carte de cet environnement. Ces
points invariants sont nommés des "amers" et l’angle sous lequel ils sont perçus correspond à
leur "azimut". La méthode d’estimation par triangulation [Haasbroek, 1968] consiste à mesurer
les azimuts de 3 amers. On reporte ensuite l’azimut depuis chacune des positions des amers correspondants.
L’intersection des 3 droites obtenues définie un triangle, plus ou moins grand en
fonction de la précision des relevés. La position du navire est estimée à l’intérieur de ce triangle.
La trilatération est une méthode similaire pour laquelle la position est estimée en fonction de
la distance aux amers en lieu et place de leur azimut. Dans la cadre de la navigation visuelle
1. http ://expositions.bnf.fr/lamer/bornes/feuilletoirs/conquete/32.htm
- 42 -CHAPITRE 2. MODÈLES DE NAVIGATION EN ROBOTIQUE
monoculaire, on préférera souvent une mesure par triangulation, puisque la mesure de l’azimut
est alors plus précise qu’une estimation de distance aux amers (qui ne peut s’estimer visuellement
que par la hauteur apparente des amers lorsque les distances sont importantes).
FIGURE 2.1 – Principe de la navigation maritime. A - Sans repère visuel, la navigation est réalisée à l’estime. La
vitesse et le cap permettent d’estimer sa position, mais cette estimation est soumise au cumul d’erreurs. A chaque
nouvelle mesure, les incertitudes s’accumulent, ce qui limite ce type de navigation à des trajets cours. B - La richesse
des amers visuels aux abords d’une côte permet une localisation précise par triangulation. La mesure de l’azimut
(l’angle) perçu de 3 amers permet de déterminer un triangle virtuel au sein duquel se trouve la position réelle. C -
Au large des côtes, les seuls amers disponibles sont les astres. La connaissance de la position terrestre pour laquelle
un astre donné est au zénith permet de se localiser : le relevé de son azimut permet de définir un cercle de positions
possibles. La mesure de l’azimut de 3 astres permet de déterminer la position exacte par triangulation (à l’intersection
des 3 cercles).
2.1.2 Navigation à l’estime
Lorsque les explorateurs quittèrent la côte pour s’aventurer en pleine mer, la méthode de localisation
par triangulation d’amers devenait impossible par manque d’indices visuels. Ils avaient
alors recours à la méthode de navigation à l’estime (voir fig. 2.1 - A). Celle-ci consiste à déduire
la position du navire à partir de son cap et de la distance parcourue depuis sa dernière position
connue. Le trajet est donc estimé par l’intégrale des vecteurs de mouvements élémentaires au
cours du temps. Ces vecteurs sont déduits, à chaque point de mesure, par la vitesse et le cap du
navire. Le problème inhérent à ce type de méthode récursive est son cumul d’erreurs progressif.
Même si la méthode est très précise localement (sur de petites distances), elle intègre les petites
erreurs de mesure et devient vite problématique. En effet, en plus d’une dérive propre au bateau
et aux courants marins, chaque nouvelle estimation de position introduit une erreur de mesure
du cap due à la précision angulaire ainsi qu’une erreur de mesure de la vitesse. Ces limitations
rendaient la méthode inefficace lors de voyages sur de longues distances. L’amélioration de la
- 43 -2.2. NAVIGATION EN ROBOTIQUE CLASSIQUE
précision des instruments de mesure à permis de ralentir ce cumul d’erreur mais sans repères
externes fixes l’utilisation de la navigation à l’estime restait limitée.
2.1.3 Navigation astronomique
Pour parvenir à se localiser en pleine mer sans accumulation d’erreur, les explorateurs ont
dû prendre en compte les seules informations visuelles disponibles loin des côtes : les étoiles
(voir fig. 2.1 - C). Avec l’invention d’outils de mesure beaucoup plus précis, la navigation
astronomique est devenue exploitable (deuxième moitié du 19ème siècle). Celle-ci consiste à
déterminer sa position à l’aide de l’observation des astres et la mesure de leur azimut (c’est-à-
dire l’angle entre l’astre et l’horizon) [Jean, 1990]. La connaissance de la position terrestre pour
laquelle un astre donné est au zénith permet de se localiser : le relevé de son azimut permet de
définir un cercle représentant l’ensemble des positions terrestres pour lesquels l’astre en question
est perçu sous cet azimut. La mesure de l’azimut de 3 astres distincts permet de déterminer
la position exacte par triangulation. L’intersection des 3 cercles se trouve être la seule position
garantissant les 3 observations. Cette méthode est appelée méthode par interception 2
.
Finalement la méthode de navigation la plus fiable consiste à cumuler navigation à l’estime
et navigation observée. La navigation à l’estime fournie une localisation plus précise mais est
soumise au cumul d’erreurs sur de longue distance. La position devait donc subir une recalibration
périodique par le biais d’une estimation de position sur la base d’indices astronomiques afin
de limiter cette dérive. Nous allons voir que ces principes sont toujours utilisées en robotique
mobile aujourd’hui.
2.2 Navigation en robotique classique
Selon le point de vue de l’approche classique de la navigation robotique, la construction
d’une carte précise de l’environnement est nécessaire pour qu’un agent parvienne à planifier ses
actions et puisse naviguer de manière autonome dans cet environnement. Selon Newman, cette
capacité est considérée comme primordiale pour la durée de vie d’agents mobiles autonomes
[Leonard and Newman, 2003] La cartographie d’un environnement inconnu est généralement
considérée comme l’un des problèmes les plus importants pour atteindre une réelle autonomie
en robotique mobile [Thrun, 2002b; Leonard and Newman, 2003].
Les premiers modèles internes de l’environnement ont été proposé par [Nilsson, 1984] puis
[Moravec and Elfes, 1985] dans les années 80. Le modèle est basé sur une grille représentant
l’espace libre et occupé par les obstacles (occupancy grid). Une méthode alternative basée sur
une représentation métrique à ensuite été proposée par Chatila et Laumond [Chatila and Laumond,
1985]. D’autres approches proposent une cartographie topologique (décrivant les connections
entre lieux) [Kuipers and Byun, 1991; Mataric, 1992]. A partir des années 90, le domaine
est dominé par l’approche probabiliste, dont les travaux de Smith, Self, et Cheeseman [Smith
et al., 1987] introduisent un câdre statistique pour répondre au problème du SLAM (c’est à
dire, parvenir à cartographier l’environnement tout en s’y localisant dans le même temps). Ces
approches probabilistes sont principalement représentées par 2 grandes familles : l’une d’elle
utilise la méthode du filtrage de Kalman [Kalman, 1960], tandis que l’autre se base sur l’algorithme
Expectation Maximization [Dempster et al., 1977] pour réaliser ces estimations.
2. http ://en.wikipedia.org/wiki/Celestial_navigation
- 44 -CHAPITRE 2. MODÈLES DE NAVIGATION EN ROBOTIQUE
Le filtre de Kalman permet d’estimer les états d’un système linéaire dynamique à partir d’une
série de mesures incomplètes ou bruitées. Il est utilisé dans une large gamme de domaines technologiques
(radar, vision électronique, communication ...). Ce filtre fait l’hypothèse que le bruit
est purement gaussien, ce qui est une approximation insuffisante dans de nombreux cas. De
plus, il ne permet de traiter que des problèmes impliquant des dépendances linéaires entre les
différentes variables [Thrun, 2002b]. Une variante, le filtrage de Kalman étendu permet de traiter
les problèmes non-linéaires [Julier and Uhlmann, 2004].
Le filtrage particulaire est une méthode permettant de ne pas se limiter à de telles hypothèses de
bruit gaussien et de linéarité, mais cette technique présente un coût computationnel important
[Gordon et al., 1993]. Cette technique est utilisée pour la localisation de robot mobile par Thrun
et al. [Thrun, 2002a]. De nombreuses variantes de ces méthodes existent, mais leur description
et comparaison est en dehors du champ de cet état de l’art.
Ces méthodes probabilistes tentent de résoudre 5 problèmes majeurs liés à la cartographie autonome
[Thrun, 2002b] : (1) les bruits de mesures ne sont pas statistiquement indépendants.
La nature de ces bruits dépend fortement du contexte. Par exemple, l’utilisation d’une caméra
panoramique non calibrée crée une erreur de localisation des amers dépendante de l’orientation.
S’affranchir d’un bruit non-centré (biaisé) s’avère extrêmement compliqué. De même, pour une
navigation à l’estime, le cumul d’erreurs affecte la manière dont les futures mesures seront interprétées
(voir fig. 2.2 - a). (2) La dimensionnalité de la représentation augmente considérablement
avec la taille de l’environnement et la précision du modèle, ce qui implique une quantité de mé-
moire importante. (3) Le problème le plus dur à résoudre est celui de la correspondance qui
survient lors de la clôture d’une boucle au sein d’une trajectoire (correspondence ou loop closing
problem) [Williams et al., 2009]. La difficulté réside dans le fait de déterminer si plusieurs
mesures, enregistrées à des moments différents, correspondent à la même entité physique dans
l’environnement. Ce phénomène provient de la nature ambiguë de la perception, phénomène
bien connu en psychologie et expliqué par la théorie de la "Gestalt" [Smith, 1988b]. (4) L’aspect
dynamique du monde réel peut rendre inopérant le système si des éléments essentiels à la localisation
viennent à disparaître. Il est alors nécessaire d’effectuer un réapprentissage pour s’adapter
à ces changements. Enfin (5), le système doit pouvoir planifier son chemin au sein d’un environnement
partiellement connu. Les solutions doivent bien souvent faire face à un compromis
entre réactivité et fiabilité. L’utilisation de méthodes statistiques [Thrun, 2002b] permet de s’affranchir
du problème de la navigation en environnement inconnu mais implique de nombreux
passages dans chaque lieu, ce qui reste incompatible avec le besoin d’une grande réactivité au
stade initial.
En restant dans le cadre de l’approche classique de la robotique, les méthodes basées sur
la construction de modèles internes du monde sans a priori sont finalement celles qui donnent
les meilleurs résultats. Assez récemment une telle méthode à permis des performances impressionnantes
de navigation en intérieur sur le long terme (plusieurs semaines) avec changements
environnementaux [Andreasson et al., 2005]. Cependant, le passage à l’échelle à des environnements
plus larges et moins structurés (extérieurs) pose encore de nombreux problèmes tels
que l’explosion de la taille mémoire du modèle interne, l’odométrie non fiables sur terrains accidentés
ou encore le recollement de cartes.
D’autres méthodes plus ad-hocs donnent de bons résultats en réponse à des problèmes spéci-
fiques. Les travaux de Leonard et Newman [Leonard and Newman, 2003] montrent, par exemple,
qu’il est possible de développer un algorithme dont le temps de convergence est constant
- 45 -2.3. NAVIGATION ANIMALE
FIGURE 2.2 – Figure extraite de [Thrun, 2002b]. a - Exemple de trajectoire obtenue à l’aide d’information
odométrique uniquement. La figure montre l’impact du cumul d’erreur sur la trajectoire. De petites erreurs peuvent
avoir un effet important sur de grandes distances. b - Exemple de cartographie d’un environnement intérieur
cyclique. La figure montre le problème de correspondance qui survient lorsque le robot achève une boucle au cours
de sa trajectoire. Parvenir à établir cette correspondance est un des plus importants défis dans le domaine du SLAM.
dans le cas ou le robot est autorisé à faire des visites répétées de toutes les régions de l’environnement.
Steux et Hamzaoui [Steux and Hamzaoui, 2010] sont parvenus à développer un
algorithme léger et très simplifié de SLAM dont le code ne dépasse pas 200 lignes. Cet algorithme
permet au robot d’atteindre une vitesse de 2.5m/s en embarquant l’ensemble des calculs
sur un processeur ARM9. Nguyen et al [Nguyen et al., 2006] propose un modèle également très
léger basé sur l’hypothèse d’un environnement formé de plans orthogonaux (ce qui est souvent
le cas en intérieur) permettant ainsi de simplifier considérablement la complexité des calculs.
Bien que très utilisées dans certains domaines précis, ces méthodes requièrent la plupart du
temps un scanner laser précis et donc très coûteux. De plus, elles sont fortement dépendantes
du modèle a priori du monde. Des travaux récents visent justement à s’adapter aux déplacements
et à l’occlusion d’amers visuels et à se remettre à jour dynamiquement [Lee et al., 2006].
D’autres méthodes donnent de bons résultats dans des environnements fortement dynamiques
comme l’algorithme développé par Foka et Trahanias [Foka and Trahanias, 2010]. L’algorithme
permet à un robot mobile de se localiser et naviguer dans un milieu encombré (une foule d’êtres
humains par exemple). Des approches ensemblistes sont également utilisées pour la robotique
sous-marine [Jaulin, 2009, 2011] pour s’affranchir des conditions données par l’environnement
(Les fonds marins sableux sont des lieux très pauvres en amers et présentant de fortes redondances).
Malgré de nombreux progrès réalisés dans ce domaine, le SLAM présente tout de même des
défis importants. Aujourd’hui, il existe de nombreuses méthodes pour cartographier et se localiser
simultanément dans un environnement si celui-ci est statique, structuré et de taille limitée.
La navigation au sein d’environnements complexes, dynamiques, non-structurés et de grandes
tailles restent encore un problème de recherche largement ouvert [Thrun, 2002b].
2.3 Navigation animale
La plupart des animaux possèdent des capacités à trouver leur chemin sans l’aide d’aucune
carte ou d’instruments particuliers. Les sternes arctiques (espèce d’oiseaux), les papillons
monarques ou encore les saumons migrent régulièrement sur des milliers de kilomètres et parvi-
- 46 -CHAPITRE 2. MODÈLES DE NAVIGATION EN ROBOTIQUE
ennent à trouver leur site de reproduction [Dingle Hugh and Drake, 2007]. Selon Wolpert, la
capacité à naviguer dans un environnement complexe est l’une des compétences les plus diffi-
ciles à réaliser pour les animaux : cette compétence est cruciale pour leur survie et à certainement
été un moteur pour le développement du cerveau au cours de l’évolution [Wolpert, 2002]. Cette
théorie ne vaut cependant que pour certains animaux, comme les mammifères, et pour des tâches
de navigation sophistiquées, comme la reconnaissance de lieux et la planification de trajectoire.
Nous allons voir que la plupart des insectes sont tout à fait capables d’exhiber certains comportements
de navigation simples et robustes sans besoin d’un système nerveux complexe [Srinivasan
and Zhang, 2003; Wystrach et al., 2013].
De nombreux travaux en éthologie se sont intéressés à l’étude des stratégies utilisées dans la
nature pour pouvoir naviguer. Von Frisch a montré que les abeilles peuvent naviguer à l’aide du
soleil, de la polarisation de la lumière ou du champ magnétique terrestre, bien qu’elles préfèrent
s’en référer au soleil lorsque celui-ci est disponible [Von Frisch, 1955]. Keeton a montré que
les pigeons voyageurs pourraient même faire usage d’un éventail d’indices aidants à la navigation,
comprenant le soleil, le champ magnétique terrestre, l’olfaction et la vision [Keeton, 1971].
Lockley a démontré qu’une espèce de petit oiseau marin, le Puffin des Anglais, peut s’orienter et
revenir à son nid très rapidement à condition que le soleil ou les étoiles soient visibles [D. Lack,
1938].
La caractéristique importante à noter ici est qu’une partie des solutions utilisées chez les animaux
ne semblent pas recourir à une carte de l’environnement ni à l’utilisation de connaissances
à priori. Bien souvent, le maintien d’invariants dans les perceptions suffit à faire émerger un
comportement cohérent et robuste. Les animaux semblent prendre des décisions en se basant
sur une mesure de corrélation entre l’information actuelle et l’information mémorisée. Leur
développement semble basé sur des réflexes et conditionnements relativement simples [Piaget,
1936]. De plus, il semble que l’information extraite et mémorisée se limite à l’information utile
pour la tâche. Par exemple, dans le cadre d’une tâche de navigation vers un but, la reconnaissance
d’un objet est codé de telle manière que celui-ci puisse être utile pour rejoindre le but [Gaussier
and Zrehen, 1995]. Ce point de vue, adopté par de nombreuses espèces, permet à l’inverse des
techniques d’intelligence artificielle classiques, de résoudre des tâches complexes avec la seule
aide d’un cerveau minimaliste.
Les insectes sont des exemples intéressants pour illustrer ce principe. Certaines espèces de
fourmis n’utilisent que l’information visuelle directement accessible sur un lieu important afin
d’apprendre à retrouver ce lieu [Wehner and Räber, 1979]. Une expérience permet de montrer
ce phénomène : un bâton décoré de 2 anneaux noirs est placé à la sortie du nid (voir fig. 2.3 - A
et B). La fourmi apprend la position de son nid en mémorisant l’angle sous lequel elle perçoit le
motif du bâton. Lorsque ce dernier est remplacé par un bâton 2 fois plus haut, la fourmi se met à
chercher son nid à la position pour laquelle les motifs du bâton sont perçus sous le même angle
que ceux appris. De la même manière, les guêpes parviennent à retrouver leur nid en apprenant sa
position relative aux amers environnants. Tinbergen a réalisé une expérience qui met en évidence
cette méthode [Tinbergen, 1969]. La guêpe apprend à reconnaître la position de son nid vis à
vis de pommes de pins disposées autour de celui-ci. Elle tourne systématiquement autour de
ces pommes de pins pendant plusieurs secondes avant de s’éloigner. Lorsqu’elle revient, les
pommes de pins ont été volontairement déplacées de quelques mètres du nid. La guêpe tente
alors de retrouver son nid au centre des pommes de pins (voir fig. 2.3 - C et D).
- 47 -2.3. NAVIGATION ANIMALE
FIGURE 2.3 – Figure extraire de [Gaussier and Zrehen, 1995]. A - La fourmi apprend la position de son nid en
mémorisant l’aspect visuel d’un bâton. B - Si le bâton est remplacé par un objet similaire 2 fois plus grand, la fourmi
cherche son nid plus loin et ne parvient pas à le retrouver [Wehner and Räber, 1979]. C - Avant de s’éloigner de son
nid, la guêpe tourne autour de pommes de pins, disposées tout autour du nid, afin d’apprendre la position de celui-ci.
D - Si la position des pommes de pins est déplacée (translation) alors la guêpe ne parvient pas à retrouver son nid
[Tinbergen, 1969].
2.3.1 Intégration de chemin
De nombreux animaux ont la capacité d’évaluer en permanence la distance les séparant de
leur nid ainsi que l’orientation à prendre pour le rejoindre, comme si un mécanisme de mémorisation
du chemin parcouru leur permettait l’accès à tout moment au vecteur de retour au nid
(homing vector) où bien à une position ultérieure [Etienne and Jeffery, 2004]. Pour certains animaux,
ce vecteur permet un retour direct au nid même après plusieurs heures d’exploration de
l’environnement. En 1873, Darwin citait un explorateur de la Sibérie du Nord, Von Wrangell, qui
avait observé que les natifs de cette contrée étaient capables de garder un cap en direction d’un
point particulier sur de longues distances, malgré des changements de direction incessants et la
totale absence de repères célestes ou terrestres [Darwin, 1873]. Le point crucial, relevé par Darwin,
est qu’aucun des repères directionnels lointains, comme les repères célestes, ou les autres
indices purement directionnels comme le champ géomagnétique, ne peut diriger le déplacement
vers un point particulier de l’espace. Ces indices fournissent, au mieux, la direction d’un point
unique de l’espace. La détermination d’une position ne peut résulter que d’un processus d’inté-
gration de chemin : une navigation à l’estime (dead reckoning).
Là encore, la fourmi est un bon exemple pour illustrer un tel processus. Cette dernière quitte
généralement le nid à la recherche de nourriture en ayant principalement recours à une stratégie
d’exploration aléatoire [Müller and Wehner, 1988; Wittlinger et al., 2006; Grah et al., 2005].
- 48 -CHAPITRE 2. MODÈLES DE NAVIGATION EN ROBOTIQUE
Lorsqu’elle tombe sur une source de nourriture, il a été observé qu’au lieu de parcourir la trajectoire
en sens inverse, la fourmi est capable de rejoindre son nid en ligne droite en empruntant
le chemin le plus court. Les fourmis forestières pourraient utiliser des indices visuels ou olfactifs
pour retrouver le chemin du nid. Les fourmis du désert, quant à elles, n’ont pas accès à de
tels indices visuels et les vents puissants empêchent l’utilisation d’indices olfactifs. Ces fourmis
ont recours à un mécanisme d’intégration de chemin basé sur des informations idiothétiques :
elles comptent leurs pas (voir fig. 2.4). La fourmi du désert "cataglyphis fortis" est ainsi capable
de retourner à son nid après une exploration sur plusieurs centaines de mètres [Wehner and
Srinivasan, 1981].
FIGURE 2.4 – Mécanisme d’intégration de chemin chez la fourmi. Figures extraites de [Müller and Wehner, 1988;
Wittlinger et al., 2006; Grah et al., 2005]. A - Trajectoire d’une fourmi s’éloignant de son nid jusqu’à tomber sur une
source de nourriture (F). Malgré une trajectoire complexe et hasardeuse, la fourmi est ensuite capable de retourner à
son nid en ligne droite. B - Lorsque la taille des pattes de la fourmi est modifiée (prolongement ou amputation) après
qu’elle ait trouvé la source de nourriture, cette dernière sur-estime ou sous-estime la distance au nid. C - Illustration
d’une fourmi dont les pattes ont été allongées artificiellement.
Une fois la source de nourriture découverte par la fourmi, les chercheurs procèdent à une
modification de la taille de ses pattes : un allongement artificiel par le biais d’échasses, ou bien
un raccourcissement par amputation. Lors du retour au nid, les fourmis amputées sous-estiment
la distance au nid, tandis que celles dotées d’échasses la sur-estiment.
Les insectes volants comme l’abeille sont également capables d’intégrer leur chemin en utilisant
principalement le flot optique, l’azimut du soleil ou le champ magnétique du ciel [Srinivasan
and Zhang, 2003; Wehner, 1994]. Même si ce mécanisme a été principalement étudié chez les
rats et les insectes, il semble aussi faire partie intégrante de la navigation spatiale chez l’humain
[Maguire et al., 1998]. Les chiens, les hamsters et les humains utilisent principalement leur
proprioception [Seguinot et al., 1998; Loomis et al., 1993]. Le choix de la modalité sensorielle
varie d’une espèce à l’autre et dépend également de la confiance en cette stratégie dans une
situation donnée [Jeffery, 1998] (voir fig. 2.5).
2.3.2 Région hippocampique et cellules de lieu
L’hippocampe est une structure majeure du cerveau des mammifères appartenant au système
limbique (voir fig. 2.6). Il joue un rôle très important dans la navigation spatiale, la mémorisation
à court terme et la consolidation de la mémoire à long terme. Chez l’Homme et le primate, il se
situe dans le lobe temporal médian, sous la surface du cortex avec lequel il est en étroite collaboration.
Il se compose de trois sous-structures : le subiculum, la corne d’Ammon (composée des
- 49 -2.3. NAVIGATION ANIMALE
FIGURE 2.5 – Figure extraite et modifiée de [Etienne and Jeffery, 2004]. Comparaison inter-espèce de l’erreur
d’intégration de chemin au cours d’une expérience de privation d’information allothétique. Les sujets effectuent un
parcours en forme de "L", de (S) à (P) en étant privés de stimuli externes. Une fois en (P), ils tentent de retourner
au point de départ par le chemin qu’ils estiment le plus court. Araignées, hamsters et humains sont privés des sens
visuel, auditif, olfactif et tactil. Fourmis et abeilles sont privées de références comme le soleil. Les chiens sont privés
de vision et d’audition à l’aller mais pas lors du trajet retour. Le trait en pointillés désigne le vecteur de retour réel,
tandis que la flèche représente le vecteur emprunté par le sujet.
aires CA1, CA2 et CA3) et le gyrus denté. Le système limbique, quant à lui, est un groupement
de structures contrôlant les émotions primaires comme la colère, la peur ou le plaisir, la modulation
du comportement et la formation de la mémoire [Broca, 1871].
L’hippocampe ferait office de mémoire à court terme et participerait à la consolidation de souvenirs
récents dans le cortex, siège de la mémoire à long terme. Au cours de cette consolidation,
l’hippocampe se désengage progressivement de la mémorisation et récupération des souvenirs.
Le caractère progressif des amnésies rétrogrades à notamment été observé par Scoville et Milner
[Scoville and Milner, 2000].
Chez le rat, la région hippocampique a été identifiée comme responsable de la mémoire spatiale
[O’Keefe and Dostrovsky, 1971].
FIGURE 2.6 – A - L’hippocampe est situé dans le lobe temporal médian. C’est une structure paire, présente
de manière symétrique dans chaque hémisphère. B - Représentation d’une coupe transversale de la région hippocampique
du rat ainsi que des principales structures et connexions excitatrices les liants. On retrouve notamment
le gyrus denté (DG) et la corne d’Ammon (CA1-3) qui forme l’hippocampe proprement dit. On trouve également la
structure para-hippocampique constituée notamment du cortex enthorinal (EC) et du subiculum (Sub).
De nombreuses cellules situées dans les régions CA1 et CA3 de l’hippocampe présentent des
activités, en terme de fréquence de décharge, correspondant à des positions spatiales précises de
l’animal dans l’environnement [O’Keefe and Dostrovsky, 1971]. Ces neurones sont communé-
- 50 -CHAPITRE 2. MODÈLES DE NAVIGATION EN ROBOTIQUE
ment appelés "cellules de lieux" puisqu’ils répondent pour des endroits précis de l’espace. Leur
activité est caractérisée par une réponse maximale en un point de l’environnement. Cette projection
de la réponse neuronale sur l’environnement est appelée "champ de lieu" de la cellule
[Rédei, 2008]. Le protocole standard d’enregistrement de ces cellules consiste à implanter des
électrodes dans le cerveau d’un rat puis de le placer dans un enclos fermé. La position du rat et la
fréquence moyenne de décharge des cellules de lieu sont enregistrées simultanément, après quoi
il est possible de tracer l’activité d’une cellule donnée superposée à la trajectoire obtenue. Les
champs de lieu se recouvrent entre cellules codant pour des lieux proches. La taille des champs
semble principalement dépendre de la taille de l’enclos. Les activités des cellules apparaissent
quelques minutes après la première entrée du rat dans l’enclos et peuvent parfois mettre plusieurs
semaines pour converger vers une représentation stable [Wilson and McNaughton, 1993]. Après
que les champs aient convergés vers une activité invariante, ils restent stables durant des semaines,
voire des mois [Thompson and Best, 1990].
On sait également que l’hippocampe possède, avec le septum, un rôle important pour la détection
de la nouveauté et la neuromodulation pour permettre l’apprentissage de nouveaux motifs
[Hasselmo and Fehlau, 2001]. L’acétylcholine sécrétée dans le septum permettrait d’inhiber l’activation
de motifs anciens afin de faciliter l’acquisition des nouveaux [Hasselmo and Schnell,
1994].
Dans la suite de ces travaux nous adopterons la représentation de la fig. 2.7-B pour parler
de la réponse (en rouge) d’une cellule unique superposée à la trajectoire (en noir) de l’agent.
D’autres part, nous préférerons la représentation de la fig. 2.7-C pour présenter les zones pour
lesquels différentes cellules impliquées sont gagnantes (une couleur différente pour chaque cellule).
FIGURE 2.7 – A - Figure extraite de [Bird and Burgess, 2008]. champ de lieu d’une cellule hippocampique dans
un environnement bi-dimensionnel. Des électrodes, implantée dans le cerveau d’un rat, permettent d’enregistrer l’activité
des cellules de lieu pendant que celui-ci explore un enclos de 1m2
. L’activité (en rouge) est superposée à la trajectoire
(en noir). B - Figure issue d’internet sous licence libre. Champs de lieu de plusieurs cellules hippocampiques
dans un environnement mono-dimensionnel. Chaque couleur correspond à l’activité d’une cellule de lieu différente.
On observe des recouvrements entre champs de cellules proches.
Bien que les signaux qui permettent d’activer ces cellules soient encore difficiles à caractériser,
il apparaît que leur activité est fortement liée aux indices visuels présents dans le milieu.
La vision joue un rôle primordial dans l’activation des cellules de lieu puisqu’une rotation de
ces points d’intérêt en bordure de l’environnement entraîne une rotation des champs de lieu associés.
De même, les champs sont homothétiques de la taille de l’environnement [Muller and
Kubie, 1987]. Cependant, d’autres modalités peuvent venir compléter le code spatial. De nom-
- 51 -2.3. NAVIGATION ANIMALE
breuses expériences montrent, par exemple, le rôle du système vestibulaire et des mécanismes
d’intégration de chemin [Foster et al., 1989; Kelemen and Fenton, 2010], des informations olfactives
[Zhang and Manahan-Vaughan, 2013], auditives [O’Keefe and Nadel, 1978] et tactiles
[Save et al., 1998] dans la construction de ce code. Des études montrent également que les cellules
de lieu répondent lorsque l’animal est plongé dans le noir complet et ne peut plus utiliser de
repères visuels [Quirk et al., 1990] bien que la précision de la réponse se dégrade au fil du temps.
Ces travaux montrent l’importance de certaines informations idiothétiques dans l’activation des
cellules de lieu.
Certaines études suggèrent que cette intégration d’information multimodale aurait lieu en amont
de l’hippocampe, dans le cortex entorhinal (EC), qui constitue la principale entrée de l’hippocampe
[Gothard et al., 2001]. Une étude montre qu’en cas de conflits entre modalités idiothé-
tique et visuelle, les champs de lieu peuvent devenir instables [Knierim et al., 1998]. Des activités
de cellules de lieu ont également été observées dans d’autres régions cérébrales proches de
l’hippocampe, notamment dans le cortex entorhinal. Ces cellules de lieu ont la particularité d’exhiber
des champs beaucoup plus diffus [Quirk et al., 1992; Sharp, 1999b]. Le gyrus denté (DG)
constitue une voie isolée de communication entre EC et le reste de l’hippocampe. D’autres structures
comme le subiculum, le cortex retrosplénial, le thalamus, le striatum ou encore le cortex
entorhinal jouent également un rôle très important dans la localisation de l’animal puisqu’elles
hébergent des cellules de direction de la tête (head direction cells). Ces cellules codent chacune
pour une certaine orientation de la tête, agissant de ce fait comme une boussole relative [Sargolini
et al., 2006].
Récemment, d’autres cellules particulières ont été découvertes lors d’enregistrement dans le
cortex entorhinal dorso-caudal médian (dMEC). Ces cellules, nommées "cellules de grille" (grid
cells), ont la particularité de présenter des champs de lieu étroits et multiples. Leur réponse est
périodique dans l’environnement, formant ainsi un pavage régulier de l’espace, à l’instar d’une
grille [Hafting et al., 2005]. Les cellules de grille pourraient être à l’origine d’un système de
localisation spatial basé majoritairement sur des informations idiothétiques. Nous reviendrons
plus en détail sur leur fonctionnement dans le chapitre 4.
La découverte des cellules de lieu a stimulé la compréhension du fonctionnement de la navigation
spatiale chez l’animal. Ces cellules constituent alors la première preuve de l’implication
de l’hippocampe dans des tâches de navigation et a réactualisé l’idée de l’utilisation de
"cartes cognitives" [O’Keefe and Nadel, 1978]. La notion de carte cognitive correspondrait à
une représentation interne de l’environnement permettant à l’agent d’inférer son chemin parmi
plusieurs. Elle se base sur l’apprentissage de la topologie existante entre différents états. Ainsi
l’animal pourrait remettre en cause la planification de son chemin lors de l’apparition d’un raccourci
ou encore sélectionner le chemin optimal vers un but particulier. Le concept de carte
cognitive avait déjà été proposée par Tolman 40 ans plus tôt [Tolman and Honzik, 1930].
La navigation vers un but unique n’implique pas nécessairement la construction d’une carte
topologique de l’environnement. Dans ce cas, il peut suffire d’utiliser une stratégie purement
sensori-motrice en associant simplement une action (une direction à suivre) à un lieu. Dans la
suite de mes travaux, nous n’utiliserons pas de carte cognitive mais seulement des associations
entre lieux et actions à réaliser. Ce choix nous permettra, dans un premier temps, de pouvoir
présenter des solutions dans le cas, plus simple, de la navigation sensori-motrice.
- 52 -CHAPITRE 2. MODÈLES DE NAVIGATION EN ROBOTIQUE
2.4 Navigation robotique bio-inspirée
Basée sur les nombreuses études des solutions utilisées chez l’animal pour naviguer, une
approche concurrente de la navigation robotique classique s’est développée en proposant des
modèles inspirés de la biologie. Cette approche a permis l’apparition de robots réactifs, rapides
et capables de comportements simples et robustes. A l’inverse de l’intelligence artificielle
classique, les solutions obtenues sont souvent sous-optimales mais adaptatives et se prêtent particulièrement
bien aux environnements inconnus. Certaines approches bio-inspirées se veulent
également biologiquement plausible et, de ce fait, permettent un enrichissement mutuel des disciplines
de la robotique et des sciences du vivant. Les expériences robotiques permettent de
confirmer ou d’infirmer certaines hypothèses sur les modèles.
A partir des classifications proposés par les ethologues [Gould, 1986], différents modèles
d’architectures de contrôle pour la navigation ont été proposés [Trullier and Meyer, 1997]. [Mallot
and Franz, 2000] proposent de faire une distinction hierarchique entre stratégies locales de
retour au nid (fig. 2.8) et stratégies de recherche de chemin (fig. 2.9). Un classement hiérarchique
existe également au sein de chacune des 2 catégories. Parmi les stratégies locales : l’agent a recours
à une exploration aléatoire en l’absence d’indice sensoriel. Il peut suivre un sentier si
celui-ci existe (dépôt de phéromones ou traces visuelles par exemple). Il peut viser le nid par
remontée de gradient si un indice sensoriel saillant y est présent. Enfin, l’agent peut rejoindre le
nid par l’apprentissage de relations spatiales entre celui-ci et des amers proches, sans codage de
la position du nid lui-même.
FIGURE 2.8 – Hierarchie des stratégies locales de retour au nid (homing) selon Franz et Mallot. Figure extraite de
[Mallot and Franz, 2000]. a - Exploration aléatoire. b - Suivi de piste ou de sentier. c - Visée du nid (nécessite un
indice sensoriel saillant sur le nid). d - Guidage vers le nid par le biais de relations spatiales entre amers environnants.
Parmi les stratégies de recherche de chemin : Si l’environnement est relativement statique,
un chemin peut être appris par une séquence simple d’associations entre états (lieux) et actions
(direction à suivre). Dans le cas d’apparition d’obstacles, des chemins multiples peuvent être
appris par la construction d’une topologie entre lieux proches. L’agent connaît ainsi une autre
route en cas d’échec sur la première (navigation topologique). Enfin, l’exploration des alentours
permet de découvrir des raccourcis (navigation métrique).
2.4.1 Modèles inspirés des insectes
L’une des premières constatations de l’approche bio-inspirée a été de dire que, dans de nombreux
cas, la construction d’une carte précise du monde n’est pas nécessaire pour résoudre la
tâche. Cette constatation est particulièrement vraie dans le cas de l’insecte, dont les ressources
- 53 -2.4. NAVIGATION ROBOTIQUE BIO-INSPIRÉE
FIGURE 2.9 – Hierarchie des stratégies de planification de chemin selon Franz et Mallot. Figure extraite de [Mallot
and Franz, 2000]. a - Chemin simple défini par une séquence d’associations état/action. La stratégie ne s’adapte
pas à l’apparition de nouveaux obstacles (e.g porte fermée). b - Des chemins multiples sont envisageables après la
construction d’une topologie entre états. L’agent peut choisir une autre route en cas d’échec. c - Explorer les alentours
permet à l’agent de découvrir des raccourcis (pointillés) aux travers de lieux inexplorés.
cérébrales sont limitées. Dans de nombreux cas, l’animal n’a pas besoin de maintenir un modèle
interne du monde, le monde lui-même est son meilleur modèle [Brooks, 1991].
Probablement, la première solution bio-inspirée proposée pour la navigation d’un robot mobile
remonte aux années 50 avec le modèle de la "tortue" de Walter [Walter, 1953]. Le robot, doté
de roues, de capteurs photosensibles et de lampes à vide, était capable de remonter un gradient
de lumière, de déclencher un arrêt sur obstacles, de se recharger en totale autonomie et
même de mimer un apprentissage par conditionnement pavlovien (association entre vision et
son) jusqu’alors réservé aux systèmes vivants.
Plus tard, Braitenberg améliora ce principe en montrant comment des véhicules à l’architecture
minimaliste (2 neurones) pouvaient exhiber des comportements complexes [Braitenberg, 1984].
Inspirés de l’abeille, les véhicules étaient capable d’évitement d’obstacles et de phototaxie (suivi
de lumière). Un panel de comportements complexes émergeait de la dynamique de la boucle entre
agent et environnement, et ce, en ne modifiant que le poids des synapses (comportement
peureux, amoureux, agressif, etc...).
Les travaux de Brooks au début des années 90 ont permis l’apparition de contrôleurs réactifs
[Brooks, 1991]. Son architecture de "Subsumption" a permis le contrôle et l’arbitrage en temps
réel d’un ensemble de comportements en parallèle, ce qui restait jusque là impossible avec des
contrôleurs basés sur un modèle du monde.
Franceschini puis Floreano ont travaillé sur des modèles, inspirés de la mouche, capablent de
maintenir le flot optique constant (à partir de la théorie écologique de Gibson [Gibson, 1978]).
Ces modèles permettent à un drone volant d’atterrir en toute sécurité sans besoin d’une estimation
complexe de la distance ou de la géométrie du sol. La vitesse du drône est proportionnelle
à sa distance aux obstacles [Ruffier and Franceschini, 2005; Floreano et al., 2009].
Cartwright et Collet proposent un modèle inspiré des abeilles pour la mémorisation du but
[Cartwright and Collett, 1983]. Le modèle réalise une détection panoramique d’amers (snapshot)
et permet l’estimation de la direction au but en sommant les contributions des déplacements angulaires
de chaque amer. Ce modèle précède les premiers modèles de cellules de lieu. L’association
d’amers est difficile et nécessite de connaître l’orientation de l’agent. Une variante améliorée
et basée sur la couleur à été proposé par Gourichon et al. [Gourichon et al., 2002]. Gaussier et
Zrehen propose un modèle minimaliste, inspiré des insectes, supposant que ces derniers peuvent
reconnaître individuellement les amers pour accéder à leur azimut. Ce modèle permet un
- 54 -CHAPITRE 2. MODÈLES DE NAVIGATION EN ROBOTIQUE
retour au nid par l’apprentissage des relations spatiales entre les amers environnants et le lieu
but [Gaussier and Zrehen, 1995].
2.4.2 Modèles inspirés des mammifères
L’implémentation d’algorithmes copiant le comportement des insectes a donné de très bons
résultats mais le passage à des mécanismes cognitifs plus complexes tels que ceux utilisés par
les mammifères reste encore un challenge dans les systèmes actuels. Le début des années 1990
à vu naître les premiers modèles computationnels de cellules de lieu hippocampiques. En 1994,
Burgess propose un premier modèle basé sur la hauteur apparente de 2 amers visuels (les murs
de l’enceinte) [Burgess et al., 1994]. Dans le même temps, Gaussier et Zrehen aboutissent à l’architecture
PerAc qui servira de base à nos travaux (l’architecture est présentée en détails dans
la section 2.5) [Gaussier and Zrehen, 1995].
Quelques années plus tard, Redish et Touretzky proposent un modèle théorique des processus
de navigation à l’oeuvre dans la région hippocampique [Redish and Touretzky, 1997]. Dans
ce modèle, le code spatial des cellules de lieu est créé à partir d’informations visuelles (vues
locales) et d’informations idiothétiques par le biais du subiculum (intégration de chemin). La
sélection de l’action serait réalisée en partie par les ganglions de la base (nucleus accumbens) à
partir d’informations spatiales fournies par l’hippocampe.
Arléo et al. propose ensuite un modèle de l’hippocampe basé sur des cellules de lieu et de
direction de la tête combinant des informations allothétiques (visuelles) et idiothétiques (proprioceptives)
[Arleo and Gerstner, 2000; Arleo and Rondi-Reig, 2007] Le système visuel projette
dans le cortex entorhinal superficiel, tandis que le système idiothétique (intégration de chemin)
projette dans EC profond. L’apprentissage non supervisé de cellules de lieu est réalisé dans les
couches superficielles de EC par une règle de Hebb. Le processus d’intégration de chemin est
modélisé par des cellules dont l’activité est une fonction gaussienne de la position et de la direction
du robot et fait abstraction de la plausibilité biologique. Finalement le recrutement de
cellules de lieu multimodales est réalisé de manière autonome à partir d’un seuil de reconnaissance.
L’environnement des expériences est réel mais contrôlé et très simplifié : les murs sont
striés afin de faciliter la détection de fréquences (amers artificiels) pour la reconnaissance des
cellules de vue. Le pavage automatique génère quelques 800 cellules de lieu pour un petit environnement
(80x80cm). Les cellules de lieu obtenues servent de base pour un apprentissage par
renforcement de l’environnement, mais cette méthode requiert un temps trop important pour des
environnements de grandes tailles.
D’autres travaux se basent également sur des modèles de cellules de lieu pour étudier des solutions
intéressantes de sélection de l’action mais se contentent d’une modélisation en simulation
[Foster et al., 2000; Dollé et al., 2008]. De plus, l’activité des cellules est une fonction gaussienne
de la position connue du robot.
Assez récemment, Milford et Wyeth ont proposé un modèle bio-inspiré, nommé "RatSLAM",
pour la cartographie d’un environnement de très grande taille [Milford and Wyeth, 2008]. Le
modèle s’inspire de la structure hippocampique du rat et permet à un véhicule mobile de construire
en temps réel une carte d’une taille conséquente à partir d’une simple webcam (un quartier
urbain complet pour un trajet de 66 km et la catégorisation de 12000 lieux). Une recalibration
de la position est effectuée lorsque le système reconnaît visuellement un lieu et un mécanisme
de maintien de cohérence permet de corriger la carte à partir de l’odométrie et d’une compéti-
- 55 -2.5. PER-AC : UN MODÈLE DE COUPLAGE SENSORI-MOTEUR POUR LA PERCEPTION
tion entre de nombreuses poses caméra. Néanmoins, le système est testé en passif d’une part et
se veut également "biologiquement inspiré" sans pour autant présenter une grande plausibilité
biologique.
La navigation au travers de grands environnements intéresse également Cummins et Newman
[Newman and Cummins, 2008] qui utilise une méthode dite d’"apparence seule". Le système
assigne à chaque nouveau panorama un lieu rencontré précédemment, ou bien un nouveau lieu
si la différence constatée est trop importante. Cette méthode ne nécessite aucune estimation de la
position métrique du robot et a permis de naviguer sur plus de 1000 kilomètres en milieu urbain.
2.5 Per-Ac : un modèle de couplage sensori-moteur pour la perception
Dans de précédents travaux datant du début des années 90, Gaussier et Zrehen ont développé
un modèle générique de couplage permettant à un robot d’apprendre des conditionnements entre
informations sensorielles (la reconnaissance d’un lieu spatial, d’une position particulière d’un
membre, d’une expression faciale, etc...) et action (une direction à suivre, une configuration
motrice) [Gaussier and Zrehen, 1995] (voir fig. 2.10). L’élégance du modèle est de proposer
une architecture générique de bas niveau et qui ne requiert aucune représentation symbolique
du but. Pour la navigation spatiale, l’équipe Neurocybernetique du laboratoire ETIS a proposé
un modèle de l’hippocampe et des boucles corticales permettant de contrôler un robot mobile
lors de tâche de navigation visuelle [Gaussier et al., 2002; Giovannangeli and Gaussier, 2010;
Banquet et al., 2005] et proprioceptive [Gaussier et al., 2007].
FIGURE 2.10 – Per-Ac : Une architecture générique de couplage entre Sensation et Action. Une voie inconditionnelle
(en bas) déclenche des actions de manière réflexe. Une autre voie non-réflexe (en haut) apprend à reconnaître
une situation sensorielle par le bais d’une compétition (WTA), puis à associer cette situation à l’action déclenchée
par la voie réflexe. Une fois l’apprentissage terminé, la reconnaissance de la situation déclenchera l’action correspondante,
même lorsque la voie réflexe est inactive.
2.5.1 Modèle de cellules de lieu visuelles
Une image panoramique est analysée séquentiellement pour en extraire un ensemble de
points d’intérêt qu’une cellule de lieu sera amenée à reconnaître.
- 56 -CHAPITRE 2. MODÈLES DE NAVIGATION EN ROBOTIQUE
La caméra monoculaire embarquée, montée sur servomoteur pan-tilt, permet la capture de 15
images successives, correspondant à un panorama à 360 degrés 3
. Le système réalise ensuite un
traitement d’images qui consiste en (1) le calcul de l’image du gradient (faisant apparaître les
contours des objets à fort contraste dans la scène), puis (2) une convolution avec un filtre DoG
(différence de gaussienne) qui permet de faire ressortir les points de forte courbure des contours.
Ces points de courbure sont intéressants puisqu’ils sont robustes et invariants aux changements
d’échelle. Ils correspondent la plupart du temps à des coins d’objets ou des éléments saillants
anguleux (e.g. les 4 coins d’un tableaux sombre sur fond clair constituent des points d’intérêt
robustes). Ces traitements permettent, à partir d’images brutes, de mettre en évidence une constellation
de points d’intérêt dans le panorama. Afin de reconnaître ces points particuliers, le
système apprend de petites imagettes circulaires centrées sur chacun d’eux. Une transformation
log-polaire est réalisée sur chaque imagette afin de rendre la reconnaissance plus robuste aux
petites rotations et aux changements d’échelle. Chaque imagette (32*32 pixels) est apprise par
un neurone codant pour un amer (landmark). Autrement dit, une "cellule d’amer" apprend à
reconnaître une imagette particulière. L’activité d’une cellule d’amer dépend de la différence
entre l’imagette perçue et l’imagette apprise par cette même cellule.
De la même façon, une "cellule de lieu" (place cell) apprend à reconnaître une constellation
d’amers associés à leurs azimuts (voir fig. 2.11). L’activité d’une cellule de lieu dépend de
la différence entre la constellation amers/azimuts perçue et celle apprise par la cellule. Selon
ce modèle, un lieu dans l’environnement est donc représenté par un agencement particulier
d’imagettes dans le panorama. Chaque cellule est capable de reconnaître un lieu particulier de
manière robuste. Cette robustesse provient en partie du grand nombre d’imagettes extraites (75
par panorama), ce qui permet de reconnaître un lieu même lorsque des objets ont été déplacés ou
bien qu’une partie du panorama est occultée. La robustesse provient également de l’utilisation
d’un mécanisme de compétition (WTA) qui sélectionne la cellule de lieu la plus active au temps
t, c’est à dire le lieu le mieux reconnu. De cette manière, la reconnaissance d’un lieu ne dépend
pas d’un niveau absolu de reconnaissance, mais bien d’un niveau relatif entre l’activation des différents
lieux. Dans ce modèle, les imagettes locales extraites correspondraient à l’information
"What" (Quoi) codée dans le cortex perirhinal ou dans d’autres aires du chemin visuel ventral
du cortex temporal du rat [Kolb and Tees., 1990]. Les angles sous lesquels sont vu les amers
correspondraient à l’information "Where" (Où), fournie par le cortex parietal par le biais de la
région parahippocampique. La fusion des informations "What" et "Where" serait réalisée dans
la couche superficielle du cortex entorhinal ou dans le cortex postrhinal [Suzuki et al., 1997;
Burwell and Hafeman, 2003]. Dans ce modèle, cette fusion est réalisée par un réseau nommé
PrPh (Perirhinal & Parahippocampique). Un neurone du groupe PrPh ne s’active que lorsqu’un
amer est reconnu sous un azimut particulier appris pour cet amer. L’azimut absolu est obtenu
par la somme entre la position relative de l’amer dans l’image, l’angle relatif de la caméra (tête)
et la direction absolue du robot. Le système de cellules de direction de la tête fourni des informations
sur l’orientation du robot. Ce système est alimenté par des données provenant d’une
boussole magnétique, mais peut se baser uniquement sur une boussole visuelle [Leprêtre et al.,
2000; Giovannangeli and Gaussier, 2007] et être complété par des informations proprioceptives.
Un système de recrutement permet d’encoder de nouveaux amers si ceux-ci n’avaient jamais
été appris. L’activité de cette population de neurones permet donc d’identifier un amer perçu.
3. Le modèle n’a pas besoin de réaliser un panorama complet et peut se contenter de mettre à jour une mémoire
dynamique. Il fonctionne également si le robot se déplace pendant la prise de panorama
- 57 -2.5. PER-AC : UN MODÈLE DE COUPLAGE SENSORI-MOTEUR POUR LA PERCEPTION
...
...
...
...
...
...
...
...
...
...
Azimuths
PC WTA
...
Action
Orientation
...
...
...
...
...
...
...
...
...
...
landmarks
azimuth
landmarks PCv
*
azimuth
PCmultimodal
Context
Joystick
...
...
path integration
PCg
Grid Cells
...
Action
orientation
...
...
...
Gradient extraction DOG convolution
Focus Points
Landmarks
One to All modifiable connections
One to one connections
...
...
...
...
...
...
...
...
...
...
amers
azimuths
PC WTA
...
Action
orientation
...
Grayscale image Gradient extraction DOG convolution Focus Points
Local Views (log polar)
One to All modifiable
connections
One to one connections
-180 +180
Grayscale image
-180 +180
FIGURE 2.11 – Modèle de cellules de lieu : architecture Per-Ac pour la navigation visuelle. A chaque instant, la
caméra du robot prend un panorama visuel de l’environnement à 360 degrés. L’image du gradient de ce panorama
est convoluée avec un filtre par différence de gaussiènne (DoG) pour en extraire une constellation de points saillants.
Le système apprend ensuite des imagettes locales centrées sur les points plus saillants. Ces imagettes sont apprises
par des cellules d’amer (landmarks). Un réseau PrPh fusionne les amers et leur azimuts respectifs. Chaque cellule de
lieu (PC) apprend ensuite à reconnaître une constellation amers-azimuts particulière. Un mécanisme de compétition
(WTA ou softWTA) sélectionne la (ou les) cellule(s) de lieu la (les) plus active(s) au temps t. Enfin, une association
est apprise entre la cellule de lieu gagnante et l’orientation actuelle du robot, après quoi le robot s’orientera dans la
direction apprise lorsque la cellule correspondante est de nouveau gagnante.
L’équation pour l’apprentissage des amers en fonction des imagettes locales est la suivante :
dWV A
ij (t)
dt = R
A
i
(t).XV
j
(t) (2.1)
Où WV A
ij représente le poids synaptique entre un neurone de vue locale j et un neurone
d’amers i. RA
i
(t) est un signal de type échelon binaire permettant le recrutement d’un neurone
lorsque l’activité du gagnant de la population de neurones passe en dessous du seuil de vigilance
ν
A. XV
est l’activité d’une cellule ayant appris à reconnaître un amer (vue locale), après transformation
log-polaire (un neurone par pixel).
L’équation pour le calcul de l’activité XA
i
d’un neurone i recruté correspondant à un amer visuel
est la suivante :
XA
i
(t) = 1 −
P
j
|WV A
ij (t) − XV
j
(t)|.Hǫ(WV A
ij (t))
P
j Hǫ(WV A
ij (t)) (2.2)
avec Hǫ la fonction de Heavyside telle que Hǫ(x) =
0 si x < ǫ
1 si x ≥ ǫ
L’activité XA
i
(t) d’un neurone non recruté est aléatoire (sa valeur est comprise entre 0 et B, B
représentant le niveau de bruit neuronal maximal). La fonction Hǫ permet de détecter les poids
ayant appris (ǫ est une valeur positive, proche de 0).
L’apprentissage du groupe PrPh est contrôlé par les équations suivantes :
dWφP
ij (t)
dt = R
P
i
(t) · Hγ(X
φ
j
(t)) (2.3)
dWAP
ij (t)
dt = R
P
i
(t) · Hγ(XA
j
(t)) (2.4)
RP
i
(t) est un signal de recrutement de type échelon binaire, déclenché lorsque l’activité du
gagnant de la population de neurones passe sous un seuil de vigilance ν
P . La fonction Hγ
- 58 -CHAPITRE 2. MODÈLES DE NAVIGATION EN ROBOTIQUE
FIGURE 2.12 – Activité de 4 cellules de lieu enregistrées sur une trajectoire rectiligne de 25m en environnement
extérieur. Les 4 maxima correspondent aux endroits précis où les lieux ont été appris. Les points de croisement
correspondent aux frontières entre lieux gagnants. Le modèle montre de bonnes capacités de généralisation puisque
le champ de lieu d’une cellule (champ pour lequel l’activité de la cellule est au dessus du bruit) est plus large que la
zone pour laquelle cette cellule est gagnante. La cellule n°5 correspond à un lieu appris en dehors de l’enregistrement
présenté. La cellule n°6 n’a pas été recrutée et son activité est donc nulle.
détecte les neurones fortement activés en entrée du PrPh (γ étant proche de 1).
L’équation pour le calcul de l’activité XP
i
du neurone i du groupe PrPh est la suivante :
XP
i
(t) = max(λi(t) · XP
i
(t − dt), f(max
j
W
φP
ij · X
φ
i
· max
k
WAP
ik · XA
k − θ)) (2.5)
avec f une fonction de seuil telle que f(x) =
0 si x < 0
x si 0 ≤ x < 1
1 si x ≥ 1
θ est le seuil d’activation des neurones du PrPh. XA représente l’activité de l’amer reconnu et
Xφ
l’azimut sous lequel il est perçu. Un seul amer est traité à chaque itération ce qui implique
que le PrPh fonctionne comme une mémoire à court terme, dont le facteur d’oubli est λi(t). Il
permet de conserver en mémoire les amers perçus pendant les prises de vue d’un panorama. La
mémoire d’un amer est remise à jour par une meilleure reconnaissance et également après un
temps défini arbitrairement (après un ou plusieurs panoramas) [Giovannangeli, 2007].
- 59 -2.5. PER-AC : UN MODÈLE DE COUPLAGE SENSORI-MOTEUR POUR LA PERCEPTION
L’activité des cellules de lieu, même en condition extérieure, montre un pic d’activité sur le
lieu appris et généralise assez bien sur de grandes distances (2 à 3m en intérieur et 20 à 30m en
extérieur) (voir fig. 2.12). Ces profils d’activité large ne correspondent pas aux enregistrements
hippocampiques (CA1 et CA3) mais plutôt aux profils de cellules enregistrées dans le subiculum
ou le cortex entorhinal [Quirk et al., 1992; Sharp, 1999b].
FIGURE 2.13 – Principe de l’apprentissage de comportements simples à base de quelques associations Lieu/Action.
Une action est associée à la cellule de lieu gagnante. Chaque lieu est ainsi associé à une direction à suivre (flèche
rouge). Chaque fois que le robot se trouve dans un lieu, il se tourne automatiquement dans la direction apprise dans
ce même lieu. Ce mécanisme permet au robot d’apprendre des comportements de type ronde (a), ou encore de type
retour au nid (homing)(b) à partir de quelques associations Lieu/Action seulement. L’idée maîtresse ici est que la
trajectoire n’est pas prescrite mais émerge de la dynamique sensorimotrice en créant des bassins d’attractions (c). A
titre d’exemple, le comportement appris en (b) permet au robot de converger vers un lieu but au centre. Pourtant ce
lieu n’est pas codé dans la mémoire du robot, mais émerge naturellement comme le fond du bassin d’attraction généré
par la dynamique de reconnaissance des lieux A, B, C et D. Dans un monde réel bruité, ce type d’apprentissage est
plus robuste qu’une simple remontée de gradient et permet au robot de converger vers le but en "tombant" dans un
bassin d’attraction.
Chaque cellule de lieu peut ensuite être associée à une action particulière (une orientation à
suivre dans notre cas) et peut servir de base à des stratégies sensori-motrices simples. Dans le
cadre de l’apprentissage d’une tâche de navigation supervisée, l’humain peut donner la direction
à suivre comme signal désiré. Le robot apprendra alors à associer l’état courant (la cellule de
lieu gagnante) à la direction désirée. On parlera d’association Lieu/Action. A partir de 3 cellules
(ou plus) dont les actions associées pointent vers un but virtuel, il est possible de construire
un bassin d’attraction autour de ce but (fig. 2.13-b). La dynamique de reconnaissance des lieux
permet au robot de converger naturellement vers le but, sans que celui-ci ne soit explicitement
codé [Gaussier and Zrehen, 1995; Gaussier et al., 2000]. Cette stratégie permet également l’apprentissage
de ronde (voir fig.2.13-a) [Giovannangeli and Gaussier, 2010]. Ce sont ces rondes
sensori-motrices que l’on étudiera abondamment dans la suite de ces travaux.
Cette stratégie d’association Lieu/Action se limite cependant à un environnement simple dans
- 60 -CHAPITRE 2. MODÈLES DE NAVIGATION EN ROBOTIQUE
lequel un choix entre plusieurs chemins possibles n’est pas nécessaire. Si plusieurs chemins
sont possibles, ou que de nouveaux obstacles induisent des minima locaux, on peut avoir recours
à une stratégie de planification basée sur la construction d’une carte cognitive [Gaussier
et al., 1997]. Atteindre plusieurs buts reste cependant possible avec une stratégie sensorimotrice
simple si un bassin d’attraction différent est créé pour chaque but [Gaussier et al., 2000].
2.5.2 Modèle d’intégration de chemin
Outre ce modèle de cellules de lieu permettant une stratégie de navigation visuelle, l’équipe
a également développé un modèle d’intégration de chemin à partir d’informations idiothétiques
[Gaussier et al., 2007] basé sur les travaux de [Mittelstaedt, 2000]. Une telle stratégie se révèle
essentielle dans certaines conditions de privation sensorielle (lorsque l’agent est plongé dans le
noir par exemple) et peut être mise en place sur une plate-forme robotique possédant des capteurs
odométriques. La stratégie se base sur 2 informations codant pour un mouvement élémentaire
du système : la vitesse linéaire ainsi que la vitesse de rotation instantanée (voir fig. 2.14). Les
mouvements élémentaires du robot définissent à chaque itération des vecteurs unitaires dans un
champ d’entrée Vi
. Un champ de sortie Di somme simplement l’activité de Vi au cours du temps.
Dans ce modèle, les champs Vi et Di sont des champs neuronaux simplifiés (sans interactions
latérales) et supposés de même taille (121 neurones). Chaque neurone code pour une portion
angulaire du panorama total à 360° (codage en population). Un nombre impair de neurones est
préférable pour des raisons de symétrie, et le nombre de neurones utilisés est un multiple de
360. Par la suite, nous parlerons de champ d’intégration de chemin pour désigner le champ de
sortie Di
.
Un masque sinusoïdal non-négatif 4
est convolué autour de la direction de chaque mouvement
élémentaire dans le champ de neurone d’entrée Vi
:
Vi(t) = 1 + cos(Θ(t)) − θi) (2.6)
Avec θi = −2π
i
N
FIGURE 2.14 – Modèle neuronal utilisé dans notre architecture pour le calcul de l’intégration de chemin. Un
champ neuronal avec liens récurrents représente une mémoire du chemin parcouru. Le champ intègre les mouvement
élémentaires du robot à chaque itération. L’index du neurone le plus actif représente l’orientation du vecteur de
mouvement global et son amplitude, la distance globale parcourue. Les mouvements élémentaires sont représentés
au sein d’un vecteur de neurones alimenté par l’orientation absolue du robot et sa vitesse linéaire instantanée.
Le champ de sortie Di réalise simplement une intégration temporelle de l’activité du champ
d’entrée Vi
. L’amplitude d’un mouvement élémentaire est modulée par la vitesse linéaire du
4. Une fonction gaussienne ou triangulaire peuvent en pratique faire l’affaire mais la démonstration implique
l’usage du cosinus
- 61 -2.5. PER-AC : UN MODÈLE DE COUPLAGE SENSORI-MOTEUR POUR LA PERCEPTION
robot. L’orientation du robot au temps t sera noté Θ(t). L’activité du champ d’intégration de
chemin est définit telle que :
Di(t) = [Di(t − dt) + αVi(Θ(t)) − r(t)]+ (2.7)
Avec r(t) un signal de remise à zéro de type échelon binaire, utilisé pour la recalibration du
champ d’intégration de chemin. [x]
+ = x si x > 0 et 0 sinon. α représente le gain du système
permettant d’empêcher la saturation du champ (0 < α < 1).
Sans connections latérales, chaque neurone Di réalise simplement la somme de toutes ses activités
passées depuis la dernière remise à zéro. Le champ D encode le chemin total parcouru
depuis le point de départ et conserve une forme sinusoïdale (voir fig. 2.15). L’amplitude du
neurone gagnant reflète la distance parcouru en ligne droite (à vol d’oiseaux) et son abscisse
représente la direction du mouvement global (voir [Gaussier et al., 2007] pour une description
complète).
FIGURE 2.15 – Principe de l’intégration de chemin. A - Les animaux ont cette capacité d’évaluer la distance les
séparant de leur nid ainsi que l’orientation à prendre pour le rejoindre (homing vector), et ce simplement en intégrant
leurs mouvements au fil de leur déplacement. B - De la même manière, un robot peut estimer en temps-réel son
vecteur-retour en cumulant angle et norme de chacun de ses vecteurs mouvements élémentaires. C - Dans notre
modèle, ces vecteurs sont représentés par des sinusoïdes dont l’amplitude correspond à la distance et la phase à
l’orientation. On montre que la résultante de la somme de ces sinusoïdes n’est autre qu’une sinusoïde correspondant
au vecteur-mouvement global.
Cette stratégie se trouve être plus précise localement en comparaison d’une stratégie basée
sur des informations allothétiques (externes) telle que la navigation visuelle. Néanmoins l’intégration
de chemin possède l’inconvénient d’introduire une erreur cumulative d’autant plus
grande que l’on navigue depuis longtemps. Par la suite, il sera nécessaire de recourir à un mé-
canisme de recalibration pour limiter cette dérive. Nous reviendrons sur ce mécanisme de recalibration
dans le chapitre 4.
Dans le chapitre suivant, nous allons nous intéresser à l’analyse du modèle de navigation
sensori-moteur PerAc en adoptant un point de vue probabiliste. Nous verrons les liens existants
entre ce modèle réactif et d’autres modèles statistiques de reconnaissance de lieu, basés sur une
approche bayésienne.
- 62 -CHAPITRE 3
Un parallèle entre formalisme neuronal et
bayésien
La navigation robotique autonome en environnement réel repose sur des mesures bruitées.
C’est la raison pour laquelle la plupart des travaux robotique de localisation, de cartographie
ou encore de planification sont basés sur des algorithmes probabilistes. La nature statistique de
ces méthodes permet de prendre en compte les incertitudes présentes sur les données mesurées
au détriment d’une faible réactivité. Pourtant, la nature nous montre que la plupart des animaux
sont tout à fait capables d’extraire l’information utile à partir de signaux bruités, tout en conservant
cet aspect réactif. Les approches neuromimétiques peuvent donc nous fournir des solutions
robustes et innovantes pour aborder ce genre de problème. Par ailleurs, de récents travaux ont dé-
montré que le cerveau était capable de réaliser des calculs très similaires aux processus bayésiens
[Deneve S, 2004]. De même qu’il est connu depuis longtemps que l’apprentissage d’un conditionnement
classique est équivalent au calcul d’une probabilité conditionnelle [Rescorla, 1988].
Les approches bayésiennes et neuromimétiques tendent donc à se rapprocher.
Nous proposons, dans ce chapitre, de comparer ces 2 approches dans le cadre de l’auto-évaluation
et de la navigation sur de grandes distances. En prenant inspiration de travaux en psychologie et
neurobiologie, nous avons d’ores et déjà proposé des solutions pour permettre à un robot de naviguer
dans de petits environnements (typiquement 1 salle) et pour de courtes durées (quelques
heures) : se référer à la section 2.5 du chapitre précédent. Cependant, plusieurs questions restent
ouvertes si l’on désire réaliser le même type de tâches dans des environnements fortement dynamiques
et sur de longues périodes temporelles. Les systèmes de navigation robotique autonomes
font face à des problèmes d’imprécisions des mesures liées au capteurs et d’incertitudes
liées à la contrainte d’un environnement dynamique. L’exploration et la navigation sur
le long terme sont des tâches assez ardues. Le changement d’échelle dans la taille de l’environnement
implique un apprentissage et une gestion d’un volume de données conséquent qui
ouvre certaines interrogations. Comment outrepasser le problème du rapport signal à bruit qui
tend à décroître avec le volume d’information ? Comment lever l’ambiguïté présente sur les informations
visuelles et réduire l’incertitude de la localisation ? Les systèmes robotiques visant
un comportement autonome doivent faire face à 2 principaux défis. Premièrement, le système
doit être capable d’extraire et apprendre de manière active l’information pertinente en ignorant
celle inutile à la tâche. Deuxièmement, le système doit être capable d’évaluer la qualité de son
comportement et l’adapter en fonction de la situation.
- 63 -3.1. LIMITATIONS DU MODÈLE ACTUEL
Dans ce chapitre nous nous intéressons au premier point en proposant une réflexion et des solutions
au problème de l’extraction de l’information pertinente pour la tâche. On notera qu’une
telle capacité à sélectionner l’information pertinente implique en elle même une certaine capacité
d’évaluation.
Nous commencerons par décrire les limitations du modèle d’apprentissage figé précédent. Adopter
une approche probabiliste permet de réduire l’ambiguïté inhérente à toute perception visuelle en
donnant au système une capacité à inférer sa position par l’apprentissage de la pertinence des
amers dans un lieu donné. Nous ferons un rapide tour des méthodes existantes dans la littérature
traitant ce type de problème avant d’analyser notre propre modèle de cellules de lieu hippocampiques
sous le prisme de l’approche probabiliste. Nous n’essaierons pas de comprendre
le fonctionnement de ce réseau neuronal en termes probabilistes, mais plutôt de proposer deux
modèles probabilistes équivalents au modèle neuronal. Ces 2 modèles probabilistes correspondent
à 2 façons différentes d’aborder le problème. Ils utiliseront simplement les mêmes entrées
et viseront à fournir des sorties équivalentes en empruntant finalement au modèle neuronal que
les notions que ce dernier manipule.
A partir de cette comparaison entre approche neuronale et bayésienne, nous montrerons comment
un robot est capable d’apprendre à inférer la reconnaissance d’un amer à partir de la perception
de son azimut. Nous montrerons, de la même manière, comment construire des cellules
de lieu "probabilistes" en apprenant à inférer la reconnaissance d’un lieu à partir de la perception
d’une constellation d’amers-azimuts donnée.
3.1 Limitations du modèle actuel
Comme nous l’avons vu précédemment, notre architecture de reconnaissance de lieu a donné
de bons résultats lors de tâches de navigation dans de petits environnements et sur de courtes
durées. Les capacités de généralisation du système tenaient la première place, et l’usage d’une
simple compétition permettait de bonnes performances comportementales lors de tâches de navigation
typiquement limitées à une pièce et sur une période temporelle restreinte à quelques
heures. On peut se poser la question de la capacité de l’architecture à traiter des problèmes de
plus grande taille (plusieurs salles, environnements extérieurs) et à maintenir des performances
identiques à long terme (plusieurs jours, semaines, mois). Le système fait alors face à plusieurs
problèmes majeurs :
1. La nature ambiguë des informations visuelles amène à des interprétations multiples des
vues locales extraites. Lors d’une navigation dans un environnement complexe, une cellule
de lieu peut ainsi présenter des champs multiples, c’est à dire répondre à plusieurs
endroits dans l’environnement (voir fig. 3.1). La capacité d’un simple mécanisme de compétition
à proposer une interprétation cohérente diminue avec l’augmentation du nombre
de vues apprises (le rapport signal à bruit tend vers 0). La distance entre les prototypes
appris diminue avec le nombre d’amers et la probabilité de fausses alarmes augmente fatalement
[Giovannangeli, 2007]. Ce problème est bien connu en robotique mobile sous
le nom d’aliasing perceptif (perceptual aliasing) lorsque différentes portions de l’environnement
se ressemblent fortement [Marsland et al., 2001]. De précédents travaux ont
montré qu’une information de contexte apprise à la volée pouvait constituer une première
solution à ce problème en permettant à la fois de limiter la compétition (augmenter le rapport
signal à bruit) mais aussi de limiter la puissance de calcul nécessaire en ne calculant
- 64 -CHAPITRE 3. UN PARALLÈLE ENTRE FORMALISME NEURONAL ET BAYÉSIEN
globalement que l’activité des neurones associés au bon contexte [Cuperlier et al., 2008].
2. Dans l’architecture actuelle, tous les amers sont traités de manière identique. Le système
est incapable de procéder à un tri. Pourtant les amers peuvent avoir des caractéristiques
différentes (proximaux ou distaux, mobiles ou immobiles) et être plus ou moins pertinents
selon la tâche envisagée. Il est donc nécessaire d’introduire une capacité à prédire
la position ou le déplacement de ces amers afin de les caractériser. Ceux dont la position
angulaire reste invariante (sur une certaine distance) devraient avoir plus de poids dans la
reconnaissance que les amers mobiles, intermittents, redondants ou ambigus. Par ailleurs,
le temps de calcul évolue de façon linéaire (compléxité en O(N)) du nombres de lieux appris
[Giovannangeli, 2007]). L’ajout d’un mécanisme attentionnel de sélection des amers
pertinents permettrait non seulement de réduire les ambiguïtés mais également d’obtenir
une complexité asymptotique (bornée) ou logarithmique.
3. L’environnement réel est souvent fortement dynamique. Des amers stables sont amenés à
disparaître, tandis que d’autres se révèlent être mobiles et ne devraient donc pas être pris
en compte. L’apprentissage actuel "en un coup" ne permet pas de rendre compte de cet
aspect dynamique. Même si l’on considère le cas où de tels changements environnementaux
ne se produisent que rarement, le cumul de petites modifications et les variations
de luminosité posent le problème du maintien de l’activité des cellules de lieu dans le
temps. En effet, les tests actuels se limitent à des expériences de quelques heures et le
système est incapable de s’adapter à des reconfigurations lentes de l’environnement ou
aux changements saisonniers. L’apprentissage ne peut donc être statique, il doit lui aussi
être dynamique et adaptatif. Ce problème est connu sous le nom de dérive des concepts
(concept drift) [Tsymbal, 2004; Widmer and Kubat, 1996]. Les propriétés statistiques de
la variable que le modèle essaie de prédire évoluent au cours du temps d’une manière a
priori imprévisible. Ceci pose problème puisque les prédictions deviennent moins exactes
au fur et à mesure que le temps passe. Pour permettre au système de traiter ce problème
de dérive, celui-ci doit être capable de mettre à jour son modèle régulièrement en prenant
en compte les nouvelles observations. Parmi les différentes approches proposées par la
communauté du "machine learning" [Miroslav Kubat, 2004; Tsymbal, 2004; Witten and
Frank, 2005], l’apprentissage incrémental est considéré comme la méthode la plus adaptée
à la résolution de ce problème.
Jusqu’à présent, la question de savoir si un amer est pertinent ou non pour la navigation a
été largement ignorée ou remplacée par la préselection de modèle a priori servant à définir ce
qu’est un "bon" amer [Marsland et al., 2001]. Le risque est double : le superviseur humain peut
sélectionner des amers difficilement reconnaissables par la machine, ou bien, au contraire, négliger
des amers qu’il juge sans intérêt mais qui pourtant seraient pertinents pour le robot.
3.2 Approche bayésienne et notion d’inférence
L’inférence statistique consiste à déduire les caractéristiques statistiques inconnues d’une
population à partir d’un échantillon de cette population. Les caractéristiques de l’échantillon,
une fois connues, reflètent avec une certaine marge d’erreur celles de la population. Cette méthode
de réflexion est souvent attribuée à l’homme et serait fonctionnelle dès la naissance. Pourtant
- 65 -3.2. APPROCHE BAYÉSIENNE ET NOTION D’INFÉRENCE
FIGURE 3.1 – Expérience mettant en évidence la présence de nombreuses ambiguïtés visuelles au sein d’un couloir.
Le robot a appris 4 lieux régulièrement espacés (A,B,C et D) dans le couloir. Le niveau de reconnaissance de ces lieux
est ensuite enregistré lors d’une navigation de A vers D à vitesse constante. Chaque panorama à 180° correspond à la
vue subjective du robot au moment de l’apprentissage du lieu correspondant. L’environnement est ici particulièrement
ambigu avec des lieux qui se ressemble fortement. Le tracé des niveaux d’activité montre de nombreux faux positifs.
la vision dominante du XXème siècle est celle de la confusion du bébé : selon W. James, le bébé
est un organisme soumis à des entrées sensorielles et incapable pendant une très longue période
de les organiser convenablement [James, 1950]. Ce point de vue est partagé par la pédiatrie
de l’époque qui considère alors le très jeune enfant comme dépourvu de capacité de structurer
ses sensations. Cette vision a également guidé l’oeuvre de Piaget [Piaget, 1967] qui considérait
l’enfant de moins de 4 ans comme "précausal", c’est à dire incapable de remonter aux causes
de ce qu’il percevait. Durant la première année de vie, selon lui, l’enfant ne vivrait que dans
le présent, incapable de saisir la permanence des objets, incapable de se représenter un objet
disparu et encore moins de créer des modèles mentaux abstraits de ses connaissances.
Plus récemment (2004), de nouvelles visions réfutent la théorie piagetienne en proposant l’idée
d’une rationalité précoce chez l’enfant. Les enfants semblent posséder des théories intuitives
du monde physique, biologique, psychologique et de sa structure causale [Schulz and Gopnik,
2004]. Une première théorie propose que le bébé dispose dès la naissance d’un noyau de connaissances
fondamentales et innées (core knowledge). Ces connaissances comprendraient les
concepts d’objet [Kellman and Spelke, 1983], de nombre [Mehler and Bever, 1967], d’espace
[Landau et al., 1981] et même de ce que les auteurs appellent une "grammaire universelle"
[Chomsky, 1961; Gleitman et al., 1995; Komarova et al., 2001].
Selon une seconde théorie, quand l’enfant joue, il réaliserait en réalité des expériences permettant
de tester des modèles comme le ferait un scientifique. Le bébé serait capable de ma-
- 66 -CHAPITRE 3. UN PARALLÈLE ENTRE FORMALISME NEURONAL ET BAYÉSIEN
nipuler des probabilités, de sélectionner les variables pertinentes, d’éliminer les variables nonpertinentes,
de repérer des ambiguïtés ou interprétations multiples et enfin de lever ces ambiguïtés
par le jeu [Gopnik, 2001; Gopnik and Rosati, 2001; Oudeyer et al., 2005]. Certains
principes, même très abstrait, peuvent ainsi être sélectionnés par apprentissage bayésien. Il n’est
alors plus nécessaire de supposer qu’ils soient innés comme le postule la théorie précédente
et l’on peut supposer que le bébé découvre par lui même les concepts d’objet, d’espace et de
grammaire. L’approche bayésienne permet en fait un compromis entre connaissances innées et
acquises.
La théorie de l’inférence bayésienne est une théorie mathématique simple qui peut être vue
comme une extension de la logique en ce sens qu’elle permet de raisonner en présence d’incertitude.
Le raisonnement peut ainsi s’étendre à un continuum de plausibilité plutôt que de se
limiter à des conclusions binaires. A l’inverse de l’approche statistique, nécessitant un grand
nombre d’observations, l’approche bayésienne permet des inférences rapides et sophistiquées
en seulement quelques exemples. Cette particularité expliquerait, par exemple, la capacité des
jeunes enfants à tirer des conclusions correctes à partir d’un petit nombre d’expériences [Gopnik
et al., 2001]. Les inférences bayésiennes rendent aussi bien compte des processus de perception
en proposant l’interprétation la plus probable à partir d’entrées ambiguës. Une expérience de
Xu et Garcia montre que les enfants sont capables de telles inférences dès l’age de 8 mois [Xu
and Garcia, 2008]. De récents travaux suggèrent que des processus statistiques sont à l’oeuvre
dans le cerveau et montrent comment certains codages en population implémentent les principes
de bases de l’approche bayésienne. Afin de pouvoir réaliser ces inférences, l’enfant serait donc
contraint de raisonner en termes de probabilités et serait également capable de se représenter les
distributions de ces probabilités [Pouget et al., 2013]. Par ailleurs de nombreux travaux ont montré
que les processus sensori-moteurs à l’oeuvre dans le système nerveux étaient bien modélisés
par une approche bayésienne, aussi bien pour réduire les ambiguïtés de la perception [Kersten
et al., 2004], combiner informations a priori et observations [Mamassian et al., 2002], lier les
informations provenant de plusieurs modalités [Körding et al., 2004] et modéliser des raisonnements
complexes [Doya, 2007].
Pratiquement toutes les méthodes de localisation robotique partagent la caractéristique commune
d’aborder le problème de la navigation selon une approche probabiliste. Ces méthodes
ont recours aux inférences bayésiennes afin de transformer les données brutes, extraites des capteurs,
en information exploitable pour la localisation. Certains travaux font usage explicitement
de méthodes d’inférences probabilistes, tandis que d’autres ne semblent pas, à première vue,
reposer sur de telles méthodes mais celles-ci peuvent en réalité être interprétées comme telles
sous certains aspects [Thrun, 2002b]. La raison de ce succès provient du fait que la robotique est
caractérisée par des incertitudes et du bruit de mesure important. Les algorithmes probabilistes
traitent le problème en modélisant explicitement différentes sources de bruit et leurs effets sur
les mesures. Ce problème est sans doute le problème le plus complexe en robotique mobile et
a contraint la communauté à adopter une vision singulière en utilisant une méthodologie math-
ématique unique pour le résoudre. Le principe de base qui sous-tend la plupart des algorithmes
de SLAM est la règle de Bayes [Bayes, 1763]. Supposons que nous voulions en savoir plus sur
une quantité X (e.g. un lieu), à partir de données de mesure D (e.g. données issues de capteurs
ultrasons, odométrie, vision). La règle de Bayes nous dit que l’on peut déterminer la probabilité
de X sachant D, si l’on connaît les probabilités de X, de D et de D sachant X :
- 67 -3.3. NOTRE MODÈLE DE CELLULES DE LIEU D’UN POINT DE VUE BAYÉSIEN
p(X|D) = p(D|X)p(X)
p(D)
(3.1)
Le terme p(X) est appelé probabilité à priori de X. Il représente l’état des connaissances
sur X à un instant donné. De même, le terme p(D) représente la probabilité à priori de D. Cette
probabilité est un terme de normalisation de l’équation. Elle assure que la somme des probabilités
soit égale à 1. Le terme p(X|D) est appelé probabilité a posteriori de X sachant D. Cette
probabilité représente l’inférence ou la "conclusion" que l’on peut tirer sur la variable X à partir
des observations D. Le terme p(D|X), pour un D connu, est appelé fonction de vraisemblance
(likelihood) de X. Il spécifie la probabilité d’observer la mesure D sous l’hypothèse X. On peut
comprendre la règle de Bayes comme :
P osteriori =
V raissemblance.Apriori
Normalisation (3.2)
Autrement dit, si l’on connaît dans le détail les causes possibles d’une conséquence observée,
l’observation des effets permet de remonter aux causes. A titre d’exemple, la simple observation
de la tour Eiffel permet avec une grande probabilité d’en déduire que l’on se situe à Paris, puisque
l’expérience nous aura appris que (1) Paris est une ville unique, (2) la tour Eiffel est également
unique et enfin (3) la tour Eiffel n’est visible qu’a Paris (en omettant les copies présentes à Tokyo
et Las Vegas !).
Les travaux de [Khatib, 1986; Thrun, 1995; Lebeltel et al., 2004] ont permis de développer
l’approche bayésienne standard pour la navigation robotique (autour de Thrun dont le livre
"Probabilistic robotics" fait autorité [Thrun, 2002a]). D’autres travaux proposent une comparaison
entre approche neuronale et probabiliste [Ma et al., 2006; Rao et al., 2002; Pfister et al.,
2003]. Ces travaux visent à comprendre le fonctionnement d’un réseau neuronal en termes probabilistes.
Les travaux de [Filliat and Meyer, 2002] évoquent les relations entre SLAM et construction
de carte cognitive. D’autres travaux [Torralba, 1999; Ullah et al., 2008] utilisent une
approche probabiliste pour la reconnaissance sémantique de lieux. Il n’y a cependant pas de lien
direct entre cellules de lieu et lieu sémantique, ces derniers ne faisant pas partie du cadre de la
localisation.
De manière générale, on dénote peu de travaux sur une modélisation neuronale des mécanismes
d’inférences. La plupart des auteurs réalisent en réalité l’inverse en montrant que leur modèle
neuronal possède bien des propriétés probabilistes afin de pouvoir appliquer la règle de Bayes.
3.3 Notre modèle de cellules de lieu d’un point de vue bayésien
Nous présentons ici deux modèles probabilistes manipulant les mêmes notions que le modèle
neuronal. Tout deux utilisent les mêmes entrées et visent à fournir des sorties équivalentes. Les
modèles probabilistes de localisation ou de SLAM partent de l’hypothèse d’existence d’amers
et d’une mesure de position. Nous partons de l’existence d’amers (caractérisés dans le modèle
par la conjonction d’une signature et d’un azimut) et de lieux.
Notons :
- 68 -CHAPITRE 3. UN PARALLÈLE ENTRE FORMALISME NEURONAL ET BAYÉSIEN
– {s
k
, θk}k∈{1..K}
: l’ensemble des vues locales extraites des images aux positions k. Ce
sont des variables aléatoires continues.
– s
(1..K)
: la collection de toutes les signatures de 1 à K et s
k
: la signature k.
– a
i
l =< wl
, si > : la valeur d’activation de la cellule l pour la vignette i du vecteur d’amers.
– a
i
θ =< θ, θi > : l’activation de la cellule θ (les crochets ne décrivant pas un produit
scalaire mais simplement une distance).
– a
i
Θ, a
i
L
et a
i
Y
représentent les vecteurs {aθ}θ∈[1..M]
, {al}l∈[1..N] et {ay}y∈[1..N][1..M]
.
De façon générale, nous utiliserons les indices pour désigner les variables aléatoires et les
exposants pour désigner une observation. Les variables aléatoires seront représentées en majuscule,
leurs valeurs en minuscule. On fera une exception pour les variables d’entrée où variables
et valeurs seront confondues afin de simplifier les notations.
3.3.1 Description générale du problème
Les entrées du système sont organisées autour d’un vecteur d’amers (landmarks) et d’un
vecteur d’azimuts qui se combinent au sein d’une carte bidimensionnelle dont les sorties sont
utilisées pour activer un vecteur de cellules de lieu (voir fig. 3.2). Les variables aléatoires associées
à ces différents vecteurs ou cartes sont respectivement L, A, Y et X. Dans la suite de cette
section, nous aurons recours au terme anglais "landmark" pour désigner un amer visuel.
Les entrées sont constituées d’une collection de vignettes vues selon différents azimuts. Elles
sont représentées par la collection de variables s
(1..K)
, θ(1..K)
.
Les variables L et A sont assimilées aux valeurs des indices des cartes de landmarks et d’azimuts.
Ce sont donc des variables discrètes. Il est alors possible d’utiliser P(L = l|s
k
), la probabilité
que la variable L prenne la valeur l lorsque l’on sélectionne la signature s
k
, c’est à dire la probabilité
que la cellule l soit sélectionnée (ou activée) par la signature s
k
. Dans le cas de l’azimut,
la variable A peut prendre des valeurs d’angle θ en présence de la signature k vue sous l’azimut
θ
k
. La probabilité qu’elle prenne une valeur θ donnée est P(A = θ|θ
k
).
Ces deux variables L et A se combinent en une carte bidimensionnelle Y correspondant au
groupe ΣΠ (voir PrPh : 2.5.1). Y est ensuite utilisée pour produire une variable aléatoire X
correspondant aux cellules de lieu. Ces variables sont également discrètes. Y désigne donc les
cellules de la carte ΣΠ et ses valeurs les indices de cette carte.
Il est possible d’envisager deux approches du traitement des observations successives. La
première conduit à factoriser dans un premier temps en fonction des observations puis de
tenter d’évaluer les termes intermédiaires. La seconde reporte la factorisation dans une étape
ultérieure.
3.3.2 Factorisation immédiate
Nous proposons de déterminer la probabilité P(X = x|{S = s
k
, Θ = θ
k}k∈[1..K]
) d’être
dans un lieu x, connaissant un ensemble de signatures s
k
et leur azimut θ
k
, que nous simpli-
fierons par l’expression P(x, {s
k
, θk}k∈[1..K]
). Afin de calculer cette probabilité, nous utiliserons
un estimateur MAP (Maximum A Posteriori) [Duda et al., 2001] :
x
∗ = argmax
x
P(x|{s
k
, θk
}k∈[1..K]
).P({s
k
, θk
}k∈[1..K]
) (3.3)
- 69 -3.3. NOTRE MODÈLE DE CELLULES DE LIEU D’UN POINT DE VUE BAYÉSIEN
FIGURE 3.2 – Description du modèle de cellules de lieu. Le système prend comme entrées un vecteur d’amers
(landmarks) L et un vecteur d’azimuts A. Les 2 vecteurs se combinent au sein d’une carte Sigma-Pi Y (PrPh) dont
les sorties servent à activer un vecteur de cellules de lieu X. L’activité d’un neurone de landmark peut être interprétée
comme le reflet de la probabilité P(l
k
/si
) de percevoir le landmark l
k
sachant la signature s
i
. Cette probabilité est
donnée par une mesure de distance entre la signature apprise s
0
et la signature perçue s
i
. De même pour l’azimut
θ
k
de ce landmark, l’activité d’un neurone d’azimut reflète la probabilité P(θ
k
/si
) de percevoir l’azimut θ
k
sachant
la signature s
i
. Les neurones de la carte Y peuvent être interprétée comme la probabilité P(y/lk
, θk
) d’obtenir
la conjonction du landmark l
k
et de l’azimut a
k
. Finalement l’activité d’une cellule de lieu est définie comme la
probabilité P(x/l1..K, θ1..K).
La question générale à résoudre est de calculer la probabilité P(x|{s
k
, θk}k∈[1..K]
). On consid-
ère dans un premier temps que les observations sont indépendantes. La règle de Bayes donne :
P(x|{s
k
, θk
}k∈[1..K]
) =
P({s
k
, θk}k∈[1..K]
|x)
P({s
k, θk}k∈[1..K]
)
P(x) (3.4)
Si l’on fait l’hypothèse d’indépendance statistique des données, nous pouvons écrire :
P(x|{s
k
, θk
}k∈[1..K]
) = Y
K
k=1
P(s
k
, θk
|x)
P(s
k, θk)
P(x) (3.5)
Soit en appliquant à nouveau la règle de Bayes :
P(x|{s
k
, θk
}k∈[1..K]
) = Y
K
k=1
P(x|s
k
, θk
).P(s
k
, θk
)
P(s
k, θk).P(x)
P(x) (3.6)
=
Y
K
k=1
P(x|s
k
, θk
)
P(x)
P(x) =
P(x)
P(x)K
Y
K
k=1
P(x|s
k
, θk
) =
1
P(x)
K−1
Y
K
k=1
P(x|s
k
, θk
)
(3.7)
- 70 -CHAPITRE 3. UN PARALLÈLE ENTRE FORMALISME NEURONAL ET BAYÉSIEN
On notera le terme ℓ
s
k
, θk
pour désigner la vraissemblance des observations :
ℓ
h
s
k
, θk
i
=
Y
K
k=1
P(s
k
, θk
|x)
P(s
k, θk)
(3.8)
Distributions intermédiaires :
Nous pouvons désormais nous intéresser aux termes du produit QK
k=1 P(X = x|s
(k)
, θ(k)
).
En introduisant pour chaque terme de ce produit les variables intermédiaires Lk et Ak :
P(x|s
k
, θk
) = X
l,θ
P(x|Lk = l, Ak = θ)P(Lk = l, Ak = θ|s
k
, θk
) (3.9)
Dans ce modèle les variable Lk et Ak désignent les index des cartes de landmarks et d’azimuts.
Moyennant l’indépendance de Ak et Lk :
=
X
l,θ
P(x|Lk = l, Ak = θ)P(Lk = l|s
k
)P(Ak = θ|θ
k
) (3.10)
L’équation générale du modèle s’écrit alors (voir fig. 3.3) :
P(x|{s
k
, θk
}k∈[1..K]
) =
1
P(x)
K−1
Y
K
k=1
X
l,θ
P(x|Lk = l, Ak = θ)P(Lk = l|s
k
)P(Ak = θ|θ
k
)
(3.11)
FIGURE 3.3 – Graphe de dépendance entre les différentes variables du modèle. la signature Sk d’un amer physique
donne lieu à la mesure de son identité Lk et de son azimut Ak. Les variables intermédiaires Yk de la carte Sigma-Pi
dépendent de la co-activation (produit) du couple Lk et Ak. Un lieu Xk est définit comme la somme d’un ensemble
de variables intermédiaires Yk.
Nous allons considérer séparément les trois termes de l’équation 3.11.
- 71 -
Protection obligatoire r´epartie : usage pour le calcul
intensif et les postes de travail
Damien Gros
To cite this version:
Damien Gros. Protection obligatoire r´epartie : usage pour le calcul intensif et les postes
de travail. Other. Universit´e d’Orl´eans, 2014. French. .
HAL Id: tel-01080544
https://tel.archives-ouvertes.fr/tel-01080544
Submitted on 5 Nov 2014
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of scientific
research documents, whether they are published
or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est
destin´ee au d´epˆot et `a la diffusion de documents
scientifiques de niveau recherche, publi´es ou non,
´emanant des ´etablissements d’enseignement et de
recherche fran¸cais ou ´etrangers, des laboratoires
publics ou priv´es.UNIVERSITÉ D’ORLÉANS
ÉCOLE DOCTORALE MATHEMATIQUES, INFORMATIQUE,
PHYSIQUE THEORIQUE et INGENIERIE DES SYSTEMES
LABORATOIRE D’INFORMATIQUE FONDAMENTALE
D’ORLÉANS
THÈSE présentée par :
Damien GROS
soutenue le : 30 JUIN 2014
pour obtenir le grade de : Docteur de l’université d’Orléans
Discipline/ Spécialité : Informatique
Protection obligatoire répartie
Usage pour le calcul intensif et les postes de travail
THÈSE DIRIGÉE PAR :
Christian TOINARD Professeur des universités, INSA Val de Loire
RAPPORTEURS :
Ludovic APVRILLE Professeur Assistant, Telecom ParisTech
Christian PEREZ Directeur de recherche INRIA, LIP, ENS Lyon
JURY :
Sébastien LIMET Professeur des universités, Université d’orléans,
Président du jury
Ludovic APVRILLE Professeur Assistant, Telecom ParisTech
Mathieu BLANC Docteur, CEA/DAM/Ile de France
Jérémy BRIFFAUT Maître de conférences, INSA Val de Loire
Christian PEREZ Directeur de recherche INRIA, LIP, ENS Lyon
Christian TOINARD Professeur des universités, INSA Val de LoireRemerciements
Je remercie MM. Ludovic Apvrille et Christian Pérez pour avoir accepté d’évaluer mes travaux
en étant rapporteurs de cette thèse. Je remercie M. Sébastien Limet pour avoir accepté de participer
à mon jury.
Je tiens à remercier mon directeur de thèse, Christian Toinard, pour son soutien et son aide
durant mes recherches, et de m’avoir offert la possibilité de réaliser cette thèse. Je remercie aussi
Mathieu Blanc pour m’avoir accueilli au sein de l’équipe SSI du CEA et m’avoir conseillé tout au
long de mes 3 années de thèse, et Jérémy Briffaut pour toute l’aide qu’il m’a apporté dans mes
travaux.
Je remercie le CEA/DAM/DIF de m’avoir accueilli pendant ces 3 années et de m’avoir fourni
les moyens de réaliser toutes les expérimentations nécessaires au cours de mes travaux.
Je tiens à remercier Pierre Clairet, Aurélie Leday et Maxime Fonda de m’avoir accueilli chez
eux lors de mes déplacements à Bourges. Je remercie aussi Sandrine pour sa relecture minutieuse
de ce mémoire ; Matthieu, Frédéric, Thierry, Pascal et Romain pour les nombreuses discussions
enrichissantes et pour toute l’aide qu’ils m’ont fourni durant cette thèse ; les membres de l’équipe
SDS du LIFO, permanents et non-permanents pour leur accueil durant mes séjours à Bourges.
Et enfin, je tiens à remercier mes parents, ma famille et mes amis pour leur soutien tout au
long de ces 3 années de thèse.
34Table des matières
Table des figures 9
1 Introduction 15
1.1 Contexte de l’étude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.2 Observateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.3 Exemples d’attaques visant les systèmes d’exploitation Linux et Windows . . . . 17
1.3.1 Exemple d’attaque pour les systèmes Linux . . . . . . . . . . . . . . . . 17
1.3.2 Exemple d’attaque pour les systèmes Windows . . . . . . . . . . . . . . 18
1.3.3 Analyse des deux attaques . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4 Objectif de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
1.5 Apports de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.6 Plan du mémoire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
2 État de l’art 25
2.1 Propriétés de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.1.1 Propriétés générales . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
2.1.1.1 Confidentialité . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.1.1.2 Intégrité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.1.1.3 Disponibilité . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.1.2 Propriétés dérivées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
2.1.2.1 Confinement de processus . . . . . . . . . . . . . . . . . . . . 27
2.1.2.2 Moindre privilège . . . . . . . . . . . . . . . . . . . . . . . . 27
2.1.2.3 Séparation des privilèges . . . . . . . . . . . . . . . . . . . . 28
2.1.2.4 Non-interférence . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.1.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
2.2 Modèles de contrôle d’accès . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2.1 Le contrôle d’accès discrétionnaire . . . . . . . . . . . . . . . . . . . . 29
2.2.1.1 Lampson . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2.1.2 HRU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
2.2.1.3 TAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2.1.4 DTAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2.2 Le contrôle d’accès obligatoire . . . . . . . . . . . . . . . . . . . . . . . 32
2.2.2.1 Bell-LaPadula . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.2.2.2 Biba . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.2.2.3 Role Based Access Control . . . . . . . . . . . . . . . . . . . 35
2.2.2.4 Domain and Type Enforcement . . . . . . . . . . . . . . . . . 36
2.2.3 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.3 Implantation des mécanismes de contrôle d’accès . . . . . . . . . . . . . . . . . 38
2.3.1 Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
5TABLE DES MATIÈRES
2.3.1.1 SELinux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.3.1.2 grsecurity . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.3.1.3 Tomoyo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
2.3.1.4 Policy Interaction Graph Analysis . . . . . . . . . . . . . . . . 43
2.3.1.5 Politique et règle de contrôle d’accès . . . . . . . . . . . . . . 45
2.3.2 Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.3.2.1 Mandatory Integrity Control . . . . . . . . . . . . . . . . . . . 46
2.3.2.2 PRECIP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.3.2.3 Core Force . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.3.3 Distributed Security Infrastructure . . . . . . . . . . . . . . . . . . . . . 49
2.3.4 Impact sur les performances . . . . . . . . . . . . . . . . . . . . . . . . 50
2.3.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3 Modélisation et répartition d’observateurs 55
3.1 Définition d’un observateur pour les systèmes d’exploitation Linux et Windows . 56
3.1.1 Éléments de base de la protection système . . . . . . . . . . . . . . . . . 57
3.1.1.1 Modélisation du système observé . . . . . . . . . . . . . . . . 61
3.1.1.2 Mode de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.1.2 Définition d’un observateur : le moniteur de référence . . . . . . . . . . 64
3.1.2.1 Phase de pré-décision . . . . . . . . . . . . . . . . . . . . . . 65
3.1.2.2 Phase de décision . . . . . . . . . . . . . . . . . . . . . . . . 68
3.1.2.3 Phase de post-décision . . . . . . . . . . . . . . . . . . . . . . 68
3.1.3 Répartition des observateurs . . . . . . . . . . . . . . . . . . . . . . . . 69
3.1.3.1 Association . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.1.3.2 Localisation . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.1.3.3 Redondance . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
3.1.3.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.2 Modélisation d’une politique de contrôle d’accès direct . . . . . . . . . . . . . . 73
3.2.1 Grammaire de la politique . . . . . . . . . . . . . . . . . . . . . . . . . 73
3.2.1.1 La portabilité des noms utilisés pour les contextes . . . . . . . 76
3.2.1.2 Modélisation de la problématique des noms . . . . . . . . . . 77
3.2.2 Application de la grammaire sur deux modèles de protection pour les systèmes
Windows . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.2.2.1 Policy-Based Access Control . . . . . . . . . . . . . . . . . . 81
3.2.2.2 Domain and Type Enforcement . . . . . . . . . . . . . . . . . 84
3.2.2.3 Lien entre la politique d’accès direct et le moniteur de référence 86
3.3 Les techniques de détournement sur les systèmes Windows . . . . . . . . . . . . 87
3.3.1 Explications des techniques . . . . . . . . . . . . . . . . . . . . . . . . 87
3.3.1.1 Détournement de la table des appels système . . . . . . . . . . 87
3.3.1.2 Inline-Hook . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
3.3.1.3 filter-driver . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
3.3.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
3.3.2.1 Place de l’observateur dans le contrôle d’accès de Windows . . 91
3.3.2.2 Contrôle des driver . . . . . . . . . . . . . . . . . . . . . . . 92
3.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
6TABLE DES MATIÈRES
4 Répartition d’observateurs en environnement HPC et analyse des performances 97
4.1 Méthode de mesure des performances d’un système réparti d’observateurs . . . . 98
4.1.1 Mesures globales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.1.1.1 Mode colocalisé . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.1.1.2 Mode distant . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.1.2 Comparaison des performances . . . . . . . . . . . . . . . . . . . . . . 102
4.1.2.1 Combinatoire . . . . . . . . . . . . . . . . . . . . . . . . . . 102
4.1.2.2 Un seul observateur . . . . . . . . . . . . . . . . . . . . . . . 102
4.1.2.3 Deux observateurs . . . . . . . . . . . . . . . . . . . . . . . . 102
4.1.3 Mesures détaillées . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
4.1.3.1 Résultats déduits . . . . . . . . . . . . . . . . . . . . . . . . . 105
4.2 Solution pour répartir les observateurs dans un environnement HPC . . . . . . . . 107
4.2.1 Architecture avec deux observateurs en mode distant . . . . . . . . . . . 107
4.2.2 Choix des observateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.2.2.1 SELinux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.2.2.2 PIGA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
4.2.2.3 Infiniband . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
4.2.3 Déport du mécanisme de prise de décision . . . . . . . . . . . . . . . . . 111
4.2.3.1 Le nœud client . . . . . . . . . . . . . . . . . . . . . . . . . . 111
4.2.3.2 Le proxy serveur . . . . . . . . . . . . . . . . . . . . . . . . . 113
4.3 Expérimentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
4.3.1 Les moyens de mesure . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
4.3.2 Résultats sur les performances . . . . . . . . . . . . . . . . . . . . . . . 115
4.3.2.1 Architecture d’expérimentation . . . . . . . . . . . . . . . . . 115
4.3.2.2 Mesures globales . . . . . . . . . . . . . . . . . . . . . . . . 116
4.3.2.3 Mesures détaillées . . . . . . . . . . . . . . . . . . . . . . . . 118
4.3.2.4 Synthèse des mesures . . . . . . . . . . . . . . . . . . . . . . 120
4.4 Amélioration de la sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
4.4.1 Propriété de sécurité . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
4.4.2 Application de la propriété de sécurité . . . . . . . . . . . . . . . . . . . 124
4.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
5 Contrôle d’accès obligatoire pour Windows et Expérimentations 127
5.1 Politique de contrôle d’accès direct . . . . . . . . . . . . . . . . . . . . . . . . . 128
5.1.1 Path-Based Access Control . . . . . . . . . . . . . . . . . . . . . . . . . 128
5.1.2 Domain and Type Enforcement . . . . . . . . . . . . . . . . . . . . . . 130
5.1.3 Modes de fonctionnement . . . . . . . . . . . . . . . . . . . . . . . . . 134
5.1.4 Définition des politiques . . . . . . . . . . . . . . . . . . . . . . . . . . 135
5.1.5 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
5.2 Implantation des mécanismes de contrôle d’accès obligatoire . . . . . . . . . . . 138
5.2.1 Modification de la table des appels système . . . . . . . . . . . . . . . . 138
5.2.1.1 Architecture fonctionnelle . . . . . . . . . . . . . . . . . . . . 139
5.2.1.2 Détournement de la table des appels système . . . . . . . . . . 139
5.2.2 Architecture basée sur les filter-driver et les Kernel Callback . . . . . . . 142
5.2.2.1 Architecture globale . . . . . . . . . . . . . . . . . . . . . . . 142
5.2.2.2 Détournement des flux d’exécution . . . . . . . . . . . . . . . 143
5.3 Expérimentations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
5.3.1 Violation d’une propriété de confidentialité . . . . . . . . . . . . . . . . 145
5.3.1.1 Environnement des expérimentations . . . . . . . . . . . . . . 145
7TABLE DES MATIÈRES
5.3.1.2 Scénario des attaques . . . . . . . . . . . . . . . . . . . . . . 146
5.3.1.3 Violation directe . . . . . . . . . . . . . . . . . . . . . . . . . 146
5.3.1.4 Violation indirecte . . . . . . . . . . . . . . . . . . . . . . . . 146
5.3.2 Étude de logiciels malveillants . . . . . . . . . . . . . . . . . . . . . . . 147
5.3.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
5.3.2.2 Architecture décentralisée . . . . . . . . . . . . . . . . . . . . 149
5.3.2.3 Protocoles des expérimentations . . . . . . . . . . . . . . . . 152
5.3.2.4 Visualisation des résultats et définition des propriétés de sécurité 153
5.4 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
5.4.1 Pertinence/complétude de la solution . . . . . . . . . . . . . . . . . . . 159
5.4.2 Performances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
6 Conclusion 161
6.1 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
7 Bibliographie 165
I Annexes 169
A Configuration pour le logiciel linpack et utilisation 171
B Code utilisé pour la réalisation des tests de performances 173
C Les techniques de détournements 175
C.1 Détournement de la table des appels système . . . . . . . . . . . . . . . . . . . . 175
C.2 Inline Hook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
C.3 Filter-driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
8Table des figures
1.1 Schéma présentant la place de l’observateur avec une politique de sécurité vis-à-
vis d’une interaction faite par un processus . . . . . . . . . . . . . . . . . . . . . 17
1.2 Schéma résumant les étapes de l’attaque pour l’exploitation d’une faille noyau
sous Linux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.3 Schéma résumant les étapes de l’installation d’un rootkit nommé ZeroAccess . . 19
1.4 Représentation sous la forme de liste des interactions directes . . . . . . . . . . . 20
1.5 Association d’observateurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.1 Couverture des propriétés dérivées vis-à-vis des propriétés générales de sécurité . 29
2.2 Représentation de Lampson d’une matrice d’accès . . . . . . . . . . . . . . . . . 30
2.3 Lois d’application des propriétés de BLP . . . . . . . . . . . . . . . . . . . . . . 33
2.4 Lois d’application des propriétés de BLP-restrictives . . . . . . . . . . . . . . . . 33
2.5 Modèle No Read Up/No Write Down . . . . . . . . . . . . . . . . . . . . . . . 34
2.6 Lois d’application des propriétés de Biba . . . . . . . . . . . . . . . . . . . . . 34
2.7 Modèle de protection des données : Biba . . . . . . . . . . . . . . . . . . . . . . 35
2.8 Schéma d’héritage du modèle RBAC1 . . . . . . . . . . . . . . . . . . . . . . . 36
2.9 Schéma du modèle DTE . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.10 Implantation des modèles RBAC et DTE par SELinux . . . . . . . . . . . . . . . 40
2.11 Fonctionnement de PIGA-CC . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.12 Lois d’application des propriétés du MIC . . . . . . . . . . . . . . . . . . . . . . 46
2.13 Modèle de protection des données : MIC . . . . . . . . . . . . . . . . . . . . . . 47
3.1 Schéma du placement de l’observateur . . . . . . . . . . . . . . . . . . . . . . . 57
3.2 Écriture d’un fichier malveillant par Firefox : Windows et Linux . . . . . . . 57
3.3 Écriture détaillée d’un fichier malveillant par un navigateur web . . . . . . . . . 59
3.4 Placement de l’observateur pour détourner le flux d’exécution . . . . . . . . . . 59
3.5 Schéma global de détournement des flux pour les deux systèmes . . . . . . . . . 60
3.6 Mode de sécurité : requête/réponse de l’observateur . . . . . . . . . . . . . . . . 63
3.7 Mode de sécurité : évidence . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.8 Mode de sécurité : notification . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.9 Schéma du moniteur de référence . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.10 Construction de la trace par le moniteur de référence : ajout de l’horodatage . . . 65
3.11 Construction de la trace par le moniteur de référence : ajout d’information pour
l’historique des processus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.12 Construction de la trace par le moniteur de référence : translation en une interaction 66
3.13 Construction de la trace par le moniteur de référence : schéma global . . . . . . . 67
3.14 Mode d’association : cascade . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.15 Mode d’association : continuation . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.16 Mode de localisation : colocalisé . . . . . . . . . . . . . . . . . . . . . . . . . . 70
9TABLE DES FIGURES
3.17 Mode de localisation : distant . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
3.18 Mode de localisation : distant avec plusieurs nœuds et plusieurs observateurs . . 71
3.19 Mode de localisation : distant avec plusieurs nœuds et un seul observateur . . . . 71
3.20 Mode de redondance : diffusion des requêtes par le nœud . . . . . . . . . . . . . 72
3.21 Mode de redondance : architecture de la forme maître-esclave . . . . . . . . . . 72
3.22 Nommage des ressources au format PBAC . . . . . . . . . . . . . . . . . . . . . 75
3.23 Nommage des ressources au format DTE . . . . . . . . . . . . . . . . . . . . . . 75
3.24 Transition de rôle modifiant les accès possibles à certaines ressources du système 76
3.25 Correspondance entre une ressource et les emplacements physiques . . . . . . . 78
3.26 Correspondance entre une ressource et les emplacements logiques . . . . . . . . 79
3.27 Représentation de la fonction Nabs . . . . . . . . . . . . . . . . . . . . . . . . . 79
3.28 Mécanisme de prise de décision du moniteur de référence . . . . . . . . . . . . . 87
3.29 Fonctionnement régulier d’un appel système présent dans la table des appels système 88
3.30 Mécanisme de détournement de la table des appels système . . . . . . . . . . . . 88
3.31 Mécanisme d’inline hook . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
3.32 Architecture des filter-driver en prétraitement . . . . . . . . . . . . . . . . . . . 89
3.33 Place de l’observateur en prétraitement . . . . . . . . . . . . . . . . . . . . . . . 90
3.34 Architecture des filter-driver en post-traitement . . . . . . . . . . . . . . . . . . 90
3.35 Empilement de driver modifiant la table des appels système . . . . . . . . . . . . 93
3.36 Schéma détaillant la situation de concurrence sur la table des appels système . . . 93
4.1 Prise du temps de référence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
4.2 Prise du temps avec ajout du premier observateur . . . . . . . . . . . . . . . . . 99
4.3 Diagramme de séquence illustrant les temps mesurés lors l’ajout d’un seul observateur
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
4.4 Prise du temps global avec deux observateurs en mode colocalisé . . . . . . . . . 100
4.5 Diagramme de séquence illustrant les temps mesurés lors l’ajout de deux observateurs
en mode colocalisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
4.6 Prise du temps global avec un observateur en mode distant . . . . . . . . . . . . 101
4.7 Diagramme de séquence illustrant le temps global distant lors du déport du second
observateur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
4.8 Prise du temps avec une communication et un observateur en mode distant . . . . 103
4.9 Diagramme de séquence illustrant les temps mesurés lors d’une communication
complète avec le second observateur en mode distant . . . . . . . . . . . . . . . 104
4.10 Prise du temps pour l’observateur 2 en mode distant . . . . . . . . . . . . . . . . 104
4.11 Diagramme de séquence illustrant les temps mesurés lors de la prise de décision
du second observateur en mode distant . . . . . . . . . . . . . . . . . . . . . . . 105
4.12 Architecture décentralisée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
4.13 Architecture de prise de décision de SELinux . . . . . . . . . . . . . . . . . . . 109
4.14 Insertion de PIGA dans l’architecture en mode colocalisé . . . . . . . . . . . . . 110
4.15 Schéma d’une communication RDMA sur un lien InfiniBand . . . . . . . . . . . 111
4.16 Architecture de protection sur un nœud client . . . . . . . . . . . . . . . . . . . 112
4.17 Architecture détaillée du contrôle d’accès sur un nœud client . . . . . . . . . . . 113
4.18 Architecture sur le serveur de sécurité . . . . . . . . . . . . . . . . . . . . . . . 113
4.19 Diagramme de séquence illustrant la mesure faite au niveau du proxy coté nœud
de calcul . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
4.20 Diagramme de séquence illustrant la mesure faite au niveau du proxy serveur pour
calculer le temps de prise de décision de PIGA . . . . . . . . . . . . . . . . . . 120
10TABLE DES FIGURES
4.21 Diagramme de séquence résumant les différentes mesures effectuées au sein de
l’architecture distribuée . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
5.1 Schéma décrivant l’apprentissage d’une politique . . . . . . . . . . . . . . . . . 136
5.2 Architecture globale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
5.3 Flux d’exécution classique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
5.4 Flux d’exécution détourné par la modification de la SSDT . . . . . . . . . . . . . 142
5.5 Architecture de détournement basée sur l’utilisation de filter-driver et de kernel
callback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
5.6 Statistiques sur la politique de contrôle d’accès pour le premier scénario . . . . . 145
5.7 Schéma du flux indirect conduisant à la violation de la propriété de confidentialité 147
5.8 Instrumentation du système pour l’analyse de logiciel malveillant . . . . . . . . . 150
5.9 Logiciel malveillant écrivant des fichiers dans la corbeille de Windows . . . . . . 154
5.10 Flash player écrit dans la Corbeille de Windows . . . . . . . . . . . . . . . 155
5.11 services.exe chargeant les fichiers écrits par les logiciels malveillants. . . . 155
5.12 Automate complet des interactions réalisées par le logiciel malveillant . . . . . . 156
5.13 Diagramme d’activité sur l’installation de l’infection . . . . . . . . . . . . . . . 157
11TABLE DES FIGURES
12Liste des symboles
ACL Access Control List : Ensemble des droits d’accès sur une ressource du système, page 30
BLP Bell-LaPadula : Modèle de protection basée sur la confidentialité des données, page 32
DAC Discretionary Access Control : Modèle de contrôle d’accès utilisé par la plupart des systèmes
d’exploitation laissant la gestion des droits à la discrétion de l’utilisateur, page 29
DTE Domain and Type Enforcement : Modèle de protection de haut niveau utilisant les notions
de domaine et de type pour abstraire les ressources, page 36
IRP I/O Request Packets : Structure en partie opaque du noyau Windows permettant la communication
entre les driver , page 89
LSM Linux Security Modules : Interface au sein des appels système sous Linux autorisant le
contrôle des actions, page 39
MAC Mandatory Access Control : Contrôle d’accès obligatoire imposant une politique de
contrôle d’accès aux utilisateurs du système, page 32
MIC Mandatory Integrity Control : Contrôle d’accès obligatoire basé sur les niveaux d’intégrité,
page 46
PBAC Path-Based Access Control : Modèle de protection basé sur les chemins complets des ressources,
page 41
RBAC Role-Based Access Control : Modèle de protection reposant sur les rôles des utilisateurs
pour donner les autorisations d’accession aux ressources, page 35
SSDT System Service Dispatch Table : Table des appels système sur les systèmes Windows,
page 140
NTFS New Technology File System : Système de fichiers propriétaire utilisé sur les systèmes
d’exploitation Windows, page 131
13TABLE DES FIGURES
14Chapitre 1
Introduction
1.1 Contexte de l’étude
L’actualité montre que les systèmes d’information et plus spécifiquement les systèmes d’exploitation
sont la source de vulnérabilités. Le premier système d’exploitation visé est Windows,
système le plus utilisé dans le monde pour les ordinateurs personnels et professionnels 1
. Ses principales
faiblesses résident dans les applications installées sur le système, qu’elles soient fournies
par l’éditeur du système d’exploitation ou par des éditeurs tiers. Ceci est confirmé par les rapports
annuels des éditeurs de logiciels antivirus 2
. Nous pouvons ainsi citer des attaques ciblant les logiciels
Adobe Reader 3 ou Adobe Flash Player 4
, particulièrement visés par les failles
récentes. Ces logiciels sont utilisés par les attaquants pour entrer sur le système d’exploitation afin
d’en modifier le comportement, de voler de l’information ou de contribuer à des attaques à grande
échelle (botnet, déni de service, etc.).
Les systèmes basés sur Linux font aussi l’objet d’attaques. Ces systèmes sont maintenant largement
répandus dans le monde des téléphones mobiles, et de plus en plus présents sur les ordinateurs
des professionnels et des particuliers, ce qui en fait une nouvelle cible pour les attaquants.
De plus, avec le développement des nouvelles technologies comme l’informatique en nuage (cloud
computing) ou les grilles de calcul, les menaces se font aussi présentes sur les systèmes distribués.
Auparavant, les attaques visaient essentiellement les serveurs pour y récupérer l’information qu’ils
hébergeaient. Maintenant, les systèmes répartis offrent des moyens d’attaque supplémentaires et
génèrent, par conséquent, des nouvelles problématiques de sécurité.
La protection des systèmes est devenue un enjeu majeur pour les sociétés actuelles, non seulement
pour protéger l’intégrité et la confidentialité des données qu’elles possèdent, mais aussi, et
c’est de plus en plus le cas, des données ou des services qu’elles hébergent pour le compte de tiers.
De plus, la fourniture de ses services est généralement contractuelle, leurs dysfonctionnement entraîne
donc des conséquences financières. Les sociétés proposant ce type de service se doivent
donc de proposer des moyens de sécurisation efficaces pour protéger les données de leurs clients.
Cette sécurisation du système et des données hébergées passe par la mise en place d’un mécanisme
de confiance capable de contrôler les interactions se déroulant au sein même du système. De
plus, la confidentialité et l’intégrité des données peuvent être assurées par l’utilisation de moyens
cryptographiques forts, que ce soit pour leur stockage ou pour leur transmission sur les réseaux.
1. Statistiques de l’entreprise NetMarketShare : http://www.netmarketshare.com/operatingsystem-market-share.aspx
2. Rapports 2014 de Symantec (http://www.symantec.com/fr/fr/security_response/
publications/threatreport.jsp) et Sophos (http://www.sophos.com/en-us/threatcenter/security-threat-report.aspx)
3. CVE-2014-0502 :http://www.cvedetails.com/cve/CVE-2014-0502/
4. CVE-2014-0497 : https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2014-0497
151.2. OBSERVATEUR
Les systèmes d’exploitation courants sont vulnérables à deux grands vecteurs d’attaque. Le
premier vecteur est l’utilisateur. Que ce soit de manière intentionnelle ou non, il peut faire sortir
ou modifier de l’information. Par conséquent, il faut contrôler de manière précise ses accès. Dans
un contexte de défense, cette vérification passe par la validation du niveau d’habilitation de l’utilisateur,
lorsque celui-ci souhaite accéder à une ressource classifiée. La gestion fine des accès aux
ressources du système donne l’assurance qu’un utilisateur ne peut accéder qu’aux ressources qui
lui sont destinées.
Le second vecteur est l’utilisation de logiciels tiers possédant des failles de sécurité. Les véri-
fications par l’analyse du code source de l’application ou par le reverse code engineering sont en
pratique complexes. En plus des logiciels tiers, le système lui-même possède des failles (applicatives
ainsi que noyau) qui sont corrigées régulièrement par les développeurs de ces systèmes.
Les systèmes d’exploitation classiques ne sont pas capables de se protéger contre ces deux
grands axes d’attaque. Il faut donc proposer d’autres approches. La première méthode concerne
les mécanismes cryptographiques capables de chiffrer les données ainsi que d’en vérifier leur
intégrité. La seconde méthode concerne les mécanismes de contrôle d’accès, qui vont garantir
que les opérations faites par les processus sur le système ne compromettent pas l’intégrité ou
la confidentialité. Nous pouvons ainsi citer les antivirus, les antimalwares, les mécanismes de
contrôle d’accès obligatoire, etc.
Notre étude va se concentrer sur l’analyse des mécanismes de contrôle d’accès limitant les
privilèges des processus, puisque, comme nous le montrerons au cours de cette thèse, c’est ce
point qui est la principale source de compromission. En effet, il manque des solutions efficaces,
performantes et extensibles capables de limiter et de contrôler les privilèges des processus.
Quel que soit le mécanisme de contrôle d’accès étudié (antivirus, antimalware, etc.), ils possèdent
tous une architecture commune composée de deux éléments : le premier élément est un
observateur et le second est une politique de sécurité. Nous nous attacherons à définir ces deux
éléments au cours de notre étude.
1.2 Observateur
Le contrôle des accès au sein même du système passe par la mise en place d’un observateur.
Un observateur est un mécanisme système détournant le flux d’exécution et réalisant des traitements
spécifiques vis-à-vis d’une politique de sécurité. Classiquement, ces traitements peuvent
être : auditer, interdire, autoriser, vérifier l’intégrité, etc. L’observateur se place généralement
en espace privilégié (noyau) afin de contrôler la totalité du système et offrir une confiance dans les
décisions qu’il prend. Le schéma 1.1 illustre le placement de l’observateur au sein du système.
Un observateur, contrôlant les interactions faites par les processus sur le système, doit commencer
par détourner le flux d’exécution régulier des processus afin de l’étudier. Ce détournement
doit être sûr car la protection ne doit pas pouvoir être supprimée par un utilisateur. De plus, il est
important que ce détournement n’introduise pas un surcoût prohibitif qui dégraderait les performances
du système. On peut notamment prendre pour exemple les antivirus qui consomment une
grande partie du temps processeur lors de leur analyse.
Dans le cadre d’un observateur contrôlant les accès au sein du système, il doit a minima analyser
les interactions directes. Une interaction directe est une représentation de l’activité observée
sous la forme d’un triplet (sujet, operation_elementaire, objet), qui se représente aussi de la
manière suivante :
sujet −−−−−−−−−−−−−−→
operation_elementaire
objet
161.3. EXEMPLES D’ATTAQUES VISANT LES SYSTÈMES D’EXPLOITATION LINUX ET
WINDOWS
Espace
utilisateur
Espace
noyau
Observateur
Processus Fichier
Ecriture
Politique
de sécurité
noyau
FIGURE 1.1 – Schéma présentant la place de l’observateur avec une politique de sécurité vis-à-vis
d’une interaction faite par un processus
Lorsqu’une interaction directe est interceptée, l’observateur recherche le triplet correspondant
à une règle dans la politique afin d’exécuter le traitement spécifique associé (autoriser, interdire,
auditer, etc.). Sinon il effectue un traitement par défaut, comme lever une alerte. Voyons dans ce
qui suit les limites du contrôle des interactions directes.
1.3 Exemples d’attaques visant les systèmes d’exploitation Linux et
Windows
À partir de deux exemples concrets pris pour les systèmes d’exploitation Linux et Windows,
nous allons illustrer le comportement des attaques pour en déduire les manques dans notre étude.
1.3.1 Exemple d’attaque pour les systèmes Linux
Les systèmes d’exploitation Linux sont aussi exposés aux attaques. On retrouve des attaques
exploitant des failles dans des logiciels tiers comme sur les systèmes Windows, mais aussi des
attaques réalisées volontairement ou involontairement par les utilisateurs dans le but d’obtenir des
privilèges supplémentaires. Dans les deux cas, le but est d’obtenir un accès administrateur (root)
sur le système pour réaliser des tâches privilégiées.
Il existe des moyens de protection efficaces sur les systèmes Linux. Ces mécanismes permettent
de contrôler les interactions directes faites entre les processus et les ressources du système.
Cependant, ils ne sont pas capables de contrer les attaques avancées correspondant à l’enchaînement
de plusieurs interactions directes, qui prises individuellement peuvent être légitimes, mais
qui constituent un scénario complet d’attaque.
Nous allons détailler un scénario d’attaque correspondant à l’exploitation d’une faille noyau
sur l’appel système perf_event_open 5
. Cette vulnérabilité permet d’obtenir un shell avec
5. CVE-2013-2094 :https://cve.mitre.org/cgi-bin/cvename.cgi?name=CVE-2013-2094
171.3. EXEMPLES D’ATTAQUES VISANT LES SYSTÈMES D’EXPLOITATION LINUX ET
WINDOWS
un accès root. La figure 1.2 illustre un exemple de 9 étapes constituant un ensemble d’interactions
directes définissant le scénario complet d’attaque permettant d’obtenir un terminal avec les
droits administrateur (un shell root).
FIGURE 1.2 – Schéma résumant les étapes de l’attaque pour l’exploitation d’une faille noyau sous
Linux
Cette attaque se déroule en plusieurs étapes. Nous avons tout d’abord une connexion de la part
de l’utilisateur, par exemple via ssh (0), l’utilisation d’un navigateur web tel que Firefox (1),
le téléchargement du logiciel malveillant (2-4) et son exécution (5-8).
Comme l’illustre la figure 1.2, le scénario complet d’attaque comporte 9 étapes composées
d’interactions "système" (création de fichier, exécution de programme), mais aussi d’interactions
"réseau" (connexion Internet, téléchargement, etc). Ce scénario met donc en jeu plusieurs types
d’interactions directes qui prises indépendamment ne constituent pas un risque.
Cette attaque illustre l’exploitation d’une faille du noyau Linux.
1.3.2 Exemple d’attaque pour les systèmes Windows
Les logiciels malveillants (malware) ciblant les systèmes d’exploitation Windows sont de plus
en plus complexes. Ils utilisent des techniques assez évoluées pour se dissimuler au sein même du
système. Il est donc nécessaire de mettre en place des mécanismes de protection avancés contrôlant
les processus.
Les attaques actuelles contre les systèmes Windows passent souvent par les navigateurs web et
les plugins installés. Les plugins sont des modules additionnels pour les navigateurs qui apportent
des fonctionnalités supplémentaires, comme lire des fichiers pdf ou exécuter du code en flash. La
figure 1.3 montre le cheminement d’une attaque d’un rootkit nommé ZeroAccess [McAfee, 2013].
181.3. EXEMPLES D’ATTAQUES VISANT LES SYSTÈMES D’EXPLOITATION LINUX ET
WINDOWS
FIGURE 1.3 – Schéma résumant les étapes de l’installation d’un rootkit nommé ZeroAccess
Afin de compromettre le système, le malware va effectuer une suite d’interactions directes.
Par l’exploitation d’une faille dans un navigateur ou dans un plugin du navigateur, le navigateur
va télécharger le malware sur le système (1,2). Le payload, c’est-à-dire la charge active installant
le rootkit s’exécute (3) via un installateur modifié de FlashPlayer (4-10). Le rootkit exploite une
faille dans un service système pour finaliser son installation (11, 12). Ce scénario complet est ainsi
constitué de 12 interactions directes.
1.3.3 Analyse des deux attaques
Ces deux scénarios complets d’attaque sont proches dans leur construction. Ils sont tous les
deux basés sur l’enchaînement de plusieurs interactions directes, c’est-à-dire une succession d’interactions
réalisées les unes à la suite des autres de manière logique, menant à la compromission
du système.
Pour contrer ce type d’attaque, il est nécessaire d’avoir un observateur capable d’intercepter
et de contrôler les interactions directes. Ainsi, l’analyse de ces interactions directes permet de
reconstruire le scénario complet sous la forme d’une liste de n interactions directes (figure 1.4).
Par exemple, pour l’attaque concernant le système Windows (figure 1.3), l’interaction numé-
rotée 3 peut se voir sous la forme :
Sujet3 : Firefox −−−−−−−−−−−−−−−−−→
operation_elementaire:open
Object3 : malware.exe
191.4. OBJECTIF DE LA THÈSE
FIGURE 1.4 – Représentation sous la forme de liste des interactions directes
Pour prévenir ce genre d’attaque, on pourrait supprimer (interdire dans la politique de contrôle
d’accès) une interaction directe de cette liste. Cependant, certaines interactions sont légitimes
comme l’écriture d’un fichier par Firefox. On ne peut donc pas interdire une des interactions
sans risquer de nuire au fonctionnement du système. Par conséquent, plutôt que d’interdire une
des n − 1 interactions intermédiaires, il est nécessaire d’analyser le scénario complet.
Pour pouvoir contrôler un scénario complet, il faut avoir un observateur réalisant des calculs
spécifiques. L’implantation d’un tel observateur, capable à la fois de gérer les interactions directes
et de reconstruire temporellement l’activité des processus est difficile à réaliser. En pratique, il
est préférable de pouvoir associer différents observateurs. Citons par exemple le défi [ANR, 2009]
dans lequel les développeurs ont mis en place deux associations d’observateurs : une première
composée de SELinux (mécanisme de contrôle d’accès obligatoire) et iptables (pare-feu) pour
contrôler les interactions directes, et une seconde composée de SELinux et de PIGA (voir la section
2.3.1.4) pour le contrôle des scénarios complets.
Afin qu’un observateur, tel que PIGA, puisse analyser le scénario complet, il faut qu’un premier
observateur lui communique chaque interaction directe horodatée. Il sera ainsi capable de
reconstruire et de contrôler les scénarios complets (figure 1.5).
1.4 Objectif de la thèse
Le travail réalisé au cours de cette thèse vise à améliorer la protection proposée par les systèmes
d’exploitation grâce à des approches avancées de contrôle d’accès.
Les mécanismes de protection, qu’ils soient système ou réseau, passent par la mise en place
d’un observateur. Cet observateur doit détourner le flux d’exécution et garantir sa conformité vis-
à-vis d’une politique de sécurité. Notre étude concerne les observateurs pour les systèmes d’exploitation,
leurs répartitions, leurs efficacités et leurs impacts sur les performances du système.
Nous définissons quatre objectifs majeurs pour cette thèse :
1. Définir un modèle d’observateur générique pour les systèmes d’exploitation.
— Pour mettre en place ce modèle, il faut définir de manière abstraite la notion d’observateur
pour les systèmes d’exploitation. Cette notion d’observateur doit être générale
et indépendante du système d’exploitation (Linux ou Windows).
— À partir de cette définition, nous proposerons une implantation fonctionnelle pour les
systèmes Windows d’un observateur capable de gérer les interactions directes car c’est
sur ce système qu’il y a les manques les plus importants.
2. Nous avons montré au cours de cette introduction qu’il était nécessaire de pouvoir associer
et répartir les observateurs pour prévenir efficacement les nouvelles menaces. Il nous faut
donc proposer un modèle général de répartition d’observateurs. Cependant, dans des mi-
201.5. APPORTS DE LA THÈSE
FIGURE 1.5 – Association d’observateurs
lieux où la contrainte en termes de performances est grande, il faut pouvoir évaluer l’impact
du modèle de répartition.
3. Il nous faut par conséquent, définir un protocole pour analyser les surcoûts engendrés par
l’association d’un ou plusieurs observateurs au sein d’un système et proposer des solutions
efficaces pour les réduire.
4. Afin de valider l’efficacité en termes de sécurité, nous développerons deux cas d’usage,
l’un pour les systèmes à haute performance sur Linux et l’autre par l’étude des malware
sur Windows.
1.5 Apports de la thèse
Nous indiquons, au travers de l’état de l’art, qu’il y a un manque de formalisation pour la notion
d’observateur. La protection du système passe par la possibilité de pouvoir répartir plusieurs
types d’observateurs, réalisant chacun des calculs spécifiques. Dans cette optique, nous proposons
une définition générique de la notion d’observateur pour les systèmes d’exploitation. Nous présenterons
au travers de notre modélisation, que cette définition ne dépend pas du système d’exploitation
sous-jacent. Ainsi, dans le but d’illustrer notre propos, nous montrerons que cette définition
s’applique aussi bien aux systèmes Linux qu’aux systèmes Windows.
Afin d’écrire la politique de sécurité d’un observateur, il est nécessaire d’avoir une grammaire.
Nous proposons donc une grammaire générique permettant l’écriture des règles de contrôle d’accès
directes pour tout type de système. Nous expliquerons comment cette grammaire supporte
deux modèles de protection différents s’appliquant à un large ensemble de systèmes différents.
211.5. APPORTS DE LA THÈSE
Cette partie répond à la problématique de définition de politique de sécurité générique pour les
systèmes.
L’écriture d’une politique de sécurité nécessite d’identifier de manière précise les ressources
du système. Nous retrouverons dans la littérature deux méthodes principales de désignation des
ressources. La première se base sur le chemin complet de la ressource dans le système de fichiers.
Cette méthode, qui a comme principal avantage d’être très usuelle, empêche d’avoir une politique
de sécurité parfaitement portable entre les systèmes. La seconde méthode pour désigner les ressources
se base sur la définition de types et de domaines. Cette méthode a le principal avantage
d’être beaucoup plus portable. Cependant, il est nécessaire d’assurer une correspondance entre
les ressources et la définition des types. Nous proposons donc une approche de désignation des
ressources applicable à Windows et à Linux et qui rend la politique portable.
Il existe des implantations d’association de plusieurs observateurs : SELinux et PIGA, SELinux
et iptables, etc. Néanmoins, il n’existe aucun modèle clair de répartition d’observateurs. Nous
définissons donc un modèle exploitable de répartition d’observateurs. Ce modèle permet de définir
l’association entre observateurs, mais décrit aussi un modèle pour spécifier la localisation ainsi
que le mode de redondance de chaque observateur.
L’intégration et la répartition des observateurs ne doivent pas nuire aux performances du système
observé. Mais pour connaître l’impact de l’ajout d’un mécanisme de sécurité sur le système,
il faut pouvoir le mesurer. Nous proposons donc une solution pour mesurer l’impact sur les performances
de l’ajout et de la répartition d’observateurs. Nous expliquerons comment nous sommes
capables d’identifier avec précision les éléments qui nuisent aux performances du système.
Nous décrivons donc un modèle pour mesurer le surcoût engendré par la mise en place d’un ou
plusieurs observateurs. Ce modèle est détaillé pour des observateurs colocalisés et distants. Nous
proposons l’implantation d’une association de deux observateurs au sein d’un environnement HPC.
Afin de réduire les temps de communication entre observateurs, nous déportons le second moniteur
en utilisant les technologies spécifiques présentes dans les environnements HPC. Nous illustrons
cette partie avec deux observateurs : SELinux pour le contrôle des interactions directes et PIGA
pour le contrôle des scénarios complets. Nous montrons ainsi que le déport du second observateur
permet de générer moins de latence par rapport à une architecture colocalisée.
Enfin, à partir de la définition générique d’observateur ainsi que de la formalisation de la création
d’une politique de sécurité, nous proposons une implantation d’un mécanisme de contrôle
d’accès obligatoire pour les systèmes Windows. Nous décrivons l’implantation des deux modèles
de politiques de sécurité supportées par notre langage et nous détaillerons les outils que nous avons
mis en place pour faciliter l’administration des politiques. Nous détaillerons les mécanismes permettant
de détourner de manière efficace les interactions directes sur les systèmes Windows. Nous
montrerons que ce mécanisme est capable de contrer les attaques simples, c’est-à-dire en contrô-
lant les interactions directes, et que, associé avec un second observateur, nous sommes capables
de contrôler les scénarios complets. De plus, nous expliquerons qu’il est possible de modifier cet
observateur dans le but d’analyser des logiciels malveillants pour en extraire des comportements
spécifiques. Cette partie répond à la problématique de manque de mécanisme de contrôle d’accès
obligatoire pour les systèmes Windows.
Le tableau 1.1 récapitule les apports de cette thèse.
— couleur verte : les solutions existantes ;
— couleur rouge : les éléments actuellement non satisfaisants que nous développerons dans
ce mémoire de thèse ;
221.6. PLAN DU MÉMOIRE
Linux Windows
Concept d’observateur
- Définition commune Manque une définition générique
Implantation d’observateurs
- Interactions directes SELinux, grsecurity SEWindows
AppArmor, Tomoyo, SMACK
Répartition des observateurs
- Modèle Modèle abstrait de répartition
- Implantation HPC Solution pour les systèmes répartis
Impact sur les performances
- Analyse des performances Solutions pour analyser
les performances des observateurs
- Réduction du surcoût Solutions pour réduire le surcoût des observateurs
TABLE 1.1 – Tableau présentant les apports de la thèse
1.6 Plan du mémoire
Le chapitre 2 fait l’état de l’art des propriétés de sécurité et des principaux modèles de contrôle
d’accès. Ensuite, nous traitons des implantations de contrôle d’accès obligatoire existantes sur les
systèmes Linux et Windows, en nous focalisant sur les implantations de référence pour chaque
système. Cette section se conclut par une synthèse listant les propriétés de sécurité que sont capables
de garantir les mécanismes que nous présentons. Enfin, nous nous intéressons à l’impact
des mécanismes de contrôle d’accès sur les performances du système. Ce chapitre se conclut en
exprimant tout d’abord, les manques des implantations de contrôle d’accès obligatoire existants
sur les systèmes Windows et ensuite, en exprimant le manque de formalisme quant à la répartition
de plusieurs observateurs au sein des systèmes.
Le chapitre 3 propose une formalisation de la notion d’observateur. Cette formalisation s’appuie
sur la modélisation d’un observateur système et sur la définition d’une politique de contrôle
d’accès directe. En formalisant la notion d’observateur, nous pourrons spécifier un certain type
d’observateur nommé moniteur de référence. De plus, nous nous attacherons à détailler des mécanismes
de détournement d’interactions directes pour les systèmes Windows. Nous proposons un
modèle de répartitions des observateurs prenant en compte les modes d’association, de localisation
et de redondance. La définition d’une politique de contrôle d’accès directe passe par la réalisation
d’une grammaire générique spécifiant les traitements de l’observateur lors du détournement d’une
interaction. Cependant, la création de règles d’accès passe par une méthode précise pour identi-
fier de manière unique les ressources du système. Pour cela, nous proposerons l’utilisation des
noms symboliques absolus indépendants de la localisation. Cette grammaire générique est ensuite
appliquée à deux modèles de contrôle d’accès directs, PBAC (path based access control) et DTE
(domain and type enforcement).
Dans le chapitre 4, nous proposons une approche permettant d’analyser le surcoût dû à l’association
d’observateur au sein d’un système. Pour cela, nous définissons des points de mesure
ainsi qu’une modélisation permettant de connaître le temps pris par chaque élément de l’association.
Puis nous implantons une répartition d’observateurs dans un environnement HPC. Nous pré-
senterons une répartition colocalisée et distante pour l’association de SELinux avec PIGA. Nous
détaillerons notre architecture permettant de déporter le second observateur, tout en utilisant les
technologies spécifiques du HPC pour réduire l’impact d’une telle association sur les performances
du système. Enfin, nous appliquerons notre méthode pour mesurer le surcoût de la répartition des
observateurs à notre approche HPC. Nous discuterons ainsi la faisabilité d’une répartition d’obser-
231.6. PLAN DU MÉMOIRE
vateurs dans les environnements à haute performance sur la base de notre méthode d’évaluation
des performances.
Dans le chapitre 5, nous proposons une implantation d’un mécanisme de contrôle d’accès
obligatoire pour les systèmes Windows nommé SEWINDOWS basée sur les deux modèles de protection
considérés au chapitre 3. Dans une première section, nous définirons deux politiques de
contrôle d’accès directes, basées sur les deux modèles de protection que nous avons définis dans le
chapitre 3. Nous expliquerons les choix techniques que nous avons dûs faire et notre approche pour
implanter une désignation adaptée des ressources. Puis nous détaillerons les deux mécanismes de
détournement des flux que nous avons implantés, le premier détournant les appels système en modifiant
une table système et le second par l’intégration d’un filter-driver. Enfin, nous détaillerons
les expérimentations que nous avons faites sur les systèmes Windows. Les premiers tests nous
ont permis de valider notre mécanisme de contrôle d’accès en bloquant des attaques. Nous montrons
par la suite, qu’en l’associant avec PIGA, nous pouvons gérer des scénarios complets. Puis,
nous utilisons notre mécanisme de contrôle d’accès dans le but de pouvoir étudier les logiciels
malveillants. Pour cela, nous expliquerons l’architecture et les outils permettant d’exploiter les
résultats obtenus.
Enfin le chapitre 6 résume les apports de cette thèse ainsi que les perspectives possibles autour
des travaux que nous avons présentés tout au long de ce mémoire.
24Chapitre 2
État de l’art
Les problématiques de contrôle d’accès sont présentes sur tous les systèmes d’information.
Cette thèse s’intéresse plus spécifiquement aux problématiques de confidentialité et d’intégrité
qui font partie intégrante des critères d’évaluation de la sécurité, que ce soit au niveau international
[TCSEC, 1985] qu’au niveau européen [ITSEC, 1991]. Ce chapitre présente les travaux de
référence en lien avec cette thèse, c’est-à-dire les travaux portant sur les problématiques de contrôle
d’accès dans des systèmes hétérogènes.
Ce chapitre s’organise de la manière suivante. Une première partie propose une définition gé-
nérale des propriétés de sécurité que nous souhaitons garantir au sein d’un système d’information.
Cette partie détaille les fondements de la sécurité informatique concernant le contrôle d’accès. La
seconde partie s’attache à décrire les différents modèles de contrôle d’accès. Ces modèles ont été
définis pour répondre aux problématiques mises en jeu par la définition des propriétés de sécurité.
La troisième partie traite de la mise en œuvre de ces modèles de contrôle d’accès. Nous avons
séparé cette partie en deux : une première section traite des mécanismes présents sur les systèmes
d’exploitation Linux tandis que la seconde s’attache aux systèmes Windows. Enfin, une section
traitera de l’impact sur les performances de tels mécanismes. Au sein de la discussion, nous ré-
sumerons les faiblesses constatées et nous décrirons le contexte dans lequel nos travaux prennent
place.
2.1 Propriétés de sécurité
Les besoins en sécurité s’expriment grâce à des propriétés de sécurité au sein d’une politique.
La littérature définit trois grands types de propriétés de référence. Ces propositions sont dépendantes
du contexte, des besoins ou encore des utilisateurs. Nous donnons ici une synthèse des défi-
nitions exprimées dans les documents de références [TCSEC, 1985, ITSEC, 1991, Bishop, 2003].
Nous avons divisé l’expression des propriétés de sécurité en deux parties : la première partie donne
des définitions des trois grands types de propriétés de sécurité, dites générales, alors que la seconde
partie exprime les propriétés dérivées de celles-ci.
2.1.1 Propriétés générales
Les trois propriétés de sécurité que nous décrivons dans cette partie sont à la base de la définition
des objectifs de sécurité. Ces objectifs de sécurité expriment les besoins des entreprises et des
systèmes en termes de sécurité.
252.1. PROPRIÉTÉS DE SÉCURITÉ
2.1.1.1 Confidentialité
La propriété de confidentialité exprime le besoin de prévention des accès non autorisés
à l’information. Elle prévient la divulgation de l’information non autorisée comme le défi-
nit [Bishop, 2003]. Elle peut être exprimée de la manière suivante :
Définition 2.1.1 Confidentialité La confidentialité est la prévention des accès non autorisés à une
information.
La propriété de confidentialité implique que seules les entités autorisées peuvent accéder à
l’information. Cette propriété est le plus souvent appliquée dans les milieux de défense assujettis
à la classification de l’information. Cette information ne doit être accessible qu’aux personnes
disposant de l’habilitation nécessaire.
2.1.1.2 Intégrité
La propriété d’intégrité exprime la prévention de toute modification non autorisée d’une information.
Aucun traitement non autorisé ne doit modifier les données que ce soit lors de leur
stockage ou lors de leur transmission. Cette propriété implique aussi que les données ne doivent
être modifiées ni de manière volontaire ni de manière accidentelle.
Définition 2.1.2 Intégrité L’intégrité est la prévention des modifications non autorisées d’une
information.
Tout comme la propriété de confidentialité, la propriété d’intégrité implique que seules les
entités autorisées du système ont le droit de modifier l’information.
2.1.1.3 Disponibilité
La propriété de disponibilité repose sur la possibilité d’accès à une donnée ou à un service
à tout instant. Cette notion est à rapprocher de la fiabilité d’un système puisque si un service
n’est pas accessible, il est considéré comme défaillant. En matière de sécurité informatique, cette
défaillance peut se traduire par l’épuisement d’une ressource partagée entre plusieurs entités du
système.
Définition 2.1.3 Disponibilité La disponibilité est la prévention de la rétention d’information ou
d’un service.
Le contexte d’application peut faire varier le sens de cette définition. En effet, les systèmes
critiques ont des besoins très forts en termes de disponibilité alors qu’un site internet aura des
besoins moindres. Cette propriété de sécurité se rapprochant plus de la sûreté de fonctionnement
que de la sécurité, elle sort du cadre de notre étude.
2.1.2 Propriétés dérivées
Les propriétés générales de sécurité sont extrêmement difficiles à mettre en place. En effet, en
pratique, un système est parfaitement intègre et respecte la propriété de confidentialité s’il ne rend
aucun service. C’est pour cette raison qu’à partir des propriétés de confidentialité, d’intégrité et de
disponibilité, il est possible de dériver de nouvelles propriétés de sécurité plus spécifiques qui sont
applicables sur les systèmes actuels. Ces propriétés dérivées sont des cas particuliers des 3 types
précédents.
262.1. PROPRIÉTÉS DE SÉCURITÉ
2.1.2.1 Confinement de processus
La problématique du confinement des processus a été écrite par Lampson [Lampson, 1973].
Définition 2.1.4 Confinement de processus Le problème du confinement concerne la prévention
de la divulgation, par un service (ou un processus), d’informations considérées comme confidentielles
par les utilisateurs de ce service.
Dans la résolution de cette problématique, Lampson énonce les caractéristiques nécessaires à
un processus pour qu’il ne puisse pas divulguer d’information. Une des caractéristiques principales
est qu’un processus observable ne doit pas stocker d’informations. Si un processus stocke de
l’information jugée confidentielle et qu’un utilisateur peut observer ce processus, alors il existe un
risque d’échange d’information entre le processus observé et l’observateur.
Cette propriété est impérativement transitive par nature. Si un processus lance un nouveau
processus, et qu’il n’est pas possible d’avoir confiance en ce dernier, alors il est nécessaire que ce
nouveau processus soit confiné lui aussi.
Le modèle de Lampson décrit dans la pratique la propriété d’isolation totale, c’est-à-dire qu’un
processus ne peut pas échanger d’information par quelque moyen que ce soit avec d’autres processus.
Cette propriété est pratiquement inapplicable dans les systèmes d’exploitation classiques,
puisque les processus partagent des ressources comme le processeur, le matériel, etc. Il existe, de
plus, des moyens de communication entre processus appelés les canaux cachés.
Définition 2.1.5 Canaux cachés Les canaux cachés sont des moyens de communication entre
deux entités actives du système. Ce moyen de communication n’est pas un moyen légitime de
communication dans la conception du système.
Prenons comme un exemple deux processus p1 et p2 qui ne peuvent pas communiquer entre
eux. Le processus p1 souhaite envoyer de l’information au processus p2, pour cela, il va trouver
une ressource que les deux peuvent partager, comme un élément du système de fichiers. Il va ainsi
pouvoir jouer soit sur le nom du fichier pour transmettre une information, soit sur le contenu du
fichier. Par exemple, en créant des fichiers nommés 0, 1 et end, il va pouvoir transmettre, sous
la forme d’un code défini entre les deux processus, un message chiffré à destination du second
processus.
2.1.2.2 Moindre privilège
Le principe de moindre privilège a été défini par [Saltzer et Schroeder, 1975]. Il établit qu’une
entité active du système ne devrait s’exécuter sur le système qu’avec les privilèges nécessaires à
la réalisation de sa tâche. Ce principe s’applique aussi bien aux processus qu’aux utilisateurs du
système.
Définition 2.1.6 Moindre privilège Le principe de moindre privilège est la réduction des droits
accordés à une entité active du système. Ce nouvel ensemble de droits doit être suffisant pour que
l’entité puisse réaliser sa tâche.
Cette propriété permet de réduire le nombre d’interactions entre les processus privilégiés et
ainsi réduire les comportements potentiellement non désirés sur le système.
272.1. PROPRIÉTÉS DE SÉCURITÉ
2.1.2.3 Séparation des privilèges
Le principe de la séparation des privilèges établit que des actions privilégiées (modification de
la configuration, mises à jour, etc.) doivent être réalisées par des utilisateurs ou processus diffé-
rents. Une première définition a été donnée par [Clark et Wilson, 1987]. Ils proposent d’assurer la
cohérence des objets du système en faisant une représentation fidèle des objets du système vis-à-
vis de la réalité. Or, il n’est cependant pas possible que cette cohérence soit assurée par un système
informatique car les systèmes d’information n’ont pas des senseurs leur permettant d’analyser
l’environnement extérieur. Ils proposent donc de séparer les opérations en différentes sous-parties
et que chaque partie soit exécutée par des utilisateurs différents, en prenant l’exemple d’un processus
d’achat, qui est divisé en plusieurs parties réalisées par des personnes différentes : la personne
qui fait la demande, celle qui fait la commande, celle qui paye, etc. Il est possible d’assurer la
cohérence des objets avec la réalité.
Définition 2.1.7 Séparation des privilèges La séparation des privilèges implique que les privilèges
soient distribués sur l’ensemble des utilisateurs.
Dans un système d’exploitation, ce principe est généralement appliqué au niveau des processus
système. Les processus privilégiés qui créent des fichiers n’ont généralement pas le droit de
les exécuter par la suite. On peut aussi étendre cette définition en l’appliquant directement aux
utilisateurs.
2.1.2.4 Non-interférence
Le principe de non-interférence [Focardi et Gorrieri, 2001] implique que plusieurs processus
puissent s’exécuter simultanément sans interférer, c’est-à-dire sans modifier la vision des données
ou le comportement des autres processus.
Définition 2.1.8 Non-interférence La non-interférence est la possibilité pour une entité de s’exé-
cuter sur un système sans être influencée par une autre entité du système. Cette propriété se caractérise
par le fait que pour deux ensembles d’objets donnés, les données du premier ensemble
ne sont pas affectées par les actions faites sur le second ensemble.
2.1.3 Discussion
Les propriétés générales de sécurité permettent d’exprimer de manière informelle des objectifs
de sécurité précis. Dans le cas d’un système d’exploitation, ces propriétés sont, suivant les situations,
soient trop expressives et conduisent à un blocage du système, soient pas assez. Il a donc été
nécessaire de définir des propriétés de sécurité adressant des objectifs de sécurité plus spécifiques.
Ce sont ces raisons qui ont conduits les auteurs à définir des raffinements aux propriétés générales.
Elles sont plus précises et permettent de gérer des cas visant à compromettre la confidentialité ou
l’intégrité, voir des deux.
Nous illustrons, dans la figure 2.1, comment se positionnent les propriétés dérivées vis-à-vis
des propriétés générales. On peut ainsi noter que la propriété de non-interférence couvre à la fois
la disponibilité, l’intégrité et la confidentialité. La propriété de moindre privilège couvre, quant à
elle, les propriétés d’intégrité et de confidentialité.
Ces propriétés de sécurité, qu’elles soient générales ou dérivées, sont difficilement applicables
à l’ensemble d’un système d’information. En effet, il est difficile d’assurer par exemple, l’isolation
total d’un processus au sein d’un système sans en bloquer le fonctionnement. C’est pour cela
que nous allons maintenant voir les modèles de protections qui permettant en pratique de garantir
la confidentialité ou l’intégrité en spécialisant le contrôle pour certains éléments (processus,
ressources) du système.
282.2. MODÈLES DE CONTRÔLE D’ACCÈS
FIGURE 2.1 – Couverture des propriétés dérivées vis-à-vis des propriétés générales de sécurité
2.2 Modèles de contrôle d’accès
La mise en œuvre des propriétés de sécurité que nous venons de définir peut se faire soit en
utilisant des mécanismes cryptographiques soit en utilisant des mécanismes de contrôle d’accès.
Nous nous intéressons ici exclusivement aux mécanismes de contrôle d’accès des systèmes. Les
systèmes d’exploitation se basent sur divers éléments :
— un ensemble de sujets : ce sont les entités actives sur le système, essentiellement les processus
;
— un ensemble d’objets : ce sont les entités passives du système. Ces entités subissent les interactions
effectuées par les sujets. Cet ensemble regroupe toutes les ressources du système
(fichiers, socket, etc.).
— un ensemble de permissions : ce sont les interactions autorisées des sujets sur les objets
(lecture, écriture, etc.) ou entre sujets (envoi d’un signal).
Le contrôle d’accès est l’ensemble des règles qui associent à un sujet un ensemble de permissions
sur un objet. Des règles d’accès peuvent aussi exister entre deux sujets.
La manière la plus naturelle de représenter les règles d’accès est d’utiliser une matrice d’accès,
comme le montre la table 2.1. Dans cette matrice, les lignes contiennent les sujets, les colonnes
correspondent aux objets et l’intersection des deux contient l’ensemble des permissions du sujet
sur l’objet.
Objets
F ichier1 F ichier2 Repertoire1 Sujet3
Sujet1 Lecture, écriture Lecture Lecture, exécution Signaux
Sujet2 Lecture Lecture, écriture, exécution
Sujet3 Exécution Ecriture
TABLE 2.1 – Représentation règles d’accès sous la forme d’une matrice d’accès
2.2.1 Le contrôle d’accès discrétionnaire
Le contrôle d’accès discrétionnaire DAC est le contrôle d’accès que l’on retrouve sur la majorité
des systèmes d’exploitation (Linux, Windows et MacOS). Il laisse à la discrétion de l’utilisateur
le soin de gérer les accès sur les fichiers qu’il possède. Dans la pratique, les utilisateurs disposent
de commandes système leur permettant de définir les accès sur ces fichiers.
292.2. MODÈLES DE CONTRÔLE D’ACCÈS
2.2.1.1 Lampson
Le premier à avoir formalisé ce modèle de contrôle d’accès est Lampson. Il commence
par donner deux définitions : la première concerne les capacités et la seconde concerne les
listes de contrôle d’accès (Access Control List, ACL ). Ces deux définitions sont décrites
dans [Lampson, 1969]. [Lampson, 1971] affine ces définitions grâce à la modélisation de la notion
de matrice d’accès. Il propose de placer dans une matrice A, l’ensemble D des domaines
de protection qui représentent des contextes d’exécution pour les programmes (les sujets) sur les
lignes, et en colonnes l’ensemble X des objets (incluant les domaines).
Lampson donne des définitions de chaque terme. Un objet est une "chose" du système qui doit
être protégée. Cela peut être, par exemple, les processus, les domaines, les fichiers, etc. Les domaines
sont les entités du système qui ont accès aux objets. La propriété essentielle d’un domaine
est qu’il a des permissions différentes des autres domaines. De part cette définition, les domaines
sont donc aussi des objets. Les capacités (capabilities) sont des privilèges accordés aux domaines.
Sous Linux, ces privilèges scindent ceux du super-utilisateur en capacité que l’on peut accorder ou
interdire à chaque utilisateur.
Définition 2.2.1 Liste des capacités Étant donné un domaine d ∈ D, la liste des capacités pour
le domaine d est l’ensemble des couples (o, A[d, o]), ∀o ∈ X.
Définition 2.2.2 Liste de Contrôle d’Accès Étant donné un objet o ∈ X, la liste de contrôle
d’accès pour l’objet o est l’ensemble des couples (d, A[d, o]), ∀d ∈ D.
Lampson ajoute deux nouvelles capacités : le droit propriétaire et le droit de copie symbolisé
par *. Dans la table 2.2, le droit propriétaire ajouté au Domaine1 l’autorise à contrôler
les droits sur le F ichier1 pour l’ensemble des domaines. D’un point de vue de la matrice, il est
capable de modifier les droits sur l’ensemble de la colonne. Le droit de copie *, s’applique sur une
permission spécifique, autorisant le domaine qui possède cette capacité à recopier la permission
sur toute la colonne correspondante.
Objets
F ichier1 F ichier2 Repertoire1 P rocess1
Domaine1 Lecture, écriture, propriétaire Lecture Lecture, exécution Signaux
Domaine2 Lecture Lecture, écriture, exécution
Domaine3 Exécution *Ecriture
FIGURE 2.2 – Représentation de Lampson d’une matrice d’accès
Ce modèle a ensuite évolué vers le modèle HRU [Harrison et al., 1976].
2.2.1.2 HRU
Dans le modèle HRU [Harrison et al., 1976], les auteurs modélisent le contrôle d’accès discré-
tionnaire à partir d’une matrice P, qui représente l’ensemble des droits d’accès des sujets sur les
objets. Les sujets peuvent créer des sujets, des objets et modifier les permissions.
Les auteurs du modèle HRU proposent de modéliser le contrôle d’accès de la manière suivante :
— l’ensemble des sujets S et l’ensemble des objets O ;
— l’ensemble des droits génériques R tels que possession, lecture, écriture, exécution ;
— une configuration de protection système repose sur le triplet (S, O, P);
— une matrice de contrôle d’accès P ;
— un ensemble fini C de commandes c1, ... , cn, représente l’ensemble des opérations fournies
par le système d’exploitation (création de fichier, modification des droits...) ;
302.2. MODÈLES DE CONTRÔLE D’ACCÈS
— un ensemble d’opérations élémentaires E : enter et delete pour l’ajout et la suppression de
droits, create subject et create object pour la création de nouveaux sujets et objets et enfin
destroy subject et destroy object pour la destruction de sujets et objets.
Afin d’étudier le problème de la sûreté d’un système de protection, HRU s’intéresse au transfert
de privilège (droit), qui se produit lorsqu’une commande insère un droit particulier r, dans une
case de la matrice P où il était précédemment absent. La problématique de sûreté d’un système
de protection se définit ainsi : étant donné une configuration initiale de la politique de sécurité,
un système est considéré comme sûr pour un droit r si aucune des commandes de ce système ne
provoque le transfert du droit r.
Les auteurs prouvent que lorsque les commandes ne contiennent qu’une seule action élémentaire,
le problème de sûreté est décidable mais l’algorithme de vérification est NP-Complet. Ce
modèle mono-opérationnel n’est pas du tout représentatif des systèmes courants. Dans le cas gé-
néral, le problème de la protection d’un système est indécidable. Le problème est néanmoins de
taille polynomiale si on retire les opérations de création de sujet et d’objet du modèle de protection.
Dans le cas d’un système d’exploitation, le problème de la vérification d’un contrôle d’accès
discrétionnaire est indécidable. Ce résultat prouve qu’il n’est pas possible de garantir des propriétés
de sécurité avec un contrôle d’accès discrétionnaire.
2.2.1.3 TAM
Le modèle TAM (Typed Access Matrix) exprimé par [Sandhu, 1992], propose une extension
du modèle HRU en intégrant la notion de typage fort. Cette notion provient de travaux plus anciens
de SPM (Sandhu’s Schematic Protection Model) [Sandhu, 1988] et se traduit par l’attachement de
types de sécurité immuables à tous les sujets et objets du système.
Le modèle HRU est enrichi d’un nouvel ensemble T des types de sécurité. Cet ensemble est
un ensemble fini, c’est-à-dire qu’il n’est pas possible de créer de nouveaux types. La gestion des
types est prise en compte dans les opérations élémentaires décrites pour le modèle HRU.
L’auteur s’intéresse ensuite à la version monotone du modèle TAM, MTAM (Monotonic Typed
Access Matrix) qui se caractérise par la suppression des opérations de suppression (droits, sujets et
objets). À partir du modèle MTAM, il démontre que le problème de sûreté de fonctionnement est
décidable car le graphe de création des sujets et des objets est acyclique. Cependant, la complexité
du problème reste NP. C’est pourquoi Sandhu définit le modèle MTAM ternaire, dans lequel toutes
les commandes ont au maximum trois arguments. Au prix d’une perte d’expressivité, le problème
de sûreté voit sa complexité ramenée à un degré polynomial.
En pratique, ce modèle théorique est difficilement applicable car il revient à ne jamais modifier
la politique de contrôle d’accès.
2.2.1.4 DTAM
La modèle DTAM (Dynamic-Typed Access Matrix) est exprimé par [Soshi et al., 2004]. Ils
proposent une extension du modèle TAM. Le but de ce modèle est d’autoriser les types des objets
à être changé de façon dynamique, à la différence du modèle TAM où ils sont statiques. De
plus, ce modèle permet de décrire les systèmes de protection non-monotonique pour lesquels la
problématique de sûreté est décidable.
Le modèle se base sur le modèle TAM à l’exception que les objets peuvent changer de types de
façon dynamique et que l’ensemble des types est un fini. Les auteurs ajoutent donc des commandes
supplémentaires aux commandes définies par HRU telles que change type of subject et change
type of object.
Les auteurs du modèle DTAM démontrent que la sûreté du système de protection est décidable
en s’appuyant sur le fait que la commande create génère des changements irréversibles sur les
312.2. MODÈLES DE CONTRÔLE D’ACCÈS
types des objets parents. Cela signifie que lorsqu’un domaine crée un objet via la commande
create, le domaine change aussi de types. De plus, un objet ne peut avoir un type qu’il a possédé
auparavant, donc le nombre de changements de types pour un objet est fini puisque le nombre
de types est fini. Par conséquence, le problème de sûreté devient décidable dans ce modèle. Il
est à noter que dans ce modèle, il est possible que le système atteigne un état dans lequel il ne
puisse plus créer de nouveaux objets lorsque tous les objets du système ont utilisés tous les types
possibles.
Cela revient à avoir une politique figée où l’on ne peut définir de nouveaux types. Ce modèle
théorique est donc aussi difficilement utilisable en pratique.
2.2.2 Le contrôle d’accès obligatoire
Le contrôle d’accès discrétionnaire laisse l’utilisateur final décider des permissions sur les
objets qu’il possède. Les différents modèles de contrôle d’accès discrétionnaire ne permettent
pas d’avoir un système sûr. [Anderson, 1972] détaille le fait qu’il est possible de se protéger des
attaques extérieures par l’ajout d’outils, mais qu’il n’est pas possible de se protéger des attaques
venant de l’intérieur. Ces attaques peuvent être malicieuses ou accidentelles.
Il est donc nécessaire d’imposer une politique de contrôle d’accès aux utilisateurs du système,
en utilisant un modèle de contrôle d’accès obligatoire (MAC, Mandatory Access Control). Cette
politique ne doit pas pouvoir être modifiée par les utilisateurs finaux. [Anderson, 1980] propose
l’utilisation d’un Moniteur de Référence. Ce moniteur de référence propose une base de confiance
associée à une matrice d’accès qui précise de manière explicite tous les accès autorisés ou refusés
au sein du système. De part son caractère non-modifiable par les utilisateurs finaux, le moniteur
permet de garantir des propriétés associées à la matrice d’accès.
Cette thèse ayant pour objectifs de permettre aux systèmes d’exploitation de garantir des propriétés
de sécurité, nous nous focaliserons uniquement sur les modèles de contrôle d’accès obligatoire
proches de nos objectifs. D’autres modèles tels que le modèle de Clark-Wilson, de la muraille
de chine, sont décrits dans [Rouzaud-Cornabas, 2010].
2.2.2.1 Bell-LaPadula
Le modèle de Bell-LaPadula (BLP ), défini par [Bell et La Padula, 1973], formalise la propriété
de confidentialité des données dans les milieux de défense. En plus des notions classiques de sujet,
d’objet et de permissions, ce modèle introduit la notion de label. Ce label est un niveau de sécurité,
qui va contenir deux types d’identifiant de sécurité. Le premier élément est le niveau hiérarchique,
qui renseigne sur le niveau de classification de l’objet ou sur le niveau d’habilitation du sujet. Le
second élément est un identifiant de catégories, qui renseigne sur le type de population capable de
manipuler les informations comme public, privé ou militaire. Ces identifiants sont indépendants
de la hiérarchie de confidentialité.
À partir de ces niveaux de sécurité, il est possible de définir deux règles qui régissent le système
en plus des mécanismes de contrôles d’accès classiques.
— ss-property : simple security property. Cette propriété assure qu’un sujet qui demande un
accès en lecture sur un objet du système possède un niveau de sécurité supérieur ou égal à
celui de l’objet.
— *-property : star property. Seuls les transferts d’informations depuis des objets de classification
inférieure vers des objets de classification supérieure sont autorisés. Cette règle
assure donc la prévention contre la divulgation d’informations.
Le système est modélisé de la façon suivante :
— un ensemble de sujet S ;
— un ensemble d’objets O ;
322.2. MODÈLES DE CONTRÔLE D’ACCÈS
— une matrice d’accès M ;
— une fonction donnant le niveau f.
On dispose également d’un ensemble de permissions d’accès A = {e, r, a, w}. Elles sont
classées suivant leur capacité d’observation (lecture) et d’altération (écriture) de l’information :
— execute : e Ni observation ni altération ;
— read : r Observation sans altération ;
— append : a Altération sans observation ;
— write : w Observation et altération.
On obtient ainsi les deux lois suivantes :
ss-property :r ∈ M[s, o] → f(s) ≥ f(o)
*-property :r ∈ M[s, o1] ∧ w ∈ M[s, o2] → f(o2) ≥ f(o1)
FIGURE 2.3 – Lois d’application des propriétés de BLP
Cependant, la propriété *-property peut être contournée en exploitant les canaux cachés pré-
sents sur le système. Ces canaux cachés échappent complètement au mécanisme de contrôle d’accès
présent sur le système. Afin de prévenir ce genre de problème, une version plus restrictive de
la politique de BLP utilise les règles suivantes :
— No Read Up : cette propriété assure qu’un sujet qui demande un accès en lecture sur un
objet du système possède un niveau de sécurité supérieur ou égal à celui de l’objet.
— No Write Down : cette propriété assure qu’un sujet qui demande à modifier un objet
possède bien un niveau de sécurité inférieur ou égal à celui de l’objet.
Les trois lois sur les niveaux, illustrées par la figure 2.5, s’écrivent ainsi :
r ∈ M[s, o] → f(s) ≥ f(o)
a ∈ M[s, o] → f(s) ≤ f(o)
w ∈ M[s, o] → f(s) = f(o)
FIGURE 2.4 – Lois d’application des propriétés de BLP-restrictives
Ces lois signifient que :
1. un sujet s a accès en lecture à un objet o si et seulement si son niveau d’habilitation f(s)
est supérieur ou égal au niveau de classification f(o) de l’objet ;
2. un sujet s a accès en écriture seul (ajout) à un objet o si et seulement si son niveau d’habilitation
est inférieur ou égal au niveau de classification de l’objet ;
3. un sujet s a accès en lecture/écriture à un objet o si et seulement si son niveau d’habilitation
est égal au niveau de classification de l’objet.
La figure 2.5 illustre comment se caractérise l’application de ce modèle de protection pour les
utilisateurs. Pour qu’un utilisateur puisse accéder à une information, c’est-à-dire puisse la lire, il
doit posséder un niveau d’habilitation supérieur ou égal à celui de l’objet. Si un utilisateur veut
modifier une information, il doit posséder un niveau d’habilitation inférieur ou égal à celui de
l’objet.
Ce modèle est difficilement intégrable dans les systèmes d’exploitation courant. En effet, il
est difficile de définir des labels pour certains objets du système qui doivent être partagés entre
les différents utilisateurs et le système. On peut ainsi citer les répertoires temporaires. Il existe
des mécanismes d’aménagement de ce modèle pour le rendre utilisable. Ces mécanismes (trusted
subjects) font transiter les objets vers un niveau de sécurité suffisant pour qu’ils puissent être
modifiés par les sujets ayant un niveau de sécurité plus élevé. Ainsi la propriété de No Write
Down n’est pas enfreinte. Cependant, ces mécanismes conduisent à faire monter l’information au
332.2. MODÈLES DE CONTRÔLE D’ACCÈS
niveau de la confidentialité la plus élevée, ce qui oblige alors à des déclassifications complexes.
Actuellement, peu de systèmes d’exploitation adoptent ces approches pour l’ensemble du système
même si certaines solutions utilisent la classification sous un autre angle.
No Read Up
Top Secret
Secret
Confidentiel
No Write Down
FIGURE 2.5 – Modèle No Read Up/No Write Down
2.2.2.2 Biba
Le modèle de BLP traite le problème de la confidentialité des données du système, mais ne
propose pas de solution pour protéger l’intégrité de ces données et du système. C’est pour cette
raison que Biba a défini un modèle dual à celui de BLP qui formalise les besoins en intégrité d’un
système [Biba, 1975]. Tous les sujets et les objets possèdent un niveau d’intégrité. C’est à partir de
ce niveau d’intégrité que de nouvelles restrictions sont mises en place sur le système. De manière
similaire au modèle de BLP, il propose aussi deux propriétés.
— No Read Down : cette propriété assure qu’un sujet qui demande un accès en lecture sur
un objet du système possède un niveau d’intégrité inférieur ou égal à celui de l’objet.
— No Write Up : cette propriété assure qu’un sujet qui demande un accès en écriture sur un
objet du système possède un niveau d’intégrité supérieur ou égal à celui de l’objet.
Les lois s’écrivent donc :
r ∈ M[s, o] → f(s) ≤ f(o)
a ∈ M[s, o] → f(s) ≥ f(o)
w ∈ M[s, o] → f(s) = f(o)
FIGURE 2.6 – Lois d’application des propriétés de Biba
Ces lois signifient que :
1. un sujet s a accès en lecture à un objet o si et seulement si son niveau d’intégrité f(s) est
inférieur ou égal au niveau d’intégrité f(o) de l’objet ;
2. un sujet s a accès en écriture à un objet o si et seulement si son niveau d’intégrité est
supérieur ou égal au niveau d’intégrité de l’objet ;
3. un sujet s a accès en lecture/écriture à un objet o si et seulement si son niveau d’intégrité
est égal au niveau d’intégrité de l’objet.
342.2. MODÈLES DE CONTRÔLE D’ACCÈS
Ces règles évitent que se produise un transfert d’information d’un niveau d’intégrité bas vers
un niveau d’intégrité haut, ce qui signifierait une compromission de l’intégrité du niveau haut.
La figure 2.7 illustre l’application du modèle de protection de Biba.
Tout comme le modèle proposé par BLP, le modèle de Biba est difficilement intégrable sur un
système d’exploitation courant. En effet, pour que le système soit fonctionnel, il est nécessaire de
définir des mécanismes modifiant les niveaux d’intégrité de certains sujets du système. Par cette
modification de leur niveau d’intégrité, les sujets sont naturellement descendus vers le niveau d’intégrité
le plus bas. De plus, le modèle de Biba interdit les accès non autorisés aux ressources mais
pas les mauvaises modifications réalisées par des utilisateurs autorisés [Clark et Wilson, 1987].
No Read Down
Niveau d’intégrité haut
Niveau d’intégrité moyen
Niveau d’intégrité bas
No Write Up
FIGURE 2.7 – Modèle de protection des données : Biba
2.2.2.3 Role Based Access Control
L’administration d’un mécanisme de contrôle d’accès obligatoire est difficile pour un administrateur.
Cela implique l’écriture et la gestion d’un grand nombre de règles. L’écriture des politiques
de contrôle d’accès peut se révéler extrêmement difficile et coûteuse en termes de temps.
Le modèle de contrôle d’accès basé sur les rôles (RBAC ) propose une solution pour diminuer cette
complexité d’écriture.
Dans la majorité des cas, les permissions d’accès ne sont pas accordées directement en
fonction des utilisateurs mais plutôt par rapport à leur activité dans l’entreprise comme le
montre [Ferraiolo et Kuhn, 1992]. Ce modèle représente les activités par des rôles.
Par la suite, un modèle plus formel a été défini par [Sandhu et al., 1996], qui se nomme
RBAC0. Les utilisateurs peuvent accéder à un ensemble de rôles. Puis, ce sont ces rôles qui sont
associés à des permissions dans le but d’effectuer des actions sur le système d’exploitation. Enfin,
l’utilisateur exerce son activité dans le cadre de sessions, durant lesquelles il peut activer un sousensemble
des rôles auxquels il appartient. Ainsi, les politiques de contrôle d’accès s’établissent à
partir des autorisations données aux rôles plutôt qu’aux utilisateurs.
A partir de ce modèle, une notion de hiérarchie des rôles a été mise en place dans
[Sandhu et al., 1996], modèle nommé RBAC1. Cette hiérarchie permet d’avoir un héritage des
permissions dans les rôles, suivant la place de la personne dans l’entreprise. Comme le montre la
figure 2.8, on retrouve le junior en bas du diagramme et il ne possède que peu de permissions.
Alors que le senior est lui placé en haut du diagramme et hérite de toutes les permissions des rôles
intermédiaires entre le junior et le senior.
352.2. MODÈLES DE CONTRÔLE D’ACCÈS
Junior
Senior
Rôle
intermédiaire
Rôle
intermédiaire
FIGURE 2.8 – Schéma d’héritage du modèle RBAC1
À partir du modèle RBAC0, [Sandhu et al., 1996] définit un troisième modèle nommé
RBAC2 qui introduit le support des contraintes. L’objectif de ce support est de modéliser les
contraintes des rôles qui peuvent être totalement disjoints.
Les types de contraintes supportés dans RBAC2 sont généralement des considérations
simples. Elles portent soit sur l’attribution des rôles aux utilisateurs, soit sur l’attribution des permissions
aux rôles. Les principaux types de contraintes sont les suivants :
— rôles mutuellement exclusifs : un utilisateur ne peut être affecté qu’à un seul rôle dans
un ensemble de rôles mutuellement exclusifs. Il s’agit d’une propriété de séparation des
privilèges ;
— cardinalité : contrainte sur le nombre maximal d’utilisateurs affectés à un rôle ;
— rôles prérequis : contrainte qui impose un prérequis pour l’ajout d’un utilisateur dans un
rôle. Par exemple, un utilisateur doit faire partie d’un certain rôle pour pouvoir être ajouté
dans le nouveau.
Le modèle RBAC3 [Sandhu et al., 1996] permet de consolider les trois modèles précédents.
Il supporte donc à la fois les hiérarchies de rôles et les contraintes sur l’assignation des rôles et
des permissions. L’objectif de ce dernier modèle est de résoudre les problèmes soulevés par la
cohabitation de ces deux concepts : support des contraintes sur la hiérarchie de rôles, résolution
de conflits entre l’héritage et les contraintes (par exemple quand un rôle hérite de deux rôles mutuellement
exclusifs). En pratique, les systèmes d’exploitation utilisent la notion de rôle de façon
simplifiée. L’utilité est alors une factorisation d’un ensemble de règles pour différents utilisateurs
en une règle associée à un rôle. L’objectif est de regrouper les utilisateurs dans des rôles pour
ensuite établir les règles par rapport à ces rôles et non plus par rapport aux utilisateurs.
2.2.2.4 Domain and Type Enforcement
Le modèle de protection Domain and Type Enforcement(DTE ) [Boebert et Kain, 1985] est un
modèle basé sur une abstraction des ressources du système, créé spécifiquement pour écrire des
politiques MAC. Ce modèle ne s’appuie pas sur les notions de sujets et d’objets mais sur celles de
domain et de type pour distinguer les entités actives et passives du système. Un type est une chaîne
de caractères qui caractérise une ressource du système.
La figure 2.9 montre que ce modèle autorise les interactions d’un domaine sur un type, mais
aussi les interactions entre les domaines.
Le modèle de protection établit par DTE diffère de BLP ou Biba. Alors que ces deux modèles
implantent une des propriétés générales de sécurité, le modèle DTE répond à la problématique de
362.2. MODÈLES DE CONTRÔLE D’ACCÈS
domaine 1
domaine 2
domaine 3
type 1
type 2
type 3
domaine 4
FIGURE 2.9 – Schéma du modèle DTE
contrôle des activités des processus. En effet, ce modèle permet de définir précisément les accès
autorisés aux domaines.
Le modèle DTE permet donc de répondre à deux objectifs de sécurité :
— restreindre les ressources accessibles par un processus : ce modèle s’applique à l’ensemble
du système, même aux processus tournant avec des privilèges élevés. C’est aussi une approche
de moindre privilège telle que définie précédemment ;
— établir un contrôle strict des processus ayant accès aux ressources jugées sensibles et empêcher
tout programme non autorisé à y accéder.
Les entités actives du système s’exécutent dans un domaine précis alors que les objets du
système possèdent tous un type. Ainsi, les lois d’accès opèrent entre les domaines et les types. Ce
modèle se base aussi sur la notion de matrice d’accès. Le modèle DTE détermine trois tables :
— la table de typages, qui associe un type à chaque objet du système ;
— la table de définition des domaines qui détermine les droits d’accès (lecture, écriture, exé-
cution, ajout, suppression) de chaque domaine sur les différents types ;
— la table d’interaction des domaines qui établit les droits d’accès entre domaines (création,
destruction, envoi de signal).
La table de définitions des domaines détermine aussi le type d’un programme. L’exécution
d’un programme binaire fait entrer le processus dans un domaine précis. Ce modèle a le mérite
d’être facile à mettre en œuvre et correspond à la notion de moniteur de référence et de confiance.
Il permet de garantir un large ensemble de cas particuliers de confidentialité et d’intégrité. Le
principal problème concerne les propriétés incluses dans la politique qui ne sont pas définies au
moyen d’un formalisme de haut niveau, ce qui peut rendre leur écriture difficile.
2.2.3 Discussion
Nous venons de détailler dans les deux premières parties de cet état de l’art les moyens
d’expression d’objectifs de sécurité et des modèles d’application. Les propriétés de sécurité
exprimées ici sont des synthèses des définitions que nous pouvons retrouver dans les documents
[ITSEC, 1991, TCSEC, 1985].
Les modèles de contrôle d’accès que nous avons présentés offrent des modélisations des objectifs
de sécurité. La première remarque que nous pouvons faire est qu’aucun modèle de protection
n’implante toutes les propriétés de sécurité que nous avons évoquées.
Dans les systèmes d’exploitation courants tels que Linux, MacOs et Windows, nous retrouvons
le DAC. Ce modèle de protection ne permet ni de protéger le système, ni les données qu’il héberge.
[Harrison et al., 1976] a démontré que la problématique de sûreté de fonctionnement pour un sys-
372.3. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS
tème se reposant sur le contrôle d’accès discrétionnaire n’était décidable qu’au prix de grandes
simplifications qui ne correspondent pas à la réalité des systèmes. Dans le cas des systèmes courants,
le problème de sûreté n’est donc pas décidable.
Les modèles de contrôle d’accès obligatoire offrent des réponses à la problématique de garantie
par le système d’exploitation de propriétés de sécurité. La plupart de ces modèles ont été établis
pour répondre à des problématiques du monde de défense, c’est-à-dire extrêmement spécifiques
et contraignantes. L’implantation réelle de ces modèles dans des systèmes existent, par exemple
le modèle de BLP dans MULTICS, on le trouve également dans certaines versions de Solaris,
HPUX ou autres systèmes UNIX. Cependant, pour les systèmes d’exploitation courants, ils sont
difficilement intégrables car il est nécessaire de créer des exceptions qui mettent le modèle de
protection à mal. De plus, ces systèmes ne traitent que d’un cas particuliers des propriétés de
sécurité qui est la confidentialité.
Le modèle RBAC offre peu d’application pratique en termes de systèmes d’exploitation et
sert essentiellement à la factorisation des règles de contrôle d’accès. Enfin, le modèle DTE est
le plus flexible. S’il n’est pas dédié à une propriété particulière, il permet d’écrire des politiques
incluant un large ensemble de propriétés de confidentialité et d’intégrité entre les processus et les
ressources, tout en minimisant les privilèges des processus.
2.3 Implantation des mécanismes de contrôle d’accès
Dans cette section, nous allons nous intéresser à l’implantation des mécanismes de contrôle
d’accès obligatoire présents à la fois sous Linux et sous Windows. Il existe d’autres implantations
présentes sur les systèmes Android, Solaris, etc, mais ces systèmes sortent du cadre de notre étude.
Sur les systèmes d’exploitation Linux, il existe un plus grand nombre d’implantations de mécanismes
de contrôle d’accès obligatoire que sous Windows car son code source est ouvert. Comme
l’objet de cette étude n’est pas de décrire l’implantation de chaque mécanisme présent sous Linux,
nous nous restreindrons à quatre implantations de références. Nous avons choisi de décrire
SELinux, grsecurity, Tomoyo et PIGA. SELinux et grsecurity font partis des mécanismes les plus
anciens et les plus matures sur les systèmes Linux. Leur intégration au sein du système d’exploitation
est aussi différente. Nous détaillons aussi Tomoyo et PIGA qui sont deux mécanismes
différents des deux premiers et qui ne réalisent pas le même type de contrôle. Une description des
projets MEDUSA, RSBAC et LIDS, offrant d’autres implantations de contrôle d’accès obligatoire,
est présente dans la thèse [Blanc, 2006].
Sur les systèmes d’exploitation Windows, nous nous attacherons à détailler le mécanisme de
contrôle d’intégrité (Mandatory Integrity Control, MIC) mis en place par Microsoft à partir des
systèmes d’exploitation Windows Vista. Nous avons aussi choisi de décrire PRECIP, qui est une
implantation restrictive du modèle de BLP ainsi que Core Force, le premier mécanisme MAC apparu
sous Windows XP.
2.3.1 Linux
Dans cette partie, nous allons traiter des mécanismes de contrôle d’accès obligatoire sur les
systèmes Linux.
2.3.1.1 SELinux
SELinux(Security-Enhanced Linux) est un mécanisme de contrôle d’accès obligatoire créé
par la NSA et intégré nativement dans les noyaux Linux. Il est proposé sous la forme de module
382.3. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS
de sécurité s’interfaçant avec les crochets de sécurité (Security Hooks) du noyau (Linux Security
Module (LSM ) [Wright et al., 2002]).
Basé sur le modèle de DTE, SELinux implante les propriétés de moindre privilège et de confi-
nement des processus pour garantir la confidentialité et l’intégrité. Son architecture est basée sur
FLASK [Spencer et al., 1998], une architecture spécifiquement créée pour SELinux, qui offre une
couche d’abstraction entre le système et le mécanisme de contrôle d’accès sous-jacent, transformant
les ressources du système en contexte de sécurité. Ainsi les ressources du système ne sont
pas identifiées par leur nom ou par leur chemin, mais par des contextes de sécurité.
L’écriture d’une politique SELinux étant complexe, SELinux utilise également le modèle
RBAC pour réduire la taille de la politique. Ainsi, les utilisateurs sont associés à des rôles qui
peuvent ensuite accéder à des domaines, et ce sont les domaines qui agissent sur les types.
Modèle général
Chaque utilisateur du système (utilisateur standard, mais aussi administrateur) est associé à
une identité SELinux unique. Cette identité SELinux peut être partagée par plusieurs utilisateurs.
L’identité SELinux est associée à un rôle par défaut, mais elle peut aussi accéder à un ensemble de
rôles. Les utilisateurs ont la possibilité de changer de rôle sans changer de session ou de compte
utilisateur. Les rôles accèdent ensuite aux domaines.
Chaque ressource du système possède un contexte de sécurité qui la caractérise. Le contexte
de sécurité est considéré comme une couche d’abstraction entre les ressources et le mécanisme de
contrôle d’accès. Il contient les informations nécessaires au modèle DTE (domaines ou types).
Contextes de sécurité
L’architecture FLASK crée une couche d’abstraction pour la représentation du système qui lui
permet de n’être qu’une interface entre le système d’exploitation et le mécanisme de contrôle d’accès
sous-jacent. Cette abstraction permet l’association de contextes de sécurité avec les ressources
du système.
Les contextes de sécurité sont définis par le serveur de sécurité qui constitue un moniteur de
référence au sens d’Anderson. Pour SELinux, un contexte de sécurité est constitué de plusieurs
attributs :
— une identité qui est liée aux identités des utilisateurs Linux présents sur le système. Ainsi,
plusieurs utilisateurs standards peuvent avoir la même identité SELinux. Cette identité SELinux
a la particularité de ne pas pouvoir être modifiée aux cours des interactions réalisées.
Seuls certains programmes d’authentification ont la capacité de pouvoir changer les identités
SELinux ;
— un rôle : un utilisateur SELinux a accès à un ensemble de rôles. Ce sont ces rôles qui
déterminent les interactions autorisées pour l’utilisateur ;
— un domaine, qui est le domaine d’exécution du processus ;
— un type, qui est le type d’un objet du système autre qu’un processus ;
— une catégorie : cet attribut est la représentation de l’implantation du modèle MultiCategorie
Security de SELinux. Il permet de définir des conteneurs pour les utilisateurs
dans le but de les isoler les uns des autres. Les catégories permettent d’isoler des populations
ayant la même identité SELinux. Il est possible d’avoir plusieurs catégories pour un
même contexte de sécurité.
— un niveau d’habilitation : cet attribut est l’application du modèle de BLP. Les niveaux
d’habilitation peuvent être une valeur unique ou une plage de niveaux. C’est l’implantation
du modèle Multi-Level Security de SELinux.
392.3. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS
Un contexte de sécurité est représenté au niveau du système de fichiers par une chaîne de
caractères de la manière suivante : id:rôle:type:catégories:sensibilités.
Un utilisateur possède une identité SELinux de part son identité standard Linux. Cette identité
SELinux lui permet d’accéder à certains nombres de rôles SELinux. Ces rôles peuvent accéder à
des domaines. Les domaines peuvent à leur tour accéder à d’autres domaines ou à des types. Ce
modèle est illustré par la figure 2.10.
Identité
SELinux
Domaine
Rôle SELinux
Type
Domaine
Domaine
Type
Type
Rôle SELinux
Changement
de rôle
Transition
FIGURE 2.10 – Implantation des modèles RBAC et DTE par SELinux
Pour les objets du système, les contextes de sécurité sont stockés dans le système de fichiers
au niveau des attributs étendus.
Politique et règle de contrôle d’accès
Les domaines effectuent des interactions sur les objets du système qui possèdent tous un type.
Une interaction se caractérise par la règle suivante D − (P)− > T, ou D est le domaine, P les
permissions et T le type. Le cas spécifique d’une interaction entre deux domaines se traduit de
manière similaire D1 − (P)− > D2.
La politique de contrôle d’accès de SELinux se divise en deux. D’un côté, nous trouvons
les règles faisant la correspondance entre les ressources du système et leur contexte de sécurité
spécifique. De l’autre, nous trouvons les règles d’accès et de transition.
Les règles d’accès définissent de manière explicite les interactions autorisées par des domaines
sur des types du système. Les règles de transition sont les règles qui autorisent la création de
nouveau domaine à partir de type spécifique.
La définition d’une règle d’accès dans la politique SELinux se fait donc de la manière suivante
2.1.
✞ ☎
1 allow linpack_t etc_t:file { read open getattr };
✝ ✆
Listing 2.1 – Règle d’accès dans une politique SELinux
Cette règle autorise (allow) le domaine linpack_t à lire, ouvrir et récupérer les attributs des
fichiers file { read open getattr } ayant pour type etc_t. Concrètement, cette règle autorise un
processus ayant pour domaine linpack_t à aller lire des fichiers de configurations présents dans
/etc.
Pour autoriser le rôle staff_r à accéder au domaine linpack_t, il suffit d’ajouter la règle 2.2.
✞ ☎
1 role staff_r types linpack_t;
✝ ✆
Listing 2.2 – Règle d’autorisation pour un rôle pour accéder à un type dans une politique SELinux
402.3. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS
Le dernier type de règle concerne les transitions. Ce sont des opérations spécifiques qui surviennent
lors de la création d’un nouveau domaine. La définition d’une règle de transition se définit
de la manière suivante 2.3 :
✞ ☎
1 type_transition staff_t mozilla_exec_t:process mozilla_t;
✝ ✆
Listing 2.3 – Règle de transition dans une politique SELinux
Cette règle autorise le domaine staff_t à faire transiter un type mozilla_exec_t vers le domaine
mozilla_t. Cette règle est par exemple, appliquée lorsqu’un utilisateur du staff exécute le
programme Firefox.
2.3.1.2 grsecurity
grsecurity [Spengler, 2002] est un mécanisme de contrôle d’accès obligatoire présent sur les
systèmes d’exploitation Linux. À la différence de SELinux, il n’est pas inclus dans la version
courante du noyau car il n’utilise pas les LSM comme le préconise les développeurs du noyau.
Il est donc disponible sous la forme d’un correctif noyau. En plus d’un mécanisme de contrôle
d’accès, grsecurity fournit un second correctif noyau nommé PaX, qui offre des protections contre
les attaques de type buffer overflow[Team, 2012].
Modèle général
Comme pour SELinux, grsecurity permet de définir des ensembles de règles puis d’affecter ces
ensembles à des rôles. En effet, sans cette notion de rôles, tous les utilisateurs auraient les mêmes
droits. Un utilisateur peut changer de rôle au sein d’une même session.
À la différence de SELinux qui associe un contexte de sécurité à chaque ressource du système,
grsecurity identifie les ressources en utilisant leur chemin complet dans l’arborescence du
système de fichiers. Ce modèle de protection se nomme Path-Based Access Control (PBAC ). Les
interactions sont représentées par les ACL définies sur les objets pour chaque sujet. Par défaut, un
nouveau processus hérite des permissions de son père, à part s’il possède un jeu de permissions
spécifiques.
Politique et règle de contrôle d’accès
La politique de contrôle d’accès de grsecurity s’appuie donc sur les chemins complets des
sujets (binaires exécutés correspondant à l’application) et des objets pour établir les règles de
contrôle d’accès. Chaque règle associe à un sujet, un objet ainsi que les ACL autorisées sur cet
objet. grsecurity permet aussi de gérer les capabilities POSIX [ Alexander Kjeldaas, 1998] ainsi
que les quantités de ressources utilisables [Spender, 2003].
Par défaut, chaque sujet et objet hérite des droits de son père. Ainsi, un fichier créé héritera
des permissions du répertoire dans lequel il est. Il est naturellement possible de briser cet héritage
pour définir des permissions spécifiques à ces nouveaux objets.
Un règle d’accès dans une politique grsecurity se définit de la manière suivante 2.4.
✞ ☎
1 subject /usr/bin/sudo
2 /dev/log rw
✝ ✆
Listing 2.4 – Règle d’accès dans une politique grsecurity
Cette règle autorise le sujet ayant pour chemin complet /usr/bin/sudo à lire et écrire (rw)
l’objet ayant pour chemin /dev/log.
grsecurity est aussi capable de gérer les capacités des programmes. Il est donc possible d’ajouter
ou d’enlever des capacités aux programmes, comme l’illustre le listing 2.5.
412.3. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS
✞ ☎
1 subject /sbin/syslog-ng
2 +CAP_SYS_ADMIN
3
4 subject /usr/sbin/sshd dpo
5 -CAP_ALL
6 +CAP_CHOWN
✝ ✆
Listing 2.5 – Règle de modification de capabilities dans une politique grsecurity
2.3.1.3 Tomoyo
Tomoyo [Corporation, 2003, Takeda, 2009] est un mécanisme de contrôle d’accès obligatoire
apparu en 2003. Depuis la version 2 de Tomoyo sortie en 2007, il utilise les LSM pour réaliser ses
contrôles.
Modèle général
Tomoyo reprend la notion de domaine énoncée par [Lampson, 1971], c’est-à-dire qu’un domaine
regroupe un ensemble d’entités actives du système qui ont les mêmes capacités. Ainsi Tomoyo
construit un domaine en gardant traces des précédents processus impliqués dans la création
du processus, qui réalise l’action. Par conséquent, Tomoyo n’utilise pas de label ou de contexte de
sécurité pour représenter les ressources du système, mais il se base sur les chemins complets des
sujets et des objets, donc sur le modèle PBAC.
Le listing 2.6 donne un exemple de domaine.
✞ ☎
1 /usr/sbin/sshd /bin/bash /usr/bin/man /bin/sh
✝ ✆
Listing 2.6 – Définition d’un domaine dans une politique Tomoyo
À chaque domaine est associé un ensemble de sujet et d’objet identifiés par leurs chemins
complets. La gestion des accès se fait grâce au triplet (r,w,x) sur les objets. Lorsqu’un processus
exécute un fichier binaire créant un nouveau processus, cela entraîne une transition vers un
nouveau domaine.
L’implantation de Tomoyo permet de représenter, sous la forme d’un graphe, l’évolution de
chaque domaine en cours sur le système. À la différence des mécanismes comme SELinux et
grsecurity, il est capable de gérer les connexions réseaux et l’administrateur peut donc définir au
niveau de la politique de contrôle d’accès, les plages d’adresses IP autorisées pour un domaine
donné.
Politique et règles de contrôle d’accès
La politique de contrôle d’accès de Tomoyo s’appuie donc sur deux éléments : les chemins
complets des ressources du système et la définition des domaines. La politique associe, à chaque
domaine, un ensemble de fichiers binaires que le domaine a le droit d’exécuter dans le but de créer
un nouveau domaine. Elle associe aussi un ensemble d’objets (fichier, socket, etc.) auxquels sont
associés le triplet de permissions (r,w,x).
La politique se base sur les droits (r,w,x) présents sous Linux. Chaque permission possède une
valeur numérique unique. Il est possible d’ajouter ces valeurs pour combiner plusieurs permissions.
Ainsi, on fait correspondre au triplet (r,w,x) le triplet (4,2,1). Dans cette représentation, r a pour
valeur 4, w 2 et x 1. Pour donner le droit à un domaine d’écriture et de lecture sur un objet, il suffit
de donner la valeur 4 + 2 = 6 sur l’objet pour le domaine concerné.
Le listing 2.7 montre un exemple de politique pour Tomoyo.
422.3. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS
✞ ☎
1 /sbin/mingetty /bin/login
2 1 /bin/bash
3 4 /etc/passwd
4 4 /etc/shadow
✝ ✆
Listing 2.7 – Règle d’accès dans une politique Tomoyo
Cette politique correspond à un domaine représenté par la trace
/sbin/mingetty /bin/login. Ce domaine est autorisé à exécuter (1) le fichier
/bin/bash et il est autorisé à lire les fichiers /etc/passwd et /etc/shadow.
Lorsque le domaine exécutera le fichier /bin/bash un nouveau domaine sera créé. Ce domaine
sera composé des éléments suivants : /sbin/mingetty /bin/login
/bin/bash.
Tomoyo étend les ACL par l’utilisation de mots clés dans sa politique de contrôle d’accès.
Ainsi, il est possible, grâce à des expressions régulières, d’autoriser un domaine à accéder à une
ressource qui n’est pas encore présente sur le système. L’extension des ACL se traduit aussi par
des permissions supplémentaires telles que la possibilité de supprimer une ressource. Le listing 2.8
montre un exemple d’utilisation de l’extension des ACL. Ainsi le langage de configuration supporte
à la fois les valeurs numériques des droits classiques mais aussi des mots clés permettant une
lecture plus simple des politiques.
✞ ☎
1 /usr/sbin/httpd
2 allow_read /var/www/html/\*
3 allow_read /etc/httpd/\*.conf
4 allow_read /usr/lib/httpd/modules/\*.so
5 allow_write /var/log/httpd/\*_log
6 allow_create /var/run/httpd.pid
7 allow_unlink /var/run/httpd.pid
✝ ✆
Listing 2.8 – Règle d’accès dans une politique Tomoyo
La politique offre aussi la possibilité de gérer des capacités spécifiques aux domaines. Ainsi,
il est possible de spécifier, par exemple, les plages d’IP sur lesquelles le domaine est autorisé à se
connecter comme le montre le listing 2.9.
✞ ☎
1 allow_network
2 TCP accept
3 10.0.0.0-10.255.255.255
4 1024-65535
✝ ✆
Listing 2.9 – Règle d’accès dans une politique Tomoyo
2.3.1.4 Policy Interaction Graph Analysis
PIGA [Briffaut, 2007] est un mécanisme de contrôle d’accès obligatoire proposé sous deux
formes :
— un correctif noyau qui est le Policy Enforcement Point (PEP), c’est-à-dire le point d’application
de la politique ;
— une implémentation d’un moniteur de référence, qui est donc le Policy Decision Point
(PDP), c’est-à-dire le moniteur qui prend la décision.
À la différence des mécanismes précédemment présentés comme SELinux et grsecurity, PIGA
est capable de gérer à la fois les interactions entre un sujet et un objet ou entre deux sujets, mais
aussi des compositions d’interactions (flux entre plusieurs interactions, enchaînement temporel
entre les interactions, opérateurs logiques entre interactions, etc.).
432.3. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS
PIGA se base sur un langage de spécification de propriétés de sécurité (Security Property
Language, SPL) de haut niveau, en comparaison de DTE, qui offre la possibilité d’exprimer des
propriétés de sécurité 2.1. Ces propriétés de sécurité sont par la suite garanties par le moniteur
PIGA.
Modèle général
Dans [Briffaut et al., 2009], les auteurs détaillent le langage d’expression des propriétés de
sécurité (SPL). Ce langage indépendant du mécanisme de contrôle d’accès permet d’exprimer des
propriétés combinant plusieurs types de flux. La représentation du système utilise les contextes de
sécurité définis par SELinux. Il distingue donc l’ensemble des contextes sujets SCs et l’ensemble
des contextes objets SCo. Lorsqu’une interaction est effectuée sur le système, il peut y avoir deux
effets : un transfert d’information ou une transition.
Le transfert d’information se fait du contexte sujet vers le contexte objet lorsque l’opération associée
est une écriture. Il se fait dans le sens inverse lors d’une opération de lecture. Une transition
est un changement de domaine.
À partir de ces éléments, les auteurs donnent une définition de la dépendance causale entre
deux interactions. Ainsi, deux interactions sont causalement dépendantes si :
— elle partage un même contexte de sécurité ;
— la première interaction intervient avant la fin de la seconde ;
— la première interaction modifie l’état du contexte de sécurité partagé ;
— la seconde interaction modifie l’état du contexte de sécurité final.
Cette définition permet ensuite de formaliser les notions d’interactions et de séquences. Une
interaction directe, notée >, est une opération élémentaire (lecture, écriture, etc.), qui induit un
transfert d’information direct entre un processus et une ressource. Une séquence, notée >> correspond
à une suite d’interactions causalement dépendantes et induit un flux d’information indirect
mettant en jeu au moins 3 contextes, le second servant d’intermédiaire.
Grâce à ces opérateurs de base, les auteurs peuvent exprimer des propriétés de sécurité comme
la confidentialité et l’intégrité dans un langage de haut niveau. Ces propriétés de sécurité peuvent
être exprimées en utilisant la notion d’interaction, c’est-à-dire de flux d’information direct, ou de
séquence, c’est-à-dire de flux d’information indirect, de suite temporelle, d’expression logique,
etc.
PIGA est proposé sous la forme de plusieurs outils : PIGA-CC, qui énumère les activités
autorisées par une politique MAC contrôlant les interactions directes qui violent les propriétés
PIGA exprimées en SPL, PIGA-UM, qui est le moteur de prise de décision et PIGA-Kernel, qui
est le hook noyau interceptant les accès autorisés par SELinux.
PIGA-CC, dont le fonctionnement est illustré par la figure 2.11 prend en entrée les propriétés
de sécurité écrites en SPL et la politique de contrôle d’accès directe MAC (par exemple : une politique
SELinux). Il recherche, dans la politique de contrôle d’accès directe, les activités susceptibles
de contourner les propriétés de sécurité. Cette opération se fait en mode hors ligne, c’est-à-dire
avant que PIGA ne soit déployé sur un système. Les activités illégitimes calculées sont ensuite utilisées
par PIGA-UM. Lorsque PIGA-UM reconstruit l’activité du système, il va vérifier que cette
activité ne correspond pas à une activité illégitime.
La partie prise de décision s’effectue en espace utilisateur par PIGA-UM. C’est l’implantation
du moniteur de référence définie par [Anderson, 1972]. À partir de chaque interaction capturée
en espace noyau, il reconstruit l’activité du système. Cette reconstruction lui permet de vérifier la
validité des interactions vis-à-vis des activités qu’il a pré-calculées. Lors de ce calcul, PIGA génère
les activités réelles susceptibles de violer les propriétés de sécurité. Par conséquent, si l’interaction
442.3. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS
FIGURE 2.11 – Fonctionnement de PIGA-CC
courante fait partie d’une activité réelle qui correspond à une activité illégitime, cette interaction
(appel système) est bloquée.
PIGA-Kernel permet de détourner le flux d’exécution des interactions directes. PIGA-Kernel
transmet les interactions autorisées à PIGA-UM afin qu’il contrôle les activités correspondant aux
scénarios complets.
Lorsqu’un processus effectue un appel système, il est intercepté par SELinux. Si l’appel est
autorisé au niveau de SELinux, alors PIGA-Kernel va l’intercepter. Il va ensuite l’envoyer à PIGAUM.
PIGA-UM va ajouter cet appel pour reconstruire l’activité du système, puis il va rechercher
dans les signatures qui ont été pré-calculées si cette interaction ne fait pas partie d’une activité
illégitime. Si c’est le cas, PIGA-UM a deux possibilités : soit il est en mode en détection et dans ce
cas, il se contente de lever une alerte de sécurité sans que l’interaction ne soit bloquée, soit il est en
mode protection et par conséquence, l’interaction illégitime échouera c’est-à-dire que le scénario
malveillant ne se terminera pas.
2.3.1.5 Politique et règle de contrôle d’accès
Le listing 2.10 montre un exemple de propriété de sécurité exprimée en SPL qui garantit la
confidentialité. Ainsi, la propriété 2.10 s’interprète ainsi : à partir de deux contextes de sécurité
cibles, sc1 qui le contexte sujet et sc2 qui est le contexte objet, PIGA va contrôler qu’il n’existe
aucun flux d’information indirect >> partant de sc2.
✞ ☎
1 define confidentiality( $sc1 IN SCS, $sc2 IN SCO ) [
2 SA { $sc2 >> $sc1 },
3 { not(exist()) };
4 ];
✝ ✆
Listing 2.10 – Propriété de confidentialité exprimée en SPL
Les résultats fournis par PIGA sont dans ce cas des activités autorisées par la politique de
contrôle d’accès directe qui conduisent à un flux indirect (en effet, dans la pratique, les flux directs
sont déjà traités par le MAC, comme SELinux). On voit que PIGA améliore la sécurité par rapport
à SELinux et permet de formaliser des propriétés de sécurité, ce que ne permet pas SELinux qui
est de plus bas niveau.
2.3.2 Windows
Dans cette section, nous allons maintenant détailler des implantations de mécanismes de
contrôle d’accès obligatoire pour les systèmes d’exploitation Windows.
452.3. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS
2.3.2.1 Mandatory Integrity Control
MIC (Mandatory Integrity Control) est un mécanisme de contrôle d’accès obligatoire breveté
par Microsoft [Richard Ward, 2006]. Ce modèle, plus récent que les implantations de SELinux et
de grsecurity, a été mis en place à partir des systèmes d’exploitation Windows Vista.
À la différence des implantations présentes sous Linux, qui doivent être activées pour SELinux,
et où il est nécessaire de modifier le noyau pour grsecurity, l’implantation de Microsoft
est imposée. Son principal objectif est de protéger le système des attaques, qu’elles viennent de
l’extérieur ou de l’intérieur.
Modèle général
Le modèle de protection s’inspire des modèles de Biba et de BLP que nous avons détaillé dans
la section 2.2.2.2. Chaque entité du système, que ce soit les sujets ou les objets, possède un niveau
d’intégrité [Microsoft, 2013]. Pour qu’un sujet puisse modifier un objet, il doit nécessairement
posséder un niveau d’intégrité supérieur ou égal à celui de l’objet.
Cependant, nous avons vu que le modèle de protection défini par Biba était difficilement applicable
à un système d’exploitation. Pour résoudre ce problème, Microsoft n’offre que la propriété
de non modification des objets ayant une intégrité supérieure (No Write Up).
Politique et règle de contrôle d’accès
Par défaut, il existe cinq niveaux d’intégrité.
— le niveau de non confiance (Untrusted) qui concerne les processus appartenant aux sessions
invitées et qui ne peuvent faire aucune interaction privilégiée sur le système ;
— le niveau d’intégrité bas est utilisé pour les processus ayant une forte exposition aux attaques
et qui possèdent souvent des failles de sécurité permettant d’entrer sur le système ;
— le niveau d’intégrité moyen qui est le niveau d’intégrité par défaut de l’utilisateur qui s’est
connecté. C’est aussi le niveau d’intégrité sous lequel tourne la majorité des programmes
lancés par l’utilisateur ;
— le niveau d’intégrité haut, qui est réservé à l’administrateur du système ;
— enfin, le niveau d’intégrité système réservé au système.
Tout comme le définit le modèle basé sur les niveaux d’intégrité de Biba 2.2.2.2, les sujets
ayant une intégrité inférieure à celle de l’objet ne peuvent pas le modifier (No Write Up qui s’applique
spécifiquement aux objets du système). Mais à la différence du modèle théorique, la politique
de contrôle d’accès sous Windows n’empêche pas un sujet ayant une intégrité plus élevée
que l’objet de le lire (principe du No Read Down).
Les lois s’écrivent de la façon suivante :
a ∈ M[s, o] → f(s) ≥ f(o)
w ∈ M[s, o] → f(s) = f(o)
FIGURE 2.12 – Lois d’application des propriétés du MIC
Pour renforcer son implantation, Microsoft a mis en place, en plus des niveaux d’intégrité,
des labels s’appliquant sur les sujets du système. Ces labels agissent en complément des niveaux
d’intégrité. Ils permettent de renforcer le contrôle d’accès présent sur les systèmes Windows.
Par défaut, trois labels de sécurité sont définis :
— No Read Up : les sujets ayant une intégrité strictement inférieure à celle du sujet cible ne
peuvent pas lire le contenu du sujet. Ce label empêche les processus d’intégrité basse d’ob-
462.3. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS
server les processus ayant une intégrité plus haute. Ce label de sécurité est une application
restreinte du modèle de BLP ;
— No Write Up, s’applique ici sur les sujets du système : les sujets ayant une intégrité strictement
inférieure à celle des sujets ne peuvent pas les modifier, c’est l’application d’une des
deux propriétés énoncées par Biba ;
— No Execute Up : restreint la permission d’exécution sur les objets par les sujets ayant un
niveau d’intégrité bas.
La figure 2.13 illustre l’application du modèle de protection MIC.
Niveau d’intégrité haut
Niveau d’intégrité moyen
Niveau d’intégrité bas
No Write Up
No Read Up
No Execute Up
FIGURE 2.13 – Modèle de protection des données : MIC
Cependant, dans le but d’assurer le fonctionnement du système, il existe des exceptions possibles.
Les utilisateurs autorisés à effectuer des tâches d’administration ont la possibilité de modifier
leur niveau d’intégrité. L’objectif étant d’augmenter le niveau d’intégrité d’un processus
pour qu’ils puissent réaliser les tâches privilégiées. Cette augmentation de privilège s’opère, par
exemple, lorsqu’un utilisateur veut installer un nouveau logiciel ou réaliser une mise à jour.
Cette autorisation d’augmentation du niveau d’intégrité est représentée par le jeton d’accès
Administrateur. Il autorise ainsi les processus à écrire dans les répertoires modifiables uniquement
par l’administrateur. Depuis Windows Vista, il n’existe plus de compte Administrateur sous
Windows. On peut rapprocher la possibilité d’augmentation du niveau d’intégrité pour un utilisateur
de la commande sudo sous Linux, qui permet de changer l’environnement de l’utilisateur,
généralement dans le but d’effectuer des tâches d’administration.
Ce modèle de contrôle d’accès est mis en place pour protéger le système et les fichiers systèmes
des attaques qui pourraient modifier leur intégrité. À la différence des implantations de mécanisme
de contrôle d’accès sous Linux utilisant les LSM, le contrôle du MIC est fait avant le contrôle
des droits d’accès discrétionnaire. Cela entraîne la possibilité pour l’utilisateur élevant son niveau
d’intégrité par le jeton d’accès Administrateur de contourner les droits d’accès classiques. En effet,
une fois son intégrité modifiée, il se retrouve avec des privilèges administrateur ce qui lui permet
de contourner les droits d’accès discrétionnaire et lui offre presque tous les droits.
Cette implantation d’un mécanisme de contrôle d’accès obligatoire est la première réalisée
par Microsoft. Elle a l’avantage de proposer une approche plus simple que SELinux ou grsecurity
puisqu’il n’est pas nécessaire d’écrire une politique énumérant tous les privilèges. En pratique, il
472.3. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS
ne protège pas les données des utilisateurs accessibles via le jeton d’accès Administrateur. Ainsi,
MIC ne permet pas de minimiser les privilèges, ce qui autorise de nombreuses violations de confi-
dentialité et d’intégrité car il n’implante qu’une partie du modèle de protection de Biba.
2.3.2.2 PRECIP
PRECIP (Practical and Retrofittable Confidential Information Protection) [Wang et al., 2008]
est un mécanisme de gestion des flux d’information directs développé pour Windows XP. Il implante
une simplification du modèle de BLP. En plus d’un mécanisme de contrôle, il est fourni avec
une suite d’outils aidant à son administration.
Modèle général
PRECIP associe deux niveaux de sécurité aux objets du système. Ces niveaux sont "haut" et
"bas". Les sujets possèdent aussi deux niveaux de sécurité trust et untrusted. Pour qu’un sujet
puisse accéder à un objet ayant un niveau haut, il doit être considéré comme "de confiance".
Cette modélisation est une implantation sur un système réel, ici testée sur Windows XP, du
modèle de BLP. L’objectif de cette implantation est de respectée la confidentialité du système,
même en cas d’attaque.
Cette implantation d’un mécanisme de contrôle d’accès obligatoire est l’une des premières
présente sur les systèmes d’exploitation Windows. Elle implante une simplification de modèle de
confidentialité définie par BLP. Cette implantation se base sur le suivi des flux implicites et explicites
et sur l’utilisation de l’étiquette dynamique des données. Cependant, le modèle est limité
à seulement deux niveaux de confidentialité. De plus, les règles sont limitées et ne protègent pas
le système complet, juste les fichiers considérés comme sensibles. Les règles ne sont pas applicables
à tout le système et elle ne sont pas extensibles. Enfin, les résultats montrent un impact non
négligeable sur les performances du système d’exploitation ainsi que sur le fonctionnement des
applications [Wang et al., 2008].
Politique et règle de contrôle d’accès
PRECIP définit deux niveaux de confidentialité pour les objets du système : high et low. Ces
informations sont stockées dans les flux NTFS des objets. Les sujets peuvent avoir deux niveaux
de sécurité : trust et untrusted. Ces niveaux sont stockés dans une structure du noyau. La détermination
de ces niveaux est faite sur l’établissement d’une base de données fournie par l’outil.
Un sujet est considéré comme de confiance si l’outil a pleinement conscience de toutes les
entrées et toutes les sorties possibles de l’exécutable. Si ce n’est pas le cas, il sera alors marqué
comme de non confiance. Les niveaux de confidentialité des objets du système sont dérivés des
droits d’accès discrétionnaire. Par exemple, un fichier dont le propriétaire est l’administrateur est
considéré comme sensible.
La définition des niveaux de confidentialité peut aussi être faite par le propriétaire des fichiers
grâce aux outils fournis par PRECIP. Des outils spécifiques, permettant de faire transiter des processus
en mode sensible comme les navigateurs Internet qui vont sur les sites sensibles, ont aussi
été mis en place.
2.3.2.3 Core Force
Core Force [Labs, 2005] est une suite d’outils divisée en deux parties : un pare-feu et un
mécanisme de contrôle d’accès. Core Force permet de confiner les processus et contrôler leurs
privilèges.
482.3. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS
✞ ☎
1
2
✝ ✆
Listing 2.11 – Extrait d’un fichier de configuration de Core Force pour un programme
✞ ☎
1
2
3 A Policy includes previously defined configuration
parameters.
4
5
6
7
8
✝ ✆
Listing 2.12 – Extrait d’un fichier de configuration de Core Force pour un programme spécifiant
les permissions
Modèle général
Core Force se base sur le modèle de grsecurity pour faire du contrôle d’accès, c’est-à-dire qu’il
va appliquer le triplet (r,w,x) pour chaque objet du système. Comme grsecurity ou SELinux, il est
nécessaire de définir explicitement les interactions autorisées pour chaque application du système.
Core Force est fourni sous la forme d’un logiciel, installable uniquement Windows 2000 et sur
Windows XP. Il est composé de deux driver noyau, un qui contrôle des interactions sur le système
de fichiers et sur le registre, et le second pour contrôler les interactions du réseau.
La configuration par défaut définie des profils de sécurité pour les applications. Ces profils
sont des templates de sécurité, qui proposent des politiques de sécurité par défaut vis-à-vis du
profil sélectionné. Il est cependant possible de créer des profils spécifiques pour les applications.
Politique et règle d’accès
La politique de contrôle d’accès s’appuie sur le chemin complet des sujets et des objets. Tout
comme grsecurity, une règle de contrôle d’accès associe un sujet à un objet avec un ensemble de
permission qui se définissent grâce aux ACL.
Pour configurer les permissions pour les applications, Core Force propose une interface graphique
facilitant la configuration du contrôle d’accès. Les permissions sont ensuite stockées dans
des fichiers au format XML.
Nous allons détailler un exemple de politique. Tout d’abord, le fichier XML spécifie pour quel
programme s’applique cette politique 2.11.
Ensuite, le fichier de configuration spécifie les interactions autorisées par le programme 2.12.
Nous pouvons noter ici que le programme Firefox a le droit de lecture et d’écriture sur le fichier
pluginreg.dat dans le dossier Mozilla.
L’approche Core Force a été abandonnée depuis l’arrivée de Windows Vista, 7 et 8.
2.3.3 Distributed Security Infrastructure
Distributed Security Infrastructure (DSI) [Pourzandi et al., 2002] est un framework de dé-
ploiement et d’administration d’une politique de contrôle d’accès pour un environnement HPC.
C’est la première implantation d’un framework de gestion d’une politique de sécurité orienté
492.3. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS
système distribué. Le projet a ensuite évolué pour être intégré dans un framework nommé HAOSCAR
[Leangsuksun et Haddad, 2004].
Les auteurs de DSI ont mis en place une architecture distribuée pour répondre à la problématique
de déploiement et de gestion d’une politique de sécurité dans un environnement distribué.
L’intégration de DSI dans HA-OSCAR avait pour objectif de cibler les environnements HPC. Cette
intégration a entraîné le changement de nom pour devenir RASS [Darivemula et al., 2006] (Reliability,
Availability, Serviceability and Security). Cette architecture se base sur la définition de deux
éléments clés : le Security Server et Security Manager.
Le Security Server est le point d’entrée du système pour la gestion de l’infrastructure. Il est
chargé du déploiement de la politique de sécurité sur tous les nœuds. Il doit aussi distribuer les
mises à jour de la politique. Il s’occupe enfin de remonter les alertes de sécurité en provenance des
nœuds.
Les Security Manager sont déployés sur les nœuds du cluster. Ce sont les agents locaux
chargés d’appliquer la politique de sécurité qu’ils ont reçue du serveur de sécurité. Dans
[Pourzandi et al., 2002], les auteurs appliquent une politique de sécurité pour SELinux.
Les communications entre le serveur de sécurité et les managers se font sur des canaux authentifiés
et chiffrés. Ces canaux de communication sont utilisés pour remonter les alarmes et les
alertes de sécurité ainsi que pour la distribution de la politique de sécurité.
La politique de sécurité, appelée Distributed Security Policy (DSP) par les auteurs, définit explicitement
les accès autorisés sur chaque système. Elle est gérée sur le SS par un administrateur.
Grâce aux canaux de communication chiffrés, les agents locaux autorisent des mises à jour de
la politique. Les règles d’accès définissent les accès autorisés sur le système mais aussi sur les
échanges entre les systèmes. Pour contrôler les interactions entre les systèmes, DSI ajoute un security
node ID (SNID). En plus de ce SNID, DSI définit des secure ID(SID) pour chaque sujet
(SSID) et chaque objet d’un système (TSID). Grâce à ces deux ID, les auteurs établissent le cluster
security ID (CSID). Ce CSID est ajouté aux options des paquets IP. Ce sont enfin les Security
Manager qui réalisent le contrôle d’accès en vérifiant les CSID présents dans chaque paquet IP.
Il est ainsi possible de contrôler les communications établies entre les nœuds du cluster. Cependant,
cette approche est très proche de SELinux et peu extensible, elle n’offre en pratique aucun
couplage possible avec d’autres mécanismes de sécurité.
2.3.4 Impact sur les performances
Nous allons traiter dans cette partie de l’impact sur les performances des mécanismes de
contrôle d’accès. En vue de l’intégration d’un mécanisme de contrôle d’accès obligatoire, il est
nécessaire de connaître son impact sur le système d’exploitation, spécialement pour le HPC.
Dans l’article [M. Fox et Thomas, 2003], les auteurs opposent SELinux à grsecurity. Ils pré-
sentent dans une première partie le fonctionnement de chaque mécanisme de contrôle d’accès
obligatoire. Puis ils exécutent différents benchmarks : lmbench et unixbench. Ces benchmarks
réalisent des séries d’opérations sur le système de fichiers comme des lectures et écritures
de fichiers de différentes tailles mais aussi des opérations spécifiques comme des exécutions de
processus, etc. Ces benchmarks sont exécutés suivant différentes configurations (par un utilisateur
standard, un administrateur, puis en mode protection). La conclusion de cet article est que ces
mécanismes de contrôle d’accès influencent différemment les performances du système d’exploitation.
Cette influence va dépendre de l’action réalisée : écriture, changement de contexte, etc. Il
n’est donc pas possible de dire avec précision si un mécanisme de contrôle d’accès est plus adapté
qu’un autre aux environnements HPC. La principale limite de cet article est que les auteurs ne font
que comparer SELinux avec grsecurity sans proposer les résultats pour un système sans contrôle
d’accès obligatoire.
502.3. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS
Les auteurs de RASS [Leangsuksun et al., 2005] proposent aussi une étude sur l’impact sur les
performances du mécanisme de contrôle d’accès obligatoire qu’ils ont mis en place dans un milieu
HPC. Les résultats portent sur des versions du noyau Linux assez anciennes puisque la version du
noyau est 2.4.17.
L’impact sur le système de fichiers est compris entre 0% et 2% suivant les opérations par rapport
à un système sans le système RASS. Les opérations les plus impactées sont les exécutions de
nouveau processus. Par contre, une latence comprise 20% et 30% a été mesurée pour les messages
envoyés et reçus en UDP. Cette latence est due aux modifications des paquets IP faites par les Security
Manager dans le but d’y ajouter les CSID. Sans le contrôle réseau, la latence est de l’ordre
de 5%.
Cette première étude montre que l’intégration d’un mécanisme de contrôle d’accès obligatoire
dans un environnement ayant de fortes contraintes en termes de performances est possible. Cependant,
les latences réseaux générées à cause des modifications des paquets IP ne sont pas encore
intégrables dans les environnements HPC.
Dans une seconde étude [Blanc et Lalande, 2012], les auteurs montrent que l’intégration d’un
MAC peut être faite dans un environnement HPC. Dans une première partie, les auteurs proposent
la mise en place de propriétés de sécurité pour confiner les utilisateurs et protéger les services critiques
présents sur le système. Pour cela, ils utilisent SELinux. Le confinement des utilisateurs se
fait par l’utilisation des catégories présentes dans SELinux. Ils concluent par des tests de performance
sur le système de fichiers Lustre. Il en résulte que l’ajout de SELinux, associé à ce système
de fichiers spécifiques, engendre un surcoût de 10% sur les entrées/sorties. Cependant, il s’agit
uniquement d’une expérimentation avec SELinux qui n’offre pas de cadre général pour évaluer les
performances.
2.3.5 Discussion
Nous venons de détailler les implantations des mécanismes de contrôle d’accès obligatoire
présents sur les systèmes d’exploitation Linux et Windows. Pour chaque implantation, nous avons
détaillé les propriétés de sécurité que le mécanisme est capable de garantir.
Le tableau 2.2 récapitule, pour chaque système d’exploitation étudié, la liste des propriétés de
sécurité supportées. Nous pouvons tirer deux constats de ce tableau. Le premier est que les mécanismes
de contrôle d’accès obligatoire présents sous Linux sont assez complets et permettent de
couvrir un large panel de propriétés de sécurité que nous avions exprimés. Il n’est donc pas nécessaire
de rajouter un nouveau mécanisme pour ce système d’exploitation. Cependant, nous avons
aussi montré un manque d’intégration de ces mécanismes dans les environnements distribués et
plus particulièrement dans les environnements HPC. Seul le projet DSI propose une intégration
d’un MAC dans les clusters, mais sans pour autant juger avec précision de l’impact sur les performances
du système. De plus, les travaux proposés sont maintenant assez anciens par rapport aux
noyaux Linux actuels.
Le second constat que nous pouvons faire, est le manque de mécanismes capables d’appliquer
des propriétés de sécurité sur les systèmes Windows. Le plus complet est le MIC, le mécanisme
mis en place par Microsoft, mais ce dernier souffre de quelques faiblesses qui peuvent se révéler
dangereuses pour le système. Comme nous l’avons détaillé, ce mécanisme n’est pas capable de
protéger efficacement tout le système puisqu’il s’attache à vérifier l’intégrité des fichiers du système.
Il ne contrôle pas, par défaut, les actions effectuées sur les fichiers des utilisateurs. Certains
mécanismes tels que Core Force ou PRECIP existent, mais ils ne sont, soit plus maintenus pour
les systèmes actuels (Windows 7 et Windows 8) soit ne permettent pas un contrôle précis de toutes
les activités.
512.4. CONCLUSION
Linux Windows
MAC SELinux grsecurity Tomoyo PIGA MIC PRECIP Core Force
Confidentialité
- des objets oui oui oui oui x oui x
- des sujets x x oui oui oui x x
Intégrité
- des objets oui oui oui oui oui x x
- des sujets x x x oui oui x x
Propriétés spécifiques
- BLP oui oui x oui x oui x
- Biba oui x x oui oui x x
Propriétés dérivées
- Conf de processus oui oui oui oui x oui oui
- Moindre privilège oui oui oui oui x x oui
- Séparation de privilèges oui oui x oui x x x
- Non-interférence x x x oui x x x
- Nouvelles propriétés oui oui oui oui x x oui
TABLE 2.2 – Tableau récapitulatif des propriétés de sécurité appliquées par les implantations de
contrôle d’accès obligatoire
2.4 Conclusion
La problématique du contrôle d’accès s’avère différente à traiter suivant les systèmes d’exploitation.
D’un côté, nous avons plusieurs implantations matures et éprouvées, de l’autre, il n’existe
que très peu de choses.
Sur les systèmes d’exploitation Linux, nous avons choisi de détailler l’implantation de quatre
mécanismes de contrôle d’accès obligatoire. Il en existe cependant d’autres proposant leurs propres
implantations. Nous pouvons par exemple citer SMACK [Casey Schaufler , 2008] (Simplified
Mandatory Access Control Kernel) qui se base sur la définition de labels de sécurité et qui propose
une implantation du modèle de BLP. Comme son nom l’indique, c’est un mécanisme qui se veut
simple à configurer et à utiliser puisqu’il ne propose que peu de labels (trois par défaut). Il est notamment
utilisé dans le système d’exploitation de Samsung pour ses téléphones portables, appelé
Tizen.
Tous ces mécanismes se basent sur la définition de politique de sécurité qui peuvent être ré-
digées soit à la main, soit générées de manière plus ou moins automatiques facilitant ainsi grandement
leur intégration dans les systèmes Linux. La mise à disposition d’outils d’administration
et d’aide à la gestion des politiques permet d’avoir des systèmes qui peuvent être maintenus facilement.
De plus, il est facile de noter que sur les systèmes d’exploitation Linux, nous avons le
choix dans le mécanisme de contrôle d’accès à utiliser. Ce choix est en partie dû à la possibilité de
s’intégrer au noyau facilement en utilisant les LSM, hormis grsecurity qui continue de proposer un
patch noyau.
Sur les systèmes d’exploitation Windows, il n’existe pas autant de choix. Les premiers projets
sur le renforcement du contrôle d’accès ne proposent que d’étudier les faiblesses de configuration
du contrôle d’accès discrétionnaire, par exemple Netra [Naldurg et al., 2006]. Ces outils, qui
fournissent des rapports et des graphiques présentant les attaques possibles à partir d’un état du
système, ne sont que des moyens de détection hors ligne et n’offrent pas de réelles solutions pour
renforcer la sécurité des systèmes d’exploitation Windows.
D’autres projets proposent des mécanismes pour faire de la protection du système. Ces implantations
se focalisent sur certains points précis du système : gestion des exécutables ou protection
des fichiers considérés comme sensibles. Ces outils sont issus de phase d’expérimentation sur des
522.4. CONCLUSION
logiciels malveillants, ils ne sont pas capables de contrer les comportements qu’ils ne connaissent
pas.
Le mécanisme de contrôle d’accès obligatoire proposé par Microsoft, le MIC, vise essentiellement
à protéger le système de toute modification malveillante, mais ce mécanisme ne protège
en aucun cas les données des utilisateurs (protection en intégrité ou en confidentialité). De plus,
dans la pratique, l’utilisation de ce mécanisme se révèle difficile pour l’ensemble du système et
fragile puisque l’utilisateur peut autoriser l’élévation de privilèges. Nous pouvons aussi ajouter
que Microsoft propose, sur les versions Enterprise et Ultimate de Windows 7, un outil qui se
nomme AppLocker [Microsoft, 2009]. Il permet de configurer les droits d’accès sur les ressources
du système. Cette configuration peut se faire de manière graphique.
Nous nous sommes aussi intéressés à l’intégration dans les environnements distribués, et plus
particulièrement dans les milieux HPC, des mécanismes de contrôle d’accès obligatoire. Il existe
des projets visant à renforcer la sécurité des grilles, notamment les échanges entre les différents
services par exemple en utilisant les langages de type XACML [OASIS, 2013]. Néanmoins, si le
projet DSI s’intéresse à l’intégration d’un MAC dans les milieux HPC, il traite de façon incomplète
l’impact d’un tel mécanisme sur les performances du système d’exploitation.
D’une part, nous avons donc vu que sur les systèmes d’exploitation Linux, il existait un certain
nombre de modèles de protection obligatoire. Tous ces modèles ont été développés pour être inté-
grés dans les systèmes pour les stations de travail. Avec le développement des systèmes distribués,
mais aussi des environnements de calcul à haute performance, le renforcement du contrôle d’accès
sur les grilles devient une nécessité. Peu de projets se sont intéressés à l’intégration de ce type de
mécanisme de contrôle d’accès dans les environnements distribués et l’impact d’un tel mécanisme
sur les performances des systèmes d’exploitation est peu évoqué. On manque notamment de modèles
et de protocoles précis d’évaluation des performances. Enfin, nous considérons qu’il n’est
pas envisageable de faire reposer le contrôle d’accès sur un seul mécanisme et là encore, les approches
et les modèles permettant d’associer différents mécanismes de contrôle d’accès manquent.
De plus, les modèles de répartition de ces mécanismes sont quasiment inexistants. Enfin, si déjà les
protocoles d’évaluation des performances manquent pour les systèmes de protection homogènes
(par exemple basés exclusivement sur SELinux), ils sont encore plus inexistants dans le cadre des
systèmes répartis de contrôle d’accès hétérogènes où l’on voudra associer et répartir différents
mécanismes.
D’autre part, nous avons noté le manque de mécanisme de contrôle d’accès obligatoire sur les
systèmes Windows capable d’appliquer des propriétés de sécurité que nous avons définies au début
de ce chapitre. La nécessité de l’implantation d’un tel mécanisme dans les systèmes Windows est
extrêmement grande puisque c’est, encore à ce jour, le système le plus utilisé en tant que station
de travail.
Les chapitres suivant traitent de façon uniforme de ces différents points en s’intéressant à la fois
à la protection des systèmes d’exploitation hétérogènes, à l’association des différents mécanismes
de protection, à leurs répartitions et aux méthodes et protocoles d’évaluation des performances
dans ces systèmes répartis de protection.
532.4. CONCLUSION
54Chapitre 3
Modélisation et répartition
d’observateurs
Les exemples que nous avons détaillés dans l’introduction de notre étude (voir la section 1.3),
ont mis en avant que les attaques sur les systèmes d’exploitation sont de plus en plus complexes.
Pour les prévenir de manière efficace, c’est-à-dire sans nuire au fonctionnement du système, il faut
connaître le scénario complet de ces attaques.
La connaissance de ce scénario complet passe par le contrôle des interactions directes au sein
du système. Pour contrôler ces interactions, la mise en place d’un observateur, capable de détourner
le flux d’exécution régulier et de prendre des décisions en fonction d’une politique de sécurité,
est essentielle. Ce modèle de protection, basé sur deux éléments complémentaires, s’appuie pleinement
sur la définition d’un Policy Enforcement Point et d’un Policy Decision Point. Le PEP est
le moyen utilisé par l’observateur pour détourner le flux d’exécution. On peut citer par exemple
les LSM, présents nativement sur les systèmes Linux, qui offrent la possibilité au module de sécurité
de détourner les flux d’exécution réguliers. Le PDP est la partie de l’observateur qui prend les
décisions. Dans le cadre d’un mécanisme contrôlant les accès, [Anderson, 1980] a défini un observateur
particulier : le moniteur de référence. Le moniteur de référence est donc un observateur
prenant des décisions d’accès au regard d’une politique de sécurité.
Mais le seul contrôle des interactions directes ne suffit pas à protéger le système contre les scé-
narios complets. En effet, un observateur ne traitant que les interactions directes n’est pas capable
de traiter un scénario complet d’attaque. Il faut pour cela utiliser d’autres observateurs capables
de reconstruire le scénario complet. Pour ce faire, un premier type d’observateur doit être capable
d’horodater chaque interaction directe dans le but de les situer les unes par rapport aux autres.
Ensuite, il faut être capable d’associer les différents observateurs nécessaires à la reconstruction
du scénario pour qu’ils puissent s’échanger non seulement les requêtes, mais aussi les décisions
d’accès qu’ils prennent.
Pour prendre sa décision, un observateur s’appuie sur une politique de sécurité. Cette politique
peut être une base de données contenant les éléments à bloquer, des signatures à détecter, ainsi que
les interactions directes à contrôler. Comme nous avons besoin en premier lieu d’un observateur
capable de gérer les interactions directes, nous allons proposer un modèle de politique de sécurité
générique pour contrôler les accès directs des processus sur les ressources. Nous appliquerons
plus spécifiquement cette politique pour les systèmes Windows car, comme nous l’avons montré
au cours de l’état de l’art 2.4, c’est sur ce système qu’il y a le plus de manque. Dans le but d’obtenir
une politique de sécurité générique pour les systèmes Windows, nous proposons une désignation
des ressources pour ces systèmes.
Le langage pour la politique directe supporte à la fois PBAC et DTE. Dans le modèle PBAC,
les ressources sont identifiées par leur chemin complet dans l’arborescence du système de fichiers,
553.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION
LINUX ET WINDOWS
comme le fait grsecurity. Pour PBAC, notre désignation des ressources permet une politique portable
car indépendante de la localisation des ressources. Dans le modèle DTE, les ressources sont
identifiées par des types et des domaines. Cette méthode supporte mieux l’hétérogénéité puisque
la politique pourrait aisément être projetée sur Linux comme sur Windows.
Nous étudierons ensuite comment mettre en œuvre un PEP pour Windows. Ainsi grâce à ce
PEP et à la politique générique, nous pouvons proposer un PDP qui gère les interactions directes et
offre ainsi un moniteur de référence pour les versions récentes de Windows, à savoir Windows 7.
3.1 Définition d’un observateur pour les systèmes d’exploitation Linux
et Windows
Cette section s’intéresse à la définition générique de la notion d’observateur. Pour que l’observateur
puisse fonctionner sur le système, cela passe par la mise en place de deux éléments :
— un PEP (Policy Enforcement Point, point d’application de la politique) : c’est-à-dire un
moyen pour détourner le flux d’exécution régulier du système ainsi que pour appliquer les
décisions prises par l’observateur ;
— une politique de sécurité utilisée par le PDP (Policy Decision Point, un point de décision),
qui définit les traitements à effectuer.
Dans le cadre d’un observateur contrôlant les accès au sein d’un système, l’application de la
politique de sécurité se fait par un observateur particulier nommé moniteur de référence. Mais
pour que ce contrôle soit efficace, il est nécessaire que le moniteur puisse observer l’ensemble du
système. Pour cela, l’observateur se place de manière naturelle en espace noyau.
L’espace noyau est une protection matérielle qui a été mise en place au niveau des processeurs.
Cette protection se nomme anneau de protection (ou rings). L’objectif de cette protection est
d’établir des niveaux de confiance pour l’exécution de code. Les systèmes d’exploitation modernes
n’utilisent que deux anneaux de protection : l’anneau 0 et l’anneau 3. L’anneau 0 est un anneau
de protection considéré de confiance, c’est-à-dire que le code qui s’exécute n’est pas supervisé.
Cela se traduit par la possibilité de réaliser des tâches privilégiées et de pouvoir utiliser toutes les
instructions du processeur. C’est dans cet anneau de protection que s’exécute le noyau du système
d’exploitation. L’anneau de protection 3 est un anneau de protection où s’exécute du code qui
n’est pas considéré comme sûr. Cela se traduit par la possibilité d’utiliser un jeu d’instructions
plus restreintes au niveau du processeur. Les systèmes d’exploitation modernes utilisent l’anneau
de protection 3 pour exécuter les applications. Dans ce mode, les interactions des applications sont
supervisées et, par conséquent, pour réaliser une opération spécifique, l’application doit passer par
un appel système, qui lui sera contrôlé et exécuté par le noyau.
C’est dans le but de pouvoir réaliser des tâches privilégiées que nous plaçons l’observateur en
espace noyau. Il pourra ainsi contrôler tout le système sans restriction. Les opérations d’entrée/-
sortie n’étant possibles que par les appels système, le détournement des appels systèmes permet
de contrôler toutes les interactions entre des processus sur les ressources.
Sur les systèmes d’exploitation Windows, pour exécuter du code en espace noyau, il faut que
ce code soit directement dans le noyau ou soit exécuté par un pilote de périphérique (un driver).
Dans le cas de Windows, comme il n’est pas possible de recompiler le noyau pour y inclure nos
modifications, nous sommes contraints de mettre en place un driver. Sur les systèmes d’exploitation
Linux, ce contrôle peut être effectué soit par un module noyau, soit par une modification du
code du noyau, puisque ce dernier est modifiable.
La figure 3.1 illustre le placement de l’observateur de manière générale vis-à-vis d’un appel
système fait par un processus. Lorsqu’un processus effectue une interaction sur une ressource,
celle-ci passe par un appel système (flèche 0). Dans un premier temps, l’observateur doit détourner
563.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION
LINUX ET WINDOWS
le flux d’exécution (flèche 1). Il prend ensuite une décision au regard de sa politique de sécurité
(flèche 2). Dans le cas où l’interaction est autorisée, il va exécuter l’appel système et récupérer
le retour de celui-ci (flèche 3). L’observateur peut aussi réaliser des traitements spécifiques sur le
retour de l’appel. Pour finir, et quelle que soit le traitement que l’observateur a réalisé, il renvoie
une réponse au processus ayant réalisé l’interaction (flèche 4).
Un observateur est donc composé d’un mécanisme de détournement appelé Policy Enforcement
Point et d’un mécanisme de prise de décision nommé Policy Decision Point.
FIGURE 3.1 – Schéma du placement de l’observateur
3.1.1 Éléments de base de la protection système
Pour définir de façon générique la notion d’observateur, nous allons nous appuyer sur les deux
scénarios d’attaque que nous avons présentés en introduction de ce mémoire (voir les figures 1.2
et 1.3). De plus, nous allons préciser les éléments de base de la protection système, non seulement
pour un observateur mais aussi pour l’écriture de la politique de sécurité.
Dans ces deux scénarios, nous observons une interaction directe commune : l’écriture par un
navigateur web d’un fichier malveillant comme décrit par la figure 3.2.
FIGURE 3.2 – Écriture d’un fichier malveillant par Firefox : Windows et Linux
Cette interaction est composée de trois éléments. Le premier élément est le sujet, correspondant
au processus Firefox, le second élément est l’objet, le fichier malware.exe sur Windows
et exploit.sh sur Linux, et une opération élémentaire write. Cette interaction directe
est représentée de la manière suivante :
F irefox −−−→
write
malware.exe
573.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION
LINUX ET WINDOWS
Définition 3.1.1 Un sujet Un sujet s est une entité active du système qui réalise une opération
élémentaire. Sur les systèmes Windows, l’ensemble des sujets S est composé des processus, des
services, des services système et des drivers. Sur les systèmes Linux, ce sont exclusivement les
processus.
En nous appuyant sur la figure 3.2, le processus nommé Firefox.exe est le sujet pour
les systèmes Windows alors qu’il est nommé /usr/bin/firefox sur Linux. Sur les systèmes
Windows, les processus sont représentés par leur nom relatif et non par leur chemin complet.
Définition 3.1.2 Un objet Un objet o est une entité du système qui est la cible d’une opération
élémentaire. L’ensemble des objets O est composé des ressources classiques (fichiers, répertoires,
socket, etc.), des éléments du registre (les ruches, les clés, les valeurs et des données) ainsi que de
l’ensemble S des sujets.
Dans la figure 3.2, le fichier malware.exe est un exemple d’objet pour Windows et le fichier
exploit.sh l’est pour Linux.
Définition 3.1.3 Une classe Une classe class est utilisée pour caractériser un objet. Elle permet
de spécifier le type d’objet, et par conséquent, les opérations élémentaires possibles sur cet objet.
L’ensemble Class constitue l’ensemble des classes autorisées sur le système.
La classe permet ainsi de différencier les opérations élémentaires réalisées sur un fichier des
opérations réalisées sur un tube. Les objets malware.exe et exploit.sh sont de la classe
fichier.
Définition 3.1.4 Une opération élémentaire Une opération élémentaire oe est une opération de
base effectuée par un sujet sur un objet (ou sur un sujet) lors de l’exécution d’un appel système.
Par exemple sur Linux, l’ouverture d’un fichier met en œuvre deux opérations élémentaires.
L’opération élémentaire getattr vérifie les droits sur le fichier et l’opération élémentaire open
retourne un descripteur de fichier.
Définition 3.1.5 Un appel système Un appel système est une fonction du noyau permettant d’effectuer
des opérations d’entrée/sortie, de communication, etc. Toutes ces opérations sont considé-
rées comme sensibles au niveau du système d’exploitation. C’est pour cette raison qu’elles sont
réalisées par le noyau. Lors d’un appel système, une opération élémentaire est réalisée.
Pour pouvoir réaliser l’opération élémentaire write, le processus Firefox.exe utilise une
fonction nommée WriteFile(), présente en espace utilisateur. Elle correspond à un appel système
en espace noyau qui se nomme NtWriteFile(). C’est cette fonction qui réalise l’opération
d’entrée/sortie sur le fichier. Nous obtenons la même chose sous Linux de manière complètement
analogue, seuls les noms des fonctions sont différents. La figure 3.3 détaille ce cheminement
d’une écriture dans un fichier.
La définition des notions de sujets, d’objets et d’opérations élémentaires, nous permettent de
formaliser la notion d’interaction.
Définition 3.1.6 Une interaction Une interaction it, s −→oe
o est un triplet composé d’un sujet,
d’un objet et d’une opération élémentaire. Elle est notée it = (s, o, oe)
Dans notre exemple 3.2, l’interaction est composée du sujet Firefox.exe, de l’opération
élémentaire écriture et de l’objet malware.exe.
Nous pouvons affiner cette définition d’interaction par l’ajout de la notion directe. Cela signifie
que le sujet exécute directement un appel système sur l’objet.
583.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION
LINUX ET WINDOWS
FIGURE 3.3 – Écriture détaillée d’un fichier malveillant par un navigateur web
Définition 3.1.7 L’observateur Pour observer une interaction directe, il est nécessaire de mettre
en place un mécanisme capable d’intercepter les opérations élémentaires. Pour cela, cette interception
est réalisée par un observateur au niveau des appels système. Cet observateur doit détourner
le flux d’exécution. La figure 3.4 montre le placement de l’observateur en amont de l’appel
système, donc en espace noyau. En se plaçant en amont de l’appel système, l’observateur est capable
de bloquer le flux d’exécution dans le cadre de l’application d’une politique de protection.
Il peut aussi traiter le retour de l’appel système.
Il existe différents types d’observateurs : les moniteurs de référence, qui contrôlent les interactions,
les auditeurs, qui génèrent des traces en fonction des interactions, les vérificateurs d’inté-
grité, etc.
FIGURE 3.4 – Placement de l’observateur pour détourner le flux d’exécution
Nous proposons le placement d’un observateur en espace noyau car nous voulons avoir un
observateur capable de contrôler toutes les interactions qui se passent sur le système, tout en se
protégeant des potentielles attaques des processus.
593.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION
LINUX ET WINDOWS
Définition 3.1.8 Détournement de flux d’exécution Le détournement du flux d’exécution est une
opération réalisée le plus souvent en espace noyau dans le but de contrôler les interactions réalisées
par le système. Pour réaliser cela, il faut, soit utiliser un mécanisme prévu dans le système
d’exploitation comme les LSM, soit modifier directement le noyau.
Lors de sa prise de décision, l’observateur a la possibilité d’enregistrer sa décision dans le but
d’assurer la traçabilité des interactions qu’il observe. Pour cela, il génère une trace.
Définition 3.1.9 Trace Une trace tr est générée par l’observateur lors d’une observation, elle
contient l’interaction it décrivant l’opération. Elle peut aussi contenir d’autres informations renseignant
sur l’état du système comme un identifiant de trace ou un horodatage que l’on peut noter
d. tr = (d, s, o, oe).
Pour réaliser un traitement spécifique vis-à-vis d’une observation, l’observateur s’appuie sur
une politique de sécurité.
Définition 3.1.10 La politique de sécurité Un observateur a besoin d’une politique de sécurité
dans le but de réaliser des traitements spécifiques.
Une politique de sécurité peut être de la forme : politique d’audit, politique de détection,
politique de protection, etc. Une politique est constituée d’un ensemble de règles. Une règle permet
à l’observateur d’exécuter un traitement spécifique lorsqu’il intercepte une interaction. Il existe
plusieurs types de règles : règles d’audit, règles de détection, règles de protection, etc.
Dans le cas d’une politique de protection, le traitement est le suivant : si l’interaction courante
ne correspond pas à une règle d’autorisation dans la politique de sécurité, alors l’observateur
l’interdira.
La figure 3.5 illustre le fonctionnement du système avec la mise en place d’un observateur
ainsi que d’une politique de sécurité. Nous avons vu que les deux systèmes d’exploitation étudiés,
Windows et Linux, possèdent une symétrie au niveau de leur fonctionnement. Grâce à cette
symétrie, nous pouvons obtenir un placement générique pour notre observateur commun au deux
systèmes.
FIGURE 3.5 – Schéma global de détournement des flux pour les deux systèmes
Chaque interaction est détournée par l’observateur en espace noyau qui exécute un traitement
conforme à sa politique de sécurité. Dans le cas où l’interaction n’est pas bloquée, l’appel système
se poursuit.
603.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION
LINUX ET WINDOWS
3.1.1.1 Modélisation du système observé
Nous venons de définir les éléments clés d’un système : les sujets, les objets, les opérations
élémentaires, etc. Grâce à ces définitions, nous allons pouvoir modéliser l’observation du système
d’exploitation.
Le système est constitué d’un ensemble S de sujets et d’objets O. Les sujets réalisent des
opérations élémentaires sur les objets. Ces opérations se traduisent par la définition d’une interaction
it = (s, o, oe). L’ensemble des interactions possibles sur un système est représenté par
l’ensemble IT. Nous pouvons noter que lors d’un appel système, une opération élémentaire oe est
réalisée entre l’appelant (le sujet) et la cible (l’objet ou le sujet). Ainsi lors d’un appel système,
l’observateur reconstruit une interaction directe.
Un observateur détourne un appel système pour prendre une décision et reconstruit une interaction.
Cette décision s’appuie sur une politique de sécurité P ol, qui est composée d’un ensemble
de couples : traitement_observateur et it formant les règles d’accès. On obtient alors, pour une
politique P ol donnée, P ol =
P(traitement_observateur, it). À partir de l’interaction observée
et d’une politique de sécurité, l’observateur prend une décision en utilisant la fonction Dec :
Dec(it, P ol) 7→ (decision, tr) où tr est une trace générée par l’observateur comme le détaille
l’algorithme 1.
Algorithm 1 Prise de décision de l’observateur
Require: P ol
Require: it
d ← Horodatage()
decision ← RechercheDansP olitique(it, P ol)
tr ← GenererT race(d, decision, it)
return decision, tr
L’observateur s’appuie sur deux fonctions : RechercheDansP olitique, fonction qui recherche
l’interaction observée dans la politique pour en extraire une décision et GenererT race,
qui construit une trace.
L’algorithme 2 détaille le mécanisme de recherche d’une interaction it dans une politique P ol
de sécurité. Une politique P ol est composée d’un ensemble de couples : interaction it et traitement
traitement_observateur. Lorsque l’interaction n’existe pas dans la politique, la fonction
retourne un traitement par défaut traitement_def ault qui sera spécifié en fonction du type d’observateur
voulu.
613.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION
LINUX ET WINDOWS
Algorithm 2 Recherche dans la politique
Require: P ol
Require: it
trouve ← F alse
for all r ∈ P ol ET trouve == F alse do
if Satisf ait(it, r) then
trouve ← T rue
end if
end for
if trouve == T rue then
decison ← r.traitement_observateur
else
decision ← traitement_def ault
end if
return decision
Enfin, la deuxième fonction sur laquelle s’appuie l’observateur est la fonction générant une
trace tr, détaillée par l’algorithme 3. Elle prend en paramètre l’horodatage, la décision ainsi que
l’interaction. Elle ajoute à ces trois éléments un identifiant unique de trace.
Algorithm 3 Génération d’une trace
Require: d (horodatage)
Require: decision
Require: it
id ← CurrentId()
tr ← (d, id, it, decision)
return tr
On peut, à partir de tous ces éléments, modéliser le système observé, comme l’ensemble des
sujets, des objets, des interactions auxquels on ajoute une politique de sécurité et un observateur :
Systemobserve = (S, O, IT, P ol, Observateur)
3.1.1.2 Mode de sécurité
Un observateur possède 3 modes de sécurité. Un mode de sécurité est le comportement de
l’observateur vis-à-vis d’une requête qu’il reçoit. Par construction, ces 3 modes de sécurité sont
mutuellement exclusifs, c’est-à-dire qu’un observateur ne peut pas être simultanément dans deux
de ces modes.
Requête/Réponse
Le premier mode de sécurité est le mode requête/réponse. Ce mode est illustré par la fi-
gure 3.6. Classiquement, lorsque l’observateur reçoit une requête, il va fournir une réponse. Dans
ce mode, l’observateur peut refuser l’appel, retranscrit sur le schéma par les pointillés. Il observe
l’appel système et transmet la réponse de l’appel au système. On peut ajouter un comportement
facultatif à ce mode qui est l’émission d’une alerte.
Classiquement, ce mode est le mode protection (ou enforcing) que l’on retrouve dans les implantations
telles que SELinux ou grsecurity. Lorsque l’observateur reçoit une requête, il autorise
ou non l’interaction et répond à l’appelant (c’est-à-dire : l’observateur se comporte comme un
623.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION
LINUX ET WINDOWS
FIGURE 3.6 – Mode de sécurité : requête/réponse de l’observateur
intermédiaire entre le processus et l’appel système). Si l’interaction est refusée, une alerte sera
enregistrée dans un fichier d’audit.
Évidence
Le second mode de sécurité est le mode évidence. Ce mode est illustré par la figure 3.7. Le
fonctionnement se base sur deux étapes : lorsque l’observateur reçoit une requête, il transmet la
requête à l’appel système et peut éventuellement émettre une alerte. Dans ce mode de fonctionnement,
l’observateur exécute toujours l’appel système.
FIGURE 3.7 – Mode de sécurité : évidence
On retrouve ce comportement dans les systèmes de détection d’intrusion (Intrusion Detection
System). Lorsque l’observateur reçoit une requête qui correspond à une des règles, il va lever une
alerte (ou générer une trace), sinon il ne fait rien. On retrouve aussi ce comportement pour les
mécanismes de protection qui sont placés en mode détection aussi appelé permissif.
Notification
Le troisième mode de sécurité est le mode notification. Ce mode est illustré par la figure 3.8.
Le fonctionnement de ce mode repose sur le fait que l’observateur va envoyer une notification sans
avoir reçu d’évènement spécifique.
FIGURE 3.8 – Mode de sécurité : notification
Il peut s’agir d’un observateur qui par exemple envoie un signal à un processus qui consomme
trop de temps processeur.
633.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION
LINUX ET WINDOWS
3.1.2 Définition d’un observateur : le moniteur de référence
Nous allons, dans cette partie, décrire plus en détail notre modèle de moniteur de référence. Ce
modèle est assez générique pour être appliqué sur les différents systèmes. Le moniteur de référence
est chargé d’appliquer le traitement présent dans la politique de sécurité au regard de l’interaction
courante. Dans le cadre de notre moniteur de référence, les traitements possibles sont : autoriser,
refuser et auditer. Si ce modèle couvre les approches Unix existantes, nous montrerons qu’il peut
être implanté sur différents systèmes. Nous proposons plus spécifiquement une mise en œuvre
pour Windows puisque le manque se situe à ce niveau.
Le moniteur de référence est un observateur particulier qui peut empêcher l’interaction, il est
donc en mode de sécurité requête/réponse. Cela se traduit de la manière suivante :
— la requête : c’est une demande d’accès d’un sujet sur un objet du système ;
— la réponse : c’est la décision du moniteur de référence pour la demande d’accès. Elle peut
être de deux types : autorisation ou refus.
À la différence des moniteurs existants sur Linux, notre moniteur de référence est plus gé-
nérique en supportant des politiques de sécurité de type PBAC et des politiques DTE, que nous
détaillerons par la suite.
Notre moniteur de référence propose 3 modes d’utilisation :
— désactivé : aucun contrôle n’est réalisé et le flux d’exécution n’est pas détourné ;
— actif : le flux d’exécution est détourné et les décisions permettent d’empêcher les interactions.
En cas de refus, une alerte est levée par la génération d’une trace. C’est le mode
protection ;
— permissif : le flux d’exécution est détourné, le moniteur de référence cherche dans la politique
et prend une décision, mais il n’empêche pas l’interaction. Ce mode permet de créer
plus facilement la politique de contrôle d’accès et de la valider sans nuire au fonctionnement
du système. Dans ce mode, par défaut, tous les accès, qu’ils soient autorisés ou non,
peuvent être enregistrés dans un fichier d’audit. C’est le mode évidence.
La figure 3.9 illustre les différents traitements que réalise notre moniteur de référence. Pour
décrire cette architecture logicielle, nous allons dérouler un cas pratique en détaillant chacune des
étapes réalisées au sein du moniteur de référence. Nous séparerons en trois parties ce cheminement
: les opérations réalisées durant une phase de pré-décision, c’est-à-dire avant de prendre une
décision pour savoir si l’appel système sera exécuté ou non, une phase de décision, et les opérations
réalisées en post-décision, c’est-à-dire une fois que la décision a été prise.
643.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION
LINUX ET WINDOWS
FIGURE 3.9 – Schéma du moniteur de référence
3.1.2.1 Phase de pré-décision
La première opération, qui n’est pas directement du ressort du moniteur de référence et qui
consiste à détourner le flux d’exécution régulier, correspond à la flèche 1. Nous décrirons diffé-
rentes méthodes de détournement pour les systèmes Windows dans la section 3.3. Cette partie agit
comme les LSM et propose des interfaces de connexion à notre moniteur de référence. Ainsi, ce
dernier n’a pas besoin de savoir comment est réalisé le détournement du flux d’exécution.
Prétraitement Une première phase notée 2.1 regroupe un ensemble d’opérations de prétraitement.
Dans cette phase, le moniteur attribue un identifiant unique de trace et ajoute un horodatage.
Nous simplifierons les notations en considérant que l’élément d contient à la fois l’horodatage et
un identifiant unique. Ces deux informations serviront à reconstruire l’activité globale du système
pour trouver les scénarios complets d’attaque. La figure 3.10 illustre ce mécanisme.
FIGURE 3.10 – Construction de la trace par le moniteur de référence : ajout de l’horodatage
653.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION
LINUX ET WINDOWS
Le moniteur ajoute ainsi des informations qui ne serviront pas directement à la prise de décision
mais qui se révèlent utiles pour construire/analyser les activités du système. Dans notre cas,
nous avons choisi de prendre les PID et PPID du sujet, illustré par la figure 3.11.
FIGURE 3.11 – Construction de la trace par le moniteur de référence : ajout d’information pour
l’historique des processus
Notre moniteur de référence doit ensuite calculer les éléments qui vont lui servir à la prise de
décision. Pour cela, il doit récupérer le sujet, l’objet, la classe de l’objet et l’opération élémentaire
demandée par le sujet sur l’objet, illustré par la figure 3.12.
FIGURE 3.12 – Construction de la trace par le moniteur de référence : translation en une interaction
Nous calculons dans cette première phase l’interaction requise qui permettra au moniteur d’autoriser
ou de refuser l’appel système.
Dans le cas du modèle de protection PBAC, le moniteur translate les sujets et objets vers leurs
noms absolus (voir les détails ultérieurs). Les opérations élémentaires sont calculées sous la forme
d’ACL étendues comme définies dans la politique.
Pour le modèle de protection DTE, il est nécessaire d’obtenir les contextes de sécurité incluant
les types pour les sujets et objets. Ils sont donc calculés dans cette phase. Les opérations élémentaires
sont elles directement dérivées des appels système.
A la fin de cette phase, le moniteur possède une interaction it décrivant l’interaction à contrôler.
Tout le cheminement de la construction de la trace effectuée en phase de prétraitement est
illustré par la figure 3.13.
663.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION
LINUX ET WINDOWS
FIGURE 3.13 – Construction de la trace par le moniteur de référence : schéma global
L’algorithme de construction de la trace par le moniteur de référence est défini par l’algorithme
4. Il prend en entrée l’appel système composé d’un processus et d’un objet. Il commence
par horodater la trace puis l’enrichit en ajoutant les PID et PPID. Enfin, il transforme l’appel système
en une interaction directe.
Algorithm 4 Construction de la trace par le moniteur de référence
Require: AS : processusobjet
tr ← processus, objet
d ← horodatage()
tr ← d, tr
pid, ppid ← enrichissement()
tr ← pid, ppid, tr
it ← translation(as)
tr ← modif ication_trace(tr, it)
return tr
L’algorithme de translation de l’appel système en une interaction directe est illustré par l’algorithme
5. Il prend en entrée l’appel système et commence par modifier le processus et l’objet pour
coller au modèle de protection (PBAC ou DTE). Puis, il va faire correspondre l’appel système à une
opération élémentaire pour construire une interaction directe. La fonction ObtenirOE() retourne
l’opération élémentaire associée à l’appel système.
673.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION
LINUX ET WINDOWS
Algorithm 5 Translation de l’appel système en interaction
Require: AS : processusobjet
s ← Sujet(processus)
o ← Objet(objet)
oe ← ObtenirOE(AS)
it ← (s, oe, o)
return it
3.1.2.2 Phase de décision
Une fois que le moniteur de référence a toutes les informations nécessaires, il est capable de
prendre une décision, qui correspond à la phase 2.2 de notre schéma. Pour ce faire, il va aller
rechercher dans la politique de sécurité l’interaction requise.
1. Si l’interaction ne satisfait pas la politique, alors le moniteur considère que l’appel système
doit être refusé et qu’il faut auditer ce refus.
2. Si l’interaction est présente dans la politique, alors le moniteur effectue le traitement correspondant.
Le moniteur génère une trace lors des interdictions dans le but d’assurer la traçabilité des
opérations effectuées sur le système. Lorsque les opérations sont autorisées par la politique de
sécurité, il n’est pas nécessaire de générer de trace.
3.1.2.3 Phase de post-décision
audit Après la phase de décision, le moniteur entre dans la phase d’audit. Dans cette phase, il va
pouvoir enregistrer les éléments de l’interaction : sujet, objet, opération élémentaire. De plus, nous
avons récupéré lors de la phase de prétraitement une date et un identifiant unique, ainsi que des
informations secondaires. Nous allons nous servir de tous ces éléments pour construire une trace
suffisamment précise pour décrire l’interaction.
Cette phase est obligatoire lorsque le moniteur est mis en mode permissif.
détection et protection Lorsque le moniteur est en mode permissif, l’opération élémentaire se
poursuit c’est-à-dire que l’appel système est toujours exécuté.
Lorsque le moniteur est en mode actif, en cas de refus explicite, l’interaction ne se poursuit pas
et l’appel système n’est pas exécuté. Si l’interaction est autorisée, alors le moniteur va exécuter
l’appel système (flèche 3). Il s’agit du mode protection.
post-traitement La phase de post-traitement permet d’effectuer des traitements après l’exécution
de l’appel système ou en cas de refus.
Dans le cadre du retour de l’appel système, le moniteur peut mettre à jour la trace d’audit
en spécifiant par exemple le code de retour de l’appel système : s’il a réussi, échoué, quel code
d’erreur, etc. La mise à jour de la trace passe aussi par l’inscription de la date de retour de l’appel
système. Ainsi, en traitant les différentes traces, on peut connaître les sujets ayant eu accès en
même temps à une ressource et ainsi contrer les attaques de type race condition, en analysant les
dépendances causales entre interactions [Rouzaud-Cornabas, 2010].
Lorsque l’interaction a été refusée, le moniteur peut notifier les utilisateurs en fonction de la
gravité de l’opération élémentaire. Par exemple, il peut envoyer un message directement depuis
l’espace noyau pour déclencher une alerte.
683.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION
LINUX ET WINDOWS
retour du moniteur La dernière phase consiste à retourner le résultat de l’appel système au
processus appelant. Lorsque l’interaction a été autorisée et que l’appel système a été exécuté, on
peut renvoyer les résultats retournés par l’appel système. Lorsque l’interaction a été refusée, il
faut renvoyer un code d’erreur significatif au processus. Par exemple sous Windows, le moniteur
peut renvoyer le code STATUS_ACCESS_DENIED et sous Linux -EACCES. Il est à noter que le
post-traitement permet de modifier si besoin les résultats de l’appel.
3.1.3 Répartition des observateurs
Nous avons présenté dans l’introduction de notre étude 1.3.3 qu’un seul observateur n’était pas
suffisant pour protéger efficacement le système et qu’il était nécessaire de mettre en place plusieurs
observateurs.
La répartition des observateurs consiste à ajouter différents observateurs dans la chaîne de
contrôle des interactions, c’est-à-dire des appels système. Définir la répartition nécessite de décrire
la méthode d’association de deux observateurs, leurs localisations et leurs redondances.
3.1.3.1 Association
Nous définissions deux modes d’association pour qu’une interaction puisse être traitée par
deux observateurs. Ces deux modes sont mutuellement exclusifs. Deux observateurs ne peuvent
pas être à la fois en mode cascade et en mode continuation, puisque comme nous le verrons, dans
le premier mode, le premier observateur attend la réponse du second, ce qui n’est pas le cas dans
le second mode.
Cascade
Le premier mode est le mode cascade. Ce mode est illustré par la figure 3.14. Dans ce mode, le
premier observateur reçoit la requête et la transmet au second observateur. Le second observateur
renvoie la réponse au premier observateur qui renvoie ensuite une réponse à l’appelant.
FIGURE 3.14 – Mode d’association : cascade
Ce mode de fonctionnement a été, par exemple, mis en place dans le défi ANR [ANR, 2009]
par l’utilisation combinée de SELinux et de PIGA. Il permet d’additionner les contrôles des deux
observateurs.
Continuation
Le second mode est le mode continuation. Ce mode est illustré par la figure 3.15. Dans le
mode continuation, le premier observateur n’attend pas la réponse du second. Il effectue son traitement
et transmet ensuite, si nécessaire, la requête au second.
Ce mode peut être illustré en donnant une priorité dans les contrôles d’accès. Le premier
contrôle est prioritaire et décide seul d’interdire/autoriser l’accès ou bien de transmettre la demande
au second mécanisme.
693.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION
LINUX ET WINDOWS
FIGURE 3.15 – Mode d’association : continuation
3.1.3.2 Localisation
Nous avons défini les modes de sécurité ainsi que les modes d’association possibles pour les
observateurs. Nous allons maintenant détailler les modes de localisation, c’est-à-dire la place d’un
observateur au sein de différentes architectures.
Colocalisée
Le premier mode concerne un observateur localisé sur la même machine que le client. Ce mode
est illustré par la figure 3.16.
FIGURE 3.16 – Mode de localisation : colocalisé
Ce mode est principalement utilisé par les mécanismes de contrôle d’accès obligatoire : SELinux,
grsecurity, etc.
Distante
Le second mode de répartition possible est d’avoir un observateur distant. Ce mode est illustré
par la figure 3.17. Dans ce mode, les requêtes ne sont pas transmises localement, mais envoyées
depuis un client vers un nœud distant. Nous avons dans ce schéma une relation 1 : 1, c’est-à-dire
qu’à chaque nœud, nous associons un observateur spécifique sur une machine distante.
FIGURE 3.17 – Mode de localisation : distant
Ce mode peut être illustré par le fonctionnement en mode client/serveur du programme de
gestion des traces système (syslog-ng). Le serveur de centralisation des logs reçoit les logs
depuis tous les nœuds distants.
703.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION
LINUX ET WINDOWS
Parallèle
Ce troisième mode de répartition est différent du précédent. Le mode distant associe à chaque
nœud une machine hébergeant un observateur, ce qui pose clairement un problème de dimensionnement
du système réparti. Dans le mode parallèle, une même machine est capable d’héberger
plusieurs observateurs qui s’exécutent en parallèle. Cependant, chaque observateur n’est associé
qu’à un seul nœud distant. Ce mode est illustré par la figure 3.18. S’il est difficile de qualifier
ce modèle, on peut le noter n : 1(||) au sens que n nœuds peuvent être traités en parallèle par 1
machine.
FIGURE 3.18 – Mode de localisation : distant avec plusieurs nœuds et plusieurs observateurs
Partagée
Dans le mode partagé, au lieu d’avoir une relation 1 : 1 entre les nœuds et les observateurs,
la relation se note en n : 1(p). Cela signifie qu’un observateur est partagé par plusieurs nœuds
distants. Ce mode est illustré par la figure 3.19.
FIGURE 3.19 – Mode de localisation : distant avec plusieurs nœuds et un seul observateur
3.1.3.3 Redondance
Dans les architectures distribuées, il est nécessaire d’assurer la disponibilité des services. Dans
le cas qui nous intéresse, l’observateur est un élément vital qu’il faut pouvoir redonder.
Diffusion
Le premier mode de redondance est le mode diffusion. Dans ce mode, le nœud envoie simultanément
les requêtes à (au moins) deux observateurs. Il doit ainsi traiter les deux réponses des
713.1. DÉFINITION D’UN OBSERVATEUR POUR LES SYSTÈMES D’EXPLOITATION
LINUX ET WINDOWS
observateurs. Ce mode est illustré par la figure 3.20. Ainsi, si un des deux observateurs ne répond
plus, le nœud n’est pas obligatoirement bloqué puisqu’il peut obtenir une réponse du second observateur.
Dans le cas de fautes byzantines, on peut imaginer au moins trois redondances (R1, R2,
R3) avec un vote majoritaire.
FIGURE 3.20 – Mode de redondance : diffusion des requêtes par le nœud
Maître-Esclave
Le second mode de redondance est le mode maître-esclave. Dans ce mode, ce sont les observateurs
qui se communiquent les requêtes envoyées par le nœud au serveur maître. Nous avons
pris comme exemple l’observateur maître qui fait suivre la requête. Ainsi, les deux observateurs
possèdent tous les deux toutes les requêtes envoyées. Ce mode de fonctionnement est illustré par
la figure 3.21. Lorsque l’observateur maître ne répond plus, le nœud se connecte à l’observateur
esclave.
FIGURE 3.21 – Mode de redondance : architecture de la forme maître-esclave
3.1.3.4 Discussion
Nous venons de détailler les différents modes d’association, de localisation et de redondance
des observateurs.
Par la définition des modes d’association, nous modélisons l’utilisation combinée de deux observateurs.
Dans le mode en cascade, le premier observateur a un rôle primordial dans la chaîne
de traitement des requêtes puisque c’est lui qui doit envoyer les requêtes au second observateur
et attendre la réponse. Il est ainsi possible de corréler, au niveau du premier observateur, les dé-
cisions prises par les deux observateurs. Cependant, dans ce mode de fonctionnement, le premier
observateur doit attendre une réponse du second observateur, ce qui peut réduire les performances
du système. Dans le second mode, le premier observateur n’attend pas la réponse du second. Il
effectue son traitement et transmet ensuite, si nécessaire, la requête au second. Ce mode de fonctionnement
évite le blocage du premier observateur attendant la réponse du second. Cependant, il
n’est plus possible de corréler les réponses des observateurs au niveau du premier.
723.2. MODÉLISATION D’UNE POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT
Les modes de localisation adaptent les modèles des systèmes répartis aux observateurs. À partir
du mode distant, nous avons spécialisé l’approche de répartition. Ainsi, par la définition des modes
parallèle et partagé, nous avons centralisé les requêtes et les décisions prises par les observateurs.
Avec une localisation distante et les deux cas particuliers (parallèle et partagé), il semble possible
de réduire la charge de calcul des nœuds clients. De plus, avec les modes parallèles et partagés, il
est possible de faire des corrélations entre les interactions des différents nœuds clients.
Néanmoins, en déportant les observateurs sur une machine dédiée, nous introduisons des situations
de pannes supplémentaires : les pannes sur le réseau et les pannes de la machine hébergeant
l’observateur déporté. De plus, ce déport peut aussi entraîner une latence au niveau de la communication
avec l’observateur puisque cette communication passe par un lien réseau.
Pour réduire les pannes potentielles introduites par le déport de l’observateur, nous avons proposé
un modèle de redondance. Nous considérons deux modes de fonctionnement. Le premier
repose sur la diffusion des requêtes faites directement par le nœud. Le principal avantage de cette
méthode est qu’elle permet de tolérer un grand nombre de situations de défaillance. Cependant,
le nœud doit gérer les réponses envoyées par plusieurs observateurs, ce qui implique un calcul
supplémentaire réalisé au niveau du nœud. Le second mode de fonctionnement propose un modèle
maître-esclave. Dans ce mode de redondance, le nœud envoie les requêtes qu’à un seul observateur,
le maître et c’est ce dernier qui transmet à l’observateur esclave. Cependant, lorsque l’observateur
maître ne répond plus, c’est au nœud client de se connecter à l’observateur esclave, ce qui peut
entraîner une latence importante, voir un blocage du nœud si l’observateur met trop de temps à
répondre.
Nous venons de donner une définition de la notion d’observateur pour les systèmes et une
modélisation de la notion de la répartition des observateurs. Nous allons maintenant décrire la
modélisation de la politique de sécurité sur laquelle se base l’observateur pour effectuer ces traitements.
3.2 Modélisation d’une politique de contrôle d’accès direct
Une politique de sécurité définit les traitements à entreprendre par l’observateur, tels que :
autoriser, refuser, auditer, détecter, etc. Dans le cadre d’une politique de sécurité ayant pour objet
de faire du contrôle d’accès direct, nous avons vu dans l’état de l’art (voir en section 2.2.2), qu’il
existe plusieurs modèles obligatoires. Nous avons choisi ici deux modèles de contrôle d’accès
direct : le path-based access control et le domain and type enforcement. Nous proposons une
grammaire commune à ces deux modèles.
La création d’une politique de sécurité impose de nommer chaque ressource du système, que
ce soit les processus, les fichiers ou les sockets par exemple. Nous allons expliquer pourquoi
il est nécessaire de proposer un système de noms absolus indépendants de la localisation pour
désigner les ressources. Grâce à ce système de nommage, nous pouvons générer des politiques
de sécurité portables. Nous montrons l’usage pour les systèmes Windows. Nous définissons une
grammaire commune supportant PBAC et DTE pour Windows. Nous présentons ensuite une étude
des mécanismes de détournement pour Windows.
3.2.1 Grammaire de la politique
Une politique de protection regroupe l’ensemble des interactions qui sont autorisées ou interdites.
Ces règles peuvent être :
— des règles de décision : autorise ou refuse les interactions ;
— des règles d’audit : définit si l’interaction doit être auditée ;
733.2. MODÉLISATION D’UNE POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT
✞ ☎
1 grammar gram_commune;
2
3 politique : (regle’\n’)*;
4 regle : regle_traitement|regle_transition;
5
6 regle_traitement : regle_decision|regle_audit;
7 regle_transition : role_transition|objet_transition;
8
9 regle_decision : autorise_interaction vecteur_acces;
10 regle_audit : audit vecteur_acces;
11
12 role_transition : autorise_role ’ ’ role ’ ’ role;
13 objet_transition : autorise_objet ’ ’ contexte ’ ’ contexte (’:’ classe)? ’ ’ contexte ;
14
15 vecteur_acces : contexte Delimiteurs_debut? (liste_operations_elementaires)+
Delimiteurs_fin? ;
16 liste_operations_elementaires : (’ ’|’\t’)* contexte(’:’ classe)? operations_elementaires
;
✝ ✆
Listing 3.1 – grammaire commune aux modèles de protection PBAC et DTE
— des règles de transition : modifie l’état de la politique ou les contextes du système (sujet
ou objet).
Nous avons défini une grammaire commune pour l’écriture d’une politique de contrôle d’accès,
que l’on retrouve dans le listing 3.1.
Notons que cette grammaire ne propose aucun terminal. En effet, les terminaux sont propres à
chaque modèle de protection. Nous spécifierons dans la suite de cette étude les terminaux pour les
modèles PBAC et DTE.
Nous allons maintenant détailler la grammaire.
Les ressources du système (contextes) Nous avons distingué dans une interaction directe l’élé-
ment sujet, qui réalise l’opération élémentaire, de l’élément objet. Dans la grammaire, il n’est pas
nécessaire de distinguer ces deux éléments puisque les sujets et les objets sont des sous-ensembles
de l’ensemble des contextes. C’est pourquoi nous regroupons ces deux notions au sein d’un même
ensemble que nous appelons contexte.
Définition 3.2.1 Un contexte identifie une ressource à l’aide d’un nom. On retrouve dans la littérature
essentiellement deux méthodes pour nommer les ressources d’un système. La première
méthode consiste à utiliser le chemin complet dans l’arborescence du système de fichiers, ce qui
est fait dans le modèle PBAC utilisé par grsecurity 2.3.1.2 tandis que la seconde méthode est d’associer
un label à la ressource pour la caractériser, ce qui est fait dans le modèle DTE, comme le
fait SELinux (voir en section 2.3.1.1).
On notera CS l’ensemble des contextes sujet et CO l’ensemble des contextes objet.
La figure 3.22 illustre l’opération d’écriture faite par le processus Firefox.exe.
Dans le modèle PBAC, ce dernier est représenté par son chemin complet
C:\Program Files\Mozilla\Firefox.exe. Il réalise une écriture sur le fichier
C:\Users\bob\Downloads\malware.exe.
Nous pouvons faire de même pour les systèmes Linux, illustré aussi par la figure 3.22.
La figure 3.23 illustre cette opération d’écriture d’un contexte sujet sur un contexte objet en
utilisant le modèle DTE. Comme ce modèle associe des types ou des domaines aux ressources,
nous associons au processus Firefox.exe le domaine domaine_firefox et au fichier
malware.exe le type type_malware. Le principal avantage de ce modèle est la possibilité
d’abstraire les ressources du système. Ainsi, il suffit d’associer le domaine domaine_firefox
743.2. MODÉLISATION D’UNE POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT
FIGURE 3.22 – Nommage des ressources au format PBAC
au processus /usr/bin/firefox et le type type_malware au fichier exploit.sh pour
que la même figure illustre cette même opération sur un système Linux.
FIGURE 3.23 – Nommage des ressources au format DTE
Une politique de sécurité Une politique de sécurité est un ensemble de deux types de règles :
les règles de traitement, qui définissent les actions de l’observateur vis-à-vis des interactions et les
règles de transition, qui vont modifier l’état effectif de la politique.
Règle de traitement Une règle de traitement est composée de deux éléments : un traitement
spécifique à effectuer par l’observateur et un vecteur d’accès. Le tableau de vecteurs d’accès dé-
termine les sujets, objets et les opérations élémentaires de l’interaction. Le traitement de l’observateur
peut être : une autorisation explicite, un audit, une interdiction explicite, etc. Le vecteur
d’accès détermine des opérations élémentaires entre un contexte sujet et un contexte objet.
Règle de transition Une règle de transition va modifier l’état effectif de la politique ainsi que
les contextes des sujets et des objets. Nous définissons deux règles de transition :
1. une transition entre deux rôles ;
2. une transition entre différentes ressources du système.
La transition entre deux rôles permet de modifier l’ensemble des opérations élémentaires accessibles.
Par exemple, un utilisateur ayant le rôle user aura besoin de changer de rôle pour effectuer
des tâches d’administration. La figure 3.24 illustre les interactions autorisées pour les rôles
user et admin.
Les transitions entre les ressources du système interviennent lors de la création d’un processus.
Dans ce cas, la transition provient du chargement du fichier en mémoire dans le but de créer un
nouveau processus.
Vecteur d’accès Un vecteur d’accès v représente un ensemble d’interactions directes à observer
sur le système. Il est composé d’un contexte sujet, d’un contexte objet et d’une liste d’opérations
élémentaires potentiellement regroupées par un ensemble associé à une classe.
Soit cs ∈ CS, soit co ∈ CO, soit class ∈ Class et oe1, ..., oen ∈ OE,
753.2. MODÉLISATION D’UNE POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT
role:user
liste d’accès
read write execute
fichier 1
Accès Refusé
Accès Autorisé
fichier 2
read
Accès Autorisé
read
fichier
transition de rôle
role:admin
liste d’accès
read write execute
fichier 1
Accès Autorisé
Accès Refusé
fichier 2
read
Accès Autorisé
read
fichier
FIGURE 3.24 – Transition de rôle modifiant les accès possibles à certaines ressources du système
alors v = (cs, co : class, {oe1, ..., oen})
Selon la figure 3.2 (présente au début de ce chapitre), pour une seule interaction sur un système
Windows entre le contexte sujet firefox.exe et le contexte objet malware.exe on peut par
exemple écrire un vecteur :
v = (f irefox.exe, malware.exe : f ile, {write})
On peut factoriser un ensemble d’interactions entre deux contextes avec un seul vecteur de la
façon suivante :
v = (f irefox.exe, malware.exe : f ile, {create, setattr})
Cependant, nous verrons qu’il est préférable d’avoir des contextes précis (ici la règle s’applique
à tous les sujets firefox.exe présents sur le système ce qui peut être acceptable pour
une interdiction mais peu recommandé pour une autorisation) avec dans ce cas la nécessité que
les noms soient indépendants de leurs localisations physiques afin de garantir la portabilité des
politiques.
3.2.1.1 La portabilité des noms utilisés pour les contextes
Dans notre grammaire, un contexte est un nom qui désigne aussi bien les sujets et les objets.
Il est donc nécessaire que ces noms soient précis afin de contrôler finement chaque processus et
chaque ressource du système. En même temps, ces noms doivent être les plus portables possibles.
Le système de nommage sous Windows
Sur les systèmes Windows, il n’existe pas de racine commune à l’espace de noms. Historiquement,
les systèmes Windows sont installés sur la lettre du lecteur "C:" car les lecteurs "A :" et "B :"
étaient utilisés pour les lecteurs de disquettes. Il est cependant possible d’installer le système sur
un autre lecteur mais aussi d’avoir plusieurs partitions montées sur des lecteurs différents. Ainsi, le
listing 3.2 montre sur sa première ligne le chemin classique pour l’exécutable de Firefox alors
que la seconde ligne montre un chemin depuis un autre lecteur pour le même exécutable.
✞ ☎
1 C:\Program Files\Mozilla\Firefox.exe
2 D:\Program Files\Mozilla\Firefox.exe
✝ ✆
Listing 3.2 – Deux chemins Windows différents désignant le même exécutable
763.2. MODÉLISATION D’UNE POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT
Si l’on utilise le nom C:\Program Files\Mozilla\Firefox.exe désignant précisément
l’exécutable Firefox concerné, ce nom n’est pas portable puisqu’il n’est pas correct sur
un système où les programmes sont installés sur le système de fichiers D :.
Pour résoudre ce problème, nous utilisons la notion de nom symbolique absolu
indépendant de la localisation définie par [Hagimont et J.Mossière, 1996].
1. Un nom symbolique, par exemple le fichier ./policy.24, correspond à un nom usuel
qui est manipulé par les usagers. Ce nom usuel est associé à une localisation physique, sans
que l’utilisateur n’ait besoin de la connaître. Ainsi le nom symbolique ./policy.24 est
par exemple associé au numéro d’i-node 11274188 et au périphérique 19h/25d sous
Unix.
2. Un nom absolu rend le nom symbolique unique c’est-à-dire qu’il désigne une seule ressource.
Le nom absolu est par exemple /home/damien/policy.24 en opposition au
nom relatif policy.24.
3. Un nom absolu indépendant de la localisation physique est un nom qui ne fait pas apparaître
l’emplacement de stockage de la ressource. Cette solution est particulièrement
efficace pour assurer la portabilité des noms.
Pour atteindre ce but sur les systèmes Windows, nous allons abstraire le nom usuel pour rendre
absolu et indépendant de la localisation le nom symbolique.
Définitions
Pour formaliser cette problématique de nommage sur Linux et sur Windows, nous allons défi-
nir les deux notions importantes que sont nom et ressource.
Définition 3.2.2 Ressource Une ressource est un identifiant interne au système utilisé pour manipuler
des objets : par exemple, l’i-node d’un système de fichier.
Définition 3.2.3 Nom Un nom est un moyen simple et usuel pour accéder à une ressource. Géné-
ralement, le nom est représenté sous la forme d’une chaîne de caractères.
Ainsi, une même ressource peut avoir plusieurs noms différents. Nous illustrerons cela dans la
suite de cette partie.
3.2.1.2 Modélisation de la problématique des noms
Nous allons maintenant montrer comment fonctionne le mécanisme de nom symbolique absolu
indépendant de la localisation. Notre modélisation commence par définir deux éléments importants
du système : les notions d’Emplacement physique et de Ressource.
Définition 3.2.4 Emplacement physique Soit ephy un élément de l’ensemble Ephy regroupant les
emplacements physiques. Concrètement, ephy correspond à un bloc de données sur le disque dur.
Définition 3.2.5 Ressource Soit r une ressource du système, par exemple un fichier, appartenant à
l’ensemble R, l’ensemble de toutes les ressources du système. Cette ressource r se caractérise par
un ensemble d’emplacement physique. Nous noterons RSC la fonction qui associe à une ressource
r un ensemble d’emplacement physiques.
773.2. MODÉLISATION D’UNE POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT
∀r ∈ R, RSC r 7→ e tel que e = {ephy1, .., epyhn} avec {ephy1, .., epyhn} ∈ Ephy
Toute ressource du système possède, au moins, un élément dans l’espace d’arrivée Ephy. A contrario,
tout élément de l’espace Ephy ne possède pas nécessairement un antécédent dans l’espace des
ressources. Par exemple, lorsqu’un fichier est supprimé par le système par les fonctions classiques
de suppression telles que rm, les données présentes sur le disque dur associées à ce fichier ne sont
pas supprimées. Il faut, pour cela, utiliser des fonctions spécifiques.
De plus, tout élément de Ephy qui possède un antécédent, ne possède qu’un seul et unique
antécédent par la fonction RSC. Donc par définition, la fonction RSC est injective. Ceci est
illustré par le schéma 3.25.
Ressource Emplacement physique
r
ephy1
ephyn
R E_phy
e
FIGURE 3.25 – Correspondance entre une ressource et les emplacements physiques
En outre, chaque ressource du système possède un emplacement logique. Cet emplacement
logique se caractérise sur le système par un chemin dans le système de fichiers. Une ressource
peut posséder plusieurs emplacements logiques différents, grâce à des opérations de montage ou
par la création de liens.
Définition 3.2.6 Emplacement logique et chemins Nous noterons Elog la fonction qui associe à
une ressource r un emplacement logique dans le système. Cette fonction renvoie un chemin complet
de l’arborescence du système de fichiers. L’ensemble de tous les chemins complets possibles est
noté Chemin. C’est cet emplacement logique qui est utilisé par l’utilisateur pour accéder à la
ressource.
∀r ∈ R, Elog : r 7→ chemin avec chemin ∈ Chemin
Pour qu’une ressource du système puisse être utilisée par un utilisateur, il est nécessaire qu’elle
possède au moins un emplacement logique, c’est-à-dire un nom dans l’espace des noms logiques.
Une ressource peut posséder plusieurs emplacements logiques grâce à des opérations de montage
ou par la création de lien. Cette notion est illustrée par la figure 3.26. On obtient pour un fichier,
une ressource correspond à l’i-node et un ensemble d’emplacement physique.
Comme une ressource peut être désignée par plusieurs emplacements logiques, il est nécessaire
de définir une nouvelle fonction capable d’uniformiser la description d’une ressource pour un
utilisateur.
783.2. MODÉLISATION D’UNE POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT
Ressource Emplacement logique
r
chemin_1
R E_log
chemin_2
FIGURE 3.26 – Correspondance entre une ressource et les emplacements logiques
Définition 3.2.7 Nom symbolique absolu indépendant de la localisation Nous définissons la
fonction Nabs. Cette fonction associe à un emplacement logique d’une ressource un nom symbolique
absolu indépendant de la localisation n
abs
r ∈ Nabs, où Nabs est l’ensemble des noms
symboliques absolus indépendants de la localisation.
Soit r ∈ R et soit chemin ∈ Chemin avec Elog : r 7→ chemin, alors Nabs : chemin 7→ n
abs
r
Par définition, tout emplacement logique possède un seul et unique nom symbolique absolu indé-
pendant de la localisation. A contrario, un nom symbolique absolu indépendant de la localisation
possède au moins un emplacement logique. La fonction Nabs est donc surjective, illustrée par la
figure 3.27.
Emplacement logique
chemin1 n^abs
Chemin
Nom symbolique absolu indépendant
de la localisation
chemin2
N^abs
FIGURE 3.27 – Représentation de la fonction Nabs
793.2. MODÉLISATION D’UNE POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT
La propriété essentielle de cette fonction est la suivante : si une même ressource possède diffé-
rents emplacements logiques, alors, par la fonction Nabs, elle ne possède qu’un seul et unique nom
symbolique absolu indépendant de la localisation. Cette propriété s’exprime de la façon suivante :
∀r ∈ R, si ∃Elog(r) = chemin1 et Elog(r) = chemin2
avec chemin1 6= chemin2 ⇒ Nabs(chemin1) = Nabs(chemin2)
Cette propriété sera illustrée par la suite.
Solution pour les systèmes Windows
Sur les systèmes Windows, la problématique de nommage des ressources est essentiellement
due au fait qu’il n’y a pas de racine commune entre les différents systèmes. Pour résoudre ce
problème et pour appliquer notre fonction permettant d’obtenir un nom symbolique absolu indé-
pendant de la localisation, nous allons utiliser un mécanisme interne au système commun à chaque
système Windows.
Dans un premier temps, le nom de la ressource est séparé en deux : la lettre du lecteur qui est
potentiellement changeante, et son chemin dans l’arborescence qui est constant. Nous appliquons
la fonction Nabs à la partie changeante. Pour ce faire, nous utilisons la notion d’espace de noms
(namespace) d’une ressource. L’espace de noms d’une ressource est une fonctionnalité du système
qui associe aux ressources une représentation abstraite indépendante de leur localisation.
La fonction Nabs est appliquée à C:\Program Files exemple présenté dans le listing
3.2. C’est la partie que l’on considère comme changeante. On obtient ainsi Nabs(C :
\P rogramF iles) = ns_programf iles.
En reprenant notre exemple présenté dans le listing 3.2, nous obtenons pour les deux noms
usuels différents 3.3 un même nom symbolique absolu indépendant de la localisation.
✞ ☎
1 C:\Program Files\Mozilla\Firefox.exe : ns_programfiles:\Mozilla\Firefox.exe
2 D:\Program Files\Mozilla\Firefox.exe : ns_programfiles:\Mozilla\Firefox.exe
✝ ✆
Listing 3.3 – Application des noms symboliques absolus indépendants de la localisation pour
identifier une même ressource sur un système Windows
L’utilisation de cet espace de noms offre une meilleure portabilité de la politique de contrôle
d’accès. Cet espace de noms étant géré directement au sein du système Windows, il n’est plus
nécessaire de réécrire les politiques pour les appliquer sur un autre système Windows.
Solution pour les systèmes Linux
Les systèmes Linux utilisent des identifiants internes pour différencier les ressources sur un
système. Même si ces identifiants sont accessibles depuis l’espace utilisateur, ils ne sont pas facilement
manipulables. Et même si les systèmes Linux disposent d’une racine commune, nous
pouvons aussi appliquer notre formalisation à ce système.
Par exemple en adaptant le listing 3.4 et en appliquant la fonction Nabs, nous obtenons le
résultat suivant 3.5.
✞ ☎
1 /lhome/gros/policy.24 : ns_home:gros/policy.24
2 /mnt/home/gros/policy.24 : ns_home:gros/policy.24
✝ ✆
Listing 3.5 – Application des noms symboliques absolus indépendants de la localisation pour
identifier une même ressource sur un système Linux
803.2. MODÉLISATION D’UNE POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT
✞ ☎
1 gros@ossus:~% stat /lhome/gros/policy.24
2 File: ’/lhome/gros/policy.24’
3 Size: 1592659 Blocks: 3112 IO Block: 32768 regular file
4 Device: 19h/25d Inode: 11274188 Links: 1
5
6 sudo mount -o bind /home/ /mnt/
7
8 gros@ossus:~% stat /mnt/home/damien/policy.24
9 File: ’/mnt/home/gros/policy.24’
10 Size: 1592659 Blocks: 3112 IO Block: 32768 regular file
11 Device: 19h/25d Inode: 11274188 Links: 1
✝ ✆
Listing 3.4 – Différents noms Linux pour une même ressource identifiée par son numéro i-node
3.2.2 Application de la grammaire sur deux modèles de protection pour les systèmes
Windows
L’étude des travaux précédents a montré qu’il existait des implantations de modèles de protection
pour les systèmes Linux. C’est pourquoi nous allons nous concentrer exclusivement sur les
systèmes Windows pour l’application de notre grammaire. La première partie de cette section a
démontré que cette grammaire pouvait s’appliquer sur les deux systèmes d’exploitation.
Nous appliquons la grammaire que nous venons de définir sur deux modèles de protection :
PBAC et DTE. Dans cette section, nous montrerons que seuls les terminaux de la grammaire doivent
être spécifiés, mais que ces deux modèles se basent sur la grammaire commune que nous avons
définie. Nous avons choisi le modèle PBAC pour la facilité qu’il permet dans la rédaction de la
politique car ce modèle se base sur les chemins des ressources. Le second modèle, DTE, offre une
couche d’abstraction entre la politique et le système permettant d’avoir des politiques plus précises
mais aussi supportant mieux l’hétérogénéité.
3.2.2.1 Policy-Based Access Control
Représentation du système
Grâce à l’introduction de notre mécanisme d’abstraction des noms, il est possible de décrire
complètement le système.
Nous définissons NS la fonction du système qui associe à un répertoire donné un élé-
ment de l’espace de noms. Par exemple, NS(C:\ProgramFiles)=ns_programfiles où
ns_programfiles est un élément de l’espace de noms.
Les objets Les objets du système sont toutes les entités qui subissent les interactions : fichiers,
répertoires, éléments du registre, mais aussi les processus.
Grâce à sa stabilité d’architecture, il existe un certain nombre de répertoires communs entre les
différentes versions des systèmes Windows. Il est donc possible de définir des éléments propres à
l’espace de noms pour ces répertoires. Le listing 3.6 fait la correspondance entre les répertoires et
leur nom dans l’espace de noms.
✞ ☎
1 NS(C:\Windows) = ns_windows
2 NS(C:\Program Files) = ns_programfiles
3 NS(C:\Users) = ns_users
4 NS(C:\Recycler) = ns_recycler
✝ ✆
Listing 3.6 – Correspondance entre les répertoires système et leur nom dans l’espace de noms
813.2. MODÉLISATION D’UNE POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT
✞ ☎
1 NS(C:\Windows\explorer.exe) = ns_windows\explorer.exe
2 NS(System) = system
✝ ✆
Listing 3.8 – Noms associés aux sujets pour le modèle PBAC
Lorsqu’un répertoire est spécifique à un système, ou simplement ajouté par un administrateur,
il est possible de lui ajouter un élément générique de l’espace de nom comme
ns_racine\monrepertoire, où ns_racine désigne de manière générique la racine du
système. L’administrateur peut aussi définir ses propres éléments, dans la cadre d’un parc informatique
identique, en utilisant par ns_monrepertoire.
De manière analogue, nous pouvons faire la même chose pour le registre, illustré par le listing
3.7.
✞ ☎
1 NS(HKEY_LOCAL_MACHINE) = ns_hklm
2 NS(HKEY_USERS) = ns_hku
✝ ✆
Listing 3.7 – Correspondance entre les ruches du registre système et leur nom dans l’espace de
noms
Les sujets Les sujets sont les entités du système qui réalisent les interactions sur les objets. Dans
la pratique, les sujets sont un sous-ensemble de l’ensemble des objets. En effet, comme les sujets
sont associés aux processus et aux services, ils peuvent interagir entre eux : un processus pouvant
par exemple récupérer un handle sur un autre processus dans le but d’interagir avec lui.
A la différence des systèmes Linux où l’extension des fichiers n’est pas représentative de
son comportement, sur les systèmes Windows, elle permet de spécifier la nature de la ressource.
Ainsi, la reconnaissance des processus, et donc des sujets, se fait par l’extension .exe qui leur est
associée.
Néanmoins, il existe des processus spécifiques qui ne respectent pas ce schéma, comme le
processus System associé au PID 4. Cependant, ce processus possède le même nom ainsi que le
même PID sur chaque système Windows, il est donc facilement reconnaissable.
Ainsi, nous aurons, en prenant par exemple les sujets explorer.exe et System les noms
associés comme le montre le listing 3.8.
Les opérations élémentaires Les opérations élémentaires sont basées sur les ACL classiques
présentes sous Windows. Nous obtenons ainsi les droits :
1. r, pour le droit de lecture ;
2. w, pour le droit d’écriture ;
3. x, pour le droit d’exécution.
À ces droits classiques, nous rajoutons les droits suivants :
1. h, pour cacher un élément aux autres entités du système ;
2. ap, pour ajouter des privilèges ;
3. rp, pour supprimer des privilèges.
Les rôles Dans ce modèle de politique, la notion de rôle pour les utilisateurs est très importante.
En effet, une politique de type PBAC donne les mêmes droits à tous les utilisateurs, sans distinction
aucune. Il est donc nécessaire de définir des rôles pouvant accéder à certains domaines privilégiés
pour faire de la séparation de privilèges.
823.2. MODÉLISATION D’UNE POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT
✞ ☎
1 grammar pbac;
2
3 // include gram_commune
4
5 classe : Chaine ;
6 autorise_interaction : ;
7 audit : ’audit ’;
8 autorise_objet : ’’;
9 autorise_role : (’role’);
10
11 contexte : Chaine ;
12
13 operations_elementaires : ’ ’ operation_elementaire (’\n’)?;
14 operation_elementaire : (’r’|’w’|’x’) ;
15 role: Chaine ;
16
17 Chaine : ( ( ’a’..’z’|’A’..’Z’|’0’..’9’|’_’|’.’|’,’|’\\’) )+ ;
18 Delimiteurs_debut: ’ {’ (’’|’\n’ )? ;
19
20 Delimiteurs_fin: (’ ’)? ’}’ ;
✝ ✆
Listing 3.9 – Définition des terminaux pour le modèle de protection PBAC
✞ ☎
1 systemroot\explorer.exe {
2 systemroot\cmd.exe w
3 systemdrive\fichier.txt r
4 }
5 audit explorer.exe { programfiles\firefox.exe r }
6 role user admin
✝ ✆
Listing 3.10 – Extrait d’une politique PBAC
Sous Windows, on peut se baser sur les groupes d’appartenance des utilisateurs pour établir
les rôles de chaque utilisateur. Le principal avantage de cette méthode est que ce mécanisme est
intégré à Windows et facilement modifiable.
Grammaire spécifique pour le modèle PBAC
À partir de la grammaire générique que nous avons définie dans le listing 3.1, nous pouvons
étendre cette grammaire pour le modèle PBAC.
Le listing 3.9 détaille la grammaire spécifique pour PBAC. Cette extension ne fait que renseigner
les terminaux de la grammaire, qui sont spécifiques à ce modèle de protection.
Cette grammaire spécifique pour le modèle de protection PBAC permet de définir les éléments
de la politique : les contextes, les rôles et les opérations élémentaires. Elle va aussi spécifier les
délimiteurs pour l’écriture des vecteurs d’accès.
Dans cette politique, les contextes, en pratique des noms symboliques absolus, sont définis
comme des chaînes de caractères spécifiques (par exemple incluant les antislash).
Les opérations élémentaires sont représentées par les ACL classiques présentes sur les systèmes
: r pour l’opération read, w pour l’opération write, etc.
Nous proposons dans le listing 3.10 un extrait de politique pour le modèle PBAC.
Les lignes 1 à 4 autorisent deux interactions directes. La ligne 5 définit une interaction directe
qui doit être auditée. Enfin, la ligne 6 permet à un utilisateur du rôle user de changer son rôle pour
atteindre le rôle admin.
833.2. MODÉLISATION D’UNE POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT
3.2.2.2 Domain and Type Enforcement
Représentation du système
Dans le modèle de protection basé sur DTE, les sujets sont associés à des domaines alors que
les objets sont associés à des types. Nous allons décrire ici comment construire ces deux notions.
Puis, comment proposer des contextes de sécurité étendus avec des notions d’identité et de rôle.
Les objets Les types, qui sont donc associés aux objets du système, sont construits à partir
de deux éléments. Le premier élément est simplement le nom relatif de la ressource sans son
extension, dans le cas où elle en possède une. Ce nom relatif n’est pas unique sur le système,
puisqu’il ne se base que sur le nom de la ressource sans son chemin dans l’arborescence du système
de fichiers. Le second élément est un suffixe qui précise la nature de l’objet : répertoire, exécutable,
bibliothèque, etc.
Par exemple, la ressource C:\Program Files\Mozilla\Firefox.exe. Le nom relatif
de la ressource sans son extension est Firefox. On ajoute à cela sa caractéristique,
ici Cat(executable). Donc le type associé au fichier C:\Program Files \Mozilla
\Firefox.exe est F irefox.Cat(executable).
De manière similaire, nous aurons des catégories pour les répertoires, les driver, les bibliothèques,
etc.
Les éléments du registre seront typés de manière similaire au système de fichiers, à la diffé-
rence qu’ils disposent de catégories spécifiques telles que Cat(key) et Cat(value). Cette dernière
catégorie est aussi utilisée pour la prise de décision.
Les sujets Les sujets sont associés à la partie domaine du modèle DTE. À la différence des
objets qui possèdent une catégorie, les sujets n’en ont pas besoin. En effet, il n’est pas nécessaire
de renseigner la catégorie puisqu’il n’y a que la catégorie processus (en général).
Le domaine est uniquement composé du nom relatif du fichier exécutable
privé de son extension. Par exemple, le domaine associé au fichier C:\Program
Files\Mozilla\Firefox.exe sera Firefox. Tout comme pour le modèle PBAC,
il existe des cas particuliers tels que le processus nommé System qui aura pour domaine
exactement le même nom.
Les opérations élémentaires Dans ce modèle de protection, les opérations élémentaires sont
dérivées des appels système.
En définissant la fonction Cl, qui associe à un objet o appartenant à l’ensemble O des objets
du système l’ensemble des opérations élémentaires spécifiques à cet objet, nous pouvons écrire :
Cl(o) = oe1, ..., oen, avec oei ∈ OE où OE est l’ensemble de toutes les opérations élémentaires.
Par exemple, le fichier cmd_exec_t se définit de la manière suivante : Cl(cmd_exec_t) =
f ile et il possède les opérations élémentaires associées aux fichiers f ile{read write execute etc.}.
Nous pouvons citer quelques opérations élémentaires simples comme read, write ou encore
execute. Il y a aussi getattr lorsqu’un processus demande à récupérer les attributs d’un objet. La
liste de ces opérations élémentaires est équivalente au nombre d’appels système disponibles pour
l’objet considéré.
Extension aux contextes de sécurité Nous définissons des contextes de sécurité plus complets
en ajoutant les notions d’identités mais aussi de rôles aux types et aux domaines. Pour la notion
de rôles, nous utiliserons la même représentation que pour le modèle PBAC, à savoir l’utilisation
des groupes présents sous Windows. Les identités seront liées au SID de l’utilisateur. Les identités
843.2. MODÉLISATION D’UNE POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT
✞ ☎
1 grammar dte
2
3 // include gram_commune
4
5 classe : Chaine ;
6 autorise_interaction : (’allow ’|’neverallow ’);
7 audit : ’auditallow ’;
8 autorise_objet : ’transition’;
9 autorise_role : ’role’;
10
11 contexte : (utilisateur ’:’)? (role ’:’)? (attribut);
12
13 utilisateur: Chaine ;
14 role: Chaine ;
15 attribut: Chaine ;
16
17 operations_elementaires : ’ { ’ (operation_elementaire ’ ’)* operation_elementaire ’ }’;
18 operation_elementaire: (’read’|’write’| Chaine ) ;
19
20
21 Chaine : ( ’a’..’z’|’A’..’Z’|’0’..’9’|’_’|’.’)+ ;
22 Delimiteurs_debut: ’ ’ ;
23 Delimiteurs_fin: ’}’ ;
✝ ✆
Listing 3.12 – Définition des terminaux pour le modèle de protection DTE
et les rôles permettent des contrôles supplémentaires même si ceux-ci sortent du cadre de notre
travail.
Ainsi, on obtiendra un contexte de sécurité sous Windows de la forme 3.11.
✞ ☎
1 SELinux : user:role:type/domaine
2 Windows : SID:Groupe Windows:type/domaine
✝ ✆
Listing 3.11 – Représentation d’un contexte de sécurité sous Windows
Les transitions Il existe deux types de transition : la première est la plus courante, c’est le
passage d’un type à un domaine. Cela se caractérise par l’exécution d’un fichier qui est dans la
Cat(executable). Pour qu’un processus soit autorisé à transiter vers un domaine destination, il est
nécessaire que :
1. le domaine source possède une règle d’accès autorisée à exécuter ce fichier, ainsi que toutes
les opérations élémentaires annexes nécessaires à ce type d’opération comme le droit de
récupérer des informations sur le fichier (getattr) ;
2. le fichier exécutable possède le domaine destination dans la politique de contrôle d’accès.
La seconde transition possible est le changement de rôle. Cette transition n’est pas propre au
modèle DTE. Cela permet de réduire considérablement la taille de la politique donnant les accès
aux rôles plutôt qu’aux utilisateurs directement.
Grammaire spécifique pour le modèle DTE
Comme pour le modèle PBAC, nous étendons la grammaire commune pour qu’elle puisse
fonctionner sur ce modèle de protection. Le listing 3.12 illustre les éléments propres à ce modèle.
Nous définissons deux mots clés pour les règles d’autorisation : allow et neverallow. Le premier
permet d’autoriser de manière explicite l’interaction qui est donnée pour le vecteur d’accès.
Le second l’interdit de manière explicite. Nous montrerons dans la partie expérimentation comment
nous utilisons ces règles d’interdiction. La règle d’audit est signifiée par le mot clé audit.
853.2. MODÉLISATION D’UNE POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT
À la différence du modèle PBAC, où le contexte est une chaine de caractères représentant un
chemin dans le système de fichiers, dans le modèle DTE, il est composé de trois identifiants : un
identifiant pour spécifier l’utilisateur, un autre pour le rôle et enfin un attribut. Les deux premiers
éléments ne sont pas propres au modèle DTE, mais ils facilitent l’administration du système. L’attribut
est soit un domaine, pour un sujet, soit un type pour un objet.
Nous proposons une politique minimale dans le listing 3.13 illustrant la grammaire.
✞ ☎
1 allow explorer_t cmd_exec_t:file { write read getattr execute }
2 auditallow firefox_t document_t:file { read }
3 role user_r sysadm_r
4 transition explorer_t cmd_exec:file cmd_t
✝ ✆
Listing 3.13 – Extrait d’une politique DTE
La première règle autorise le domaine firefox_t à accéder au fichier cmd_exec_t en
lecture et écriture. La seconde règle est une règle d’audit, mais qui n’autorise pas l’interaction.
Enfin, les règles 3 et 4 sont des transitions de rôles et de domaine. Pour que le domaine cmd_t
soit autorisé, il faut la règle de la ligne 1 du listing ainsi que la ligne 4.
3.2.2.3 Lien entre la politique d’accès direct et le moniteur de référence
La politique d’accès directe (PBAC ou DTE) est parcourue par le moniteur de référence lors de
la phase de décision. Cette décision peut être divisée en deux : soit le moniteur trouve une règle
d’accès dans la politique et il applique le traitement associé, soit il ne trouve rien et dans ce cas-là,
il applique une règle par défaut.
La figure 3.28 illustre les deux possibilités offertes par le moniteur. Comme nous pouvons
le voir sur la figure, nous avons ajouté une règle à la grammaire regle_defaut définissant
l’action par défaut que doit avoir le moniteur lorsqu’il ne trouve pas le vecteur d’accès au sein
de la politique de sécurité. Dans le cadre d’un moniteur de référence, nous avons choisi d’avoir
une règle par défaut qui refuse l’opération et qui génère une trace dans le but de connaître les
opérations qui ont été interdites par le moniteur.
863.3. LES TECHNIQUES DE DÉTOURNEMENT SUR LES SYSTÈMES WINDOWS
FIGURE 3.28 – Mécanisme de prise de décision du moniteur de référence
3.3 Les techniques de détournement sur les systèmes Windows
Dans cette section, nous allons expliquer les techniques de détournement des flux d’exécution
présent sous Windows. Des détails se trouvent en annexe C de notre étude. Nous discuterons
des limites de chaque méthode de détournement et de leur place dans le contrôle d’accès sur les
systèmes Windows.
3.3.1 Explications des techniques
3.3.1.1 Détournement de la table des appels système
Sur les systèmes d’exploitation Windows, tous les appels système sont stockés dans une table
nommée table des appels système. Dans cette table, Windows associe un numéro d’appel système
avec une adresse mémoire.
Pour réaliser des interactions, les processus utilisent les fonctions de l’API Win32, qui sont les
fonctions de haut niveau fournies par Microsoft. Il faut ensuite faire correspondre ces fonctions
de haut niveau avec les appels système. Pour cela, une couche d’abstraction placée en espace
utilisateur récupère la fonction de l’API Win32 pour ensuite utiliser l’appel système correspondant.
Pour détourner le flux d’exécution, un driver va aller modifier l’adresse d’un appel système,
dans la table des appels système, pour la remplacer par l’adresse d’une de ses propres fonctions.
Ainsi, lorsque Windows exécute l’appel système dont l’adresse a été modifiée, il exécute une
fonction du driver.
873.3. LES TECHNIQUES DE DÉTOURNEMENT SUR LES SYSTÈMES WINDOWS
Le schéma 3.29 montre le flux d’exécution d’une action sous Windows. Lorsqu’un processus
veut effectuer une interaction sur le système, il fait appel à une fonction présente dans la table des
appels système qui exécute une fonction au sein du noyau.
Le second 3.30 schéma illustre lui le détournement d’un appel système. Lorsque le processus
veut effectuer une interaction, avant de passer dans le noyau, son interaction est détournée par
l’observateur, qui va autoriser ou refuser cette interaction.
FIGURE 3.29 – Fonctionnement régulier d’un appel système présent dans la table des appels système
FIGURE 3.30 – Mécanisme de détournement de la table des appels système
3.3.1.2 Inline-Hook
Cette technique consiste à modifier directement la fonction en mémoire. Sous Windows, au
début des fonctions, il existe une partie de code appelée junk code : c’est ce que l’on appelle un
code sans effet de bord. On peut donc le modifier sans pour autant modifier le comportement de la
fonction.
En allant modifier le junk code présent au début de la fonction pour y placer un saut inconditionnel,
il est possible de détourner le flux d’exécution pour le rediriger vers l’espace mémoire du
driver.
Cette technique a été implémentée pour les fonctions de l’API Win32 et est connue sous le
nom de MS Detour [Hunt et Brubacher, 1999]. Ce projet est porté par Microsoft Research et cible
essentiellement les systèmes Windows XP. Microsoft propose, au travers d’un framework, des
API pour modifier de manière complètement transparente des fonctions spécifiques en espace
utilisateur grâce à l’utilisation d’un mécanisme nommé trampoline. Cette interface est chargée de
récupérer les arguments des fonctions pour qu’ils puissent être exploités par la fonction réalisant
l’inline hook. Elle est cependant transposable aux appels système.
883.3. LES TECHNIQUES DE DÉTOURNEMENT SUR LES SYSTÈMES WINDOWS
Cette méthode est illustrée par la figure 3.31. Elle détaille le placement, en début de fonction,
de la modification introduite pour détourner le flux d’exécution et le placement de l’observateur.
FIGURE 3.31 – Mécanisme d’inline hook
3.3.1.3 filter-driver
Microsoft a mis en place une architecture spécifique basée sur des driver en couches pour
contrôler les interactions réalisées sur le système de fichiers. Cette architecture se base sur la création
de filter-driver s’enregistrant auprès d’un gestionnaire d’entrée/sortie et demandant à traiter
certaines IRP (I/O Request Packets). Une IRP représente une opération d’entrée/sortie. À la différence
des appels système qui ne font qu’une seule opération élémentaire (ouverture de fichier,
lecture, écriture, etc.), les IRP englobent plusieurs appels système pour finalement représenter un
type d’action, par exemple l’ouverture d’un fichier.
La figure 3.32 montre l’architecture des driver en couches. Pour représenter ces différentes
couches, qui définissent le comportement du driver, les filter-driver possèdent une altitude. Cette
altitude définit le type du driver. Par exemple, il existe une plage d’altitude pour les driver d’antivirus
ou pour les driver de chiffrement. Par construction, les filter-driver sont naturellement placé
en mode continuation.
Action d’un processus
sur le système de fichiers
Espace utilisateur
Espace noyau
Moniteur d’activité
Altitude 360 000
FSFilter Antivirus
Altitude 325 000
FSFilter Compression
Altitude 165 000
FSFilter de chiffrement
Altitude 145 000
Driver de stockage
Filter Manager
Frame 0
FS Filter
Pas d’altitude
Filter Manager
Frame 1
I/O Manager
FIGURE 3.32 – Architecture des filter-driver en prétraitement
L’altitude du filter-driver définit le type du driver mais aussi son placement par rapport aux
autres filter-driver. Ce placement influe sur les informations que reçoit ou non le driver.
Une IRP est transmise aux filter-driver concernés par l’action courante. Les transmissions aux
filter-driver sont faites de manière séquentielle et sont définies par leur altitude. Ainsi un filterdriver
qui est à l’altitude 325 000 récupère l’IRP avant un filter-driver qui est à l’altitude 145
893.3. LES TECHNIQUES DE DÉTOURNEMENT SUR LES SYSTÈMES WINDOWS
000 pour des opérations de prétraitement. A contrario, lors des opérations de post-traitement, le
filter-driver qui est à l’altitude 145 000 récupère l’IRP avant celui à l’altitude 325 000.
Dans cette architecture, l’observateur se place dans la pile de driver comme illustré dans la
figure 3.33 pour le prétraitement et pareillement pour le post-traitement 3.34.
FIGURE 3.33 – Place de l’observateur en prétraitement
FIGURE 3.34 – Architecture des filter-driver en post-traitement
Grâce à cette architecture spécifique, nous pouvons définir à quelle altitude sera notre filterdriver.
Comme il a pour but de superviser les interactions faites sur le système de fichiers, ce sera
un driver de type moniteur d’activité et aura donc une altitude comprise entre 360000 et 389999.
Cette altitude a l’avantage de nous placer très haut dans la pile des driver.
903.3. LES TECHNIQUES DE DÉTOURNEMENT SUR LES SYSTÈMES WINDOWS
3.3.2 Discussion
Nous venons de présenter les méthodes de détournements présentes sous Windows. Nous allons
dans cette section discuter du placement de l’observateur dans l’architecture du contrôle d’accès
sur les systèmes Windows. Ensuite nous présenterons des méthodes de contrôle des driver.
3.3.2.1 Place de l’observateur dans le contrôle d’accès de Windows
Comme nous l’avons déjà présenté dans l’état de l’art (voir la section 2.3.2.1), depuis l’arrivée
de Windows Vista, un nouveau mécanisme de sécurité a été introduit dans le système Windows.
Il est complémentaire au modèle de protection discrétionnaire classique. Mais à la différence des
contrôles d’accès obligatoires présents sous Linux, la vérification du niveau d’intégrité est faite
avant la vérification des droits discrétionnaire, ce qui permet par ailleurs, de les contourner.
Avec l’insertion de notre observateur au sein du système Windows, il est nécessaire de
connaître sa place dans l’architecture du contrôle d’accès sous Windows. Nous allons ici traiter
les trois méthodes présentées précédemment en expliquant le placement de l’observateur pour
chaque cas.
Détournement de la table des appels système Lorsque l’observateur détourne le flux d’exécution
en modifiant la table des appels système, l’appel système n’est exécuté qu’à partir du moment
où l’observateur a autorisé l’interaction.
Cela implique que dans cette configuration, le contrôle s’effectue de la manière suivante :
1. contrôle d’accès obligatoire ;
2. contrôle d’intégrité obligatoire ;
3. contrôle des droits discrétionnaires.
En effet, le détournement empêche l’appel système et donc en pratique les contrôles classiques
qui, de ce fait, ont lieu à la suite des contrôles de notre observateur.
Inline hook Cette technique consiste à modifier des fonctions du noyau dans le but de contrôler
le plus grand nombre d’opérations. Dans la pratique, si on ne s’intéresse qu’aux appels système,
nous aurons donc le même comportement que le détournement de la table des appels système.
Dans cette configuration, le contrôle s’effectue de la manière suivante :
1. contrôle d’accès obligatoire ;
2. contrôle d’intégrité obligatoire ;
3. contrôle des droits discrétionnaires.
filter-driver Dans ce modèle de détournement, l’ordre des vérifications est différent. En effet,
dans cette architecture, les requêtes passent par le noyau et sont ensuite transférées au gestionnaire
d’entrée/sortie qui les transmet aux filter-driver concernés par l’opération.
1. contrôle d’intégrité obligatoire ;
2. contrôle des droits discrétionnaires;
3. contrôle d’accès obligatoire.
913.3. LES TECHNIQUES DE DÉTOURNEMENT SUR LES SYSTÈMES WINDOWS
3.3.2.2 Contrôle des driver
Toutes ces techniques se basent sur l’utilisation d’un driver pour agir en espace noyau et ainsi
avoir un impact sur tout le système. Cependant, toutes les opérations que nous avons décrites
peuvent être aussi réalisés par n’importe quel driver. Il est donc nécessaire de contrôler les autres
driver qui sont chargés.
Sur les systèmes Windows, les driver offrent des moyens de communication entre les périphé-
riques tels que les scanner, les webcam, etc. et le système d’exploitation. Ils sont donc nécessaires
au bon fonctionnement du système. On ne peut tout simplement pas empêcher le chargement des
driver. Il faut par conséquent proposer des solutions pour contrôler aussi les driver.
Depuis les systèmes Windows Vista 64 bits et la mise en place de Kernel Patch Protection, les
driver qui sont chargés doivent être signés numériquement par un certificat délivré par Microsoft.
Cela constitue une première vérification quant au chargement des driver. Cependant, ce mécanisme
n’est pas suffisamment fiable puisque certains logiciels malveillants arrivent à charger des
drivers malgré la présence de ce mécanisme.
Nous allons discuter dans cette section, pour chaque solution, du contrôle du chargement des
driver. En effet, il est nécessaire les driver existant ne puissent pas contourner voire supprimer
notre détournement.
Détournement de la table des appels système
Le chargement des driver s’effectue par l’appel système NtLoadDriver. Il est donc possible,
en contrôlant cet appel de contrôler le chargement des driver. Cependant, nous allons dé-
tailler deux installations de driver qui pourraient compromettre le bon fonctionnement de notre
moniteur. Le premier exemple concerne un driver légitime et le second, un driver malveillant.
Un driver légitime peut modifier la table des appels système. Ce sont généralement les logiciels
de sécurité qui réalisent ce type d’opération comme les antivirus ou les pare-feux.
Si un driver légitime modifie la table des appels système, nous pouvons être confrontés à deux
possibilités :
1. l’observateur se charge en dernier parmi l’ensemble des driver qui modifient la table des
appels système : cela implique que notre observateur sera correctement installé et il prendra
la première décision.
2. l’observateur ne se charge pas en dernier, c’est-à-dire qu’un driver, que l’on a autorisé
à se charger, modifie la table des appels système après nos modifications. Si le driver
fait correctement la modification, c’est-à-dire qu’il prend l’adresse présente dans la table
avant sa modification pour appeler l’appel système, alors notre observateur sera toujours
impliqué dans la chaine d’exécution. Si le driver préfère résoudre manuellement l’appel
système, alors l’observateur ne sera plus impliqué dans la chaine d’exécution.
La figure 3.35 illustre l’empilement des driver qui détournent des flux d’exécution engendrés
par la modification de la tables des appels système par plusieurs driver. Chaque observateur maintient
une table modifiée des appels système. Le dernier observateur maintient lui la table régulière
pour exécuter l’appel système. Dans cette configuration, les observateurs sont en mode cascade.
923.3. LES TECHNIQUES DE DÉTOURNEMENT SUR LES SYSTÈMES WINDOWS
Observateur 1
Table courante
des appels système
Table des appels
système modifée
par un second
observateur
processus
Table des appels
système régulières
Observateur 2
Décision Décision
appel système
FIGURE 3.35 – Empilement de driver modifiant la table des appels système
Un driver malveillant peut conduire à une attaque basée sur une situation de concurrence,
illustrée par la figure 3.36. Le principe de l’attaque repose sur le fait que les vérifications faites par
le driver ayant détourné l’appel système ne sont pas atomiques, c’est-à-dire qu’elles prennent un
certain temps.
La fonction NtLoadDriver prend en paramètre un UNICODE. Cet UNICODE contient le
chemin complet du driver à charger. L’attaque réussie lorsque cette fonction est appelée depuis
l’espace utilisateur. Au moment du passage en espace noyau, la structure n’est pas recopiée, mais
seul un pointeur est copié en espace noyau.
processus
malveillant
chemin vers
driver légitime
1
2
3
4
Observateur
5
6
7
8
9
table des appels
système modifiée
NtLoadDriver
Décision
appel système
FIGURE 3.36 – Schéma détaillant la situation de concurrence sur la table des appels système
Tout d’abord, un processus malveillant remplit un UNICODE avec un chemin de driver lé-
gitime (flèche 1), puis exécute l’appel système NtLoadDriver (flèche 2). Comme la table des
appels système a été modifiée par l’observateur, le flux d’exécution est détourné dans l’observateur
(flèche 3). L’UNICODE n’est pas recopié en espace noyau, l’observateur récupère juste un pointeur
vers cet UNICODE (flèche 4). L’observateur effectue ses vérifications (flèche 5). Une fois ces
vérifications faites, le processus malveillant modifie les informations contenues dans l’UNICODE
pour mettre un chemin vers un driver malveillant (flèche 6). L’observateur poursuit le flux d’exé-
cution en appelant la véritable fonction (flèche 7). Le noyau récupère lui aussi un pointeur vers cet
UNICODE (flèche 8) et exécute la fonction (flèche 9). Il est ainsi possible de charger un driver
malveillant malgré les vérifications.
933.4. DISCUSSION
Inline hook
Cette technique ne ciblant pas que les appels système, nous pouvons contrôler plus de fonctions
impliquées dans le chargement des driver. Nous pouvons commencer par contrôler l’appel système
NtLoadDriver. Nous pouvons aussi cibler MmLoadSystemImage. Nous citons ici quelques
fonctions mais cette liste n’est pas exhaustive. En effet, beaucoup de fonctions internes ne sont pas
documentées donc non présentes sur la MSDN.
Tout comme pour le détournement de la table des appels système, si un driver effectue la
même opération que nous, c’est-à-dire placer un saut inconditionnel en début de fonction, notre
observateur ne sera plus impliqué dans la chaîne d’exécution. Il est donc nécessaire de mettre en
place un moniteur qui va vérifier que le saut est toujours présent.
A la différence du détournement de la table des appels système, il n’est pas possible d’avoir
un empilement, comme le montre la figure 3.35 au niveau des driver qui réalisent ce genre de
détournement. Par conséquent, si un driver fait une modification après notre observateur, il faut
soit générer une erreur pour bloquer le système, soit remettre en place le saut inconditionnel. Ce
n’est pas la seule différence. En effet, ce genre de technique n’est pas une technique couramment
utilisée par les driver légitimes. Donc, si on est capable de détecter ce genre de modification, on
peut légitimement supposer que le driver ne devrait pas être autorisé à être chargé. Tout comme
pour le mécanisme de détournement de la table des appels système, il est difficile de contrôler
une modification qui interviendrait sur notre driver. Par conséquent, si un driver vient modifier
notre observateur pour modifier la fonction responsable de la supervision des modifications, alors
l’observateur ne verra pas les nouvelles modifications.
filter-driver
Le filter-driver étant la technique préconisée par Microsoft, elle est donc légitimement devenue
la méthode utilisée par les logiciels antivirus.
Les filter-driver ne contrôlent que les interactions réalisées sur le système de fichiers. Par
conséquent, ils ne sont pas capables de contrôler le chargement des exécutables et par extension,
des driver. C’est pourquoi il est nécessaire de mettre un système de callback. Un callback peut
s’enregistrer auprès du Process Manager. Il peut ainsi contrôler le chargement de tous les exécutables,
y compris les driver. Le contrôle du réseau doit se faire par la création d’un driver spé-
cifique, basé sur l’architecture Windows Filtering Platform. Ces techniques ne sont pas réservées
au filter-driver, mais elles sont nécessaires pour contrôler le chargement des exécutables par un
filter-driver.
Les filter-driver sont installés en spécifiant une altitude. Pour respecter les spécifications de
Microsoft, il faut faire une demande sur leur site pour se faire attribuer une altitude. Une fois que
filter-driver possède une altitude fournie par Microsoft, il enregistre cette altitude dans une clé du
registre. On peut aussi retrouver toutes les altitudes définies dans un fichier fourni par Microsoft.
Néanmoins, rien n’empêchera un filter-driver malveillant de se charger à une autre altitude que
celle spécifiée dans le registre. Cette définition d’altitude n’implique, en aucun cas, que seul un
filter-driver précis peut se charger à cette altitude donnée.
3.4 Discussion
Dans ce chapitre, nous avons commencé par formaliser la notion d’observateur. Nous définissons
les éléments observés tels que les sujets, objets et opérations élémentaires. Nous avons ensuite
défini les modes de sécurité possible pour un observateur : requête/réponse, évidence et continuation.
Puis, nous avons détaillé un observateur spécifique : le moniteur de référence. Dans cette
943.4. DISCUSSION
section, nous avons décrit les trois grandes phases de traitement. Ce moniteur de référence sera par
la suite, appliqué aux systèmes Windows 7. Enfin, nous formalisons les modes de répartition des
observateurs, qui se traduit par des méthodes d’association, de localisation et de redondance.
Nous nous sommes ensuite intéressés à la création de politique d’accès direct. Nous avons,
pour cela, proposé un langage générique pour la protection du système définissant une grammaire
commune aux modèles obligatoires PBAC et DTE. Pour le modèle PBAC, les politiques sont portables
entre les différents systèmes Windows car notre méthode de désignation des ressources est
indépendante de la localisation des ressources. Pour le modèle DTE, les ressources étant identi-
fiées par des types ou des domaines, les politiques pourraient être utilisées à la fois sur Linux et
sur Windows.
Enfin, nous finissons ce chapitre en décrivant des méthodes de détournement de flux d’exécution
sur les systèmes Windows. Au sein d’une discussion ainsi que dans l’annexe C, nous avons
décrit quelle est leur place dans le contrôle d’accès sous Windows ainsi que leurs limites. Nous
avons expliqué la nécessité de contrôler le chargement des driver pour protéger notre observateur.
Il ressort de ce chapitre que nous avons défini de manière générique la notion d’observateur
pour les systèmes d’exploitation. Nous avons montré que cette notion pouvait s’appliquer aussi
bien aux systèmes Linux qu’aux systèmes Windows. Nous avons abstrait aussi bien leurs modes
de sécurité que leurs modes de répartition.
Dans le chapitre 4, nous allons nous intéresser à la répartition de deux observateurs dans un
environnement HPC en proposant une architecture originale. Mais nous devrons aussi proposer un
modèle nous permettant de mesurer l’impact de la répartition de ces observateurs sur un système.
Dans le chapitre 5, nous mettrons en œuvre le moniteur de référence défini dans ce chapitre
pour les systèmes Windows. Pour cela, nous montrerons comment écrire une politique de contrôle
d’accès direct et les usages que nous en avons faits pour l’analyse et le contrôle des malware.
953.4. DISCUSSION
96Chapitre 4
Répartition d’observateurs en
environnement HPC et analyse des
performances
En étudiant deux scénarios d’attaque complets sur les systèmes d’exploitation en introduction
de notre étude (voir la section 1.3), nous avons expliqué qu’il faillait pouvoir mesurer et contrôler
les interactions directes. Ce contrôle s’effectue par la définition d’un observateur capable de gérer
les interactions directes. Cependant, il est parfois difficile de prévenir une attaque en agissant uniquement
sur les interactions directes sans pour autant nuire au fonctionnement global du système.
C’est pour cette raison qu’il est nécessaire d’associer plusieurs observateurs, réalisant des calculs
supplémentaires pour protéger le système en profondeur sans nuire à son bon fonctionnement.
Dans le chapitre 3, nous avons proposé une définition générique d’observateur pour les systèmes
d’exploitation ainsi qu’un modèle de répartition. Ajouter des observateurs au sein d’un
système va nécessairement consommer des ressources supplémentaires, que ce soit du temps processeur,
de la mémoire vive, des ressources sur le disque, etc. Cependant, il n’existe pas de modèle
de mesure des performances permettant de quantifier de manière précise le surcoût engendré par
l’ajout d’observateurs au sein d’un système. Il est pourtant nécessaire de pouvoir calculer ce surcoût,
surtout en vue de l’intégration dans des environnements à haute performance.
Nous avons détaillé au cours de l’introduction, mais aussi tout au long de notre étude, qu’il
existait des associations naturelles d’observateurs sur les systèmes : SELinux et PIGA, SELinux
et iptables, un antivirus et un pare-feu sous Windows, etc. Néanmoins, il n’existe pas de modèle
permettant de formaliser ces répartitions, c’est pour cela que nous en avons proposé un dans la
section 3.1.3. Au cours de cette modélisation, nous avons défini des modes de répartition autorisant
le déport de l’observateur.
Dans une première section de ce chapitre, nous allons détailler la méthode que nous avons
développée pour mesurer l’impact sur les performances du système d’exploitation de l’association
de plusieurs observateurs. Nous traiterons plus spécialement les modes colocalisés et distants
avec une association en cascade des observateurs. Puis, dans une autre section, nous détaillerons
deux répartitions d’observateurs, SELinux avec PIGA, dans un environnement HPC. La première
répartition est colocalisée et la seconde est distante. Nous expliquerons comment nous avons pu
déporter PIGA en utilisant les technologies spécifiques des environnements HPC. Enfin nous appliquerons
notre méthode de mesure des performances pour calculer l’impact de la répartition des
observateurs sur le système. Nous comparerons la répartition colocalisée et notre architecture distante
à haute performance. Nous montrerons l’amélioration de la protection grâce aux moniteurs
SELinux et PIGA.
974.1. MÉTHODE DE MESURE DES PERFORMANCES D’UN SYSTÈME RÉPARTI
D’OBSERVATEURS
4.1 Méthode de mesure des performances d’un système réparti d’observateurs
4.1.1 Mesures globales
L’objectif est l’impact des observateurs répartis sur les performances d’un nœud client. Nous
avons choisi de comparer deux observateurs colocalisés et deux observateurs en mode distant.
En effet, le mode colocalisé et le mode distant opèrent sur le même principe sauf que le mode
distant nécessite des communications réseaux. On pourra ainsi déduire le gain réalisé grâce au
mode distant et il est légitime de penser que cela améliorera les performances du nœud client.
Afin d’évaluer l’impact sur les performances du système d’exploitation de ces deux associations,
il convient d’avoir un temps de référence (noté tempsreference). Ce temps de référence
correspond au temps pris par un appel système, donc à la différence entre son appel tr0 et son
retour tr1, sans observateur. Cette méthode de mesure peut être étendue à un jeu de tests, où le
premier temps correspond au début du jeu et le second temps à sa fin. Ce temps fait référence au
temps sans aucun observateur comme l’illustre la figure 4.1.
FIGURE 4.1 – Prise du temps de référence
984.1. MÉTHODE DE MESURE DES PERFORMANCES D’UN SYSTÈME RÉPARTI
D’OBSERVATEURS
4.1.1.1 Mode colocalisé
Le second temps concerne la latence générée par le premier observateur, noté
temps1_coloc_rr = tl1 − tl0 où tl1 et tl0 correspondent respectivement au temps de fin et de
début de l’appel système (ou du jeu de test), colocalisé en mode requête/réponse, illustré par la
figure 4.2.
FIGURE 4.2 – Prise du temps avec ajout du premier observateur
Cette mesure, que l’on nomme temps1_coloc_rr comprend :
— le détournement par l’observateur du flux d’exécution ;
— la prise de décision de la part du premier observateur ;
— le retour de l’observateur.
Ces trois éléments mesurés sont illustrés par le diagramme de séquence 4.3.
FIGURE 4.3 – Diagramme de séquence illustrant les temps mesurés lors l’ajout d’un seul observateur
Le troisième temps est la mesure du temps global, noté temps2_glob_coloc_rr = tgl1 − tgl0,
avec deux observateurs colocalisés et associés en mode cascade. Cette prise de temps est illustrée
par la figure 4.4. Dans ce cas, le second observateur est aussi en mode requête/réponse.
994.1. MÉTHODE DE MESURE DES PERFORMANCES D’UN SYSTÈME RÉPARTI
D’OBSERVATEURS
FIGURE 4.4 – Prise du temps global avec deux observateurs en mode colocalisé
Cette mesure, que l’on nomme temps2_glob_coloc_rr comprend :
— le détournement par un observateur du flux d’exécution ;
— la prise de décision de la part du premier observateur ;
— la communication entre les observateurs ;
— le temps de prise de décision du second observateur ;
— la communication retour entre les deux observateurs ;
— le retour du premier observateur.
Ces éléments mesurés sont illustrés par le diagramme de séquence 4.5.
FIGURE 4.5 – Diagramme de séquence illustrant les temps mesurés lors l’ajout de deux observateurs
en mode colocalisé
4.1.1.2 Mode distant
Pour la mise en place du second observateur en mode distant, nous introduisons deux nouveaux
composants : un client et un serveur.
1004.1. MÉTHODE DE MESURE DES PERFORMANCES D’UN SYSTÈME RÉPARTI
D’OBSERVATEURS
Cette quatrième mesure concerne le temps global avec : un observateur local en mode requê-
te/réponse associé en mode cascade avec un observateur distant en mode requête/réponse. Ce
temps, noté temps2_glob_dist_rr = td1 − td0 où td0 et td1 correspondent respectivement au début
et fin de l’appel système, est illustré par la figure 4.6.
FIGURE 4.6 – Prise du temps global avec un observateur en mode distant
Cette mesure, que l’on nomme temps2_glob_dist_rr comprend :
— le détournement par un observateur du flux d’exécution ;
— la prise de décision de la part du premier observateur ;
— la communication entre le client et le serveur ;
— le temps de prise de décision du second observateur ;
— la communication entre le serveur et le client ;
— le retour du premier observateur.
Ces éléments mesurés sont illustrés par le diagramme de séquence 4.7.
FIGURE 4.7 – Diagramme de séquence illustrant le temps global distant lors du déport du second
observateur
1014.1. MÉTHODE DE MESURE DES PERFORMANCES D’UN SYSTÈME RÉPARTI
D’OBSERVATEURS
4.1.2 Comparaison des performances
4.1.2.1 Combinatoire
En reprenant les modes de répartition que nous avons définis dans le chapitre 3, chaque observateur
peut avoir : 3 modes de sécurité, 2 modes d’association et 4 modes de localisation possibles.
L’ensemble des configurations possibles est 3x2x4=24 pour un seul observateur. Il semble diffi-
cile d’évaluer et comparer toutes ces configurations possibles. Nous avons donc restreint l’étude à
certaines configurations pour limiter la combinatoire.
Ainsi, nous considérons les modes requête/réponse (protection) et évidence (détection) pour
deux observateurs en cascade de façon colocalisée et distante.
Le nombre de configurations pour un seul observateur, placé sur la même machine que le
client, se résume à 1 localisation, 1 association et 2 modes de sécurité, donc 1x1x2=2. Nous avons
donc 2 configurations à évaluer. Pour ce premier observateur, il n’y pas de configuration distante
car c’est la solution que nous rencontrons en pratique avec SELinux où le moniteur est en mode
colocalisé.
L’ajout d’un second observateur ajoute un certain nombre de configurations. Pour le second
observateur, nous avons : 2 localisations, 2 modes de sécurité et 1 association, donc 2x2x1=4. Ce
second observateur crée 4 configurations supplémentaires. Nous avons donc 2x4=8 configurations
à évaluer, les 2 du premier multipliées par les 4 du second.
Pour résumer, nous devons donc réaliser 8 mesures pour les 8 configurations possibles et les
comparer entre elles et avec le temps de référence. A priori, l’instrumentation a peu d’impact et
surtout est uniforme avec le temps de référence. En pratique, la réalisation de moyennes sur les
temps mesurés lisse la variabilité et le caractère non reproductible des jeux d’essais.
4.1.2.2 Un seul observateur
Le tableau 4.1 établit les mesures à effectuer suivant les modes voulus du premier observateur.
Mode de sécurité de l’observateur
Localisation d’un seul observateur Requête/Réponse Evidence
Colocalisé temps1_coloc_rr temps1_coloc_evi
TABLE 4.1 – Tableau des mesures à réaliser pour les différents modes d’un seul observateur
Nous retrouvons dans ce tableau les 2 mesures pour un seul observateur placé en mode colocalisé
avec le client.
4.1.2.3 Deux observateurs
Le tableau 4.2 établit les mesures à effectuer suivant les modes voulus du second observateur.
Chaque mesure doit donc être réalisée suivant les deux modes possibles du premier observateur
soit au total deux tableaux 4.2 pour les deux modes de sécurité du premier observateur. Nous ne
précisons ici que les temps pour le second observateur.
Mode de sécurité du second observateur
Localisation de second observateur Requête/Réponse Evidence
Colocalisé temps2_glob_coloc_rr temps2_glob_coloc_evi
Distant temps2_glob_dist_rr temps2_glob_dist_evi
TABLE 4.2 – Tableau des mesures à réaliser pour les différents modes du second observateur
1024.1. MÉTHODE DE MESURE DES PERFORMANCES D’UN SYSTÈME RÉPARTI
D’OBSERVATEURS
4.1.3 Mesures détaillées
En plus des mesures globales que nous venons de présenter, nous allons spécifier des mesures
plus détaillées. Nous n’avons réalisé ces mesures que pour le second observateur en mode requê-
te/réponse étant donné que c’est celui-ci qui introduit le plus d’attente pour l’appel système.
La cinquième mesure concerne, puisque nous sommes dans le mode distant, le temps de communication
ainsi que le temps de décision du second observateur en mode requête/réponse comme
illustrée par la figure 4.8. De nouvelles mesures au niveau du client permettent d’évaluer le temps
tempscomm_observateur2_rr = tgo1 − tgo2, où tgo0 et tgo1 correspondant aux temps d’émission et
de réception au niveau du client.
FIGURE 4.8 – Prise du temps avec une communication et un observateur en mode distant
Cette mesure, que l’on nomme tempscomm_observateur2_rr comprend :
— la communication entre les observateurs ;
— le temps de prise de décision du second observateur ;
— la communication de retour.
Cette mesure est illustrée par le diagramme de séquence suivant 4.9.
1034.1. MÉTHODE DE MESURE DES PERFORMANCES D’UN SYSTÈME RÉPARTI
D’OBSERVATEURS
FIGURE 4.9 – Diagramme de séquence illustrant les temps mesurés lors d’une communication
complète avec le second observateur en mode distant
Enfin, la sixième mesure concerne le temps de décision du second observateur en mode requête/réponse,
illustrée par la figure 4.10. Cette mesure se fait au niveau du serveur, on la note
tempsobservateur2_rr = tod1 − tod0, où tod1 et tod0 sont les réponses et les requêtes envoyées
depuis le serveur.
FIGURE 4.10 – Prise du temps pour l’observateur 2 en mode distant
Cette mesure, que l’on nomme tempsobservateur2_rr comprend :
— Le temps de prise de décision du second observateur.
Cette mesure est illustrée par le diagramme de séquence suivant 4.11.
1044.1. MÉTHODE DE MESURE DES PERFORMANCES D’UN SYSTÈME RÉPARTI
D’OBSERVATEURS
FIGURE 4.11 – Diagramme de séquence illustrant les temps mesurés lors de la prise de décision
du second observateur en mode distant
4.1.3.1 Résultats déduits
Nous venons de détailler des mesures globales et des mesures détaillées. Mais certains temps
ne sont pas mesurables, comme le temps de communication entre le client et le serveur. Cependant,
il est calculable.
Ainsi, nous proposons un ensemble de calcul de performance issu des mesures effectuées :
— Le temps de communication : nous n’avons pas défini de mesure pour déterminer le temps
pris par la communication entre les deux observateurs. Il est effet difficile de mesurer de
manière précise une communication réseau entre deux machines car il faut synchroniser
parfaitement les horloges des deux systèmes. Cependant, ce temps est obtenu en soustrayant
deux mesures.
2 ∗ tempscommunication = tempscomm_observateur2_rr − tempsobservateur2_rr (4.1)
— Le temps global : même si nous réalisons une mesure du temps global, nous pouvons la
vérifier en additionnant des points de mesure.
temps2_glob_dist_rr =temps1_coloc_rr + tempscommunication ∗ 2 + tempsobservateur2_rr
(4.2)
— Nous pouvons en déduire la latence introduite par l’ajout des deux observateurs en mode
colocalisé, qui s’obtient de manière naturelle en comparant le temps de référence au temps
global, qu’il soit mesuré ou calculé.
tempslatence_colocalise_rr = |temps2_glob_coloc_rr − tempsreference|
— Nous pouvons en déduire la latence introduite par l’ajout des deux observateurs en mode
distant, qui s’obtient de manière naturelle en comparant le temps de référence au temps
global, qu’il soit mesuré ou calculé.
tempslatence_distant_rr = |temps2_glob_dist_rr − tempsreference|
— Nous pouvons ensuite comparer les deux modèles de localisation : colocalisé et distant.
Nous pouvons ainsi en déduire l’impact d’une architecture vis-à-vis de l’autre.
impactrr =
temps2_glob_coloc_rr
temps2_glob_dist_rr
1054.1. MÉTHODE DE MESURE DES PERFORMANCES D’UN SYSTÈME RÉPARTI
D’OBSERVATEURS
— Taux d’augmentation Comme nous comparons chaque valeur mesurée par rapport à un
temps de référence, nous pouvons exprimer le taux d’augmentation introduit au niveau de
chaque appel système. Par exemple, le taux d’augmentation pour l’observateur 2 en mode
colocalisé est :
taux_augmentation =
temps2_glob_coloc_rr − tempsreference
tempsreference
1064.2. SOLUTION POUR RÉPARTIR LES OBSERVATEURS DANS UN ENVIRONNEMENT
HPC
4.2 Solution pour répartir les observateurs dans un environnement
HPC
Dans cette section, nous allons nous intéresser au développement d’une solution pour répartir
les observateurs dans un environnement HPC.
Nous allons donc détailler la mise en place d’une architecture avec deux observateurs pour
les systèmes Linux. Le premier observateur est SELinux tandis que le second est PIGA. Cette
répartition se fera suivant deux modes de localisation : le mode colocalisé et le mode distant.
Dans l’objectif de limiter l’impact sur les performances du nœud client, nous utilisons un réseau
InfiniBand pour faire communiquer les deux observateurs entre eux dans le mode distant.
Cette architecture a fait l’objet de deux publications : [Blanc et al., 2013a] et
[Blanc et al., 2013b].
Nous nous sommes intéressés dans la publication [Blanc et al., 2011] à la protection des nœuds
de connexion, en composant en mode colocalisé SELinux et PIGA.
4.2.1 Architecture avec deux observateurs en mode distant
Notre modèle de protection se base sur l’ajout de deux observateurs. Nous avons ici choisi
d’utiliser SELinux et PIGA, qui réalisent des calculs complémentaires. En effet, SELinux gère les
interactions directes alors que PIGA est capable de contrôler les scénarios complets. La figure 4.12
illustre l’architecture globale que nous avons mise en place. Le canal de communication que nous
avons choisi est un lien InfiniBand. Nous appelons serveur de sécurité le nœud qui héberge PIGA.
FIGURE 4.12 – Architecture décentralisée
Dans cette architecture, SELinux est chargé de détourner les flux d’exécution du système pour
les traiter et les envoyer à PIGA. Il réalise ce détournement grâce à l’utilisation des LSM. Les deux
observateurs sont mis en mode de sécurité cascade, ce qui permet d’attendre la réponse de PIGA
lorsque celui-ci est en mode protection ou de simplement transférer les requêtes sans attendre de
réponse lorsque PIGA est en mode évidence (détection).
1074.2. SOLUTION POUR RÉPARTIR LES OBSERVATEURS DANS UN ENVIRONNEMENT
HPC
4.2.2 Choix des observateurs
4.2.2.1 SELinux
Dans le but de nous rapprocher au maximum des conditions réelles, c’est-à-dire celles mises
en place par le CEA, nous avons utilisé un système d’exploitation proche de celui mis en place
sur les différents nœuds. Sur les calculateurs tels que Curie, c’est le système d’exploitation Bull
Advanced Server qui est déployé. Cette distribution est un clone du système Red Hat Enterprise
Linux. Dans ce système d’exploitation, SELinux est intégré et activé par défaut.
SELinux étant nativement intégré au noyau Linux, il n’est pas nécessaire de modifier le code
du noyau pour le faire fonctionner. De plus, les politiques SELinux fournies avec cette distribution
sont fonctionnelles.
Mais surtout, notre choix a été motivé par les premières expérimentations que nous avons faites
sur l’impact de SELinux sur les performances du système d’exploitation. Comme nous le verrons
dans la partie résultat de ce chapitre 4.3.2, l’impact de SELinux est minime sur les performances
du système. Il peut donc être intégré, même sur les nœuds de calcul. Cela est rendu possible par
les différentes optimisations présentes dans SELinux. Nous pouvons par exemple citer le Access
Vector Cache qui va conserver les derniers vecteurs d’accès calculés par SELinux. Ainsi, si une
décision est déjà présente dans ce cache, il n’est pas nécessaire de parcourir de nouveau la politique
pour rechercher ce vecteur d’accès. Une seconde optimisation de SELinux est la non revérification
des droits acquis lors des opérations de lecture ou d’écriture en l’absence de modification des
contextes sujets et objets.
La figure 4.13 illustre le mécanisme de prise de décision de SELinux :
1. un processus réalise une opération élémentaire (un appel système) (flèche 1) ;
2. SELinux la détourne grâce aux LSM (flèche 2) : ces deux premières étapes correspondent
à une requête ;
3. il prend une décision au regard de sa politique de contrôle d’accès (flèche 3) ;
4. si l’interaction est interdite, une trace est inscrite dans le fichier d’audit (flèche 4) : cette
étape est une réponse de l’observateur ;
5. un code d’erreur est retourné à l’application ayant fait la requête (flèche 5) ;
6. si l’interaction est autorisée, alors SELinux transmet la requête au noyau pour qu’elle soit
exécutée (flèche 6) ;
7. le noyau envoie le retour de l’appel système à l’application (flèche 7) : cette étape est une
réponse, ici de l’appel système, qui dans ce cas, n’est pas traitée par SELinux.
Chaque décision de SELinux est associée à un access vector. Un vecteur d’accès se compose
des contextes sujet et objet, de la classe de l’objet, des opérations élémentaires et enfin de la
décision d’accès donnée par SELinux.
4.2.2.2 PIGA
Le choix de PIGA a été motivé par le fait qu’il est capable de gérer les scénarios complets en
reconstruisant l’activité du système, tout en se basant sur les politiques de SELinux.
PIGA est le second mécanisme de protection utilisé dans notre architecture. Il est constitué de
deux parties : PIGA-Kernel, qui détourne les interactions autorisées par SELinux et PIGA-UM,
qui est le moteur de décision. Il faut noter que PIGA n’a pas été implanté pour avoir un mode de
fonctionnement distant, il nous faut donc résoudre ce problème.
1084.2. SOLUTION POUR RÉPARTIR LES OBSERVATEURS DANS UN ENVIRONNEMENT
HPC
FIGURE 4.13 – Architecture de prise de décision de SELinux
PIGA-Kernel Comme nous l’avons déjà dit, PIGA est basé sur la reconstruction des activités du
système. Pour cette reconstruction, PIGA se base sur les vecteurs d’accès générés SELinux. Pour
récupérer ces vecteurs, PIGA-Kernel insère un hook directement dans le code de SELinux pour
détourner le flux d’exécution.
Une fois le flux d’exécution de SELinux détourné, PIGA-Kernel construit sa propre trace avant
de l’envoyer à PIGA-UM et il attend une réponse lorsqu’il est placé en mode protection, sinon il
rend la main à SELinux. Une fois que la réponse a été calculée, il poursuit l’exécution. Si PIGAUM
n’autorise pas l’interaction, PIGA-Kernel modifie le vecteur d’accès de SELinux afin que
l’interaction soit refusée, sinon la décision d’accès prise par SELinux est appliquée.
PIGA-UM PIGA-UM récupère la trace envoyée par PIGA-Kernel pour reconstruire les activités
et vérifie que cette interaction ne fait pas partie d’un ensemble d’activités illégitimes.
Une fois que la décision est prise, PIGA-UM la renvoie à PIGA-Kernel. L’insertion des composants
PIGA-Kernel et PIGA-UM dans le système, en mode colocalisé, est détaillée dans la
figure 4.14.
1. un processus réalise une opération élémentaire (un appel système) qui est détournée par
SELinux(flèche 1) : cela correspond à la requête ;
2. SELinux prend une décision au regard de sa politique de contrôle d’accès (flèche 2) ;
3. si l’interaction est autorisée, PIGA-Kernel détourne le flux d’exécution (flèche 3), si l’interaction
est refusée par SELinux, le refus est envoyé au processus appelant (flèche 10),
cette étape constitue alors une réponse ;
4. PIGA-Kernel envoie la trace à PIGA-UM (flèche 4). En mode détection, il n’attend pas le
retour de PIGA-UM et il redonne la main à SELinux (flèche 6) ;
1094.2. SOLUTION POUR RÉPARTIR LES OBSERVATEURS DANS UN ENVIRONNEMENT
HPC
5. PIGA-UM vérifie que cette interaction ne termine pas un scénario complet (flèche 5) ;
6. PIGA-UM envoie une réponse à PIGA-Kernel (flèche 6) ;
7. PIGA-Kernel transmet la réponse à SELinux (flèche 7) ;
8. si l’interaction est refusée, SELinux envoie le refus au processus appelant (flèche 10) : cette
étape constitue une réponse ;
9. si l’interaction est autorisée, alors l’appel système est exécuté (flèche 8) ;
10. se noyau envoie le retour de l’appel système à l’application (flèche 9) : cette étape est une
réponse, ici de l’appel système, qui dans ce cas, n’est pas traitée par SELinux.
FIGURE 4.14 – Insertion de PIGA dans l’architecture en mode colocalisé
Il est à noter que PIGA-Kernel autorise l’interaction sans attendre de réponse de la part de
PIGA-UM lorsque celui-ci est en mode évidence (ou détection). Dans ce mode, on voit que PIGA
est moins pénalisant, au niveau de l’impact sur les performances, pour les processus appelant.
4.2.2.3 Infiniband
Pour assurer les communications entre le nœud client et le serveur de sécurité, nous avons fait
le choix d’utiliser les réseaux Infiniband. Ce sont des réseaux à très haute performance utilisés
dans les environnements HPC qui offrent un important débit et ont une faible latence.
La principale particularité de l’architecture Infiniband est qu’elle peut s’appuyer sur différents
protocoles pour être intégrée dans des environnements hétérogènes. Il existe plusieurs types de
protocoles : Remote Direct Memory Access, IP over IB, ISCSI, etc. Nous avons fait le choix du
protocole RDMA car c’est le protocole qui est le plus efficace lors de l’utilisation d’InfiniBand. Le
principal avantage du protocole RDMA est qu’il passe directement par le matériel. Le protocole
RDMA peut être utilisé suivant deux méthodes : soit la carte du nœud écrit dans la mémoire
distante, soit c’est la carte distante qui vient lire dans la mémoire de la première. Nous avons fait
le choix d’écrire dans la mémoire distante.
La figure 4.15 illustre le fonctionnement d’une communication Infiniband sur RDMA. Un
processus veut écrire dans la mémoire d’un processus placé sur une autre machine. Le noyau alloue
au driver de la carte Infiniband un espace mémoire (ou plusieurs). Cet espace mémoire sera le
tampon d’échange (lecture ou écriture) pour les deux processus impliqués dans la communication.
1104.2. SOLUTION POUR RÉPARTIR LES OBSERVATEURS DANS UN ENVIRONNEMENT
HPC
Le processus va écrire dans la mémoire allouée (flèche 1) puis valider l’écriture auprès de la
carte de la machine courante. Cette dernière va alors récupérer les informations de la mémoire
(flèche 3) pour les écrire directement dans la mémoire du processus distant en utilisant le lien Infi-
niBand (flèche 4). Une fois que la carte a fini son opération d’écriture (flèche 5), l’écrivain notifie
le lecteur que l’information est disponible (flèche 6) au travers d’une communication InfiniBand.
Le lecteur peut accéder au contenu de la mémoire pour récupérer l’information (flèche 7).
FIGURE 4.15 – Schéma d’une communication RDMA sur un lien InfiniBand
Au cours de cette opération, le noyau n’a jamais été impliqué dans la communication. Ainsi,
nous évitons un changement de contexte pour le processus, la création d’un paquet TCP, le parcours
des différentes couches du modèle de réseau OSI, etc.
4.2.3 Déport du mécanisme de prise de décision
Nous venons de détailler le fonctionnement en local de SELinux, de PIGA et le fonctionnement
du protocole RDMA sur des réseaux InfiniBand. Nous allons maintenant, à partir de tous les
éléments proposés, définir une architecture permettant de déporter le mécanisme de protection
PIGA.
Nous proposons un programme que l’on nomme proxy, chargé des échanges entre PIGA-UM
et PIGA-Kernel.
Le proxy
Le proxy est un programme que l’on va retrouver à la fois sur le nœud client, mais aussi sur
le serveur de sécurité. Sur le nœud client, il est chargé de récupérer les vecteurs d’accès générés
par SELinux et transmis par PIGA-Kernel pour les envoyer sur le lien InfiniBand. Il attend ensuite
la réponse provenant du proxy serveur de sécurité pour la transmettre à SELinux. Le proxy serveur
récupère les vecteurs d’accès envoyés par le client, les transmet à PIGA-UM, puis renvoie la
décision d’accès de PIGA-UM sur le lien InfiniBand.
4.2.3.1 Le nœud client
Nous allons présenter l’architecture simplifiée mise en place sur un nœud client, illustrée par
la figure 4.16.
1114.2. SOLUTION POUR RÉPARTIR LES OBSERVATEURS DANS UN ENVIRONNEMENT
HPC
FIGURE 4.16 – Architecture de protection sur un nœud client
Comme nous l’avons décrit auparavant, SELinux détourne le flux d’exécution régulier pour
prendre une décision (flèche 1). Si l’interaction est autorisée par SELinux, PIGA-Kernel intercepte
à son tour le flux (flèche 2) pour le transmettre au proxy client (flèche 3), qui va l’envoyer au
serveur (flèche 5) par le lien InfiniBand.
Le proxy client attend la réponse du proxy serveur et la récupère toujours sur le lien InfiniBand
(flèche 5). Il transmet la réponse à PIGA-Kernel (flèche 6) qui la renvoie à SELinux (flèche 7). Si
l’accès est autorisé, le vecteur d’accès n’est pas modifié. Dans le cas contraire, une modification du
vecteur d’accès a lieu pour interdire l’interaction. Cette décision est enfin transmise au processus
(flèche 8). Si la décision est interdite, elle sera enregistrée dans un fichier d’audit.
La figure 4.17 représente l’architecture complète mise en place sur le nœud de calcul et le
chemin du contrôle d’une interaction directe.
1. un processus réalise une interaction directe (un appel système) qui est détournée par la
couche LSM ;
2. la couche LSM transmette cette requête à SELinux : c’est la requête ;
3. SELinux prend une décision au regard de sa politique de sécurité ;
4. si SELinux autorise l’opération, alors le vecteur d’accès est détourné par PIGA-Kernel ;
5. PIGA-Kernel transmet la trace au proxy ;
6. le proxy envoie cette trace sur le lien Infiniband ;
7. le proxy récupère la réponse du serveur de sécurité ;
8. il la transmet à PIGA-Kernel ;
9. PIGA-Kernel la renvoie à SELinux ;
10. si l’interaction est interdite (soit par SELinux, soit par PIGA), alors la trace est enregistrée
dans le fichier d’audit ;
11. si l’interaction est refusée, un retour spécifique est envoyé au processus : c’est une réponse ;
12. sinon, la requête est transmise au noyau, qui l’exécute ;
13. le noyau envoie le retour au processus, non traité par SELinux, c’est une réponse.
1124.2. SOLUTION POUR RÉPARTIR LES OBSERVATEURS DANS UN ENVIRONNEMENT
HPC
FIGURE 4.17 – Architecture détaillée du contrôle d’accès sur un nœud client
4.2.3.2 Le proxy serveur
Sur le serveur distant, nous n’avons que deux éléments : le proxy serveur et le moniteur de
référence PIGA-UM. La figure 4.18 illustre l’architecture du contrôle mise en place sur le serveur
de sécurité.
FIGURE 4.18 – Architecture sur le serveur de sécurité
1. Le proxy récupère la trace sur le lien InfiniBand ;
2. Il la transmet à PIGA-UM ;
3. PIGA-UM prend une décision au regard de sa politique de sécurité ;
4. Il envoie sa décision au proxy ;
5. Le proxy la transmet au nœud de calcul en utilisant le lien InfiniBand.
1134.3. EXPÉRIMENTATIONS
4.3 Expérimentations
Nous venons de détailler la mise en place d’une architecture décentralisée basée sur l’utilisation
de deux observateurs : SELinux et PIGA. Pour faire communiquer ces deux observateurs,
nous avons implanté un proxy qui gère les différentes communications entre les observateurs.
Nous allons maintenant nous attacher à comparer l’impact sur les performances d’une architecture
en mode colocalisé avec une architecture où un des observateurs est déporté. Nous allons
pour cela, nous appuyer sur le modèle d’analyse que nous avons défini dans la section 4.1.1.
Pour réaliser des mesures de temps précises et surtout reproductibles, nous avons utilisé deux
logiciels : le premier se nomme linpack et le second est un programme permettant de stresser
les observateurs en faisant beaucoup d’entrées/sorties.
4.3.1 Les moyens de mesure
Pour tester l’impact sur les performances de la répartition de deux observateurs, nous avons
défini deux types de tests : un test de référence appliqué dans le HPC, et un logiciel spécifique
stressant les deux moniteurs de référence SELinux et PIGA.
Le premier test que nous avons réalisé se base sur le logiciel de benchmark linpack 1
. Ce logiciel
est utilisé pour classer les calculateurs dans le monde entier (voir le site Internet top500 2
).
Nous avons configuré ce logiciel au moyen du fichier de configuration disponible en annexe A. La
particularité de ce logiciel est qu’il réalise très peu d’accès disque et d’appels système. C’est essentiellement
du calcul en mémoire qui est réalisé, et il va de surcroit utiliser le nombre maximum
de cœurs du processeur.
Pour le stress, nous avons créé un logiciel spécifique qui réalise le scénario suivant :
1. ouverture d’un fichier présent sur le système, correspondant à l’appel système sys_open ;
2. lecture d’un nombre constant d’octets dans un tampon mémoire, correspondant à l’appel
système sys_read ;
3. fermeture du fichier, correspondant à l’appel système sys_close ;
4. création d’un nouveau fichier avec un nom aléatoire sur le disque local, correspondant à
l’appel système sys_open ;
5. écriture du tampon dans le fichier, correspondant à l’appel système sys_write ;
6. fermeture du fichier, correspondant à l’appel système sys_close ;
Le code utilisé est mis en annexe B. Nous avons réalisé ce test pendant une durée d’une heure et
les prises de temps sont réalisées en début et fin de séquence pour avoir une vision macroscopique
des latences qui sont dues au modèle de protection.
Ce test nous permet d’estimer l’impact du modèle de protection sur le système dans, ce que
l’on peut considérer comme le pire des cas pour les mécanismes de protection. En effet, le scénario
effectue beaucoup d’appels système puisqu’il ne fait que des entrées/sorties. Toutefois, réaliser des
tests sur un système de fichiers peut soulever quelques problèmes. En effet, il ne faut pas que les
mesures soient influencées par le cache du système de fichiers, ou par la vitesse d’écriture du
disque dur. C’est pourquoi, nous avons réalisé la prise de temps en début et en fin de scénario,
plutôt qu’entre chaque appel système car cela permet de linéariser les effets des différents caches
présents sur le système. Ce test est réalisé de manière séquentielle, c’est-à-dire qu’un seul cœur du
processeur est utilisé durant l’expérimentation.
1. http://www.netlib.org/benchmark/hpl/
2. http://top500.org
1144.3. EXPÉRIMENTATIONS
4.3.2 Résultats sur les performances
Nous présentons ici les résultats pour les 8 temps globaux que nous avons présentés dans la
section 4.1.1. Comme nous l’avons dit, nous allons comparer ces mesures avec une mesure de
référence prise sans aucun observateur.
Nous présentons ici les résultats que nous avons obtenus pour comparer les modèles de répartition
sur les performances des systèmes. Nous allons découper ces résultats en partant d’une vision
globale puis isoler chaque élément de la prise de décision grâce au modèle vu en section 4.1.1.
4.3.2.1 Architecture d’expérimentation
Les expérimentations que nous présentons ici ont toutes été réalisées sur des machines physiques
pour être les plus précises possibles. En effet, la virtualisation ajoute une couche de complexité
et entraîne des effets de bords qu’il est difficile d’annuler.
Les nœuds clients Nous disposions de deux machines parfaitement identiques pour réaliser des
calculs. Nous avons ainsi pu réaliser des tests en mode colocalisé et en utilisant notre architecture
décentralisée.
Les nœuds de calcul disposent de deux processeurs Intel(R) Xeon(R) X5450 cadencés à 3,00
GHz. Ils disposent chacun de 8 Go de mémoire vive. Les tests sont réalisés sur un système de
fichiers en ext4, avec un matériel en RAID-10, sur des disques en SAS à 15 000 tours par minutes.
Nous avons choisi comme distribution Scientific Linux 6, qui un clone de RHEL 6.
Les paquets formant le système de base sont les mêmes entre les deux distributions. Comme nous
avons eu besoin de modifier le noyau, nous avons modifié un RPM source de Red Hat nommé
2.6.32-279.5.2.el6.
SELinux a été modifié pour ne charger que 37 modules. Nous avons supprimé du chargement
de la politique les modules inutiles sur un nœud de calcul tels que le module mozilla, ou encore
openoffice. La politique SELinux ne contient plus que 79196 règles d’autorisation alors que
la politique de référence en contenait 240669.
De plus, nous avons défini des politiques SELinux spécifiques pour que linpack et notre
logiciel stressant le système de fichiers soient autorisés.
Le serveur de sécurité Le serveur de sécurité est une machine dédiée qui dispose de deux processeurs
Intel(R) Xeon(R) E5405 cadencés à 2,00 GHz. Ce nœud dispose lui aussi de 8 Go de
mémoire vive. Le système installé est aussi du Scientific Linux 6.
Sur cette machine, nous avons déployé PIGA-UM, qui s’exécute en espace utilisateur, avec
l’ensemble de propriété de sécurité du listing 4.1. Ces propriétés de sécurité sont générales et assurent
la confidentialité des utilisateurs vis-à-vis des personnes présentes dans le rôle staff_r
ainsi que des personnes présentes dans le rôle sysadm_r, l’intégrité des fichiers de configuration
et des domaines linpack et staff_t. En traitant à la fois de la confidentialité et de l’inté-
grité, nous configurons PIGA dans le pire des cas car cela génère un grand nombre d’activités à
surveiller.
Le canal de communication Les deux machines sont connectées en Ethernet et en InfiniBand.
Le nœud de calcul et le serveur de sécurité disposent de la même technologie de carte Mellanox
Technologies MT26428 offrant un débit théorique maximum de 40 Gb par secondes.
1154.3. EXPÉRIMENTATIONS
✞ ☎
1 confidentiality( $sc1:="user_u:user_r:user.*_t", $sc2:=system_u:object_r:etc_t
);
2
3 confidentiality( $sc1:=system_u:object_r:nfs_t, $sc2:=user_u:user_r:user_t );
4 confidentiality( $sc2:=system_u:object_r:nfs_t, $sc1:=user_u:user_r:user_t );
5
6 confidentiality( $sc1:=system_u:object_r:nfs_t, $sc2:=staff_u:staff_r:staff_t )
;
7 confidentiality( $sc2:=system_u:object_r:nfs_t, $sc1:=staff_u:staff_r:staff_t )
;
8
9 confidentiality( $sc1:="user_u:user_r:user.*_t", $sc2:="staff_u:staff_r:staff.*
_t" );
10 confidentiality( $sc2:="user_u:user_r:user.*_t", $sc1:="staff_u:staff_r:staff.*
_t" );
11
12 confidentiality( $sc1:="user_u:user_r:user.*_t", $sc2:="sysadm_u:sysadm_r:
sysadm.*_t" );
13 confidentiality( $sc2:="user_u:user_r:user.*_t", $sc1:="sysadm_u:sysadm_r:
sysadm.*_t" );
14
15 integrity( $sc1:="user_u:user_r:user.*_t", $sc2:=".*:.*:.*etc_t" );
16 integrity( $sc1:="staff_u:staff_r:staff.*_t", $sc2:=".*:.*:.*etc_t" );
17
18 domainintegrity( $CHROOT:="staff_u:staff_r:linpack.*" );
19 domainintegrity( $CHROOT:="staff_u:staff_r:staff.*" );
✝ ✆
Listing 4.1 – Propriétés de sécurité appliquées pour les tests de performances
4.3.2.2 Mesures globales
L’objectif est tout d’abord de déterminer la latence globale au niveau de l’application due à
notre modèle de protection.
Linpack Ce test a été fait pendant une durée de 23 heures. Linpack réalise plusieurs types
d’opérations, c’est-à-dire des calculs matriciels, et propose le temps mis pour réaliser le calcul
comme le montre l’extrait 4.2. Il réalise 18 opérations différentes. Nous faisons une moyenne du
temps mis et de la puissance calculée pour les différents tests que nous avons réalisés.
✞ ☎
1 T/V N NB P Q Time Gflops
2 WR00L2L2 26752 128 2 4 8117.16 1.573e+00
✝ ✆
Listing 4.2 – Extrait d’un fichier de résultat de linpack
Le tableau 4.3 propose les résultats d’un ensemble de tests effectués pour connaître l’impact
sur les performances du système d’exploitation des différentes répartitions d’observateurs.
Comme les premiers résultats obtenus avec SELinux (en mode requête/réponse mais aussi en
mode évidence) sont concluants, nous avons réalisé les expérimentations suivantes avec SELinux
uniquement en mode requête/réponse. Nous comparons donc 6 temps globaux avec le temps de
référence. De plus, dans le but de minimiser les traitements réalisés par PIGA, il est nécessaire de
bloquer les interactions directes lorsqu’elles ne sont pas autorisées dans la politique de contrôle
d’accès. C’est pour cela que nous avons réalisé les tests en ajoutant PIGA uniquement avec SELinux
en mode protection.
Pour cela, nous avons tout d’abord réalisé un premier test avec aucune protection obligatoire,
que ce soit SELinux ou PIGA. C’est le test de référence. Puis nous avons ajouté un à un chaque
1164.3. EXPÉRIMENTATIONS
moniteur dans le but d’avoir des résultats précis et exploitables. Nous avons donc ajouté SELinux
à nos tests en utilisant les modes : détection et protection. Lors du test de ces deux modes, SELinux
disposaient de la même politique de sécurité. On peut noter une légère amélioration des résultats
lorsque SELinux est activé sur la machine. Cela peut s’expliquer par le fait que SELinux va bloquer
des programmes concurrents et ainsi, linpack ne sera pas préempté. Nous avons ensuite ajouté
PIGA en mode détection pour avoir une première vision de l’impact de ce mécanisme. Nous avons
réalisé ces tests avec une version en mode colocalisé puis avec une version décentralisée. L’objectif
étant de savoir si le déport d’un observateur apportait réellement un plus au niveau de l’impact sur
les performances du système d’exploitation.
Les résultats obtenus avec Linpack montrent que la version décentralisée n’impacte pas les
performances du système d’exploitation. La version en mode colocalisé de PIGA génère une faible
latence.
Temps en secondes Puissance en GFlops
tempsref erence 8 124 1.571
SELinux détection : temps1_coloc_evi 8 118 1.572
SELinux protection : temps1_coloc_rr 8 111 1.575
SELinux/PIGA colocalisé : temps2_glob_coloc_evi 8 127 1.571
SELinux/PIGA colocalisé : temps2_glob_coloc_rr 8 130 1.570
SELinux/PIGA distant : temps2_glob_dist_evi 8 121 1.572
SELinux/PIGA distant : temps2_glob_dist_rr 8 114 1.573
TABLE 4.3 – Tableau des résultats avec l’utilisation de linpack avec PIGA
Le tableau 4.3 présente aussi les résultats obtenus, toujours avec linpack, mais cette fois-ci,
PIGA est mis en mode protection. Dans cette configuration, SELinux est toujours placé en mode
enforcing.
L’utilisation de PIGA en mode distant améliore légèrement les performances vis-à-vis du mode
colocalisé.
Stress des moniteurs répartis Notre second test vise à réaliser un maximum d’appels système
afin de solliciter de manière soutenue les observateurs répartis.
Nous rappelons brièvement le protocole de test. Le programme est lancé pendant une heure et
réalise en boucle le scénario des actions : ouverture, lecture, fermeture, création, écriture, fermeture.
Nous récupérons le nombre de jeux/scénarios réalisés. Le temps indiqué est le temps moyen
de chaque scénario correspondant à un jeu de test.
Le tableau 4.4 présente les résultats que nous avons obtenus en stressant le système de fichiers.
Dans ce tableau, nous détaillons les résultats obtenus avec le moniteur PIGA mis en mode détection.
Dans chaque test, nous avons mis SELinux en mode protection puisque la première mesure,
temps1_coloc_rr présente dans ce tableau, confirme que l’impact de SELinux en mode requête/ré-
ponse est négligeable par rapport au temps de référence, mais aussi à son mode évidence.
En mode détection, avec SELinux et PIGA en mode colocalisé, nous multiplions par 6 le
temps moyen par scénario, ce qui conduit à réduire de moitié le nombre de scénarios. Avec PIGA
en distant, nous réduisons cette latence. Ainsi nous obtenons un temps moyen multiplié par 3 et
un nombre d’opérations réduit d’un tiers par rapport au mode avec le seul moniteur SELinux.
Le tableau 4.4 donne aussi les résultats obtenus avec PIGA en mode protection. Avec PIGA en
mode colocalisé, nous divisons par 5 le nombre de scénarios et nous multiplions le temps moyen
par 13. Cependant, nous améliorons avec PIGA en mode distant puisque le nombre de scénarios
réalisés est divisé par 2 et le temps moyen est multiplié par 5.
1174.3. EXPÉRIMENTATIONS
Nombre de scénarios temps par scénario en µs
tempsreference 5 176 731 689
SELinux : temps1_coloc_evi 5 176 731 691
SELinux : temps1_coloc_rr 5 176 731 692
SELinux + PIGA colocalisé temps1_glob_coloc_evi 2 481 727 3 787
SELinux + PIGA colocalisé temps1_glob_coloc_rr 1 133 107 7 954
SELinux + PIGA distant temps2_glob_dist_evi 3 889 542 1 717
SELinux + PIGA distant temps2_glob_dist_rr 2 746 805 3 186
TABLE 4.4 – Table détaillant l’impact avec stress des moniteurs répartis
À partir de ces différentes mesures, obtenues en mode détection et en mode protection, nous
pouvons estimer le temps moyen par appel système. Pour cela, nous divisons le temps moyen par
scénario par le nombre d’opérations élémentaires réalisées par notre programme, c’est-à-dire 6.
Ces résultats, illustrés par le tableau 4.5, nous permettent, tout d’abord, de calculer un temps
moyen par appel système (ou plus exactement par interaction) au niveau de notre système.
Ensuite, nous sommes capables d’estimer le surcoût induit par la répartition de deux observateurs,
que ce soit en mode cololocalisé ou en mode distant :
— colocalisé : en mode protection, le surcoût est de 1211 µs par appel système alors qu’en
mode détection il n’est que de 517 µs ;
— distant : en mode protection le surcoût est de 417 µs par appel système alors qu’en mode
détection, il n’est que de 172 µs.
temps moyen/scénario en µs temps moyen/appel système en µs
Sans SELinux : tempsref erence 689 114,3
SELinux temps1_coloc_rr 692 115,3
SELinux + PIGA colocalisé : temps2_glob_coloc_evi 3 787 631,12
SELinux + PIGA colocalisé : temps2_glob_coloc_rr 7 954 1325,6
SELinux + PIGA distant : temp2_glob_dist_evi 1 717 286,16
SELinux + PIGA distant : temp2_glob_dist_rr 3 186 531
TABLE 4.5 – Table détaillant le temps moyen par appel système
Il faut rappeler que ces surcoûts correspondent à notre avis au pire des cas et que celui-ci est
peu représentatif des environnements HPC. En effet, dans la pratique, les codes de calcul ne font
pas autant d’entrée/sortie, mais réalisent des calculs en mémoire.
4.3.2.3 Mesures détaillées
Afin de définir où sont les surcoûts des observateurs répartis, nous appliquons notre méthode
de mesure définie en section 4.1.1. Dans cette partie, nous nous sommes exclusivement intéressés
au mode distant car c’est cette architecture qui vise à être implantée dans un environnement HPC.
L’objectif est de donc d’utiliser notre solution pour analyser les performances sur cette architecture.
Nous réalisons ces tests uniquement pour le mode requête/réponse de PIGA.
Grâce à nos premiers tests, nous avons montré que ce n’était pas SELinux qui générait une
latence. Toutes les mesures vont nous permettre de quantifier les surcoûts aux différents endroits.
Estimation du coût d’une communication complète avec prise de décision du second observateur
Nous avons réalisé des mesures de temps au niveau du proxy client déployé sur le nœud
client. Cette mesure, tempscomm_observateur2_rr, consiste à connaitre le temps pris par la suite
d’instructions suivantes :
1184.3. EXPÉRIMENTATIONS
1. le proxy a déjà lu la trace générée par PIGA-Kernel donc cette interaction n’est pas prise
en compte dans la mesure ;
2. il prend le premier temps ;
3. il envoie la trace au serveur de sécurité et attend la réponse ;
4. il obtient une réponse ;
5. il prend le deuxième temps.
Le diagramme de séquence 4.19 détaille toutes les opérations qui se déroulent pendant la
mesure.
FIGURE 4.19 – Diagramme de séquence illustrant la mesure faite au niveau du proxy coté nœud
de calcul
Cette mesure a été réalisée sur une moyenne d’un million de communications entre le nœud
client et le serveur de sécurité. Nous obtenons une valeur moyenne de 260 µs pour le temps
tempscomm_observateur2_rr, une valeur maximum de 400 µs et une valeur minimum 200 µs.
Lecture d’une trace avec une prise de décision Cette première mesure montre que la latence
est générée, soit par la communication, soit par la prise de décision de la part de PIGA. Nous allons
donc mesurer le temps de prise de décision de PIGA, tempsobservateurs2_rr.
1. le proxy lit la trace en mémoire ;
2. la première mesure de temps est déclenchée ;
3. le proxy transmet la trace à PIGA.
4. PIGA prend une décision d’accès ;
5. le proxy récupère la décision ;
6. la seconde mesure de temps est réalisée.
Ainsi, en prenant le temps au niveau du proxy, nous pouvons déterminer le temps pris par
PIGA pour prendre une décision d’accès. Cette procédure est illustrée par le diagramme de sé-
quence 4.20.
On obtient un temps de prise de décision moyen pour PIGA de 220 µs, qui correspond au temps
tempsobservateurs2_rr. Tout comme pour la précédente mesure, ce temps est obtenu en faisant une
moyenne sur un échantillon d’un million d’appels à PIGA.
Afin d’être précis, nous avons fait cette mesure au niveau du proxy qui est en C plutôt qu’au
niveau de PIGA qui est en Java.
1194.3. EXPÉRIMENTATIONS
FIGURE 4.20 – Diagramme de séquence illustrant la mesure faite au niveau du proxy serveur pour
calculer le temps de prise de décision de PIGA
Coût d’une communication À partir des deux dernières mesures, nous pouvons en déduire le
coût d’une communication entre le proxy client et le proxy serveur.
En nous basant sur les moyennes obtenues, on obtient un temps 260−220
2
soit 20 µs, correspondant
au temps tempscommunication. Les messages échangés entre les deux proxys ont une taille
maximale de 300 octets.
Mesures spécifiques Nous avons dû réaliser des mesures spécifiques inhérentes à l’architecture
que nous avons choisie et plus précisément, à la mise en place du proxy sur le nœud de calcul. En
effet, de part sa conception, il doit récupérer les traces générées par PIGA-Kernel pour les envoyer
sur le lien InfiniBand et il doit ensuite renvoyer à PIGA-Kernel les décisions d’accès prises par
PIGA.
Pour ce faire, nous avons choisi d’utiliser le système de fichiers procfs. Nous avons donc
deux pipes nommés : pigaseq et piga_rep. Le premier permet au proxy de lire les traces
provenant de l’espace noyau tandis que le second lui permet d’écrire les décisions d’accès.
Nous avons donc dû mesurer le temps pris par le proxy pour lire et écrire dans ces pipes. Pour
cela, nous avons daté l’envoi des traces ainsi que sa réception.
Le temps de lecture par le proxy donne, en moyenne, 10 µs. Par contre, la mesure de l’écriture
se révèle beaucoup plus difficile à réaliser. Dans le but d’avoir une valeur correcte, nous allons
prendre la valeur moyenne que nous avons calculée dans ce tableau 4.5, à savoir 115 µs.
4.3.2.4 Synthèse des mesures
Nous allons dans cette partie synthétiser les mesures que nous avons réalisées sur la répartition
de deux observateurs au sein d’une architecture distribuée.
En nous appuyant sur le tableau 4.5, nous pouvons calculer que la latence générée en mode
protection (ou requête/réponse) par l’architecture décentralisée de 417 µs.
Ce nombre est la somme de :
1. le temps de la prise de décision de la part de PIGA tempsobservateurs2_rr : 220 µs ;
2. le temps de la communication (aller-retour) 2 ∗ tempscommunication : 40 µs ;
1204.3. EXPÉRIMENTATIONS
3. le temps de lecture et d’écriture de la part du proxy dans les pipes pour communiquer avec
PIGA-Kernel : 10 + 114 µs ;
4. le temps introduit par SELinux temps1_coloc_rr : 1 µs.
On obtient pour résultat 385 µs, soit une différence de 32 µs avec la mesure globale. Ce résultat
s’explique par le fait que nous avons à chaque fois pris des moyennes sur un échantillon donné,
donc il existe toujours une marge d’erreur non négligeable.
De plus, grâce à toutes ces différentes mesures, nous pouvons voir que les mécanismes de
mesure de temps n’influent pas ou peu sur le temps global.
Nous proposons ce diagramme de séquence 4.21 qui nous permet de résumer de manière
simple les différentes mesures que nous avons effectuées pour connaitre les points qui peuvent
être améliorés en termes de performance. Ce diagramme illustre la répartition de SELinux avec
PIGA en mode protection (temp2_glob_dist_rr).
FIGURE 4.21 – Diagramme de séquence résumant les différentes mesures effectuées au sein de
l’architecture distribuée
Nous proposons une synthèse des temps calculés dans le tableau suivant 4.6 établi par rapport
aux résultats sur les expérimentations du stress du système de fichiers.
temps par appel système en µs
tempsreference 114,3
SELinux temps1_coloc_rr 115,3
SELinux + PIGA colocalisé : temps2_glob_coloc_evi 631,12
SELinux + PIGA colocalisé : temps2_glob_coloc_rr 1325,6
SELinux + PIGA distant : temp2_glob_dist_evi 286,16
SELinux + PIGA distant : temp2_glob_dist_rr 531
Communication + PIGA distant tempscomm_observateur2_rr 260
PIGA distant tempsobservateur2_rr 220
TABLE 4.6 – Tableau résumant les mesures effectuées pour la répartition de deux observateurs
Nous proposons une synthèse des temps déduits dans le tableau suivant 4.7 établi par rapport
aux résultats sur les expérimentations du stress du système de fichiers. Ce tableau montre que le
déport du second moniteur de référence permet de réduire l’impact sur le nœud client. Ce gain se
situe entre 2,2 et 2,5 par rapport au mode colocalisé.
1214.3. EXPÉRIMENTATIONS
temps en µs
tempscommunication 20
tempslatence_coloc_evi 517
tempslatence_coloc_rr 1211
tempslatence_dist_evi 172
tempslatence_dist_rr 417
impactevi 2,2
impactrr 2,5
TABLE 4.7 – Tableau résumant les temps calculés
Cette amélioration vient, d’une part par l’utilisation des technologies spécifiques à faibles latences
des environnements HPC (InfiniBand et RDMA) et, d’autre part, par le déport de PIGAUM.
En déportant ce composant de notre architecture qui le plus consommateur en terme de
ressources système (mémoire et processeur), nous réduisons son impact sur le nœud de calcul.
De plus, comme PIGA-UM dispose d’une machine dédiée, il ne sera plus pré-empté par un autre
processus et disposera de toute la puissance qui lui est nécessaire.
1224.4. AMÉLIORATION DE LA SÉCURITÉ
4.4 Amélioration de la sécurité
Dans cette partie, nous nous intéressons à l’attaque que nous avons présentée en introduction
de ce mémoire1.3. Nous montrons comment nous contrôlons cette attaque grâce à l’utilisation des
observateurs SELinux et PIGA. Pour pouvoir contrôler ce scénario complet, il est nécessaire tout
d’abord de définir une propriété de sécurité qui sera appliquée par PIGA. Puis nous montrerons
comme PIGA est capable de détecter ce scénario complet.
4.4.1 Propriété de sécurité
Nous montrons ici qu’il est possible d’utiliser PIGA pour améliorer la sécurité et traiter les
scénarios complets d’attaque. À partir du scénario complet que nous avons étudié en introduction
de ce mémoire (voir la section 1.3), nous allons exprimer une propriété de sécurité permettant de
le contrôler.
Le listing 4.3 montre la définition de la propriété de sécurité que nous avons donnée à PIGA.
✞ ☎
1 define exploit_staff_kernel( $sc1 IN CS, $sc2 IN CS, $sco1 IN CSO ) [
2 Foreach $eo1 IN is_execute_like(IS), Foreach $a1 IN ACT, Foreach $a2 IN
ACT
3 TQ { ( $sc2 -> { $eo1 } $sco1 o $sc1 -> { $eo1 } $sco1 ) } ,
4 { not( exist() ) } ;
5 ];
✝ ✆
Listing 4.3 – Propriété de sécurité contrôlant l’exploitation de la faille perf_event
Cette propriété se décrit de la manière suivante. Elle s’assure qu’il n’existe aucun lien not(
exist() ) entre l’enchaînement des interactions suivantes : tout d’abord le contexte de sécurité $sc1
fait une opération d’exécution sur le contexte de sécurité $sco1 puis que le contexte de sécurité
$sc2 réalise lui aussi une opération d’exécution sur le contexte de sécurité $sco1.
La fonction not( exist() ) s’assure qu’il n’y a aucun lien entre ces deux interactions. Ce lien
peut être : un contexte de sécurité partagé, un processus en commun, une filiation, etc.
sc1 −−−−→
execute
sco1
sc2 −−−−→
execute
sco1
Nous avons appliqué cette propriété de la manière suivante 4.4.
✞ ☎
1 exploit_staff_kernel( sc1:=staff_u:staff_r:staff_t,
2 sc2:=system_u:system_r:kernel_t,
3 sco1:=system_u:object_r:shell_exec_t );
✝ ✆
Listing 4.4 – Application de la propriété de sécurité pour contrer l’exploitation de la faille
Le contexte de sécurité sc1 correspond au contexte de sécurité de connexion de notre utilisateur
de test. Ici nous avons choisi que ce dernier puisse être dans le rôle staff_r.
Le contexte de sécurité sc2 correspond aux sujets qui s’exécutent en espace noyau. Or, comme
la faille permet d’exploiter une faille au sein même du noyau, son contexte d’exécution sera
system_u:system_r:kernel_t.
Le contexte de sécurité sco1 correspond au contexte de sécurité des objets du système de type
shell, comme bash, zsh, etc. Comme l’exploit lance un shell depuis l’espace noyau, nous
avons décidé de bloquer explicitement cette exécution.
1234.5. DISCUSSION
4.4.2 Application de la propriété de sécurité
Pour appliquer cette propriété, PIGA a besoin de la politique de contrôle d’accès de SELinux.
L’objectif de PIGA est de trouver les chemins autorisés dans la politique permettant de violer la
propriété de sécurité que nous venons de décrire.
À partir de cette propriété de sécurité seule et en parcourant la politique de SELinux, PIGA a
détecté 6 activités pouvant mener à violer la propriété de sécurité.
Le listing 4.5 montre le résultat d’une détection de la part de PIGA lorsque l’utilisateur tente
d’exploiter la faille.
✞ ☎
1 ( system_u:system_r:kernel_t -( file { execute } )-> system_u:object_r:
shell_exec_t rond staff_u:staff_r:staff_t -( file { execute } )-> system_u:
object_r:shell_exec_t ) | 172.30.3.1 55031 system_u:system_r:kernel_t->
system_u:object_r:shell_exec_t:file execute;2180 2081 -1 -1 exploit null
138016
2 ( system_u:system_r:kernel_t -( file { execute_no_trans } )-> system_u:object_r
:shell_exec_t rond staff_u:staff_r:staff_t -( file { execute_no_trans } )->
system_u:object_r:shell_exec_t ) | 172.30.3.1 55034 system_u:system_r:
kernel_t->system_u:object_r:shell_exec_t:file execute_no_trans;2180 2081 -1
-1 exploit null 138016
✝ ✆
Listing 4.5 – Détection par PIGA de la violation de la propriété de sécurité
Nous retrouvons dans cette détection les deux activités visées. La première concerne l’exécution
par l’utilisateur du shell 4.6, puis nous avons une seconde activité qui détecte l’exécution
du shell par le noyau 4.7.
✞ ☎
1 staff_u:staff_r:staff_t -( file { execute } )-> system_u:object_r:shell_exec_t
)
✝ ✆
Listing 4.6 – Première activité détectée par PIGA
✞ ☎
1 system_u:system_r:kernel_t -( file { execute } )-> system_u:object_r:
shell_exec_t
✝ ✆
Listing 4.7 – Deuxième activité détectée par PIGA
Nous sommes donc bien capables de détecter et de prévenir les scénarios d’attaque complets
correspondant à de réelles vulnérabilités grâce à l’association de deux observateurs.
4.5 Discussion
Dans ce chapitre, nous avons proposé un modèle d’évaluation des performances pour la répartition
des observateurs. Cette méthode permet de comparer les modes colocalisés et distants. Cette
méthode conduit à comparer 8 mesures globales à un temps de référence sans observateur. Nous
ajoutons à cette méthode des mesures détaillées qui permettent de connaître précisément les temps
de communication entre les deux observateurs pour le mode distant ainsi que le temps de décision
pour le second observateur.
Nous avons ensuite proposé une architecture originale pour déporter de manière efficace le second
observateur. Nous avons pour cela exploité les technologies spécifiques des environnements
HPC afin de minimiser les temps de communication. Nous avons mis en place cette architecture
avec les moniteurs de référence SELinux et PIGA. Pour l’échange des requêtes, un proxy client et
un proxy serveur permettent les communications sur des liens InfiniBand entre les deux moniteurs.
Nous avons enfin réalisé des expérimentations dans le but de comparer deux observateurs en
mode colocalisé avec deux observateurs en mode distant. Nous avons pour cela appliqué notre mé-
thode d’évaluation des performances sur l’architecture que nous avons mise en place. Durant ces
1244.5. DISCUSSION
expérimentations, les deux moniteurs sont utilisés en mode requête/réponse et en mode évidence,
ce qui conduit à devoir comparer 8 mesures avec un temps de référence.
Pour établir ces mesures, nous avons utilisé dans les premières expérimentations le logiciel
Linpack, un logiciel spécialement utilisé dans les environnements HPC. Les résultats que nous
avons obtenus montrent que la répartition des observateurs SELinux et PIGA n’impactent pas
les performances du code de calcul car Linpack réalise essentiellement des calculs mémoire et
peu d’entrées/sorties. On peut donc considérer que ce logiciel se place dans le meilleur des cas
quant à l’impact des observateurs sur les performances. Dans la seconde expérimentation, nous
avons voulu tester le pire des cas pour les observateurs en stressant le système de fichiers. Nous
résumons les taux d’augmentation pour chaque temps global dans le tableau 4.8. Nous rappelons
que dans les modes d’association colocalisés et distants, le premier observateur (SELinux) est
toujours placé en mode requête/réponse.
Mesure temps en µs surcoût en %
tempsreference 114,3
temps1_coloc_evi 115,3 0.8
temps1_coloc_rr 115,3 0.8
temps2_glob_coloc_evi 631 453
temps2_glob_coloc_rr 1325 1062
temps2_glob_dist_evi 286 150
temps2_glob_dist_rr 531 365
TABLE 4.8 – Tableau détaillant le surcoût de la répartition
Ce tableau montre que le mode distant améliore d’un facteur 3 les performances de la répartition
des observateurs. Il est nécessaire de rappeler que ces chiffres sont donnés pour le pire des
cas et qu’il n’y a pas de code de calcul qui réalise autant d’entrées/sorties lors de son exécution.
A contrario, les résultats de Linpack représentent le meilleur des cas, puisque sur une durée
de 23 heures, ce logiciel fait seulement 3000 opérations d’entrée/sortie. Nous pouvons dire qu’un
code de calcul "standard" se situe entre les deux. De plus, nous avons volontairement choisi une
configuration, au niveau des propriétés de sécurité PIGA, non optimale puisque nous garantissons
l’intégrité et la confidentialité pour tout le système. Un gain important pourrait être obtenu en
affinant les propriétés de sécurité PIGA et en évitant les propriétés contrôlant les flux indirects.
Dans la pratique, un code de calcul fait des entrées/sorties sur le système de fichiers essentiellement
pour réaliser des checkpoints (points de sauvegarde en cas de panne). Ces entrées/sorties
se traduisent pas l’écriture (ou la lecture) de fichiers ayant une taille importante mais générant peu
d’appels, donc les moniteurs sont moins sollicités que dans notre scénario de stress. Par consé-
quent, le comportement d’un code de calcul sera plus proche du comportement de Linpack que
de notre logiciel pour stresser les moniteurs de référence.
Nous notons que le logiciel Linpack réalise environ 3000 appels système en 23 heures, soit
0,036 appels système par secondes (soit 2,17 par minutes) alors que notre logiciel de stress réalise
5 000 000 d’appels système en 1 heure, soit 1 388 appels système par secondes. Dans le cas de
Linpack, nous ne notons aucune augmentation de la latence tandis que l’impact du stress du
système de fichiers est compris entre 150 et 365 % pour le mode distant, que ce soit en mode
évidence ou requête/réponse. Cependant, aucun de ces deux logiciels ne correspond exactement
au nombre d’entrées/sorties d’un code de calcul.
Par une estimation linéaire, nous pouvons estimer qu’un code de calcul réalise entre 100 et 200
appels système par secondes, nous pouvons estimer l’impact suivant les modes de répartition :
— en mode évidence (détection) et distant, l’impact sur les performances du code de calcul
serait compris entre 10 et 20%. Puisqu’un ordre de 1500 appels système par secondes
1254.5. DISCUSSION
correspond (environ) à un impact de 150%, on obtient par estimation linéaire un impact de
150/1500x100 soit 10% pour 100 appels système par secondes.
— en mode requête/réponse (protection) et distant, l’impact sur les performances du code de
calcul sera entre 25 et 50% par estimation linéaire.
Pour l’instant, il semble difficile de mettre en place une répartition de deux observateurs tels
que SELinux et PIGA sur les nœuds de calcul sans nuire aux performances. Le gain réalisé par le
déport du second moniteur en mode détection introduisant un surcoût de l’ordre de 10%. Néanmoins,
l’amélioration des politiques PIGA devrait permettre de passer à un surcoût plus faible,
potentiellement de l’ordre de 5% selon les propriétés requises. D’autres améliorations sur le moteur
de PIGA devrait permettre d’aller encore en dessous.
Les autres nœuds du calculateur sont moins demandeurs en termes de performance. Nous
pouvons par exemple citer les nœuds de visualisation ou de connexion.
Les nœuds de visualisation sont utilisés pour présenter graphiquement les résultats obtenus
lorsque les calculs sont finis. Sur ce type de nœuds, les programmes chargent des fichiers de taille
importante (plusieurs téraoctets) mais réalisent peu d’appels système. Par conséquent, l’impact
devrait être acceptable pour la visualisation.
Pour les nœuds de connexion, ils sont utilisés pour accéder au calculateur, ce sont donc des
nœuds exposés aux attaques. En effet, les utilisateurs disposent d’un accès ssh leur permettant de
déposer leur code de calcul, tester leur code, etc. Sur ces types de nœuds, les besoins en performances
sont moins importants que sur les nœuds de calcul mais les besoins en sécurité sont donc
plus importants. Ce type de nœuds est donc tout à fait candidat pour utiliser nos deux moniteurs
répartis en mode protection.
Enfin, nous avons illustré l’efficacité de deux moniteurs pour prévenir les scénarios complets
d’attaque. Pour la vulnérabilité réelle décrite en introduction de ce mémoire, nous avons défini
une propriété de sécurité qui prévient le scénario de façon optimiste c’est-à-dire qui laisse les
activités légitimes avancer. Il est à noter que la propriété est générique car elle prévient toutes les
vulnérabilités de ce type.
126Chapitre 5
Contrôle d’accès obligatoire pour
Windows et Expérimentations
Dans l’état de l’art 2.3.5, nous avons montré la nécessité d’avoir un moniteur de référence pour
les systèmes Windows. Dans le chapitre 3, nous avons défini un modèle de moniteur pour contrôler
les interactions directes. Nous proposons dans ce chapitre une implantation fonctionnelle d’un tel
moniteur pour les systèmes Windows.
Un moniteur de référence doit mettre en place des mécanismes de détournement du flux d’exé-
cution au sein du système, afin d’appliquer les décisions prises par la partie moniteur de référence
de notre implantation.
Notre moniteur de référence implante les deux modèles de protection obligatoires que nous
avons présentés dans la section 3.2, à savoir les modèles PBAC et DTE. Pour obtenir une politique
PBAC portable sur les différents systèmes Windows, nous apportons une réponse à la problématique
de désignation des ressources. Pour le modèle DTE, nous proposons de calculer dynamiquement
les contextes de sécurité à chaque interaction.
Toutefois, l’écriture d’une politique de sécurité pour tout un système est une tâche complexe
et laborieuse et nous avons donc mis en place un mécanisme facilitant leur écriture. Ce mécanisme
se base sur les traces générées par l’observateur pour dériver, de manière automatique, les règles
correspondantes.
Ce chapitre est divisé en quatre parties. Dans une première partie, nous traiterons de la problé-
matique de création des politiques. Nous proposerons une solution pour résoudre la problématique
de la construction des noms symboliques absolus indépendants de la localisation. Nous présenterons
enfin notre mécanisme de génération automatique de la politique.
La seconde partie sera consacrée à l’implantation de deux Policy Enforcement Point, c’est-à-
dire des méthodes pour détourner le flux d’exécution régulier du système, que nous avons décrites
dans la partie 3.3. Nous avons ici choisi de nous focaliser sur le détournement de la table des appels
système et sur la création d’un filter-driver. Nous expliquerons en détail le fonctionnement de ces
deux méthodes.
La troisième partie traitera des expérimentations que nous avons réalisées. Dans une première
section, nous montrerons que nous sommes capables de bloquer des attaques simples visant à
violer une propriété de sécurité telle que la confidentialité. Nous illustrerons les limites de ce
mécanisme grâce à des scénarios d’attaques complets. Pour franchir ces limites, nous introduirons
l’utilisation d’un second moniteur, PIGA.
Dans une seconde section, nous proposerons des modifications de notre moniteur pour l’orienter
sur l’étude des logiciels malveillants. Nous présentons les modifications apportées ainsi que la
plateforme mise en place pour faciliter l’interprétation des résultats. Pour cela, nous reprendrons
l’exemple que nous avons présenté dans l’introduction de ce mémoire 1.3.
1275.1. POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT
Enfin, la dernière partie discutera les choix que nous avons faits ainsi que les limites de notre
implantation.
L’implantation de la solution basée sur le modèle DTE et sur le détournement de la table des
appels système a fait l’objet d’une publication [Gros et al., 2012]. L’application des propriétés
de sécurité est détaillée dans [Blanc et al., 2012]. Une application du modèle de protection a été
proposée au sein des clouds dans [Blanc et al., 2014].
5.1 Politique de contrôle d’accès direct
Cette section s’intéresse à la création et à la gestion des politiques de contrôle d’accès direct.
Nous traitons dans cette partie les deux modèles de protection, PBAC dans un premier temps puis
le modèle DTE dans un second temps.
Chaque sous-section est organisée ainsi : dans une première partie, nous expliquerons les choix
réalisés pour représenter les ressources du système. Puis, nous aborderons la création d’une politique
de contrôle d’accès s’appliquant à chaque modèle de protection. Enfin, nous détaillerons le
mécanisme d’automatisation pour générer des politiques de sécurité.
5.1.1 Path-Based Access Control
Représentation du système
Nous avons détaillé dans la partie 3.2.1.1 la problématique du système de nommage des fichiers
sous Windows. Pour résoudre ce problème, nous proposons l’utilisation de noms symboliques
absolus indépendants de la localisation.
L’implantation choisie se base sur l’utilisation des variables d’environnement présentes sous
les systèmes Windows. Les variables d’environnement dites "système", c’est-à-dire gérées directement
par le noyau, sont communes à tous les systèmes Windows. On peut par exemple citer
systemroot qui est la variable d’environnement pointant sur le répertoire d’installation du dossier
Windows. Pour simplifier leur utilisation, nous utilisons les dénominations utilisées en batch,
ce qui se traduit par l’utilisation de la syntaxe %systemroot%.
En utilisant les variables d’environnement, nous sommes capables de gé-
nérer des politiques de sécurité portables sur chaque système Windows. Par
exemple, le fichier C:\Windows\system32\cmd.exe se transforme en
%systemroot%\System32\cmd.exe.
Cette méthode fonctionne aussi bien pour les sujets que pour les objets de type fichier. Les
répertoires sont traités de la même façon. Tous les répertoires système possèdent une variable
d’environnement associée. Lorsqu’un répertoire est au niveau du point de montage du système
mais ne possède pas de variable d’environnement associée, il suffit d’utiliser la variable définie
pour le point de montage du système %systemdrive%. Pour étendre ce modèle aux disques ou
aux partitions qui seraient montés sur un autre lecteur et qui ne possèderaient pas de variables
associées, il est nécessaire d’en créer de nouvelles. Concrètement, si une partition est montée sur
la lettre D: et ne contient aucun dossier système comme les répertoires des utilisateurs ou des
programmes, il est nécessaire de la nommer avec une variable comme %datadrive%.
La gestion du registre est simplifiée par rapport à celle du système de fichiers. Les ruches,
qui sont les éléments qui hébergent les clés du registre, sont identiques sur tous les systèmes
Windows. On peut donc s’en servir comme espace de noms pour désigner les clés. Ainsi, la clé
CurrentVersion qui est dans la ruche HKEY_LOCAL_MACHINE, est représentée par le chemin
\HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion.
Les éléments du réseau se gèrent aussi de façon naturelle. Ils peuvent être identifiés à la fois
par un couple d’adresse IP et de port, soit par le nom des hôtes. Pour qu’il n’y ait pas de confusion
1285.1. POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT
entre un objet local et un objet réseau, nous les préfixons par l’espace de nom RES. Ainsi l’objet
192.168.1.254 avec le port 80 est représenté par la directive RES/192.168.1.254 80. Nous
avons la même directive pour les noms d’hôte, par exemple RES/www.google.fr 80.
Extrait d’une politique basée sur les chemins complets
Nous avons précisé dans le listing 3.9 les terminaux propres au modèle de protection PBAC. De
plus, la définition de la grammaire générique 3.1 précise la forme des vecteurs d’accès que nous
reprenons dans ce listing 5.1 :
✞ ☎
1 vecteur_acces : contexte Delimiteurs_debut? (liste_operations_elementaires)+
Delimiteurs_fin? ;
✝ ✆
Listing 5.1 – Règle générique d’un vecteur d’accès extrait de la grammaire générique
Donc à partir de ces différents éléments, nous allons pouvoir écrire une politique de sécurité
basée sur le modèle de protection PBAC.
Ainsi, le listing 5.2 illustre la manière d’autoriser le sujet %systemroot%\explorer.exe
à lire (r) et exécuter (x) l’objet ayant pour chemin %systemroot%\System32\cmd.exe.
Ce fichier se situe donc dans le répertoire d’installation du dossier Windows. Le sujet
%systemroot%\explorer.exe est aussi autorisé à aller lire (r) et écrire (w) dans le fichier
%programfiles%\fichier.txt, dont la variable d’environnement correspond au répertoire
nommé Program Files.
✞ ☎
1 %systemroot%\explorer.exe {
2 %systemroot%\System32\cmd.exe rx
3 %programfiles%\fichier.txt rw
4 }
✝ ✆
Listing 5.2 – Extrait d’une politique de type TPE
Pour les accès au registre, les règles s’écrivent de la même façon. Ainsi le listing 5.3
montre comment autoriser le sujet %systemroot%\explorer.exe à lire (r) la clé
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion.
✞ ☎
1 %systemroot%\explorer.exe {
2 HKEY_LOCAL__MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion r
3 }
✝ ✆
Listing 5.3 – Extrait d’une politique de type PBAC pour le registre
Pour les autorisations liées aux objets du réseau, nous écrivons la politique suivante 5.4. Ainsi
la première ligne autorise le sujet %systemroot%\explorer.exe à se connecter (c) au domaine
www.google.fr vers le port 80.
✞ ☎
1 %systemroot%\explorer.exe {
2 RES\www.google.fr 80 c
3 }
✝ ✆
Listing 5.4 – Extrait d’une politique de type PBAC pour le réseau
Création d’une politique basée sur le modèle PBAC
La création d’une politique au format PBAC peut se faire de manière manuelle mais aussi
automatique. Ces deux méthodes peuvent se faire en se basant sur une trace d’audit. Cette méthode
simplifie l’écriture des règles d’accès.
1295.1. POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT
Pour faciliter l’administration d’une politique de contrôle d’accès basée sur le modèle PBAC,
nous proposons l’utilisation d’un outil capable d’automatiser la création d’une telle politique en
utilisant les fichiers d’audit générés par le moniteur de référence. Nous présentons la méthode
d’automatisation plus en détail dans la section 5.1.4.
Ainsi, à partir du listing 5.5, nous avons généré la règle 5.6.
✞ ☎
1 type=PBAC audit(1174358746:36452) ips:denied { read execute } for pid=2004 comm
="%systemroot%\explorer.exe" ppid=872 path="%systemroot%\system32\audiodev.
dll" tclass=file
✝ ✆
Listing 5.5 – Trace d’audit pour l’implantation utilisant le modèle PBAC
✞ ☎
1 subjet %systemroot%\explorer {
2 %systemroot%\system32\audiodev.dll rwa
3 }
✝ ✆
Listing 5.6 – Règle de contrôle d’accès pour le modèle PBAC résultat de l’apprentissage
Une fois que la règle a été ajoutée à la politique courante et que l’observateur a rechargé cette
nouvelle politique, lorsque le moniteur observe que l’interaction courante est présente dans la
politique, il va le spécifier dans la trace qu’il génère. Il faut noter que, mis à part le timestamp
et l’identifiant de trace qui sont modifiés, la seule différence se trouve dans la décision prise par
l’observateur qui passe de denied à granted comme le montre les traces 5.5 et 5.7
✞ ☎
1 type=PBAC audit(1174956145:264) ips:granted { read execute } for pid=1024 comm=
"%systemroot%\explorer.exe" ppid=988 path="%systemroot%\system32\audiodev.
dll" tclass=file
✝ ✆
Listing 5.7 – Trace d’audit pour l’implantation utilisant le modèle PBAC
Trusted Path Execution
Nous avons défini les répertoires de confiance à partir d’une installation classique d’un système
Windows. Ainsi, les répertoires %systemroot% et %systemroot%\System32 qui sont les
répertoires d’installation du système, et %programfiles%, qui est le répertoire d’installation
des applications tierces, sont des répertoires de confiance. Naturellement, pour qu’un fichier puisse
être exécuté, il est nécessaire qu’une règle d’accès autorise un sujet à l’exécuter. La définition des
répertoires de confiance permet de mettre en place une règle d’accès simple qui stipule que tout
sujet qui souhaite exécuter un fichier qui n’est pas dans un de ces dossiers, verra son accès refusé.
Les répertoires d’où sont exécutés les exécutables que l’administrateur autorise, sont notés en
début de politique sous la forme suivante 5.8 :
✞ ☎
1 tpe {
2 %programfiles%
3 %systemroot%
4 }
✝ ✆
Listing 5.8 – Définition des répertoires de confiance
5.1.2 Domain and Type Enforcement
Labellisation
Le second modèle de protection que nous avons traité est le modèle DTE. Nous avons présenté
les avantages d’utiliser ce modèle de protection dans la section 3.2.2.2.
1305.1. POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT
Sur les systèmes Linux supportant SELinux, les contextes de sécurité des objets sont stockés
dans les attributs étendus du système de fichiers. Ces informations sont disponibles en utilisant
les commandes comme ls -Z ou encore getfattr. Un exemple de résultat est montré dans le
listing 5.9. Il est possible de stocker ces informations car le système de fichiers prévoit la possibilité
d’avoir des noms arbitraires d’attributs étendus. L’avantage de cette technique est la persistance
des contextes mais celle-ci pose des problèmes pratiques.
✞ ☎
1 getfattr -m security.selinux -d pol.xml.bak
2 # file: pol.xml.bak
3 security.selinux="system_u:object_r:default_t:s0"
✝ ✆
Listing 5.9 – Récupération des attributs étendus sous Linux
Cependant, dans le cas de Windows, il n’est pas prévu d’étendre le système de fichiers pour
ajouter des contextes de sécurité comme sous Linux car c’est un système de fichiers propriétaire
(NTFS). Par conséquent, plutôt que de les stocker, nous avons fait le choix de les calculer dynamiquement.
Cette opération se déroule durant la phase de prétraitement du moniteur de référence
(phase 2.1 de la figure 3.9).
Le calcul à la volée des contextes de sécurité implique une considération importante : il est
nécessaire de pouvoir identifier précisément chaque ressource. Sous SELinux, le fait d’avoir des
contextes de sécurité non uniques est compensé par l’impossibilité pour un utilisateur de modifier
les contextes. Ainsi, SELinux s’appuie à la fois sur le nom de la ressource mais aussi sur son
contexte pour différencier les objets sur le système.
Le calcul à la volée des contextes ne permet pas de faire cette distinction dans ce cas. Par
exemple, il n’est pas possible de différencier un fichier explorer.exe qui se trouve dans
C:\Windows\explorer.exe et dans C:\Users\Damien\explorer.exe, lorsque les
contextes de sécurité ne sont basés que sur le nom relatif des fichiers.
Pour résoudre ce problème, nous avons utilisé notre approche de désignation des ressources
déjà appliquée au modèle PBAC. Ainsi, nous offrons une méthode dynamique et portable. Nous
ajoutons une couche d’abstraction par l’utilisation des noms symboliques absolus indépendants de
la localisation. Dans ce cas, nous avons aussi utilisé les variables d’environnement puisqu’elles
sont communes à tous les systèmes Windows.
À partir de ces choix, nous pouvons labelliser le système. Nous rappelons qu’un contexte de
sécurité est constitué d’une identité, d’un rôle, d’un type pour les objets et d’un domaine pour les
sujets. Dans l’implantation actuelle, nous n’utilisons ni l’identité, ni les rôles. Nous nous sommes
concentrés sur les types et les domaines tout comme le fait SELinux.
Les objets Dans la section 3.2.2.2 où nous avons présenté notre formalisation pour la description
des objets dans le modèle de protection DTE, nous avons défini des catégories pour identifier la
nature des ressources. Par exemple, un répertoire a un type associé finissant par dir_t.
Le listing 5.10 exprime une règle de correspondance entre le chemin exprimé sous la forme de
variable d’environnement et le contexte de sécurité qui lui est associé. Nous noterons que tous les
objets possèdent les mêmes identité et rôle system_u:object_r. Le rôle object_r précise
explicitement que ce contexte de sécurité se rattache à un objet du système.
✞ ☎
1 %programfiles% system_u:object_r:programfiles_dir_t
✝ ✆
Listing 5.10 – Contexte de sécurité associé au répertoire Program Files
Le contexte de sécurité des objets calculé à la volée fait apparaître son chemin complet
dans le système de fichiers. Ainsi, si l’objet courant est dans un point de l’arborescence avec
plusieurs répertoires parents, son contexte contiendra tous ces répertoires. Pour aider à la lecture
des contextes de sécurité dans les fichiers d’audit, nous séparons chaque répertoire par
1315.1. POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT
le caractère |. Ce caractère étant un caractère interdit dans le nom des fichiers et des répertoires
sous Windows, nous sommes sûrs qu’il n’apparaîtra pas dans le nom des objets. Par
exemple, le répertoire C:\Program Files\Mozilla\Plugins a pour contexte de sécurité
system_u:object_r:programfiles|mozilla|plugins_dir_t.
La construction du contexte de sécurité pour les fichiers se fait de façon similaire. Cependant,
un répertoire possède une catégorie spécifique aux répertoires, c’est-à-dire un suffixe dir_r
ajouté au type de son contexte de sécurité, il faut aussi définir les catégories pour les fichiers. Pour
faciliter la reconnaissance faite par le moniteur de référence, il va se baser sur les extensions des
fichiers pour en extraire leur catégorie.
Nous obtenons un grand nombre de catégories possibles pour les fichiers : exécutable, bibliothèque,
driver, un document Word, etc. Dans ces catégories, nous portons une attention toute
particulière à un sous-ensemble : les fichiers qui peuvent être exécutés comme les binaires exécutables
mais aussi les bibliothèques, ainsi que les fichiers pouvant transporter une charge virale tels
que les fichiers pdf ou MS Word.
Les fichiers ont aussi un suffixe spécifique dans leur type qui représente leur catégorie.
Ainsi, un fichier exécutable, classiquement représenté par son extension .exe, aura comme type
exec_t. Un driver, qui a pour extension .sys aura comme type sys_t.
Ainsi, le fichier C:\Windows\system32\cmd.exe a pour contexte de sécurité
system_u:object_r:systemroot|system32|cmd_exec_t. De manière analogue,
les fichiers de bibliothèques dynamiques (dll) ont un type se finissant par lib_t.
Grâce à cette méthode de labellisation dynamique, chaque objet du système possède un
contexte de sécurité précis basé sur sa place dans l’arborescence du système de fichiers. Cependant,
cette méthode conduit à avoir potentiellement un nombre important de contextes de sécurité.
Nous avons donc prévu un traitement spécifique pour certains répertoires dans lesquels fichiers et
répertoires ont tous le même contexte de sécurité.
Cette exception dans notre méthode de labellisation dynamique s’applique essentiellement
pour les dossiers temporaires. En effet, il n’est pas possible de prévoir le contenu de ce type de
dossiers dans le but de pouvoir faire une politique de contrôle d’accès. Prenons un répertoire
temporaire tel que C:\Temp, si un utilisateur y crée un fichier, alors il aura pour contexte de
sécurité system_u:object_r:tmp_t.
Les sujets Les contextes de sécurité sujet sont construits à partir du nom relatif du
fichier du binaire exécuté. Les identités et rôles utilisés sont génériques pour l’instant.
Par exemple, le processus explorer.exe a pour contexte de sécurité le label
system_u:system_r:explorer_t.
Il n’est pas nécessaire de stocker tout le chemin du binaire dans le contexte de sécurité sujet.
L’objectif est d’alléger les traces et les politiques, ainsi que de faciliter leur lecture. Cependant,
nous pourrions tout à fait stocker tout le chemin dans le contexte de sécurité comme pour les
objets.
Le registre Dans l’implantation proposée, nous ne faisons qu’une labellisation générique
du registre. Cela signifie que tous les objets du registre ont pour contexte de sécurité
system_u:object_r:registry_t.
Néanmoins, à partir de la formalisation que nous avons proposée, nous pouvons définir les
contextes de sécurité pour les objets du registre. Ainsi, en utilisant les mêmes méthodes que pour le
modèle PBAC, c’est-à-dire en utilisant le nom de la ruche comme namespace, on peut construire
les contextes de sécurité en utilisant tout le nom de la clé. On utilisera aussi le même séparateur
que celui utilisé pour les chemins dans le nom des objets, à savoir |, pour décrire l’arborescence
de la clé.
1325.1. POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT
On utilisera aussi des catégories spécifiques. Ainsi, une clé aura pour suffixe key_t, alors
qu’une valeur aura pour catégorie value_t. Le listing 5.11 montre sur deux exemples le résultat
sur une clé et sur une valeur.
✞ ☎
1 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run system_u:
object_r:hkey_local_machine|software\microsoft|windows|currentversion|
run_key_t
2 HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Run|Avira system_u
:object_r:hkey_local_machine|software\microsoft|windows|currentversion|
run_avira_value_t
✝ ✆
Listing 5.11 – Exemples d’associations d’éléments du registre et de contextes de sécurité
Extrait d’une politique basée sur les types
Comme pour le modèle de protection PBAC, nous avons formalisé les terminaux pour le modèle
de protection DTE dans le listing 3.12. La spécification des terminaux nous permet de définir de
manière explicite les traitements que l’observateur doit réaliser lorsqu’il intercepte les interactions
directes.
Les règles d’autorisation sont plus complexes que dans le cas de PBAC car les permissions
exprimées sont basées sur les appels système, donc avec une plus grande finesse. Ainsi, pour autoriser
(allow) un sujet ayant comme domaine explorer_t à exécuter un invite de commande,
il faut, tout d’abord, l’autoriser à récupérer des informations et à lire le fichier binaire. Cette règle
est représentée par la ligne 1 du listing 5.12. Ensuite on doit l’autoriser à exécuter le fichier binaire
pour en faire un processus, ce qui est représenté pour la ligne 2 du listing.
✞ ☎
1 allow explorer_t systemroot|system32|cmd_exec_t:file { read execute create
getattr }
2 allow explorer_t systemroot|system32|cmd_exec_t:process { execute }
✝ ✆
Listing 5.12 – Extrait d’une politique SEWindows
Lors de l’exécution d’un fichier binaire (généralement un .exe), il se produit
une transition du type du fichier vers un domaine. Par exemple, lorsque le sujet
ayant comme domaine explorer_t exécute un invite de commande, soit le
binaire C:\Windows\system32\cmd.exe qui a pour contexte de sécurité objet
system_u:object_r:%systemroot%|system32|cmd_exec_t, le nouveau processus
transite vers le contexte de sécurité sujet system_u:system_r:cmd_t.
Le contrôle des accès pour le registre se fait de manière similaire. Il est possible d’associer
chaque opération du registre à une opération élémentaire (lire, écrire, exécuter, etc). Donc la création
d’une règle d’accès pour le registre se fait comme une règle pour le système de fichiers. Le
listing 5.13 détaille une règle pour la lecture du contenu d’une clé.
✞ ☎
1 allow explorer_t hkey_local_machine|software|microsoft|windows|currentversion|
run_key_t:key { read execute }
✝ ✆
Listing 5.13 – Extrait d’une politique SEWindows pour la gestion du registre
Nous avons défini dans la grammaire trois traitements possibles pour une règle d’accès. L’instruction
allow autorise de manière explicite les interactions. L’instruction allowaudit va gé-
nérer un message dans le fichier d’audit spécifiant que cette règle a été utilisée. Elle peut être
utilisée pour surveiller des interactions particulières. Toutefois elle n’autorise pas l’interaction,
pour cela, elle doit être complétée avec une règle allow. Enfin, l’instruction neverallow empêche
explicitement l’interaction décrite par la règle d’accès. Cette règle prime sur toute règle
allow autorisant la même interaction.
1335.1. POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT
Création de la politique basée sur le modèle DTE
Comme pour le modèle de protection PBAC, la création d’une politique pour le modèle DTE
peut se faire de manière manuelle ou automatique. Nous allons ici décrire la création de règles
d’accès à partir d’une trace générée par le moniteur.
Nous allons détailler cette création sur un exemple concret. Nous avons lancé l’application
Windows Media Player. Au niveau du mécanisme de création de processus de Windows,
c’est le processus %systemroot%\explorer.exe qui lance le processus qui a pour nom
wmplayer.exe. Cette opération se traduit par la génération de plusieurs traces. Nous avons
extrait deux traces pour illustrer notre propos.
Dans un premier temps, le processus %systemroot%\explorer.exe va demander
les opérations élémentaires { read execute create getattr } sur le fichier
%programfiles%\windows media player\wmplayer.exe comme le montre la première
ligne du listing 5.14.
Le processus de labellisation transforme les noms et chemins des fichiers en contexte de sécurité
comme expliqué dans la partie 5.1.2 . Ainsi, le processus %systemroot%\explorer.exe
aura pour contexte de sécurité sujet system_u:system_r:explorer_t.
De la même façon, l’objet %programfiles%\windows
media player\wmplayer.exe aura pour contexte de sécurité
system_u:system_r:programfiles|windowsmediaplayer|wmplayer_exec_t.
Avec ces éléments, nous sommes capables de créer une première règle pour notre politique de
contrôle d’accès comme le montre la première règle du fichier de politique présent en listing 5.15.
Ensuite, il y a une deuxième interaction faite par le sujet qui est la création du processus. Cette
interaction se traduit au niveau du moniteur par une seconde trace. La différence se fait sur la classe
de l’objet. En effet, sur la première trace, l’interaction se fait sur le fichier, alors que la deuxième
trace concerne une création de processus, c’est-à-dire à la transition du fichier vers son domaine.
Pour autoriser la création du processus, il est nécessaire d’ajouter la deuxième ligne présente
dans le listing 5.15.
✞ ☎
1 type=DTE audit(1285242977:13) avc:denied { read execute create getattr } for
pid=1576 comm="%systemroot%\explorer.exe" ppid=1528 path="%programfiles%\
windows media player\wmplayer.exe" scontext=system_u:system_r:explorer_t
tcontext=system_u:object_r:programfiles|windowsmediaplayer|wmplayer_exec_t
tclass=file
2 type=DTE audit(1285242977:14) avc:denied { execute } for pid=1576 comm="%
systemroot%\explorer.exe" ppid=1576 path="%programfiles%\windows media
player\wmplayer.exe" scontext=system_u:system_r:explorer_t tcontext=
system_u:object_r:programfiles|windowsmediaplayer|wmplayer_exec_t tclass=
process
✝ ✆
Listing 5.14 – Extrait d’un fichier d’audit
✞ ☎
1 allow explorer_t programfiles|windowsmediaplayer|wmplayer_exec_t:file { read
execute create getattr }
2 allow explorer_t programfiles|windowsmediaplayer|wmplayer_exec_t:process {
execute }
✝ ✆
Listing 5.15 – Règles de contrôle d’accès créées à partir d’une trace
5.1.3 Modes de fonctionnement
Notre moniteur de référence a trois modes de fonctionnement : disabled, permissif (évidence)
aussi appelé détection et enforcing ou protection (requête/réponse). Dans le mode disabled, le flux
1345.1. POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT
d’exécution n’est pas détourné par le moniteur et aucune décision n’est calculée. Nous allons donc
détailler dans cette section les deux autres modes du moniteur.
Mode détection (Évidence)
Le mode détection, ou permissif, est un mode dans lequel le moniteur n’applique pas sa décision.
Le flux d’exécution est détourné, une décision est bien calculée au regard de la politique, mais
elle n’est pas appliquée. Ce mode peut aussi fonctionner sans aucune politique prédéfinie, dans ce
cas, toutes les interactions seront considérées comme refusées. Cette particularité peut se révéler
intéressante pour l’étude des logiciels malveillants puisqu’il sera alors possible d’enregistrer toutes
les opérations qui se déroulent au sein du système.
Ce mode a deux objectifs : la première, il permet de créer une politique de contrôle d’accès
pour un nouveau programme et la seconde, il permet de valider la politique. Ce mode peut aussi
être appelé mode d’apprentissage quand il est utilisé pour créer une politique.
La création de la politique se fait à partir des traces générées par le moniteur. Une fois les traces
générées, l’écriture de la politique peut se faire de manière manuelle ou automatique comme nous
le détaillons dans la section 5.1.4. Chaque interaction est vérifiée dans la politique et une trace est
générée spécifiant si cette interaction est autorisée, c’est-à-dire qu’il existe une règle d’accès dans
la politique qui l’autorise, sinon l’interaction est refusée.
Le mode apprentissage peut être réalisé avec ou sans politique de sécurité. Si une politique
existe, les traces contiennent le terme granted stipulant que l’interaction est autorisée dans la
politique courante comme le montre le listing 5.16. La règle pour autoriser cette interaction a été
définie dans le listing 5.12.
✞ ☎
1 type=DTE audit(1285243100:4600) avc:granted { execute } for pid=1576 comm="%
systemroot%\explorer.exe" ppid=1576 path="%systemroot%\system32\cmd.exe"
scontext=system_u:system_r:explorer_t tcontext=system_u:object_r:systemroot
|system32|cmd_exec_t tclass=process
✝ ✆
Listing 5.16 – Extrait d’un fichier d’audit autorisant une interaction
Une fois que l’administrateur considère avoir réalisé toutes les interactions nécessaires pour
que son programme puisse fonctionner et avant de passer le moniteur en mode protection, ce qui
pourrait bloquer la machine, il peut valider sa politique dans le mode détection en vérifiant les
traces générées.
Ce mode peut aussi se révéler utile dans des environnements où seule la détection des interactions
est voulue.
Mode protection (Requête/Réponse)
Le mode protection, ou enforcing, est le mode dans lequel le moniteur applique les décisions.
Si une interaction n’est pas dans la politique de contrôle d’accès, alors elle sera bloquée par le
moniteur et une trace sera générée pour notifier l’administrateur de ce refus.
5.1.4 Définition des politiques
Les politiques de contrôle d’accès peuvent être écrites soit de façon manuelle, soit de manière
automatique grâce à l’outil que nous proposons. Nous allons dans cette section détailler les deux
fonctionnements.
1355.1. POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT
Automatisation
Nous proposons un outil pour la création automatique d’une politique de contrôle d’accès, quel
que soit le modèle de protection. Grâce à cette automatisation, la politique s’écrit par répétition.
Pour réaliser cet apprentissage, il est nécessaire de mettre le moniteur en mode détection, ainsi
le programme ou processus pour lequel on veut créer la nouvelle politique ne sera pas bloqué.
Prenons un exemple illustré par la figure 5.1. Nous désirons ici ajouter un programme sur
notre système d’exploitation, il faut donc ajouter les règles d’accès correspondantes pour qu’il
puisse fonctionner correctement. Ce mode peut fonctionner avec ou sans politique de base. Si le
moniteur n’a pas de politique de base, il va enregistrer toutes les interactions faites sur le système,
même celles qui ne sont pas réalisées par le programme que l’on veut ajouter.
La méthodologie d’apprentissage est la suivante. On change le mode du moniteur en détection.
On lance une première fois le nouveau programme (flèche 0 du schéma). Le moniteur trace les
interactions du processus (flèche 1) et les enregistre dans le fichier d’audit (flèche 2). Notre outil
parcourt le fichier d’audit (flèche 3) et transforme automatiquement les traces en règles d’accès au
bon format, c’est-à-dire PBAC ou DTE. Ces nouvelles règles sont ajoutées à la politique courante
(flèche 4) puis cette nouvelle politique est rechargée par le moniteur (flèche 5). Le processus ou
programme que l’on veut ajouter est ensuite relancé.
La fin du processus d’apprentissage est laissée à la discrétion de l’administrateur. En effet,
il n’est pas possible de déterminer de manière certaine quand un programme a réalisé toutes les
interactions de manière automatique. Par exemple, pour une application graphique, il faut que
l’administrateur réalise lui-même les tâches qu’il souhaite autoriser. Il est donc conseillé d’avoir
une check-list précisant les tâches nécessaires au moment de lancer l’apprentissage.
L’apprentissage peut être considéré comme terminé lorsqu’on a réalisé toutes les tâches listées
dans la check-list et qu’il n’apparaît plus aucune trace d’accès bloqué.
FIGURE 5.1 – Schéma décrivant l’apprentissage d’une politique
1365.1. POLITIQUE DE CONTRÔLE D’ACCÈS DIRECT
Avantages Le principal avantage de cette méthode d’écriture de la politique de contrôle d’accès
est sa grande facilité de mise en place. En effet, il suffit de lancer le programme d’apprentissage et
de réaliser les tâches nécessaires au sein du programme que l’on veut ajouter pour que les règles
soient automatiquement générées. En plus de facilité l’écriture, cela l’accélère aussi. De plus,
si l’administrateur a minutieusement réalisé toutes les tâches désirées au sein du nouveau programme,
il ne devrait pas avoir à modifier plus tard sa politique. Cependant, lors d’une mise à jour
du programme, il peut être nécessaire de recommencer l’opération pour ajouter automatiquement
les nouvelles règles dans la politique mais les tâches sont prédéfinies.
Inconvénient Le principal inconvénient de cette méthode est la nécessité pour l’administrateur
de vérifier, à la main, les règles qui ont été ajoutées par l’outil dans la politique. En effet, il est
possible que le programme que l’on veuille ajouter, réalise des interactions malveillantes ou illégitimes
pour l’administrateur, cachées par des tâches "normales". Par exemple, on pourrait imaginer
un programme qui tente de copier la partie du registre contenant les mots de passe des utilisateurs.
Lors de la phase d’apprentissage, cette interaction ne sera pas bloquée par le moniteur et par apprentissage,
elle sera ajoutée à la politique courante. Si l’administrateur ne vérifie pas les règles,
cette interaction malveillante sera aussi autorisée même en mode protection.
Il est donc nécessaire pour l’administrateur de vérifier les règles qui ont été ajoutées pour un
programme. C’est pour cela que nous conseillons d’avoir au préalable une politique déjà écrite
prenant en compte le reste du système, pour ne pas être parasité par les autres applications.
Manuelle
La seconde méthode pour créer une politique est de le faire de façon manuelle. Nous pouvons
définir deux cas : soit l’administrateur connait précisément ce que fait le programme qu’il veut
ajouter, dans ce cas, il écrit toutes les règles, soit il utilise la même méthode que pour l’automatisation,
en transformant manuellement les traces en règles d’accès.
Dans les deux cas, le moniteur peut être utilisé soit en mode détection pour plus de facilité,
soit en mode protection.
Avantages Le principal avantage de cette méthode est que l’administrateur maîtrise entièrement
le processus de création des règles d’accès. Il peut ainsi vérifier qu’il n’autorise pas une interaction
malveillante ou illégitime pour le nouveau programme.
Inconvénient Le principal inconvénient est que cette méthode est beaucoup plus coûteuse en
temps. En effet, la retranscription à la main de chaque règle peut se révéler être un travail très
fastidieux, surtout dans le cas des mises à jour des programmes qui les modifient intégralement,
voire pour les mises à jour du système.
5.1.5 Discussion
Nous venons de détailler l’implantation choisie pour les modèles de protection PBAC et DTE
appliqués aux systèmes Windows. Dans cette section, nous avons dû résoudre la problématique
des ressources.
Pour le modèle de protection PBAC, nous avons choisi d’implanter le mécanisme de
namespace en utilisant les variables d’environnement. Ces variables sont divisées en deux types :
le premier est géré directement par le système. On le retrouve ainsi sur tous les systèmes Windows.
Cela assure une portabilité complète de nos politiques de contrôle d’accès. Le second type est géré
par l’administrateur. Il peut ainsi ajouter des variables d’environnement pour rédiger des règles
1375.2. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS OBLIGATOIRE
d’accès propres à son système ou à son parc de machines. Nous avons aussi ajouté à ce modèle
de protection, un second modèle de protection nommé TPE. Il permet de définir des répertoires de
confiance d’où seront lancés les fichiers exécutables.
En ce qui concerne le modèle de protection DTE, la principale difficulté était de trouver un
moyen de stocker les contextes de sécurité des objets. Nous avons vu que SELinux utilisait les
attributs étendus du système de fichiers pour les stocker. Cette solution n’est pas portable sur les
systèmes Windows qui n’utilisent pas le même système de fichiers. Nous avons ainsi proposé une
méthode évitant d’avoir à stocker les contextes de sécurité. Afin de ne pas créer de faiblesse dans
notre modèle de protection, nous avons dû définir des contextes de sécurité plus précis que ceux
proposés par SELinux. Pour cela, nous avons choisi de mettre dans le type du contexte de sécurité
objet le chemin complet de l’objet. Cette méthode conduit à avoir les mêmes problèmes que pour
le modèle PBAC, à savoir un problème dans le mécanisme de noms des ressources. Pour résoudre
ce problème, nous avons utilisé la même solution que pour le modèle PBAC. Nous avons donc
utilisé les variables d’environnement pour la définition des chemins complets des objets.
Grâce à l’implantation basée sur les variables d’environnement nous proposons donc des noms
symboliques absolus indépendants de la localisation tels que définit dans le chapitre 3. Nous offrons
donc un mécanisme permettant de désigner de manière précise chaque ressource du système.
Nous avons montré que nous pouvions appliquer cette méthode non seulement sur les ressources
du système de fichiers mais aussi sur les éléments du registre, mécanisme important dans les systèmes
Windows.
Nous avons aussi détaillé les deux modes de fonctionnement de notre moniteur de référence.
Le mode détection, qui va permettre d’écrire une politique de contrôle d’accès et un mode protection,
qui l’applique strictement. Grâce au mode détection, nous avons mis en place un outil qui
automatise la création de nouvelles règles pour l’ajout d’un nouveau programme. Cette automatisation
n’est pas sans risque puisque l’outil n’effectue aucun contrôle sur la légitimité des règles
ajoutées. Il est donc nécessaire que l’administrateur vérifie les règles générées.
Enfin, nous avons présenté notre mécanisme d’audit, qui génère des traces permettant de
connaître les interactions qui se sont déroulées sur le système, mais qui sont aussi utilisées pour
créer des règles de contrôle d’accès, que ce soit de façon automatique ou manuelle.
5.2 Implantation des mécanismes de contrôle d’accès obligatoire
Dans cette section, nous allons présenter les implantations de deux mécanismes de contrôle
d’accès obligatoire pour les systèmes d’exploitation Windows, que nous avons appelé SEWINDOWS.
Cette section, qui est divisée en deux parties, propose l’implantation sous deux formes
différentes du Policy Enforcement Point. Ces deux méthodes ont été décrites dans la section 3.3.
La première implantation que nous proposons, utilise le détournement de la table des appels
système de Windows. Cette première version nous a permis de valider les politiques que nous
avons générées. La seconde implantation utilise les filter-driver pour détourner les flux d’exécution.
Cette seconde version respecte les préconisations faites par Microsoft pour surveiller l’activité
du système.
5.2.1 Implantation du mécanisme de contrôle d’accès basé sur la modification de
la table des appels système
L’implantation de cette solution s’appuyant sur le modèle de protection DTE a fait l’objet d’une
publication [Gros et al., 2012]. L’application qui en a été faite, dont la définition des propriétés de
sécurité fut détaillée dans [Blanc et al., 2012].
1385.2. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS OBLIGATOIRE
5.2.1.1 Architecture fonctionnelle du mécanisme de contrôle d’accès
La figure 5.2 décrit l’architecture logicielle de notre solution de contrôle d’accès pour les systèmes
Windows. Nous présentons ici les composants de cette architecture. Le premier composant
est le driver. C’est le point central du mécanisme. Il est responsable de la prise de décision (Policy
Decision Point). Cette implantation reprend toutes les phases que nous avons détaillées dans la
partie 3.1.2.
Dans la phase de pré-décision, le moniteur est chargé de récupérer toutes les informations
nécessaires à la prise de décision. Il est aussi en charge d’horodater et de numéroter la trace correspondante
à l’interaction directe observée. C’est aussi dans cette phase que le moniteur doit
mettre en place la méthode de représentation du système. Dans le cadre du modèle PBAC, il transforme
les chemins des ressources en nom absolu indépendant de la localisation. Dans le cadre du
modèle DTE, il doit labelliser les ressources.
Ensuite, le moniteur doit prendre une décision pour autoriser ou non l’interaction au regard de
la politique de contrôle d’accès. La décision est ensuite ajoutée à la trace pour qu’elle puisse être
générée.
Enfin, dans la phase de post-décision, soit le moniteur autorise la poursuite de l’interaction soit
il la refuse. Dans tous les cas, il renvoie à la fin une réponse au processus ayant réalisé l’interaction.
Dans cette implantation, les points d’application de la politique (Policy Enforcement Point)
sont réalisés par un module du driver : dans ce cas la, il s’agit de la modification de la table des
appels système. La figure 5.2 illustre l’architecture divisée en trois blocs de cette implantation.
Comme le schéma le montre, le moniteur est placé au centre du flux d’exécution pour pouvoir
contrôler en prétraitement et en post-traitement les interactions réalisées sur le système.
Le premier bloc, nommé Appel de fonction, correspond à l’utilisation régulière d’un appel de
fonction depuis l’espace utilisateur. Une application, qui réside en espace utilisateur, réalise une
interaction sur le système. Cette interaction se traduit par l’exécution d’un appel système. Pour
exécuter cet appel système, le système va chercher son adresse dans la table des appels système.
C’est cette table qui a été modifiée par le driver SEWINDOWS pour détourner le flux d’exécution
régulier.
Le deuxième bloc correspond à la partie SEWINDOWS. Une fois l’interaction détournée, le
moniteur va prendre une décision dans le but d’autoriser ou non l’interaction courante. Cette décision
se fait par le serveur de sécurité qui, dans le cas du modèle DTE, labellise les ressources. Dans
le cas du modèle PBAC, les chemins sont transformés en nom symbolique absolu indépendant de
la localisation. Cette partie est réalisée par un module spécifique du driver. Une fois la décision
prise, la trace est transmise au thread d’audit qui enregistre la trace dans le fichier d’audit.
Le troisième bloc correspond à l’exécution normale, c’est-à-dire sans détournement opéré par
le driver SEWINDOWS. Les fonctions de la table des appels système permettent d’interagir avec
les éléments du système tels que le registre, le réseau ou encore le système de fichiers.
5.2.1.2 Détournement de la table des appels système
Nous allons dans cette partie décrire, d’un point de vue technique, la méthode de détournement
du flux d’exécution en modifiant la table des appels système. Pour cela, nous allons dans un
premier temps détailler le fonctionnement d’un flux d’exécution classique, puis dans un second
temps, les modifications faites par le driver.
Exécution régulière La figure 5.3 illustre un flux d’exécution régulier. Un processus fait une
interaction sur le système de fichiers comme la création d’un fichier. Pour cela, le processus utilise
la fonction CreateFile de l’API Win32. Avant d’entrer en espace noyau, le flux d’exécution passe
par la bibliothèque ntdll qui est chargée de faire correspondre la fonction CreateFile de l’API
1395.2. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS OBLIGATOIRE
FIGURE 5.2 – Architecture globale
Win32 avec l’appel système correspondant qui est NtCreateFile. La bibliothèque ntdll ne passe
au noyau que le numéro de l’appel système et non son nom. L’instruction processeur SYSENTER
est enfin déclenchée pour effectuer le changement de contexte.
Une fois en espace noyau, le dispatcheur du noyau récupère le numéro de l’appel système et
il lit dans la table des appels système SSDT l’adresse de la fonction à exécuter. Cette fonction se
situe dans l’espace mémoire du noyau. Une fois l’appel système terminé, le retour de la fonction
est renvoyé au processus ayant réalisé l’interaction. La vérification des droits d’accès est faite
directement dans l’appel système.
Exécution modifiée Notre première implantation modifie le flux d’exécution régulier en altérant
cette table des appels système. La figure 5.4 montre comment le détournement opère. Lorsque le
driver SEWINDOWS se charge, il modifie la SSDT. Il remplace les adresses des appels système
par des adresses de fonctions qu’il maîtrise.
À la différence des appels système dont les adresses sont situées dans l’espace mémoire du
noyau, ces nouvelles adresses sont situées dans l’espace mémoire du driver SEWINDOWS. Le
dispatcheur du noyau, qui lit l’adresse de l’appel système dans la SSDT obtient ainsi l’adresse
1405.2. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS OBLIGATOIRE
Espace utilisateur
Espace noyau
processus
ntdll
Dispatcheur noyau
Noyau
N° Adresse
66
SSDT
0x825824AE
FIGURE 5.3 – Flux d’exécution classique
d’une fonction du driver SEWINDOWS. Le flux d’exécution est donc détourné dans le driver
SEWINDOWS.
Le serveur de sécurité peut alors autoriser ou non l’exécution de l’appel système en fonction de
la politique de contrôle d’accès qu’il a chargée. Toute interaction refusée par le serveur de sécurité
est enregistrée dans le fichier d’audit.
L’altération de la table des appels système nous donne le contrôle des interactions ciblant
le système de fichiers, des interactions sur le registre ainsi que des communications réseau. Les
communications sont initialisées par l’utilisation de l’appel système NtDeviceIoControl.
Limites Cependant, la SSDT ne gère pas les appels système contrôlant la partie graphique de
Windows. En effet, sur les systèmes d’exploitation Windows, la partie graphique est gérée indé-
pendamment du système par le driver win32.sys. Elle possède, par conséquent, sa propre table
d’appels système spécifique à la gestion graphique qui se nomme Shadow SSDT. Nous avons fait
le choix de ne par modifier cette table système car son altération peut provoquer une instabilité du
système.
En ne modifiant pas la Shadow SSDT, nous ne traitons pas les appels système qui gèrent la
partie graphique de Windows. Un attaquant pourrait, s’il arrive à charger son exploit, réaliser des
interactions que l’on peut considérer comme critiques. Par exemple, il serait capable de modifier
ou voler les communications entre les applications. Il peut aussi forcer des applications à se fermer
sans intervention de l’utilisateur.
Les tables des appels système ne sont accessibles et donc modifiables qu’en espace noyau, ce
qui les protègent des attaques que pourraient réaliser des processus. Néanmoins, un attaquant qui
arrive à charger un driver pourrait supprimer les modifications faites sur les SSDT sans que l’utilisateur
ou l’administrateur ne s’en aperçoive. Il faut, pour détecter ces modifications, surveiller les
modifications de ces tables. Ces limitations ont été traitées plus en détails dans la section 3.3.2.2.
1415.2. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS OBLIGATOIRE
processus
ntdll
Dispatcheur noyau
N° Adresse
66
Noyau
Driver SEWindows
SSDT modifiée
Espace utilisateur
Espace noyau
0xA34E70E0
N° Adresse
66
SSDT régulière
0x825824AE
FIGURE 5.4 – Flux d’exécution détourné par la modification de la SSDT
5.2.2 Architecture basée sur les filter-driver et les Kernel Callback
Dans la première partie de cette section, nous avons mis en place une première architecture
basée sur la modification de la table des appels système (SSDT). Cette solution, bien que fonctionnelle,
n’est pas une solution pérenne.
En effet, cette première solution souffre de quelques limites qui peuvent se révéler très contraignantes.
Tout d’abord, notre implantation n’est pas portable sur les Windows 64 bits puisqu’elle
modifie une table du système qui est protégée par Kernel Patch Protection. Sur ces systèmes, Kernel
Patch Protection vérifie l’intégrité des tables système et déclenche des exceptions lorsqu’elles
sont modifiées. Ces exceptions conduisent à la création d’un Blue Screen Of Death. Il n’est donc
pas possible de les modifier. Ensuite, la modification des tables système peuve rendre le système
d’exploitation instable et peut générer des Blue Screen Of Death. Enfin, il est nécessaire d’avoir
une certificat signé par Microsoft pour pouvoir charger un driver sur un système 64 bits.
Pour résoudre ce problème, il est nécessaire d’utiliser une méthode légitime pour détourner
le flux d’exécution. Cette nouvelle solution modifie toujours le flux d’exécution du système sans
pour autant altérer les tables système. Ce modèle est celui préconisé par Microsoft pour détourner
le flux d’exécution. Il se base sur la mise en place de différents driver : les filter-driver et les Kernel
Callback. Cette méthode a été décrite dans la partie C.3 (en Annexe).
5.2.2.1 Architecture globale
La figure 5.5 décrit la nouvelle architecture logicielle que nous avons mise en place. Cette nouvelle
solution se base sur la création de trois nouveaux composants tout en conservant les éléments
clés de l’architecture que nous avons décrite dans la partie 5.2.1. L’architecture de contrôle d’accès
1425.2. IMPLANTATION DES MÉCANISMES DE CONTRÔLE D’ACCÈS OBLIGATOIRE
globale n’est en rien modifiée. Le serveur de sécurité est toujours en charge d’appliquer strictement
la politique de contrôle d’accès définie. Un processus de labellisation transforme les sujets
et les objets pour leur associer des contextes de sécurité basés sur leur chemin complet. La partie
traçabilité est conservée pour assurer des fichiers d’audit consistants détaillant avec précision les
interactions passées sur le système.
Les modifications interviennent au niveau du détournement du flux d’exécution du système.
Comme nous l’avons expliqué en introduction de cette partie, notre première implantation n’est
pas pérenne par rapport à la politique de Microsoft mais surtout elle n’est pas portable sur les
systèmes 64 bits. Les modifications introduites dans cette nouvelle architecture ont pour but de
respecter les critères de développement et de surveillance édictés par Microsoft.
Nous avons donc une architecture de détournement des flux d’exécution du système divisée
en trois composants principaux. Nous détaillerons plus la partie système que la partie réseau dans
cette section. La raison est que la partie réseau est similaire dans la conception à la méthode utilisée
par les filter-driver pour les entrées/sorties sur le système de fichiers.
Le premier composant de notre solution est un filter-driver qui gère les requêtes d’entrée/sortie
sur le système de fichiers. De part son design spécifique, il n’est pas capable de gérer d’autres
aspects du système, néanmoins, il offre la possibilité de pouvoir réaliser des traitements en pré-
traitement et post-traitement. Ce filter-driver est géré par un composant du système nommé le
gestionnaire d’entrée/sortie auprès duquel il est nécessaire de s’enregistrer.
Le second composant est un driver filtrant les interactions sur le registre. Il est lui aussi capable
de faire des contrôles en prétraitement et en post-traitement. Il s’enregistre auprès du gestionnaire
d’entrée/sortie spécifique au registre.
Le troisième composant est un driver capable de contrôler le chargement et le déchargement
de fichiers. Il peut ainsi contrôler le chargement des exécutables, mais aussi des bibliothèques ainsi
que des driver. Il est aussi notifié de la mort d’un processus.
Filter Manager
Frame 1
Filter Manager
Frame 0
FS Filter
No altitude
Action d’un processus
sur le système de fichiers
Espace noyau
Espace utilisateur
Action d’un processus
sur le registre
Action d’un processus
pour créer un nouveau processus
Registry Manager I/O Manager Process Manager
Driver de stockage
Registre
Filter Process Driver
Filter Driver
Registry Filter Driver
Driver
SEWindows
FIGURE 5.5 – Architecture de détournement basée sur l’utilisation de filter-driver et de kernel
callback
5.2.2.2 Détournement des flux d’exécution
Détournement des interactions d’entrée/sortie Une limite du détournement des appels système
par la modification de la SSDT est l’impossibilité de contrôler les interactions réalisées par
les driver. En effet, la SSDT est essentiellement utilisée par les processus, qui résident en espace
1435.3. EXPÉRIMENTATIONS
utilisateur. Or, les driver n’utilisent pas les fonctions de la table des appels système pour réaliser
des interactions sur le système.
Grâce à l’utilisation des filter-driver qui catégorisent les interactions sur le système de fichiers
au lieu de détourner juste un appel système, il est aussi possible de contrôler les interactions faites
par les driver. En effet, lorsqu’un driver utilise des fonctions comme ZwCreateFile ou IoCreateFile,
le système convertit ces fonctions en IRP pour être traitées par les filter-driver.
La description de cette méthode a été faite dans la partie C.3. Nous allons juste reprendre
quelques points importants.
Les filter-driver sont rangés grâce à un système d’altitude. Cette altitude détermine l’ordre
de traitement des requêtes. Plus un filter-driver aura une altitude haute, c’est-à-dire proche du
noyau, plus il recevra la requête tôt dans la phase de prétraitement. À l’inverse, dans la phase
de post-traitement, il sera parmi les derniers à recevoir la requête. Donc la place choisie pour le
filter-driver est très importante. Nous avons choisi comme altitude 360 000, qui est une altitude
préconisée par Microsoft pour la catégorie de filter-driver que nous faisons.
Détournement des interactions sur le registre Les accès au registre passent par un gestionnaire
d’entrée/sortie spécifique au registre. Pour contrôler les accès qui y sont fait, il est possible
d’enregistrer un driver auprès de ce gestionnaire en utilisant le mécanisme de Registry Callback.
Grâce à cet enregistrement, le driver est capable de contrôler toutes les interactions sur le
registre sans avoir à préciser les interactions qu’il désire traiter. Comme pour les filter-driver, le
contrôle se fait en pré et post traitement.
Détournement des interactions de chargement et de déchargement des fichiers Les chargements
des fichiers exécutables sont traités spécifiquement par le noyau Windows. Mais il est aussi
possible pour un driver de contrôler le chargement de ces fichiers qui sont les plus dangereux pour
le système puisqu’ils sont exécutés en espace noyau.
Le noyau Windows propose ainsi des routines de notification pour contrôler les créations de
processus, le chargement de bibliothèques mais aussi de driver, appelées Process Notify Routine.
Ces routines renseignent sur le nom du nouveau processus ainsi que sur son PID mais aussi sur le
PPID. Il est ainsi possible de contrôler le chargement des fichiers exécutables.
Ces routines du noyau Windows renseignent aussi sur la mort d’un processus. Il n’est par
contre pas possible de contrôler la mort d’un processus mais la notification offre la possibilité de
l’inscrire dans un fichier d’audit.
Détournement des interactions sur le réseau Le détournement des interactions effectuées sur
le réseau s’effectue par l’utilisation de la Windows Filtering Platform. Cette plateforme mise en
place par Microsoft est similaire à celle des filter-driver. Grâce à l’utilisation des API que la
plateforme fournie, il est possible de contrôler les interactions au niveau du réseau.
5.3 Expérimentations
Dans cette section, nous allons détailler les expérimentations réalisées grâce à notre moniteur
pour Windows. Nous avons séparé cette section en deux parties distinctes. La première partie traite
des expérimentations réalisées grâce à notre première implantation de SEWINDOWS basée sur le
modèle DTE. Ces expérimentations nous ont permis de 1) générer des politiques ainsi que des
file_context pour les systèmes d’exploitation Windows, 2) valider notre modèle de politique
et 3) valider l’implantation que nous avons faite. Nous avons pour cela mis en place des scénarios
d’attaque, basés dans un premier temps sur des interactions directes, c’est-à-dire des interactions
1445.3. EXPÉRIMENTATIONS
directes d’un sujet sur un objet, puis sur des scénarios complets avec des flux indirects en ajoutant
PIGA à l’architecture de protection.
Dans une seconde partie, nous détaillons les expérimentations faites à partir de la seconde
implantation de notre mécanisme de contrôle d’accès basée sur les filter-driver. Dans le but de
générer des propriétés de sécurité et des configurations de mécanisme de contrôle d’accès pouvant
contrer des menaces réelles, nous avons mis en place une architecture spécifique pour incorporer
notre filter-driver au sein d’un mécanisme d’étude de logiciels malveillants (sandbox). En exécutant
plusieurs logiciels malveillants et en étudiant les traces générées, nous allons écrire des règles
de contrôle d’accès ainsi que des propriétés de sécurité pour PIGA afin de contrer explicitement
ces comportements.
5.3.1 Violation d’une propriété de confidentialité
Dans cette partie, nous présentons les expérimentations réalisées grâce à notre mécanisme de
contrôle d’accès. Nos expérimentations ne portent que sur l’implantation du modèle de protection
DTE car nous voulons être en mesure d’exprimer des propriétés de sécurité grâce à PIGA.
Pour pouvoir exprimer ces propriétés de sécurité, PIGA utilise de façon préférentielle un fichier
contenant les contextes de sécurité objets et d’une politique basée sur les types.
5.3.1.1 Environnement des expérimentations
Introduction Pour pouvoir réaliser nos expérimentations, nous avons dû définir une politique de
contrôle d’accès autorisant le fonctionnement des programmes que nous voulions tester. Pour ce
faire, nous avons utilisé le mode apprentissage de notre moniteur pour générer les politiques, c’est-
à-dire que nous avions placé notre driver en mode évidence. Nous avons aussi utilisé la méthode
automatique, c’est-à-dire que nous avons utilisé notre outil transformant les traces générés en
règles de contrôle d’accès, tout en vérifiant qu’il n’y avait pas de règles illégitimes qui pourraient
fausser nos expérimentations.
Plateforme Nous avons réalisé nos expérimentations dans une machine virtuelle avec un Windows
7 32 bits. Le driver SEWINDOWS était en mode apprentissage et nous avons fait des opérations
légitimes sur la machine : exécution de Windows Media Player, Firefox, Opera,
etc. Il est nécessaire de définir précisément les opérations que l’on souhaite autoriser par la suite.
Cette planification se fait généralement à la main par l’utilisation d’une check-list.
Il faut bien évidemment refaire plusieurs fois les exécutions pour être sûr de n’avoir pas oublié
de règles nécessaires au bon fonctionnement des applications. Une fois cette phase d’apprentissage
terminée, nous disposions d’une politique suffisante pour que les applications puissent fonctionner
correctement, même avec notre moniteur en mode protection.
La politique générée est suffisante pour un fonctionnement normal du système d’exploitation,
c’est-à-dire que nous sommes capables de réaliser certaines tâches définies sans que le driver
SEWINDOWS ne les bloque. Nous obtenons donc une politique SEWINDOWS avec environ 5000
règles d’accès et 40 000 contextes de sécurité.
La table 5.6 récapitule les informations sur la politique.
Nombre de contextes de sécurité objets 40 000
Nombre de contextes de sécurité sujets 1 800
Nombre d’interactions 5 000
FIGURE 5.6 – Statistiques sur la politique de contrôle d’accès pour le premier scénario
1455.3. EXPÉRIMENTATIONS
5.3.1.2 Scénario des attaques
Nous détaillons deux scénarios d’attaque pour montrer l’efficacité de notre solution. Le premier
propose une attaque "simple" qui repose sur un scénario joué volontairement par l’utilisateur.
Il essaye de contourner la politique de contrôle d’accès par une interaction directe. Le second
scénario est plus réaliste puisqu’il utilise des flux indirects autorisés par SEWINDOWS.
Nous montrons dans le premier cas, qui correspond à un flux d’information direct, que notre
moniteur est capable de l’interdire. A contrario, nous montrerons, dans le second cas qui résultat
d’un flux d’information indirect, que notre moniteur, même s’il est capable de voir l’ensemble des
interactions directes, n’est pas capable de bloquer la violation de propriété. Il est donc nécessaire
d’utiliser un second moniteur pour détecter ce genre de violation.
5.3.1.3 Violation directe
Dans notre premier exemple, nous avons un utilisateur qui tente de lire le
contenu d’un dossier auquel il n’a pas accès en passant par un navigateur Internet.
Ce refus se traduit par la trace suivante listée en listing 5.17. Elle montre
que le sujet ayant pour contexte de sécurité system_u:system_r:firefox_t
veut lire (read) et traverser (execute) le dossier ayant pour contexte de sécurité
system_u:object_r:systemdrive|users|ensib|appdata|roaming|opera|opera_dir_t
✞ ☎
1 type=DTE audit(129320375967434054:683)
2 avc:denied { execute read } for pid=1756 comm="%programfiles%\mozilla
3 firefox\firefox.exe" ppid=1456
4 path="%systemdrive%\users\ensib\appdata\roaming\opera\opera"
5 scontext=system_u:system_r:firefox_t
6 tcontext=system_u:object_r:systemdrive|users|ensib|appdata|roaming|opera|
opera_dir_t
7 tclass=dir
✝ ✆
Listing 5.17 – Trace d’interdiction pour Firefox de lire le contenu du dossier d’Opera
5.3.1.4 Violation indirecte
Ce second scénario propose de reprendre l’attaque qui vise à enfreindre la confidentialité que
l’on veut imposer entre nos deux navigateurs Firefox et Opera. Dans cette attaque, nous allons
essayer de contourner la politique de contrôle d’accès en utilisant une suite d’interactions légitimes
au système vis-à-vis de SEWINDOWS.
Via des propriétés de sécurité comme la confidentialité, PIGA est capable de détecter des
violations indirectes de la confidentialité.
Le listing 5.18 montre la définition d’une propriété de confidentialité entre deux contextes de
sécurité. Cette propriété spécifie qu’il ne doit y avoir aucun flux d’information entre le contexte de
sécurité objet et le contexte de sécurité sujet. C’est pourquoi, dans notre propriété de confidentialité,
nous interdisons les flux d’information indirects représentés par le symbole >>, allant de sc2
vers sc1.
✞ ☎
1 define confidentiality( $sc1 IN SCS , $sc2 IN SCO )
2 ST { $sc2 >> $sc1 } , { not(exist ( ) ) } ;
✝ ✆
Listing 5.18 – Définition de la propriété de confidentialité
Nous l’appliquons entre les navigateurs Firefox et Opera. Pour contrôler les flux entre les
deux navigateurs, il est nécessaire d’écrire les deux propriétés de confidentialité comme le montre
le listing 5.19.
1465.3. EXPÉRIMENTATIONS
✞ ☎
1 confidentiality( $sc1: =".*:.*:opera_t" ,$sc2: =".*:.*:firefox_t" ) ;
2 confidentiality( $sc1: =".*:.*:firefox_t" ,$sc2: =".*:.*:opera_t" ) ;
✝ ✆
Listing 5.19 – Application de la propriété de confidentialité
En rejouant des traces générées par notre driver SEWINDOWS dans PIGA et en appliquant la
propriété de sécurité définie au listing 5.19, nous détectons un flux d’information entre Firefox
et Opera. Ce transfert d’informations réussit grâce à l’utilisation d’un logiciel tiers, ici Adobe.
Le listing 5.20 montre une détection faite par PIGA. Nous avons Firefox qui écrit un fichier
à la racine du système. Puis Adobe qui lit le contenu du fichier pour aller ensuite écrire un nouveau
fichier dans le répertoire d’Opera qui va finir par le lire.
✞ ☎
1 system_u : system_r : firefox_t −( file { create write } )−>system_u : object_r :
systemroot_file_t ;
2 system_u : system_r : adobe_t −( file { execute read } )−> system_u : object_r :
systemroot_file_t ;
3 system_u : system_r : adobe_t −( dir { create setattr unlink } )−> user_u : object_r :
systemdrive | user | bob | AppData | Local | opera_dir_t ;
4 system_u : system_r : opera_t −( file { execute getattr read } )−> system_u : object_r :
systemdrive | user | bob | AppData | Local | opera_file_t ;
✝ ✆
Listing 5.20 – Trace d’un flux indirect de Firefox vers Opera
La détection faite par PIGA pouvant être difficile à lire, nous proposons une illustration 5.7
qui montre le cheminement de l’attaque. Firefox écrit dans un fichier (flèche 1). Ce fichier est
lu par Adobe (flèche 2). Adode écrit dans un second fichier, qui est dans le répertoire visé par
l’attaque (i.e : le répertoire d’Opera). Enfin Opera lit le contenu de ce fichier.
Firefox
Fichier 1 Adobem
Fichier 2 Opera
3 : Ecrit
2 : Lit
1 : Ecrit
4 : Lit
FIGURE 5.7 – Schéma du flux indirect conduisant à la violation de la propriété de confidentialité
Nous obtenons donc un flux d’information indirect entre les deux navigateurs, obtenu grâce à
un programme intermédiaire, ici Adobe Reader.
5.3.2 Étude de logiciels malveillants
5.3.2.1 Introduction
Dans cette partie, nous développons les tests que nous avons réalisés sur une architecture
spécifique que nous avons mise en place. Ces tests se sont orientés sur l’analyse de logiciels malveillants.
Dans cette configuration, nous avons dû mettre en place une solution pour assurer l’intégrité
des fichiers d’audit que nous récupérons lors de l’exécution du logiciel malveillant. Cette
solution consiste à envoyer les traces générées par le moniteur à un serveur de sécurité.
Les expérimentations que nous avons faites ont été réalisées en machine virtuelle et nous décrivons
dans cette partie les protocoles qui ont été appliqués sur deux types de logiciels malveillants.
Nous avons mis en place des outils facilitant la lecture des traces générées dans le but de comprendre
l’impact du logiciel malveillant sur le système et pour connaître les fichiers contaminés.
1475.3. EXPÉRIMENTATIONS
Ces outils offrent une représentation textuelle et graphique des résultats ce qui facilite la compré-
hension des mécanismes d’installation du logiciel malveillant.
En plus de ces outils de visualisation, nous proposons des méthodes pour dériver une politique
de contrôle d’accès pour SEWINDOWS à partir des traces générées. Ces politiques empêchent
l’installation de ce type de logiciel malveillant en traitant les interactions directes entre les sujets
et les objets du système. Cependant, comme ces politiques empêchent les interactions illégitimes,
nous proposons aussi des outils pour en dériver des propriétés de sécurité qui pourront être appliquées
par PIGA.
Exécution d’un logiciel malveillant
Ce premier scénario propose l’exécution d’un logiciel malveillant plutôt basique. En utilisant
le mode détection de notre mécanisme, nous montrerons les comportements clés du logiciel malveillant.
Nous avons commencé par étudier un FakeAV dont l’analyse par VirusTotal se trouve
ici 1
.
Comme le binaire n’est pas présent dans la politique nous avons mis notre driver SEWINDOWS
en mode détection pour dérouler l’installation du logiciel malveillant et nous montrerons des points
clés dans son installation que notre mécanisme de contrôle d’accès est capable de bloquer.
Le premier point important est le moment où le logiciel malveillant est exécuté. Cela se traduit
par le chargement (load) du binaire par explorer.exe. Cette trace est retranscrite par
notre driver SEWINDOWS dans le listing 5.21. Nous avons volontairement renommé le logiciel
malveillant en malware pour pouvoir plus facilement suivre son évolution dans les traces. Le
logiciel malveillant est exécuté par nos soins.
✞ ☎
1 type=DTE audit(129676508858814710,43) avc:denied { execute } for pid=308
2 com="%systemroot%\explorer.exe" ppid=360
3 path="%systemdrive%\users\bob\desktop\malware.exe"
4 scontext=system_u:system_r:explorer_t
5 tcontext=system_u:object_r:systemdrive|users|bob|desktop|malware_exec_t
6 tclass=load
✝ ✆
Listing 5.21 – Chargement du logiciel malveillant par explorer.exe
Ensuite, le logiciel malveillant va exécuter un invite de commande comme le montre le listing
5.22.
✞ ☎
1 type=DTE audit(129676508874908460,159) avc:denied { execute } for pid=3376
2 com="%systemdrive%\users\bob\desktop\malware.exe" ppid=308
3 path="%systemroot%\system32\cmd.exe" scontext=system_u:system_r:malware_t
4 tcontext=system_u:object_r:systemroot|system32|cmd_exec_t tclass=load
✝ ✆
Listing 5.22 – Exécution du premier invite de commande par le logiciel malveillant
Ce premier invite de commande exécute un second invite de commande et écrit un nouveau
fichier qui se nomme script.bat. 5.23.
✞ ☎
1 type=DTE audit(129676508874908460,171) avc:denied { execute } for
2 pid=2628 com="%systemroot%\system32\cmd.exe" ppid=3376
3 path="%systemroot%\system32\cmd.exe" scontext=system_u:system_r:cmd_t
4 tcontext=system_u:object_r:systemroot|system32|cmd_exec_t tclass=load
5
6 type=DTE audit(129676508875064710,177) avc:denied { write } for pid=3376
7 com="%systemdrive%\users\bob\desktop\malware.exe" ppid=308
8 path="%systemdrive%\users\bob\desktop\script.bat"
1. https://www.virustotal.com/en/file/d0d0d53f66b400cb43b3019be9e5e49a9097458119eba8f18d27d9e7b4ac8d9b/
analysis/
1485.3. EXPÉRIMENTATIONS
9 scontext=system_u:system_r:malware_t
10 tcontext=system_u:object_r:systemdrive|users|bob|desktop|script_bat_t
11 tclass=file
✝ ✆
Listing 5.23 – Exécution d’un second invite de commande et écriture du script
Enfin, le second invite de commande va lire le contenu du script pour exécuter les commandes
qui sont à l’intérieur. 5.24.
✞ ☎
1 type=DTE audit(129676508875689710,221) avc:denied { read } for pid=2832
2 com="%systemroot%\system32\cmd.exe" ppid=2628
3 path="%systemdrive%\users\bob\desktop\script.bat"
4 scontext=system_u:system_r:cmd_t
5 tcontext=system_u:object_r:systemdrive|users|bob|desktop|script_bat_t
6 tclass=file
✝ ✆
Listing 5.24 – Lecture du script par le second invite de commande
Grâce à la précision des fichiers d’audit, nous pouvons facilement suivre l’évolution de ce logiciel
malveillant sur le système. Il nous est facile de suivre les relations de filiation grâce notamment
aux PID et aux PPID.
À travers l’étude des traces générées par notre moniteur, nous avons pu suivre l’évolution de
l’installation du logiciel malveillant. Nous ne montrons pas tous les éléments de cette infection,
mais nous pouvons bloquer une par une les interactions réalisées par le logiciel.
Ce scénario, entièrement joué puisque le moniteur est en mode détection, est un cas concret
d’exécution du logiciel malveillant par un navigateur soumis à une attaque.
5.3.2.2 Architecture décentralisée
À partir de l’implantation du mécanisme de contrôle d’accès basée sur les filter-driver et les
kernel callback, nous avons mis en place une architecture spécifique permettant d’analyser les
logiciels malveillants. L’objectif de ces expérimentations est d’exécuter les logiciels malveillants
sans bloquer leurs interactions dans le but de connaître leur impact sur le système entier et d’en
étudier leur comportement.
Comme notre driver est en mode détection pour ces études, il enregistre chaque interaction
effectuée sur le système. De plus, pour être sûr de ne pas rater d’interaction, il n’y a pas de politique
de contrôle d’accès. Cependant, le logiciel malveillant pourrait modifier le contenu du fichier
d’audit, voire le supprimer puisqu’il est stocké sur le système et que les interactions ne sont pas
bloquées par le moniteur. Pour éviter d’avoir des fichiers d’audit potentiellement modifiés par le
logiciel malveillant, nous avons décidé d’envoyer directement les traces sur un serveur de sécurité
distant.
Instrumentation du système La figure 5.8 représente notre nouvelle architecture du côté du
Windows instrumenté. Cette architecture est divisée en quatre parties distinctes.
Le premier bloc traite les accès au système de fichiers. Lorsqu’une interaction est réalisée
sur le système de fichiers, l’interaction est interceptée lors de son prétraitement par notre filterdriver
(flèche 1, 2, 3). Le filter-driver est chargé de construire une trace suffisamment précise pour
pouvoir avoir toutes les informations nécessaires à l’étude du logiciel. De plus, pour avoir une
chronologie des différentes interactions réalisées, nous ajoutons un identifiant unique pour chaque
interaction ainsi qu’un timestamp. Nous obtenons ainsi une trace contenant :
1. un numéro de trace unique, ainsi que le numéro du cœur processeur qui exécute l’action ;
2. un timestamp ;
1495.3. EXPÉRIMENTATIONS
FIGURE 5.8 – Instrumentation du système pour l’analyse de logiciel malveillant
3. le type d’accès ;
4. nom court du processus qui a fait l’action et PID ;
5. nom de l’objet.
Dans le but de ne pas faire de calcul intempestif sur la machine d’étude, nous ne calculons pas
de contexte de sécurité. Cette tâche sera faite par le serveur de sécurité dans un mode offline. Un
exemple de trace générée est illustré par le listing 5.25. Cette trace est ensuite envoyée (flèche 4)
au thread qui s’occupe de la communication avec le serveur de sécurité.
✞ ☎
1 trace=1118 , cpu=0
2 timestamp=130208621983766250
3 Access : create
4 pid : consent.exe 568
5 Object Name : \Device\HarddiskVolume2\Users\toto\AppData\LocalLow
✝ ✆
Listing 5.25 – Trace générée par le filter-driver pour une interaction sur le système de fichiers
Le second bloc traite de la gestion de processus. À chaque création ou mort d’un processus, un
thread du filter-driver enregistre certaines informations. Il doit récupérer les noms complets des
processus impliqués, c’est-à-dire du père et du fils, ainsi que leur PID (flèche 5.1 et flèche 5.2). Une
fois que ces informations sont enregistrées, la trace générée pour la création d’un processus 5.26
est envoyée au thread qui s’occupe de la communication avec le serveur de sécurité. La même
chose est faite pour la mort d’un processus 5.27. Nous ne datons pas ces traces car ce n’est pas
nécessaire. Nous nous servons de ces traces pour connaître les chemins complets ainsi que les PID
des processus créés et détruits.
✞ ☎
1 Parent Process name : \Device\HarddiskVolume2\Windows\System32\svchost.exe pid
=908
2 Process name : \Device\HarddiskVolume2\Windows\System32\consent.exe pid=568
ppid=908 sid=1
✝ ✆
Listing 5.26 – Trace générée par le filter-driver pour la création d’un processus
1505.3. EXPÉRIMENTATIONS
✞ ☎
1 Parent Process name : \Device\HarddiskVolume2\Windows\System32\svchost.exe pid
=908
2 Process name : \Device\HarddiskVolume2\Windows\System32\consent.exe pid=568
ppid=908 sid=1
✝ ✆
Listing 5.27 – Trace générée par le filter-driver pour la mort d’un processus
Le troisième bloc de l’architecture concerne la gestion du registre. Tout comme pour le système
de fichiers, nous n’interceptons que les requêtes en prétraitement. Lorsqu’un processus fait une interaction
sur le registre, elle est interceptée (flèche 6) par le gestionnaire de registre puis transmise
(flèche 7) à notre driver. Le Registry Filter Driver récupère toutes les informations nécessaires à
la compréhension de l’interaction. Il ajoute aussi un identifiant unique ainsi qu’un timestamp. La
trace construite est très proche de la trace générée pour le système de fichiers. Mais, en plus des
informations de type nom du processus ainsi que son PID et nom de l’objet, qui dans ce cas la correspond
à une clé registre, nous ajoutons le couple valeur et donnée dans la trace, pour connaître
précisément les interactions du logiciel étudié. Nous obtenons ainsi une trace complète, comme le
montre le listing 5.28, qui est envoyée au thread qui s’occupe de la communication avec le serveur
de sécurité.
✞ ☎
1 trace=2258 , cpu=0
2 timestamp=130257368578773750
3 Access : set_value_key
4 pid : explorer.exe 1644
5 \REGISTRY\USER\S-1-5-21-2571257828-2288546103-543878076-1001\Software\Microsoft
\Windows\CurrentVersion\Explorer\UserAssist\{CEBFF5CD-ACE2-4F4F-9178-9926
F41749EA}\Count
6 {Q65231O0-O2S1-4857-N4PR-N8R7P6RN7Q27}\pzq.rkr REG_BINARY :
00000000250000008001000095CA5300000080BF000080BF000080BF000080BF
7 000080
BF000080BF000080BF000080BF000080BF000080BFFFFFFFFFC0B06AEB62C4CE0100000000
✝ ✆
Listing 5.28 – Trace générée par le driver pour une interaction sur le registre
Enfin, le quatrième bloc est celui qui gère les communications avec le serveur de sécurité.
L’implantation choisie sur le système instrumenté doit assurer deux règles importantes : la première
règle est que les communications avec le serveur de sécurité distant doivent être assurées
par un module dédié de l’architecture pour ne pas interférer avec le reste du mécanisme. Pour cela,
nous utilisons un thread dédié qui ne s’occupera que des communications réseau. La seconde règle
impose que cette communication ne doit ni ralentir, ni bloquer le fonctionnement de la machine.
Pour cela, nous avons choisi une implantation basée sur le principe de producteur/consommateur.
Les producteurs sont les trois parties précédemment présentées. Elles approvisionnent une
file de messages sans attendre que le message soit envoyé. Ainsi, elles n’ont pas besoin d’attendre
un retour de la part du thread qui envoie les traces et elles ne bloquent donc pas les interactions.
Le consommateur est par conséquent le thread qui récupère les traces et les envoie au serveur de
sécurité.
Les communications sont réalisées sur une connexion TCP.
Nous noterons une chose importante. Nous avons ajouté dans les traces traitant les interactions
du système de fichiers et du registre, un identifiant unique ainsi qu’un timestamp. Il est indispensable
pour la compréhension de l’installation de l’infection que cet identifiant soit unique pour tout
le système. Il est donc partagé entre les différentes parties de notre architecture.
1515.3. EXPÉRIMENTATIONS
De plus, comme nous le montrons dans les traces, nous n’enregistrons que le nom court des
processus. Ce nom est récupéré grâce à la fonction ZwQueryInformationProcess. Elle va
lire un champ de la structure EPROCESS 2
.
Une étape importante est donc réalisée au moment du démarrage du driver. Lors de cette étape,
il va établir la liste des processus qui sont en cours de fonctionnement en recherchant, quand c’est
possible, le père de chaque processus. En effet, sous Windows, il est possible qu’un processus n’ait
pas de père (à la différence des systèmes Linux où les processus sont toujours au moins rattachés à
init). Nous obtenons ainsi un graphe de l’activité courante du système. Cela nous permet aussi
de connaître les chemins complets ainsi que les PID des processus qui sont lancés au moment où
nous exécutons le logiciel étudié.
Serveur de sécurité distant Le serveur de sécurité est divisé en deux parties : la première partie
est un serveur TCP, fait en python, qui récupère les traces envoyées par le driver pour les mettre
dans une base de données. Comme le nombre de traces est relativement grand, la mise en base
est faite de manière offline pour ne pas surcharger la machine. La seconde partie permet la visualisation
des résultats. Elle propose la génération de rapport présentant les activités qui se sont
déroulées sur le système étudié.
5.3.2.3 Protocoles des expérimentations
Plateforme Nous avons fait le choix d’instrumenter un Windows 7 32 bits. Même si cette nouvelle
implantation nous permet de tester sur les architectures 64 bits, il est nécessaire de signer
le driver avec un certificat émis par une autorité reconnue par Microsoft pour que le Kernel
Patch Protection l’autorise à se charger. Il existe cependant un mode appelé testsigning qui permet
d’auto-signer son driver avec un certificat que nous aurions créé. Néanmoins, dans ce mode, Kernel
Patch Protection ne vérifie plus que la validité de la signature, ce qui modifie le comportement
du système. Si un logiciel malveillant charge un driver auto-signé, il ne sera pas bloqué par les
protections natives du système.
Ces tests ont été réalisés dans une machine virtuelle pour bénéficier de la possibilité de faire
des instantanés des machines et ainsi éviter de les réinstaller entre chaque étude. De plus, cela nous
permet de connaître parfaitement l’état de départ de la machine qui sert pour les tests.
Le serveur de sécurité est une machine capable de faire fonctionner un serveur web ainsi que
des scripts pythons, dans notre cas, un système Linux.
Exécution des logiciels malveillants Les logiciels malveillants étudiés sont téléchargés directement
sur la machine.
Les logiciels malveillants ont besoin d’être exécutés à la main car il faut pouvoir autoriser
son exécution si une demande d’élévation des privilèges est demandée. Cette manipulation nous
permet à la fois de connaître le nom du binaire qui est exécuté mais aussi de savoir comment il doit
être lancé. Nous savons par cette manipulation que le processus, qui lance le logiciel malveillant,
est explorer.exe. Cette information facilite le traitement des résultats.
Une fois que le logiciel malveillant est installé, nous laissons l’infection se développer sur
le système. Il est parfois nécessaire que valider des opérations intermédiaires à cause de l’User
Access Control. Nous acceptons à chaque fois les demandes faites par l’User Access Control.
Nous avons fait le choix de ne pas désactiver l’User Access Control car cette désactivation
fausserait aussi l’étude. En effet, lorsque cette protection n’est plus activée, des mécanismes de
2. EPROCESS est une structure du noyau de Windows contenant les informations sur les processus (nom, PID,
thread, etc). Cette structure est opaque, c’est-à-dire qu’il est nécessaire d’utiliser une fonction pour récupérer des informations
dans les champs de structure
1525.3. EXPÉRIMENTATIONS
sécurité ne sont plus appliqués. Par exemple, il n’y a plus de vérification des niveaux d’intégrité
lorsqu’un sujet effectue une interaction sur un objet.
Serveur de sécurité Une fois que l’utilisateur considère que l’exécution est terminée, le serveur
de sécurité met dans une base de données les informations recueillies par le driver pour les
conserver et les comparer aux autres études. Il génère ensuite les résultats pour qu’ils puissent être
analysés.
5.3.2.4 Visualisation des résultats et définition des propriétés de sécurité
Une fois le logiciel malveillant exécuté, il faut pouvoir fournir des résultats pertinents, c’est-
à-dire des résultats qui permettent de comprendre le cheminement de l’infection : nous ciblerons
donc les interactions spécifiques au logiciel malveillant qui permettent la propagation de l’infection
au sein du système.
Pour ce faire, nous proposons un outil graphique générant les résultats sous la forme d’un
graphe. Ce graphe est une représentation du système ayant pour nœud les processus et comme
feuilles les interactions réalisées ainsi que les objets. Nous proposons aussi un outil qui extrait les
interactions directes sous la forme d’automates. Ces automates sont des sous graphes, qui repré-
sentent une partie du comportement du logiciel malveillant étudié. À partir de ce sous graphe, il
nous est possible d’écrire des règles de contrôles d’accès empêchant le déploiement de l’infection,
mais aussi des propriétés de sécurité qui peuvent être vérifiées et appliquées par PIGA.
Visualisation
Pour comprendre le cheminement utilisé par l’infection, nous présentons les résultats sous une
forme brute. Dans une première partie, nous listons les processus ainsi que leurs parents.
Associées à ces processus, il est possible de connaître toutes les interactions directes générées
sur le système par ce processus sans aucun filtre. Cette première visualisation permet de connaître
l’activité complète du processus (fichier créé, supprimé, processus lancé, clé registre modifiée,
etc.). Cette forme est une forme brute des traces générées, triées par ordre temporaire.
Dans le but de mieux comprendre les interactions passées sur la machine d’analyse, il est
nécessaire de travailler les résultats. La première chose est de visualiser quelques interactions
précises.
Nous avons choisi d’isoler pour la partie système de fichiers :
— les chargements,
— écriture et suppression.
Ce choix est motivé par le fait que nous voulons suivre la propagation de l’infection au sein du
système et ainsi connaître les éléments qui ont été infectés. Donc nous isolons les interactions qui
permettent d’échanger de l’information depuis un processus infecté vers un objet du système.
Ce modèle n’est pas figé. En rajoutant par exemple, les opérations élémentaires de lecture,
nous pouvons détecter les fuites d’information ou les violations de confidentialité.
Nous allons détailler nos résultats sur l’analyse d’un logiciel malveillant appelé ZeroAccess.
Ce malware est celui que nous avons utilisé dans notre introduction 1.3. Nous allons chercher
à comprendre son comportement lors de son installation pour en extraire les règles de contrôle
d’accès nécessaires pour empêcher sa propagation au sein du système.
Génération du graphe des processus La représentation sous la forme d’un graphe nous permet
de connaître quelques interactions spécifiques. La figure 5.9 montre le premier résultat obtenu. À
partir du fichier de l’infection nommé xxx-porn-movie.avi.exe, nous remarquons qu’il va
1535.3. EXPÉRIMENTATIONS
écrire des fichiers dans la corbeille de Windows qui se nomme Recycler.Bin. On peut tout
d’abord noter que le logiciel malveillant veut se cacher en utilisant une double extension, pour
tromper l’utilisateur en lui faisant croire que c’est une vidéo dans le but qu’il exécute le fichier
binaire.
FIGURE 5.9 – Logiciel malveillant écrivant des fichiers dans la corbeille de Windows
Le graphe nous montre un lien entre notre fichier principal de l’infection et un processus qui
semble légitime nommé InstallFlashPlayer.exe. Nous pouvons voir que ce fichier a été
écrit par l’infection. En effet, en extrayant les parties write et load du graphe pour le processus
xxx-porn-movie.avi.exe, nous pouvons voir que c’est l’infection qui écrit et charge ce
fichier.
La figure 5.10 nous montre une partie des interactions faites par le processus
InstallFlashPlayer.exe qui vient d’être exécuté par le logiciel malveillant. Nous pouvons
voir que celui-ci va aussi écrire dans la corbeille de Windows.
Enfin, la figure 5.11 nous montre que c’est le processus services.exe qui va charger les
fichiers qui ont été écrits par les deux processus malveillants. C’est à ce moment là que la charge
active du logiciel malveillant est exécutée. L’exécution, par un service système, de cette charge,
assure à l’infection la possibilité de pouvoir réaliser toutes les interactions qu’elle désire.
Dans cette étude, nous pouvons noter plusieurs points : tout d’abord, la dissimulation de la
véritable extension par le logiciel malveillant dans le but de tromper l’utilisateur. Cette technique
est assez courante pour installer des logiciels malveillants. Ensuite, l’utilisation d’un logiciel lé-
gitime pour installer la charge active de l’infection qui est aussi une méthode pour se cacher aux
yeux de l’utilisateur. Ici, le logiciel malveillant peut justifier l’installation par nécessité pour lire la
vidéo. Nous notons aussi l’utilisation d’un répertoire temporaire, ici la Corbeille, pour l’écriture
des fichiers utilisés pour exécuter la charge active. Enfin, nous voyons l’utilisation de processus lé-
gitime, présent sur tous les systèmes Windows et tournant avec des privilèges élevés pour installer
la charge active.
1545.3. EXPÉRIMENTATIONS
FIGURE 5.10 – Flash player écrit dans la Corbeille de Windows
FIGURE 5.11 – services.exe chargeant les fichiers écrits par les logiciels malveillants.
Nous nous sommes intéressés uniquement à l’étude de l’installation de l’infection, pour
connaître son cheminement et les fichiers qui ont été contaminés par l’infection.
1555.3. EXPÉRIMENTATIONS
Cette représentation permet de voir les liens entre les différentes entités du système ainsi que
de connaître les interactions réalisées par chaque processus au moment de l’étude. Néanmoins,
elle ne permet pas de tout représenter. En effet, dans un souci de clarté pour la représentation,
nous avons fait le choix de ne pas y inclure toutes les interactions des processus ni les éléments du
registre. De plus, cette représentation nous fait perdre la notion de temporalité des interactions.
Il faut noter que cette première représentation est suffisante pour comprendre le comportement
global de l’infection et établir des règles de contrôle d’accès permettant de contrer explicitement
son installation. Mais pour comprendre tout le cheminement de l’installation, il est nécessaire
d’ajouter la notion de temps pour situer les interactions les unes par rapport aux autres.
Automates
La représentation des traces sous la forme d’automates nous permet d’exprimer la notion de
temporalité des interactions que nous n’avons pas avec la représentation sous la forme de graphe.
Nous allons ainsi générer un automate global, c’est-à-dire que nous allons représenter les opé-
rations importantes réalisées par le logiciel malveillant pour en dégager un comportement. Nous
affinerons ce comportement en prenant en compte des "sous automates". Grâce à ces différents
éléments, nous pourrons écrire des règles de contrôle d’accès ciblant des comportements que nous
considérons comme malveillants.
La figure 5.12 montre un résultat simplifié de la génération de l’automate. Ce résultat est simplifié
puisque nous n’identifions qu’un nombre restreint d’actions qui conduisent à l’installation
de l’infection. Nous voyons dans cet automate que le canal de communication utilisé entre les différentes
entités mises en jeu dans l’installation de l’infection est une valeur dans le registre. Nous
avons nommé sample le fichier binaire qui est à la base de l’installation.
Cette représentation simplifiée permet d’inclure les éléments qui étaient difficiles à inclure
dans les graphes pour ne pas nuire à la lecture. La simplification repose sur deux éléments : tout
d’abord, nous ne nommons pas explicitement les objets du système, ensuite, nous n’utilisons pas
directement le temps des interactions, nous numérotons les interactions pour plus de clarté.
sample Corbeille Valeur
registre
Flash Player
Installer services.exe
7: Suppression
1: Ecriture
2: Ecriture
3: Ecriture
4: Exécution
5: Lecture
6: Ecriture
8: Ecriture
10: Exécution
9: Lecture
FIGURE 5.12 – Automate complet des interactions réalisées par le logiciel malveillant
L’automate met en relief la séquentialité des opérations qui se sont déroulées durant l’infection.
Cette forme sert d’intermédiaire entre les graphes des processus et les diagrammes de séquence.
Même si les interactions sont numérotées, cet automate fait perdre la notion de temporalité des
interactions. Nous proposons donc une représentation sous la forme d’un diagramme de séquence
pour raffiner encore l’analyse comme l’illustre la figure 5.13. C’est à partir de ce diagramme que
nous allons pouvoir identifier des comportements malveillants ou des séquences d’interactions
propres à la détection de logiciel malveillant.
À partir de l’automate que nous avons présenté 5.12 ainsi que du diagramme de séquence 5.13,
nous allons résumer le déroulement de l’installation de l’infection :
1565.3. EXPÉRIMENTATIONS
sample Corbeille Registre Flash services
Ecriture
Ecriture
Ecriture
Exécution
Lecture
Ecriture
Suppression
Ecriture
Lecture
Exécution
t0
t1
temps
t2
t3
t4
t5
t6
t7
t8
t9
FIGURE 5.13 – Diagramme d’activité sur l’installation de l’infection
— écriture du sample sur le disque et exécution du fichier : ces deux phases ne sont pas repré-
sentées ici car elles peuvent varier suivant les contextes. On peut imaginer un utilisateur
qui télécharge et qui l’exécute, ou encore une exploitation de vulnérabilité dans un module
tiers d’un navigateur.
— écriture des éléments pour initialiser l’installation de l’infection dans un répertoire spéci-
fique. Ce répertoire est ensuite renseigné dans le registre ;
— exécution de la charge active ;
— suppression du sample ;
— lecture des informations importantes pour l’installation et l’écriture des éléments permettant
à l’infection de survivre ;
— exploitation d’une vulnérabilité dans un processus possédant des droits élevés.
Nous avons donc proposé trois outils permettant d’analyser les logiciels malveillants. Ces trois
outils sont complémentaires en proposant chacun un degré de précision différent.
La première représentation, celle sous la forme de graphe, permet de connaître, de façon macroscopique,
les interactions qui ont été faites par tous les éléments du système. On peut ainsi
connaître les éléments qui ont été écrits, lus, chargés et supprimés. Nous n’avons présenté dans
cette étude que les interactions faites sur le système de fichiers. Nous pouvons naturellement faire
la même chose pour les interactions faites au niveau du registre.
La seconde représentation propose un raffinement de l’analyse en numérotant le début des
interactions grâce à l’utilisation des timestamps. Cette représentation permet de connaître l’enchainement
des interactions faites sur le système.
La troisième représentation ajoute un nouveau niveau de raffinement en détaillant les temps du
début des interactions. Ce diagramme pourra être étendu en rajoutant les dates de fin des interactions.
Politiques de protection
Maintenant que nous connaissons le comportement du logiciel malveillant par la définition de
l’automate et par la création d’un diagramme de séquence, nous pouvons écrire des politiques de
protection dans le but de bloquer ces comportements malveillants.
1575.3. EXPÉRIMENTATIONS
✞ ☎
1 neverallow domain recycle_bin_t:file { execute }
2 neverallow domain recycle_bin_t:process { execute }
✝ ✆
Listing 5.29 – Règle bloquant l’exécution d’un élément de la corbeille
Le premier comportement que l’on peut bloquer est l’exécution d’un élément dans la corbeille
de Windows. Pour ce faire, il suffit de mettre une labellisation générique sur cet élément du type
recycle_bin_t et d’empêcher toute exécution d’un objet de ce type.
Par exemple, les règles 5.29 permettent de contrer l’exécution d’un fichier de type
recycle_bin_t. Pour cela, nous allons utiliser une interaction spécifique de la politique par
l’utilisation de l’instruction neverallow dans la politique de contrôle d’accès. De plus, pour que
cette règle s’applique à tous les sujets du système, nous utiliserons l’instruction domain, qui repré-
sente tous les domaines du système.
Cette règle bloque donc explicitement l’interaction numéro 10 de notre automate 5.12.
Cependant, ces règles de contrôle d’accès peuvent se révéler difficiles à mettre en place. En
effet, elles pourraient nuire à l’utilisation normale du système. Imaginons par exemple qu’un administrateur
définisse la règle suivante 5.30, qui empêche toute écriture de fichier dans la corbeille,
cela implique que les utilisateurs ne peuvent plus déplacer de fichiers ou de dossiers dans la corbeille.
Ce qui nuit au fonctionnement d’un programme ou du système.
✞ ☎
1 neverallow domain recycle_bin_t:file { write }
✝ ✆
Listing 5.30 – Règle bloquant l’écriture d’un élément dans la corbeille
C’est pour cela que nous allons plutôt utiliser des propriétés de sécurité en utilisant le langage
de PIGA. Nous noterons les contextes de sécurité sujets scs et les contextes de sécurité objets sco.
Voici, sous une forme simple, les interactions qui se déroulent sur le système en termes de
contexte de sécurité et d’opérations élémentaires.
1. scs1 →w sco : création d’un nouvel objet, i.e : le sample écrit dans la corbeille.
2. scs1 →w sco1 : création d’un second objet, i.e : le sample écrit dans les fichiers temporaires
l’installateur modifié de FlashPlayer.
3. scs1 →x sco1 ⇒t scs2 : exécution du second objet qui transite vers un nouveau contexte
sc2.
4. scs2 →w scs3 : le nouveau domaine interagit avec un troisième domaine déjà présent sur
le système.
5. scs3 →x sco : ce troisième domaine va exécuter l’objet écrit par le premier domaine.
Cette énumération nous permet d’écrire directement la propriété de sécurité correspondante
5.31.
✞ ☎
1 define zeroaccess_behavior ( $sc1 IN SCS ) [
2 Foreach $eo1 IN is_write_like(IS), Foreach $eo2 IN is_write_like(IS),
Foreach $eo3 IN is_execute_like(IS),
3 Foreach $oe4 IN is_write_write(IS), Foreach $oe5 IN is_execute_like(
IS),
4 Foreach $sc2 IN $SCS, Foreach $sc3 IN $SCS,
5 Foreach $sco1 IN $SCO, Foreach $sco IN $SCO,
6 Foreach $a1 IN ACT, Foreach $a2 IN ACT
7 TQ { ( [ $a2 := $sc3 -> { $eo5 } $sco ] o $sc2 -> { $eo4 } $sc3 )
8 o ( $sc1 -> { $eo3 } $sco1 o $sc1 -> { $eo2 } $so1 o [ $a1 := $sc1
-> { $eo1 } $sco ] ) } ,
9 { INHERIT($a2 , $a1) };
1585.4. DISCUSSION
10
11 ];
✝ ✆
Listing 5.31 – Propriété de sécurité pour PIGA contrant l’installation d’une variante de ZeroAccess
Grâce à cette propriété, nous sommes capables de contrôler de manière un scénario complet.
Nous avons donc proposé deux méthodes pour contrer l’installation de ce logiciel malveillant.
La première méthode consiste à bloquer une interaction directe qui ne semble pas légitime faite
par le logiciel malveillant. Même si cette solution est efficace, sa portée sur le fonctionnement
du système pourrait se révéler très préjudiciable. En effet, les règles d’accès créées pourraient
bloquer le système. C’est pour cela que nous avons proposé une solution basée sur l’utilisation
d’un second moniteur de référence, qui offre la possibilité de bloquer un scénario complet plutôt
qu’une interaction précise.
5.4 Discussion
Dans ce chapitre, nous avons détaillé les choix que nous avions fait pour répondre aux problèmes
soulevés dans la partie formalisation.
En ce qui concerne la problématique de désignation des contextes sous Windows, nous avons
fait le choix, pour la construction des noms symboliques absolus indépendants de la localisation
d’utiliser les variables d’environnement. Elles ont l’avantage d’être à la fois communes à tous
les systèmes Windows et d’être gérées par le système. De plus, elles peuvent être étendues par
l’administrateur pour répondre à des problèmes spécifiques.
Cette solution nous a permis de répondre à un second problème plus lié à l’implantation. En
effet, nous avons dû résoudre la problématique de stockage des contextes de sécurité pour les objets
dans le modèle de protection basé sur DTE. Comme nous ne pouvions utiliser les attributs étendus
du système de fichiers comme le fait SELinux, nous avons mis en place un système de labellisation
dynamique. Cette méthode présente l’avantage d’être plus simple à administrer et plus portable car
ne nécessitant pas de labelliser les systèmes des fichiers.
Nous avons ensuite proposé deux implantations des méthodes de détournement que nous avons
décrites dans la partie formalisation. Ces deux méthodes nous ont permis de tester et de valider
nos politiques de protection pour les deux modèles PBAC et DTE. Nous avons ensuite fait le choix
de poursuivre nos expérimentations en utilisant le modèle de protection DTE.
Nos expérimentations ont porté sur deux aspects. Le premier point montre que nous sommes
capables d’associer notre moniteur Windows au moniteur PIGA pour contrôler efficacement les
scénarios complets. Le second concerne la protection contre les logiciels malveillants. Une architecture
dédiée permet l’envoi des traces de notre moniteur à un serveur limitant ainsi la compromission
de l’analyse. L’analyse permet de comprendre le scénario complet et de déduire une
politique pour notre moniteur ou pour PIGA qui empêche le scénario d’attaque. La solution PIGA
propose une méthode optimiste qui limite moins les activités légitimes.
5.4.1 Pertinence/complétude de la solution
Notre solution, basée sur une architecture modulaire est capable d’implanter deux modèles de
protection. Le premier est basé sur le modèle PBAC et le second sur le modèle DTE. Ces deux modèles
permettent de définir des politiques de contrôle d’accès fines et précises. Chaque ressource
du système est parfaitement identifiée.
Notre solution facilite la maintenabilité du mécanisme de contrôle d’accès. Le mécanisme de
création de politique basé à la fois sur un mode d’apprentissage auquel s’ajoute un outil de création
de politique de contrôle d’accès, facilite le travail de l’administrateur. Quel que soit le modèle de
1595.4. DISCUSSION
protection utilisé, il est possible d’avoir une couche d’abstraction efficace des ressources et ainsi
de pouvoir porter facilement des politiques d’un système à un autre.
Que ce soit en modifiant la table contenant tous les appels système ou par l’ajout d’un filterdriver,
nous sommes capables de gérer finement les accès, que ce soit sur le registre, au niveau
réseau et ou sur le système de fichiers. Non seulement nous pouvons vérifier les accès en prétraitement,
mais aussi en post-traitement puisque nous détournons entièrement le flux d’exécution,
chose que ne font pas encore les MAC tels que SELinux.
Grâce à cette implantation, nous contrôlons toutes les entrées/sorties des processus. Nous
contrôlons aussi les méthodes de synchronisations entre threads. Ces évènements passent par
des appels système que nous contrôlons.
5.4.2 Performances
Même si l’objectif de nos expérimentations n’était pas les performances, nous avons évalué la
latence que génère notre implantation. Nous avons fait ce test de performance sur la version qui
modifie la table des appels système.
Nous avons ainsi pu noter qu’il y avait une latence générée au démarrage des applications par
notre mécanisme de contrôle d’accès. Cela s’explique par les nombreuses interactions faites sur
le système de fichiers réalisées par l’application pour charger ses bibliothèques, créer ses fichiers
spécifiques, accéder au registre pour récupérer ses informations de configuration, etc.
Cette latence, que nous avons notée et estimée à un ajout de 2 secondes en moyenne par rapport
au temps de lancement normal de l’application, peut facilement être réduite en introduisant les
mêmes optimisations que pour SELinux. Par exemple, l’ajout d’un système de cache dans notre
driver SEWINDOWS pourrait accélérer la prise de décision. Ainsi, il ne serait pas nécessaire d’aller
consulter la politique SEWINDOWS à chaque interaction faite par le même contexte sujet.
Une seconde optimisation serait de ne pas vérifier à chaque fois les accès pour certains types
d’interactions, comme les opérations de lecture ou d’écriture. Par exemple, lorsqu’un sujet demande
l’accès en lecture sur un objet, l’accès est vérifié une première fois dans la politique. Puis,
tant que les contextes de sécurité mis en jeu ne sont pas modifiés, nous pouvons considérer qu’il
est inutile de vérifier de nouveau l’accès. Il faudrait vérifier que cette optimisation ne nuit pas à
la sécurité du système et qu’il n’existe pas de solution pour la contourner. Il faut noter que cette
optimisation a été mise en place dans SELinux.
Enfin, une troisième optimisation concerne le parcours de la politique par le serveur de sécurité.
Nous avons développé une première version où le moniteur mémorise la politique sous la forme de
chaîne de caractères. Nous avons ensuite mis en place un système basé sur des tables de hashages.
Une méthode pour optimiser la recherche dans la politique serait d’avoir une table par sujet, ainsi,
il ne serait plus nécessaire de parcourir la politique entièrement à chaque fois.
160Chapitre 6
Conclusion
Les enjeux de cette thèse étaient doubles. D’une part, il s’agissait d’améliorer la sécurité des
systèmes de calcul intensif basés sur Linux. D’autre part, des solutions devaient être apportées pour
que les postes de travail Windows puissent garantir des objectifs de sécurité. Le fait de rassembler
ces deux points présentait déjà une difficulté technique puisqu’il fallait connaitre deux systèmes
d’exploitation et maîtriser le développement dans leurs noyaux respectifs. Cet aspect technique
constituait en soi un pari. Un des objectifs était donc d’offrir un cadre commun pour protéger des
contextes d’usages aussi différents que le calcul intensif et les postes de travail Windows. Définir
une approche extensible était une première difficulté. De plus, il était nécessaire de s’intéresser
en parallèle à la sécurité et aux performances, ce qui est en soi assez antinomique. Enfin, il fallait
s’intéresser aux vulnérabilités des postes de travail et offrir des méthodes avancées d’analyse et
de protection. Il aurait été possible de faire une thèse sur chacun de ces points pris séparément. Il
n’en reste pas moins que s’intéresser de façon globale à ces domaines en dégageant correctement
les problèmes et en proposant des solutions extensibles constitue déjà un objectif ambitieux et
intéressant. Au final, nous répondons globalement à ces différents points d’étude en définissant un
cadre commun à la protection du calcul intensif et des postes de travail.
En introduction, nous avons ainsi décrit le problème de sécurité, à savoir contrôler les interactions
directes et être capable de contrôler les scénarios d’attaque complets. Nous avons aussi
synthétisé les manques dans ces domaines, à savoir l’absence de modèle général, non seulement
pour observer les appels système, mais aussi pour répartir efficacement différents observateurs afin
de détecter et prévenir des scénarios d’attaque complets. Nous nous sommes intéressés aux observateurs
appelés moniteurs de référence et capables de garantir l’intégrité et la confidentialité. Nous
avons considéré aussi le besoin d’une méthode pour répartir ces moniteurs, ainsi que mesurer et
comparer les performances de différentes solutions. Enfin, nous avons considéré, d’une part, la
nécessité d’un observateur constituant un moniteur de référence portable pour contrôler les interactions
directes, et d’autre part, d’une implantation de ce moniteur pour Windows afin d’analyser
et prévenir les scénarios d’activité des logiciels malveillants.
Dans le chapitre 2, nous avons établi l’état de l’art. Il montre à la fois le manque de modèle gé-
nérique d’observateurs, les faiblesses des moniteurs de référence existants et le manque de modèle
et de solutions pour répartir différents observateurs et évaluer leurs performances de façon précise
et extensible. Cet état de l’art étaye les points adressés par notre étude et justifie la réalité des
difficultés que nous avons listées en introduction. Il montre qu’il y a un réel manque de moniteurs
répartis pour le calcul intensif et de solutions pour les postes de travail Windows.
Le chapitre 3 a proposé une définition générique de la notion d’observateur capable de capturer
les appels système des différents processus pour contrôler les accès aux ressources du système
d’exploitation. Nous avons distingué trois modes de sécurité : requête/réponse, évidence et noti-
fication. Ils couvrent la majorité des approches permettant de détecter ou protéger les activités.
161Cette notion d’observateur est très générale et correspond à un large ensemble de mécanismes
de sécurité (pare-feu, contrôle d’accès des processus, antivirus, antimalware, détection d’intrusion.
. . ). Nous avons définis un type particulier d’observateur, le moniteur de référence, qui nous
intéresse en priorité. Ensuite, nous avons proposé un modèle conceptuel qui caractérise la répartition
des observateurs en terme d’association, de localisation et de redondance. Les deux types
d’association, cascade et notification, permettent de décrire le couplage de différents observateurs.
En pratique, le type cascade est le plus représentatif car il couvre bien la façon habituelle de coopérer
des observateurs. Les quatre localisations distinguent les observateurs colocalisés, distants,
parallèles et partagés. Ces différentes localisations visent à classifier les méthodes de répartition
des observateurs et de leurs clients. La redondance concerne les méthodes de tolérance aux pannes
d’un observateur. Pour la partie poste de travail, nous avons proposé une politique pour contrôler
les accès directs de façon obligatoire (MAC). Cette politique est générique, mais correspond bien
aux modèles DTE et PBAC adoptés sous Unix. Nous avons défini une façon de mettre en œuvre
cette politique pour Windows en offrant un mécanisme de désignation des processus et des ressources
qui simplifie l’administration des politiques. Nous avons proposé différentes méthodes
pour détourner les appels système des processus sous Windows afin de pouvoir contrôler leurs
activités. Ainsi, par la conjonction du modèle de politique et d’un détournement, nous sommes
capables d’offrir un modèle conceptuel de moniteur de référence qui est bien adapté à Windows.
Le chapitre 4 a étudié la répartition des observateurs en environnement de calcul intensif.
Nous avons proposé d’abord un objectif de mesure précise des performances. Pour cela, nous nous
sommes concentrés sur la répartition de deux observateurs en mode cascade en considérant qu’ils
peuvent être colocalisés ou distants. Nous avons proposé un calcul de la combinatoire des évaluations
et établissons la liste de mesures à effectuer. Nous avons proposé ainsi différentes mesures
globales et mesures détaillées. Nous pouvons déduire le temps de communication entre les deux
observateurs et comparer les performances pour les combinaisons des différentes approches. Une
mise en œuvre du mode distant à haute performance est proposée en utilisant des technologies
InfiniBand. L’efficacité repose sur deux coupleurs InfiniBand pour les communications entre les
deux observateurs. Nous avons proposé un protocole de mesure des performances reposant sur
deux logiciels de test. Le premier logiciel est le benchmark Linpack pour le HPC. Ce benchmark
n’est pas complètement représentatif des codes de calcul du CEA mais constitue le meilleur des
cas puisqu’il fait peu d’opérations d’entrée/sortie. Le second est un logiciel développé spécifiquement
pour stresser le système en réalisant un grand nombre d’entrées/sorties avec des politiques
SELinux et PIGA exigeantes en temps de calcul. On peut considérer qu’il s’agit donc du pire cas.
La réalité se situant entre ces deux cas, nous avons montré qu’il est possible de limiter le surcoût
à 10% pour les nœuds de calcul pour le mode détection et 25% pour le mode protection. Des
optimisations supplémentaires permettront de pouvoir passer en dessous de 5% et 10% respectivement
pour le mode détection et protection. Si ces résultats restent discutables, ils montrent la
possibilité d’un faible surcoût au regard du contrôle de scénarios d’attaque complets. L’approche
est efficace en termes de sécurité puisqu’elle réalise un contrôle optimiste qui ne limite pas les
activités légitimes.
Dans le chapitre 5, nous avons décrit la mise en œuvre d’un moniteur de référence pour Windows
autorisant l’analyse et le contrôle des logiciels malveillants. Nous avons proposé une implantation
de la désignation des ressources basée sur les variables d’environnement. Cette méthode
calcule dynamiquement les contextes de sécurité et évite donc d’avoir à les stocker au niveau des
systèmes de fichiers, simplifiant ainsi l’administration. Nous utilisons le moniteur en mode dé-
tection pour transférer de façon sûre les accès observés à un serveur. Cette approche a pour but
d’analyser le scénario d’attaque complet via différentes représentations graphiques. Ainsi, nous
sommes capables de décrire le déroulement temporel et logique du scénario. Nous montrons que
nous pouvons définir une politique pour notre moniteur, ou pour le moniteur PIGA, qui empêche
1626.1. PERSPECTIVES
l’attaque observée. Le contrôle des interactions directes par notre moniteur est plus immédiat,
mais présente le risque de limiter les activités légitimes des processus. A contrario, l’approche
PIGA est plus optimiste puisqu’elle peut bloquer le scénario à un point précis de son avancement.
Nous avons développé deux méthodes de détournement des appels système, la seconde étant davantage
portable. Globalement, nous livrons ainsi un moniteur portable aussi bien en termes de
détournement que de politique pour des environnements Windows 7 hétérogènes.
6.1 Perspectives
Amélioration des performances de PIGA Nous avons montré au cours du chapitre 4 que l’inté-
gration de SELinux dans les environnements HPC était aujourd’hui possible, notamment grâce aux
différentes optimisations réalisées. Cette intégration est possible car le surcoût dû à SELinux est
de l’ordre d’une µs par appel système. Même si le déport par Infiniband du moniteur PIGA amé-
liore les performances, des optimisations supplémentaires sont nécessaires pour passer en dessous
d’un surcoût de 5% pour les nœuds de calcul. C’est pour cela qu’il est nécessaire de travailler à
l’optimisation de PIGA.
Cela peut passer par la réécriture complète de la partie PIGA-UM pour qu’elle soit résidente
en espace noyau. Actuellement, la partie PIGA-UM est écrite en Java, qui est une technologie
consommatrice de ressources. En modifiant le code avec un langage moins consommateur, il serait
alors possible de co-localisé PIGA-UM sur un nœud client. De plus, comme nous l’avons présenté
au cours de notre étude, nous avons utilisé PIGA avec des politiques de sécurité extrêmement
génériques capable de couvrir un large ensemble de scénarios complets. Cette large couverture
n’est pas spécifique aux environnements HPC, il est donc nécessaire de travailler ces propriétés
pour qu’elles soient spécifiques à ces environnements. Grâce aux nouvelles propriétés, PIGA aurait
un plus petit nombre d’activités à surveiller et ces performances en seront améliorées.
Enfin, les compressions des signatures proposées dans [Clairet et al., 2012] devraient diminuer
de façon importante le temps de traitement et l’occupation mémoire.
Observateurs dans les systèmes répartis Nous avons commencé à mettre en place le mode de
redondance maître-esclave sur l’architecture que nous avons proposée dans le chapitre 4. Il est
nécessaire de poursuivre les travaux que nous avons commencés dans le but d’avoir un système
tolérant aux différentes pannes.
Nous avons concentré notre étude sur le mode distant pour le second observateur. Nous pouvons
maintenant orienter nos travaux sur les modes parallèles et partagés des observateurs, dans
un premier temps pour résoudre le problème de dimensionnement du mécanisme de protection, et
dans un second temps pour pouvoir corréler les requêtes reçues par le second observateur. En effet,
actuellement, le mode distant impose d’avoir une machine dédiée par observateur distant (dans
notre étude PIGA), ce qui pose un problème de dimensionnement de l’architecture de protection
puisque si nous voulons protéger 1 000 nœuds, il est nécessaire d’avoir 1 000 serveurs de sécurité
pour une localisation en mode distant. En travaillant sur les modes parallèles et partagés, nous
pourrions ainsi réduire le nombre de serveurs de sécurité utilisés dans notre architecture de protection.
De plus, il serait alors possible d’écrire des propriétés de sécurité adaptées aux systèmes
répartis.
Expérimentations à plus grande échelle de notre moniteur SEWINDOWS La première extension
pour les systèmes Windows serait la mise en place d’expérimentations à grande échelle pour
notre mécanisme de protection. Les objectifs seraient de corriger les limites de nos implantations,
de définir des politiques de plus en plus complètes ainsi que de connaître précisément l’impact sur
les performances du système.
1636.1. PERSPECTIVES
De plus, il serait intéressant de travailler sur les contextes de sécurité. Dans la version actuelle,
seuls les types et les domaines sont traités par notre moniteur, nous pourrions développer le
contrôle d’accès en nous basant sur les SID et sur les rôles.
Association des observateurs sur les systèmes Windows A partir des modèles que nous avons
définis dans le chapitre 3 de ce mémoire, il faudrait, par la suite, associer notre observateur avec
un autre observateur réalisant des calculs plus complexes. Au cours de notre étude, nous avons
réalisé cette composition de façon offline en rejouant les traces générées dans PIGA. Maintenant,
il faudrait les faire fonctionner tous les deux sur un même système.
De plus, les travaux que nous avons présentés sous Linux, visant à utiliser des technologies
du HPC pour déporter de manière efficace le second observateur, pourraient aussi être utilisés sur
les systèmes Windows. En effet, le proxy que nous avons développé est en mesure de réaliser les
mêmes actions que sur les systèmes Linux. Par extension, l’intégration de ce modèle de protection
pourrait être fait dans les architectures de cloud basées sur les technologies de Microsoft.
Extension de la répartition à d’autres systèmes d’exploitation Nous avons présenté la notion
d’observateur pour les systèmes Linux et Windows puis nous avons défini la notion de répartition.
Nous avons montré au cours de notre étude que nous pouvions appliquer ces deux notions sur ces
deux systèmes et dans des environnements hétérogènes. Nous pourrions maintenant étendre ces
notions à d’autres systèmes d’exploitation tels que les les systèmes Android et les OSX.
De plus, comme les systèmes Android ont pour base les systèmes Linux, nous pourrions dé-
ployer les deux observateurs que nous avons testés, à savoir SELinux et PIGA.
164Chapitre 7
Bibliographie
[ Alexander Kjeldaas, 1998] ALEXANDER KJELDAAS (1998). Linux Capability FAQ
v0.1. http://www.uwsg.indiana.edu/hypermail/linux/kernel/9808.1/
0178.html.
[Anderson, 1980] ANDERSON, J. (1980). Computer security threat monitoring and surveillance.
Rapport technique, James P. Anderson Company, Fort Washington, Pennsylvania.
[Anderson, 1972] ANDERSON, J. P. (1972). Computer Security technology planning study. Rapport
technique, Deputy for Command and Management System, USA.
[ANR, 2009] ANR (2009). Anr sec&si. http://www.agence-nationalerecherche.fr/programmes-de-recherche/appel-detail/programmesystemes-embarques-et-grandes-infrastructures-defi-securitesysteme-d-exploitation-cloisonne-et-securise-pour-linternaute-2008/.
[Bell et La Padula, 1973] BELL, D. E. et LA PADULA, L. J. (1973). Secure computer systems :
Mathematical foundations and model. Technical Report M74-244, The MITRE Corporation,
Bedford, MA.
[Biba, 1975] BIBA, K. J. (1975). Integrity considerations for secure computer systems. Technical
Report MTR-3153, The MITRE Corporation.
[Bishop, 2003] BISHOP, M. (2003). Computer Security Art and Science. Numéro ISBN
0201440997. Addison-Wesley Professional.
[Blanc, 2006] BLANC, M. (2006). Sécurité des systèmes d’exploitation répartis : architecture
décentralisée de méta-politique pour l’administration du contrôle d’accès obligatoire. These,
Université d’Orléans.
[Blanc et al., 2014] BLANC, M., BOUSQUET, A., BRIFFAUT, J., CLEVY, L., GROS, D., LEFRAY,
A., ROUZAUD-CORNABAS, J., TOINARD, C. et VENELLE, B. (2014). Mandatory access protection
within cloud systems. In NEPAL, S. et PATHAN, M., éditeurs : Security, Privacy and
Trust in Cloud Systems, pages 145–173. Springer Berlin Heidelberg.
[Blanc et al., 2011] BLANC, M., BRIFFAUT, J., TOINARD, C. et GROS, D. (2011). PIGA-HIPS :
Protection of a shared HPC cluster. International journal on advances in security, 4(1):44–53.
[Blanc et al., 2012] BLANC, M., GROS, D., BRIFFAUT, J. et TOINARD, C. (2012). PIGAWindows
: contrôle des flux d’information avancés sur les systèmes d’exploitation Windows
7. In MajecSTIC 2012, Villeneuve d’Ascq, France.
[Blanc et al., 2013a] BLANC, M., GROS, D., BRIFFAUT, J. et TOINARD, C. (2013a). Mandatory
access control with a multi-level reference monitor : PIGA-cluster. In ACM CLHS ’13 Procee-
165dings of the first workshop on Changing landscapes in HPC security, pages 1–8, New-York,
United States. ACM.
[Blanc et al., 2013b] BLANC, M., GROS, D., BRIFFAUT, J. et TOINARD, C. (2013b). PIGACluster
: a distributed architecture integrating a shared and resilient reference monitor to enforce
mandatory access control in the HPC environment. In SHPCS - 8th International Workshop on
Security and High Performance Computing Systems - 2013, Helsinki, Finland.
[Blanc et Lalande, 2012] BLANC, M. et LALANDE, J.-F. (2012). Improving Mandatory Access
Control for HPC clusters. Future Generation Computer Systems, pages –.
[Boebert et Kain, 1985] BOEBERT, W. E. et KAIN, R. Y. (1985). A practical alternative to hierarchical
integrity policies. In The 8th National Computer Security Conference, pages 18–27,
Gaithersburg, MD, USA.
[Briffaut, 2007] BRIFFAUT, J. (2007). Formalization and guaranty of system security properties :
application to the detection of intrusions. Thèse de doctorat, Université d’Orléans. SDS.
[Briffaut et al., 2009] BRIFFAUT, J., LALANDE, J.-F. et TOINARD, C. (2009). Formalization of
security properties : enforcement for MAC operating systems and verification of dynamic MAC
policies. International journal on advances in security, 2(4):325–343. ISSN : 1942-2636.
[Casey Schaufler , 2008] CASEY SCHAUFLER (2008). The Simplified Mandatory Access
Control Kernel . White Paper, pages 1–11.
[Clairet et al., 2012] CLAIRET, P., BERTHOMÉ, P. et BRIFFAUT, J. (2012). Compression de signatures
pour PIGA IDS. In ETIEN, A., éditeur : 9ème édition de la conférence MAnifestation
des JEunes Chercheurs en Sciences et Technologies de l’Information et de la Communication -
MajecSTIC 2012 (2012), Villeneuve d’Ascq, France. Nicolas Gouvy.
[Clark et Wilson, 1987] CLARK, D. D. et WILSON, D. R. (1987). A Comparison of Commercial
and Military Computer Security Policies. Proc. IEEE Symp. Computer Security and Privacy,
IEEE CS Press, pages 184–194.
[Corporation, 2003] CORPORATION, N. D. (2003). Tomoyo. http://tomoyo.
sourceforge.jp/index.html.en.
[Darivemula et al., 2006] DARIVEMULA, A., BOX, C., TIKOTEKAR, A. et POURZANDI, M.
(2006). Work in progress : Rass framework for a cluster-aware selinux. Cluster Computing
and the Grid, IEEE International Symposium on, 2:29.
[Ferraiolo et Kuhn, 1992] FERRAIOLO, D. F. et KUHN, D. R. (1992). Role-based access controls.
In 15th National Computer Security Conference, pages 554–563, Baltimore, MD, USA.
[Focardi et Gorrieri, 2001] FOCARDI, R. et GORRIERI, R. (2001). Classification of security properties
(part i : Information flow).
[Gros et al., 2012] GROS, D., TOINARD, C. et BRIFFAUT, J. (2012). Contrôle d’accès mandataire
pour Windows 7. In SSTIC 2012, pages 266–291, Rennes, France.
[Hagimont et J.Mossière, 1996] HAGIMONT, D. et J.MOSSIÈRE (1996). Problèmes de désignation,
de localisation et d’accès dans les systèmes répartis à objets . Rapport technique.
[Harrison et al., 1976] HARRISON, M. A., RUZZO, W. L. et ULLMAN, J. D. (1976). Protection in
operating systems. Communications of the ACM, 19(8):461–471.
[Hoglund et Butler, 2005] HOGLUND, G. et BUTLER, J. (2005). Rootkits : Subverting the Windows
Kernel. Addison-Wesley Professional.
[Hunt et Brubacher, 1999] HUNT, G. et BRUBACHER, D. (1999). Detours : Binary interception
of win32 functions. In Proceedings of the 3rd Conference on USENIX Windows NT Symposium
- Volume 3, WINSYM’99, pages 14–14, Berkeley, CA, USA. USENIX Association.
166[ITSEC, 1991] ITSEC (1991). Information Technology Security Evaluation Criteria (ITSEC)
v1.2. Technical report.
[Labs, 2005] LABS, C. (2005). Core force user’s guide. pages 1–2.
[Lampson, 1969] LAMPSON, B. W. (1969). Dynamic protection structures. In AFIPS Fall Joint
Computer Conference (FJCC 1969), volume 35, pages 27–38, Las Vegas, Nevada, USA. AFIPS
Press.
[Lampson, 1971] LAMPSON, B. W. (1971). Protection. In The 5th Symposium on Information
Sciences and Systems, pages 437–443, Princeton University.
[Lampson, 1973] LAMPSON, B. W. (1973). A note on the confinement problem. Commun. ACM,
16(10):613–615.
[Leangsuksun et Haddad, 2004] LEANGSUKSUN, C. et HADDAD, I. (2004). Building highly available
hpc clusters with ha-oscar. In Cluster Computing, 2004 IEEE International Conference
on, page 2.
[Leangsuksun et al., 2005] LEANGSUKSUN, C., TIKOTEKAR, A., POURZANDI, M. et HADDAD,
I. (2005). Feasibility study and early experimental results towards cluster survivability. In
Proceedings of the Fifth IEEE International Symposium on Cluster Computing and the Grid -
Volume 01, CCGRID ’05, pages 77–81, Washington, DC, USA. IEEE Computer Society.
[M. Fox et Thomas, 2003] M. FOX, J. Giordano, L. S. et THOMAS, A. (2003). Selinux and grsecurity
: a side-by-side comparison of mandatory access control and access control list implementations.
Rapport technique.
[McAfee, 2013] MCAFEE (2013). ZeroAccess Rootkity. Rapport technique, McAfee.
[Microsoft, 2009] MICROSOFT (2009). Applocker. http://technet.microsoft.com/
en-us/library/dd759117.aspx.
[Microsoft, 2013] MICROSOFT (2013). Windows integrity mechanism design. In The Microsoft
Developper Network.
[Naldurg et al., 2006] NALDURG, P., SCHWOON, S., RAJAMANI, S. et LAMBERT, J. (2006). Netra
: : seeing through access control. In FMSE ’06 : Proceedings of the fourth ACM workshop
on Formal methods in security, pages 55–66, New York, NY, USA. ACM.
[OASIS, 2013] OASIS (2013). Xacml. https://www.oasis-open.org/committees/
tc_home.php?wg_abbrev=xacml.
[Pourzandi et al., 2002] POURZANDI, M., HADDAD, I., LEVERT, C., ZAKRZEWSKI, M. et DAGENAIS,
M. (2002). A distributed security infrastructure for carrier class linux clusters.
[Richard Ward, 2006] RICHARD WARD, Jeffrey Hamblin, P. B. (2006). Mandatory integrity
control.
[Rouzaud-Cornabas, 2010] ROUZAUD-CORNABAS, J. (2010). Formalisation de propriétés de
sécurité pour la protection des systèmes d’exploitation. Thèse de doctorat.
[Saltzer et Schroeder, 1975] SALTZER, J. et SCHROEDER, M. (1975). The protection of information
in computer systems. Proceedings of the IEEE, 63(9):1278 – 1308.
[Sandhu, 1988] SANDHU, R. S. (1988). The schematic protection model : Its definition and analysis
for acyclic attenuating schemes. Journal of the ACM, 35(2):404–432.
[Sandhu, 1992] SANDHU, R. S. (1992). The Typed Access Matrix Model. In Proceedings of the
IEEE Symposium on Research in Security and Privacy, pages 122–136, Oakland, CA, USA.
IEEE.
[Sandhu et al., 1996] SANDHU, R. S., COYNE, E. J., FEINSTEIN, H. L. et YOUMAN, C. E. (1996).
Role-based access control models. Computer, 29:38–47.
167[Soshi et al., 2004] SOSHI, M., MAEKAWA, M. et OKAMOTO, E. (2004). The dynamic-typed
access matrix model and decidability of the safety problem. IEICE Transactions, 87-A(1):190–
203.
[Spencer et al., 1998] SPENCER, R., SMALLEY, S., LOSCOCCO, P., (national SECURITY
AGENCY), P. L., HIBLER, M., LEPREAU, J. et ANDERSEN, D. (1998). The flask
security architecture : System support for diverse security policies. In in Proceedings of The
Eighth USENIX Security Symposium, pages 123–139.
[Spender, 2003] SPENDER (2003). Grsecurity feature. https://grsecurity.net/
features.php.
[Spengler, 2002] SPENGLER, B. (2002). Detection, prevention, and containment : A study of
grsecurity. In In Libre Software Meeting 2002 (LSM2002), Bordeaux, France.
[Takeda, 2009] TAKEDA, K. (2009). Tomoyo linux overview. security mini-conf.
[TCSEC, 1985] TCSEC (1985). Trusted Computer System Evaluation Criteria. Technical Report
DoD 5200.28-STD, Department of Defense.
[Team, 2012] TEAM, P. (2012). 20 Years of PaX. pages 1–20, Rennes, France. SSTIC 2012.
[Wang et al., 2008] WANG, X., LI, Z., LI, N. et CHOI, J. Y. (2008). Precip : Towards practical
and retrofittable confidential information protection. In In 16th Annual Network and Distributed
System Security Symposium.
[Wright et al., 2002] WRIGHT, C., COWAN, C., SMALLEY, S., MORRIS, J. et KROAHHARTMAN,
G. (2002). Linux security modules : General security support for the linux kernel.
In Proceedings of the 11th USENIX Security Symposium, pages 17–31, Berkeley, CA, USA.
USENIX Association.
168Première partie
Annexes
169Annexe A
Configuration pour le logiciel linpack
et utilisation
✞ ☎
1 HPLinpack benchmark input file
2 Innovative Computing Laboratory, University of Tennessee
3 HPL.out output file name (if any)
4 6 device out (6=stdout,7=stderr,file)
5 1 # of problems sizes (N)
6 26752 Ns
7 1 # of NBs
8 128 NBs
9 0 PMAP process mapping (0=Row-,1=Column-major)
10 1 # of process grids (P x Q)
11 2 Ps
12 4 Qs
13 16.0 threshold
14 3 # of panel fact
15 0 1 2 PFACTs (0=left, 1=Crout, 2=Right)
16 2 # of recursive stopping criterium
17 2 4 NBMINs (>= 1)
18 1 # of panels in recursion
19 2 NDIVs
20 3 # of recursive panel fact.
21 0 1 2 RFACTs (0=left, 1=Crout, 2=Right)
22 1 # of broadcast
23 0 BCASTs (0=1rg,1=1rM,2=2rg,3=2rM,4=Lng,5=LnM)
24 1 # of lookahead depth
25 0 DEPTHs (>=0)
26 2 SWAP (0=bin-exch,1=long,2=mix)
27 64 swapping threshold
28 0 L1 in (0=transposed,1=no-transposed) form
29 0 U in (0=transposed,1=no-transposed) form
30 1 Equilibration (0=no,1=yes)
31 8 memory alignment in double (> 0)
✝ ✆
Listing A.1 – Fichier de configuration pour le logiciel linpack
171172Annexe B
Code utilisé pour la réalisation des tests
de performances
✞ ☎
1 #include
2 #include
3 #include
4 #include
5 #include
6
7 int main(){
8 struct timespec t1,t2;
9 FILE * file =NULL;
10 char buffer[42];
11 char fichier[102];
12
13 while(1)
14 {
15 bzero(buffer, sizeof(buffer));
16 bzero(fichier, sizeof(fichier));
17 srand(time(NULL));
18
19 clock_gettime(CLOCK_MONOTONIC, &t1);
20
21 file = fopen("/dev/urandom", "rb+");
22 if(file ==NULL) exit(-1);
23
24 fread(buffer, sizeof(buffer),1,file);
25 fclose(file);
26
27 strcat(fichier,"/local/test/");
28 sprintf(fichier,"%s%i", fichier,rand());
29 sprintf(fichier,"%s%li", fichier,t1.tv_nsec);
30 sprintf(fichier,"%s%i", fichier,rand());
31
32 file =NULL;
33 file =fopen(fichier, "wb+");
34 if(file == NULL) exit(-6);
35
36 fwrite(buffer, sizeof(buffer), 1, file);
37 fclose(file);
38
39 clock_gettime(CLOCK_MONOTONIC, &t2);
40 printf("time : %li.%li\n", t1.tv_sec, t1.tv_nsec);
41 printf("time : %li.%li\n", t2.tv_sec, t2.tv_nsec);
42 }
43 return 1;
44 }
✝ ✆
Listing B.1 – Code utilisé pour les tests de performances
173174Annexe C
Les techniques de détournements
Il existe plusieurs techniques pour détourner les appels système sur les systèmes Windows.
Ces techniques sont dangereuses car elle peuvent endommager le système en générant des BSOD
(Blue Screen of Death), c’est-à-dire que le noyau crashe, et ainsi rendre le système complètement
instable ce qui rend ces techniques illégitimes. Il existe cependant des techniques de détournement
légitimes, c’est-à-dire qu’elles sont nativement intégrées au système. Nous détaillerons dans cette
partie trois techniques spécifiques. Nous avons choisi ces techniques car ce sont les plus connues
et les plus utilisées à ce jour. Ces trois techniques sont des techniques destinées à être utilisées en
espace noyau. Il existe d’autres techniques en espace utilisateur, mais leur efficacité ainsi que leur
portée sur le système n’est pas la même.
C.1 Détournement de la table des appels système
La première technique est le détournement de la table des appels système. Cette méthode est
apparue sur les systèmes Windows avec les premiers rootkits nommés rustock 1
.
Avantages et portée Cette première technique est plutôt simple à mettre en place avec une
grande portée puisque toutes les applications utilisent la table des appels système pour réaliser
une action sur le système. Elle gère les accès au système de fichiers, les accès au registre, les
actions entre les processus comme la création de pipe nommé mais aussi les accès réseau.
L’un des principaux avantages de cette technique est qu’elle est maintenant assez documentée.
On peut par exemple retrouver les explications techniques pour la mettre en œuvre dans le
livre [Hoglund et Butler, 2005]. De plus, lorsqu’elle est correctement mise en place, elle peut permettre
l’empilement des logiciels de sécurité, c’est-à-dire que plusieurs driver peuvent détourner
les mêmes appels système sans pour autant nuire à la sécurité du système ou à sa stabilité. Le second
avantage de cette méthode est la possibilité de réaliser des contrôles en post-traitement mais
aussi en prétraitement. En effet, lorsqu’une fonction est détournée de la table des appels système,
elle est exécutée directement par le driver si l’exécution est autorisée. Mais dans ce cas, c’est aussi
le driver qui récupère le retour de la fonction. Il peut ainsi réaliser un nouveau contrôle.
Cette méthode de détournement des appels système permet de contrôler toutes les actions sur
le système réalisées par des applications mais pas les driver qui résident en espace noyau et qui
n’utilisent pas cette table pour réaliser des actions sur le système.
1. rustock : https://www.securelist.com/en/analysis/204792011/Rustock_and_All_
That
175C.2. INLINE HOOK
Limites et légitimité Cette technique modifie la mémoire du noyau, c’est-à-dire que les modifications
ne sont pas pérennes et ne résistent pas à un redémarrage. Il est donc nécessaire de
recommencer l’opération de détournement à chaque démarrage du système. Cette technique a été
énormément utilisée par les logiciels de sécurité comme les antivirus ou les pare-feux sur les systèmes
Windows XP. Même si cette technique a été utilisée par les éditeurs de logiciels de sécurité,
elle n’est pas recommandée par Microsoft. En effet, une mauvaise gestion des détournements entraîne
la génération de BSOD.
De plus, pour contrôler toutes les actions sur le système, il est nécessaire de détourner un par
un tous les appels système, opération qui peut se révéler très longue. Par exemple, sur un Windows
7, on trouve plus de 400 appels système alors qu’il n’y en a que 200 sur Windows XP. Cela nous
amène à une première limite de cette technique : la portabilité entre les différentes versions de
Windows. A chaque nouvelle version de Windows, la table des appels système est modifiée, il faut
donc refaire le détournement pour chaque nouveau Windows. De plus, le traitement de chaque
fonction peut être différent entre les versions de Windows puisque les paramètres des fonctions ne
sont pas toujours les mêmes.
Certains logiciels de sécurité détournent certains appels système dans le but de protéger leur
application. Ce détournement a pour but de contrôler la terminaison des processus et ainsi protéger
leurs processus et autres services d’un kill provenant d’un processus non autorisé à le faire. Il
existe néanmoins des techniques contournant les protections 2 mises en place au niveau de la table
des appels système. Il devient ainsi possible de tuer les processus protégés par ces détournements.
Enfin, depuis Windows Vista en version 64 bits et sur les versions supérieures de Windows,
la table des appels système est protégée par le mécanisme appelé Kernel Patch Protection 3
. Cette
protection empêche tout driver de modifier cette table. Donc la technique de détournement de la
table des appels système n’est pas portable sur les systèmes Windows 64 bits supérieurs à Windows
Vista. Il faut noter que certaines personnes ont pu réaliser ces modifications mais en désactivant
le Kernel Patch Protection, ce qui revient à désactiver un mécanisme de sécurité essentiel aux
nouvelles versions de Windows.
Pour que le contrôle réalisé par l’observateur soit efficace, il est nécessaire de contrôler le chargement
de tous les driver, puisqu’un driver pourrait supprimer ces détournements, et de vérifier
constamment que :
— la table des appels système possède toujours les modifications faites par le driver;
— qu’aucun driver malveillant ne soit chargé.
C.2 Inline Hook
Le seconde technique pour détourner les appels système est appelée inline hook. A la diffé-
rence de la modification de la table des appels système qui n’est réalisable qu’en espace noyau,
l’inline hook est une technique qui s’applique à n’importe quelle fonction et peut être réalisée en
espace utilisateur tout comme en espace noyau.
Avantages et portée Grâce à l’utilisation des frameworks, Microsoft Research ou easyhook, le
travail de détournement est grandement facilité et la portabilité entre les différentes versions de
Windows est assurée.
Depuis les systèmes Windows XP, le junk code des fonctions de l’API Win32 a été normalisé
par Microsoft. Ainsi, il n’est plus nécessaire de "rechercher" l’emplacement libre en début de
fonction pour placer le saut inconditionnel.
2. http://www.kernelmode.info/forum/viewtopic.php?f=11&t=1878
3. http://blogs.msdn.com/b/windowsvistasecurity/archive/2006/08/11/695993.
aspx
176C.3. FILTER-DRIVER
En modifiant toutes les fonctions du noyau, il est possible de contrôler toute l’activité du
système, même des driver qui résident en espace noyau, à condition qu’ils utilisent les fonctions
du noyau.
Limites et légitimité Le fait d’introduire un junk code en début de fonction est une réalisation
de Microsoft pour justement permettre le hot-patching. On peut donc considérer que ces techniques
sont autorisées par Microsoft, qui fournit à la fois l’espace nécessaire pour placer un saut
inconditionnel mais aussi un framework facilitant le déploiement de cette technique.
Pour pouvoir modifier les fonctions du noyau, il est nécessaire de désactiver Kernel Patch
Protection car il vérifie aussi l’intégrité des fonctions. En désactivant ce mécanisme de sécurité, la
signature des driver qui sont chargés ne sera plus vérifiée, ce qui peut conduire au chargement de
driver malveillant.
De plus, on se retrouve avec les mêmes inconvénients qu’avec la technique modifiant la table
des appels système. Il faut en effet modifier chaque fonction pour contrôler de manière globale le
système. Cette méthode ne se limitant pas qu’aux appels système cette technique devient extrêmement
contraignante à mettre en place.
Enfin, la modification des fonctions implique de connaître parfaitement leur fonctionnement.
Or, certaines fonctions ne sont pas documentées et peuvent être modifiées par Microsoft, que ce
soit dans leur prototypage ou dans leur fonctionnement.
C.3 Filter-driver
La troisième technique que nous décrivons se base sur les filter-driver. Elle se base sur une architecture
spécifique mise en place par Microsoft pour réaliser des contrôles sur les entrées/sorties
au niveau du système de fichiers.
Avantages et portée Les filter-driver reposent sur un système entièrement normalisé et documenté
par Microsoft. En plus de fonctionner sur toutes les architectures classiques, Microsoft
s’engage à assurer la portabilité des fonctions de l’API qu’il propose. Ainsi, un filter-driver fonctionnant
sur Windows XP fonctionne aussi sur Windows 7 ainsi que sur les différentes architectures
32 et 64 bits.
Un filter-driver ne gère que les accès au système de fichiers, mais grâce à l’utilisation des IRP,
qui regroupent des classes d’action, il est possible de contrôler non seulement les applications mais
aussi les autres driver qui réalisent des opérations sur le système de fichiers. Il est ainsi possible
de contrôler l’ensemble du système sans pour autant devoir modifier toutes les fonctions.
Limites et légitimité Comme c’est un mécanisme entièrement documenté et décrit par Microsoft,
c’est le système qu’il faut utiliser pour détourner le flux d’exécution du système. Comme les
appels système sont contenus dans les IRP, on ne détourne plus directement les appels système,
mais une classe d’appel système.
Comme nous l’avons expliqué, le modèle des filter-driver repose sur des couches de driver.
Ils sont représentés comme un empilement de driver. Cela signifie que potentiellement, le driver
précédent dans l’opération, que ce soit en prétraitement ou en post-traitement, peut modifier les
informations de l’IRP sans que le filter-driver ne puisse le savoir. Il faut donc contrôler les driver
autorisés à se charger dans la couche de driver.
177Damien GROS
Protection obligatoire répartie
La thèse porte sur deux enjeux importants de sécurité. Le premier concerne l’amélioration de la
sécurité des systèmes Linux présents dans le calcul intensif et le second la protection des postes
de travail Windows. Elle propose une méthode commune pour l’observation des appels système et
la répartition d’observateurs afin de renforcer la sécurité et mesurer les performances obtenues.
Elle vise des observateurs du type moniteur de référence afin de garantir de la confidentialité et de
l’intégrité. Une solution utilisant une méthode de calcul intensif est mise en œuvre pour réduire les
surcoûts de communication entre les deux moniteurs de référence SELinux et PIGA. L’évaluation
des performances montre les surcoûts engendrés par les moniteurs répartis et analyse la faisabilité
pour les différents noeuds d’environnements de calcul intensif. Concernant la sécurité des postes
de travail, un moniteur de référence est proposé pour Windows. Il repose sur les meilleures
protections obligatoires issues des systèmes Linux et simplifie l’administration. Nous présentons
une utilisation de ce nouveau moniteur pour analyser le fonctionnement de logiciels malveillants.
L’analyse permet une protection avancée qui contrôle l’ensemble du scénario d’attaque de façon
optimiste. Ainsi, la sécurité est renforcée sans nuire aux activités légitimes.
Mots clés : sécurité, contrôle d’accès obligatoire, systèmes d’exploitation, logiciels malveillants,
poste de travail, calcul intensif
Distributed mandatory protection
This thesis deals with two major issues in the computer security field. The first is enhancing
the security of Linux systems for scientific computation, the second is the protection of Windows
workstations. In order to strengthen the security and measure the performances, we offer a common
method for the distributed observation of system calls. It relies on reference monitors to ensure
confidentiality and integrity. Our solution uses specific high performance computing technologies to
lower the communication latencies between the SELinux and PIGA monitors. Benchmarks study
the integration of these distributed monitors in the scientific computation. Regarding workstation
security, we propose a new reference monitor implementing state of the art protection models from
Linux and simplifying administration. We present how to use our monitor to analyze the behavior of
malware. This analysis enables an advanced protection to prevent attack scenarii in an optimistic
manner. Thus, security is enforced while allowing legitimate activities.
Keywords : security, mandatory access control, operating systems, malware, workstation, high performance
computing
Laboratoire d’Informatique
Fondamentale d’Orléans
Bâtiment IIIA Rue Léonard de Vinci
B.P. 6759
F-45067 ORLEANS Cedex 2
CEA/DAM/DIF
Bruyères-le-Châtel
91297 Arpajon Cedex
M´ethodes et structures non locales pour la restauration
d’images et de surfaces 3D
Guillemot Thierry
To cite this version:
Guillemot Thierry. M´ethodes et structures non locales pour la restauration d’images et de
surfaces 3D. Signal and Image Processing. Telecom ParisTech, 2014. French.
HAL Id: tel-01022843
https://tel.archives-ouvertes.fr/tel-01022843
Submitted on 16 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.T
H
È
S
E
EDITE - ED130 2014-ENST-0006
Doctorat ParisTech
T H È S E
pour obtenir le grade de docteur délivré par
Télécom ParisTech
Spécialité : Signal et Images
Présentée et soutenue publiquement par
Thierry GUILLEMOT
le 3 Février 2014
Méthodes et structures non locales
pour la restauration d’images
et de surfaces 3D
Jury :
Mme. Julie DELON, Professeur, Université Paris Descartes Présidente
M. Pierre ALLIEZ, Directeur de recherche, Inria Sophia-Antipolis Rapporteur
M. Jean-Michel MOREL, Professeur, CMLA, Ecole Normale Supérieure de Cachan Rapporteur
M. Cyril CRASSIN, Chercheur, Nvidia Examinateur
Mme Pooran MEMARI, Chargé de Recherche, CNRS-LTCI, Télécom ParisTech Examinatrice
M. Andrés ALMANSA, Chargé de Recherche, CNRS-LTCI, Télécom ParisTech Directeur
M. Tamy BOUBEKEUR, Professeur, CNRS-LTCI, Télécom ParisTech Directeur
TELECOM ParisTech
École de l’Institut Mines-Télécom - Membre de ParisTech
46 rue Barrault 75013 Paris - (+33) 1 45 81 77 77 - www.telecom-paristech.frRemerciements
Tout d’abord, je tiens à remercier mes directeurs de thèse Andrès Almansa et Tamy
Boubekeur pour leurs qualités pédagogique, scientifique mais surtout humaine. Grâce à
eux, j’ai pu découvrir le monde de la recherche, apprendre beaucoup sur le traitement des
images et des données 3D. Leur soutien, gentillesse et optimisme m’ont permis de travailler
dans un cadre idéal pour réaliser ce doctorat.
Je remercie les membres du Jury, Pierre Alliez, Jean-Michel Morel, Cyril Crassin, Julie Delon
et Pooran Memari d’avoir accepté d’évaluer mon travail ainsi que pour leurs remarques
et conseils.
Mais que serait une thèse sans les soutiens de ces collègues devenus des amis au fils des
années ? Je pense ici aux amis du bureau C07 (ou "Bureau Link") : Baptiste et Cécilia
soutiens infaillibles depuis les premiers jours de stage, Alasdair pour sa touche anglaise et
son optimisme, Yann pour la sagesse de l’ancien et son goût de la bonne bière et Guillaume
pour sa gloutonnerie et ces blagues qui ne font rire que lui (et Alasdair). Je pense également
aux autres collègues de TSI, les sages Noura et Jean-Marc pour leurs innombrables conseils
et soirées improvisées, Charline, Emilie et Loredana pour leur inflexible bonne humeur,
Guillaume pour ses remotivations ludiques, Edoardo pour son amour de la cuisine, David
pour son amour de la bière, Joseph pour sa passion des débats, Julien pour son accent
américain, Pooran pour sa gentillesse, ainsi que tous les autres Malik, Hélène, Stéphane,
Flora, Sonia, Flora, Beibei, Leila, Mathias et Bert pour leurs discussions et conseils.
Je souhaite également remercier les anciens collègues pour m’avoir acceuilli dans les premiers
jours de thèse : Charles, Vincent et plus particulièrement Benoit pour son humour,
sa passion du monde ludique, son immense culture... et ses talents d’improvisation. Je voudrais
aussi remercier Andrés, Tamy, Isabelle, Yann, Julie, Florence et Michel pour m’avoir
donné l’envie de faire une thèse quand j’étais étudiant et pour leur accueil au laboratoire
TSI.
Avant de terminer, je voudrais exprimer ma gratitude à tous mes amis. Les plus Vieux :
Ludovic, Tom, Fabien, Sandrine et Mylène, les plus Récents : Cédric, Marine, Sophie et
Valérie, les plus Toulousains : Delphine et Manu, les plus Anglais : Terry, Cécile et Laurie,
les plus Théatreux : Marie, Cyril, Anne, Benoit, Florian, Bianka, Emmanuelle, Alban et
Sophie et les plus Télécommiens : Alexis, Romane, Rémi, Chloé, Laure et Morgane qui
ont toujours été là pour moi, même dans les moments les plus difficiles.
Je voudrais terminer ces remerciements en exprimant ma gratitude à mes proches : mon
père, ma mère et mes deux soeurs Karine et Coralie qui m’ont toujours encouragé, aidé
et soutenu pendant toutes ces années. A vous tous, sans qui rien de tout cela n’aurait été
possible, merci !
Je dédie cette thèse à mes neuveux et nièces à qui je souhaite d’avoir autant de soutien,
d’aide et d’encouragement que ce que j’ai pu avoir jusqu’à présent pour réussir ce qu’ils
entreprendront.
iTable des matières
Table des matières iii
1 Introduction 1
1.1 Contextes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.2 Du Local au Non Local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2.1 Méthodes de restauration locales . . . . . . . . . . . . . . . . . . . . 3
1.2.2 Méthodes de restauration non locales . . . . . . . . . . . . . . . . . . 4
1.3 Problématiques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.4 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.5 Organisation de la thèse . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
1.6 Prix et Publications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2 Tour d’horizon des méthodes de restauration non locales 7
2.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.2 Filtres à moyennes non locales . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.1 Formulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.2.2 Limitations et améliorations des NL-Means . . . . . . . . . . . . . . 12
2.3 Filtres 3D non locaux . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.1 Filtres surfaciques non locaux . . . . . . . . . . . . . . . . . . . . . . 15
2.3.2 Filtres non locaux de nuage de points . . . . . . . . . . . . . . . . . 15
2.3.3 Limitations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.4 Filtres collaboratifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
2.4.2 Méthodes de restauration collaboratives . . . . . . . . . . . . . . . . 18
2.4.3 Généralisation des filtres collaboratifs . . . . . . . . . . . . . . . . . 19
3 Surface de points non locale 21
3.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.1 Acquisition 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.2 Travaux existants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.1.3 Généralisation des PSS . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.1.4 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2 Surfaces de points non locales . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.1 Principe général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.2 Carte de déplacement . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.3 Fonction de pondération . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.2.4 Opérateur de projection non local . . . . . . . . . . . . . . . . . . . 29
3.3 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.1 Détails d’implémentation et performance . . . . . . . . . . . . . . . 30
3.3.2 Analyse des paramètres . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.3 Performances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
iiiiv
3.3.4 Analyse de la qualité de la surface . . . . . . . . . . . . . . . . . . . 42
3.3.5 Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.4 Limitation et possibles améliorations . . . . . . . . . . . . . . . . . . . . . . 47
4 Arbre de covariances 51
4.1 Contexte . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.1.1 Filtrage à hautes dimensions . . . . . . . . . . . . . . . . . . . . . . 51
4.1.2 Travaux existants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.1.3 Problématique . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.2 Arbre de Covariance Simplifié . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2.1 Principe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.2.2 Construction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.2.3 Apprentissage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
4.2.4 Requête . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
4.3 Généralisation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.3.1 Notations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
4.3.2 CovTree généralisé . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
4.3.3 Algorithme généralisé . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.4 Analyse et temps de calcul . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
4.4.1 Complexité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.4.2 Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
4.5 Limitations et possibles améliorations . . . . . . . . . . . . . . . . . . . . . 72
5 Filtrage collaboratif généralisé 75
5.1 Débruitage d’images par filtre collaboratif . . . . . . . . . . . . . . . . . . . 75
5.1.1 Non Local Bayes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
5.1.2 Débruitage d’images par CovTree . . . . . . . . . . . . . . . . . . . . 78
5.1.3 Analyse des paramètres . . . . . . . . . . . . . . . . . . . . . . . . . 79
5.1.4 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
5.2 Restauration par dictionnaires . . . . . . . . . . . . . . . . . . . . . . . . . 88
5.2.1 Principe général . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
5.2.2 Débruitage d’images . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
5.2.3 Reconstruction d’image échantillonnée aléatoirement . . . . . . . . . 92
5.2.4 Limitations et possibles améliorations . . . . . . . . . . . . . . . . . 93
5.3 Restauration de surface 3D . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
5.3.1 Positionnement du problème . . . . . . . . . . . . . . . . . . . . . . 94
5.3.2 Surface de points par NLB . . . . . . . . . . . . . . . . . . . . . . . 95
5.3.3 Restauration de surface par dictionnaire . . . . . . . . . . . . . . . . 96
6 Conclusion 99
7 Perspectives 101
Bibliographie 103C h a p i t r e 1
Introduction
1.1 Contextes
Les technologies à base de semi-conducteurs ont évolué de façon significative au début
des années 90 et ont permis l’arrivée de nouveaux systèmes d’acquisition numérique. Cependant,
leur qualité de capture était à l’origine trop limitée par rapport aux systèmes
analogiques. L’augmentation de la résolution des capteurs est donc rapidement devenue
un enjeu crucial de cette décennie. C’est à cette époque qu’apparaissent les premiers appareils
photographiques entièrement numériques : les pellicules et leur développement sont
respectivement remplacées par des cartes de stockages réutilisables et des impressions instantanées.
Les appareils numériques réussissent ainsi à s’imposer progressivement face aux
analogiques.
Les précédentes avancées ont permis le développement d’autres techniques dans des domaines
différents de la photographie. De nouveaux systèmes de capture ont ainsi émergés
tels que les scanners 3D. Les systèmes de capture 3D classiques, estimant la profondeur
par contact, sont ainsi améliorés par l’utilisation de capteurs CCD et de Laser. Ce nouveau
type de scanner est particulièrement employé dans des domaines tels que la conservation
du patrimoine (par ex. project Michelangelo - Figure 1.1) où il est nécessaire de numériser
des objets sans qu’ils ne subissent de détériorations. Cependant la nature des données
3D diffère de celle des images 2D. Des outils spécifiques à leur traitement ont donc été
introduits et définissent ainsi les toutes premières chaines d’acquisition 3D.
À la fin des années 90, les capteurs numériques réussissent à atteindre des résolutions équivalentes
ou supérieures à celles obtenues par des systèmes classiques. Malheureusement,
l’utilisation des appareils numériques reste réservée à une élite. Ce phénomène peut être
expliqué par plusieurs facteurs : un prix d’achat trop élevé, et des systèmes de capture
qui ne sont généralement pas adaptés aux besoins du grand public (difficulté d’utilisation,
encombrement, poids élevé, etc.). Ainsi, l’adaptation des systèmes d’acquisition numérique
à ces besoins est devenu l’enjeu principal des années 2000.
Cette démocratisation est particulièrement visible avec l’apparition des appareils photos
compacts. L’utilisation de nouveaux algorithmes de gestion automatique des paramètres
intrinsèques (focus, ouverture, balance des blancs, etc.) les rendent facile d’utilisation pour
les non-connaisseurs. La photographie numérique devient donc accessible à tous à partir
12
Figure 1.1: Résultat du projet Michelangelo : Gauche : numérisation 3D sans détérioration
utilisant des capteurs CCD et Laser. Droite : comparaison entre la statue réelle et le
résultat 3D obtenu. Les images proviennent de [LPC+00]
du début des années 2000. À partir de là, de nombreux constructeurs se sont mis à dé-
velopper des appareils de plus en plus performants à des prix toujours plus bas afin de
mieux satisfaire les demandes de ces nouveaux utilisateurs. Au milieu des années 2000,
de nouvelles avancées technologiques permettent de produire des capteurs miniaturisés à
l’extrême pour des coûts dérisoires. Désormais plus petits qu’une pièce de monnaie, ils
se retrouvent rapidement intégrés aux téléphones portables et bouleversent par la même
occasion les habitudes d’utilisation du grand public. La résolution et les performances de
capture (zoom, iso etc.) deviennent progressivement des arguments de vente incontournables.
Pendant ces années 2000, les systèmes de captures 3D ne cessent d’évoluer. De nouveaux
types de capteurs font leur apparition en proposant l’exploitation de plusieurs images
par stéréovision, la projection de motifs connus par lumière structurée, l’analyse du focus
d’un appareil photo ou, plus récemment, les capteurs plénoptiques. Pendant cette période,
l’utilisation des capteurs 3D se généralise à de nombreux domaines tels que le cinéma, les
jeux vidéo, la robotique, l’automobile, etc. . Durant plusieurs années, l’utilisation de ces
scanners 3D reste néanmoins réservée à un public restreint. Ce n’est qu’à partir du début
des années 2010 que les capteurs 3D grand public sont démocratisés par l’industrie des jeux
vidéos (par ex. Microsoft Kinect). Grâce à leur faible prix, il devient facile d’acquérir des
données 3D. Cela permet d’attirer de nouveaux utilisateurs et d’élargir les types d’usage
de ces données.
À l’heure actuelle, la démocratisation des capteurs numériques est telle, qu’en France, des
millions d’appareils photos numériques sont vendus chaque année, environ la moitié de
la population possède un capteur photo sur son téléphone (smartphone) et environ un
million de personnes possèdent une Kinect. Ainsi, chaque jour, une quantité astronomique
de données 2D et 3D est ainsi générée à travers le monde. Avec l’essor des réseaux de communications
et avec l’apparition des smartphones, une grande partie de cette information
se retrouve partagée avec le reste du monde. En guise d’exemple, des dizaines de milliards
de photos sont échangées chaque année sur l’un des principaux réseaux sociaux actuels
(Facebook).
Désormais, la majorité des systèmes d’acquisition numérique modernes sont connectés
aux réseaux de communications (3G, 4G en préparation, etc.). Ils peuvent donc trans-1.2. DU LOCAL AU NON LOCAL 3
Restauration locale Restauration non locale Restauration par base de données
Figure 1.2: Illustration des différentes méthodes de restauration. Nous représentons en
rouge le voisinage retenu.
mettre très facilement l’information acquise. Aujourd’hui, ces données partagées restent
néanmoins difficilement exploitables par les machines de calculs modernes (ordinateur
personnel, smartphone, etc.) dans la mesure où elles ne disposent pas d’une capacité de
mémoire suffisante pour pouvoir les gérer. Ainsi, les différentes évolutions récentes laissent
à penser que cette exploitation sera le nouveau challenge de ces années 2010.
Cette thèse s’inscrit au cœur de cette évolution en proposant quelques éléments de réponse
à l’un des enjeux technologiques des années 2010, à savoir : la capture, transmission et
traitements de masses de données 2D et 3D. Après cette brève introduction sur l’historique
de la capture numérique, nous introduisons les enjeux de la restauration moderne.
1.2 Du Local au Non Local
Durant ces dernières années, les technologies d’acquisition numériques n’ont cessées de
se perfectionner. Ces différentes évolutions ont donc permis l’apparition de capteurs miniaturisés,
économes en énergie et surtout capables d’acquérir des données avec une qualité
toujours plus fine. Malgré ces différentes améliorations, les capteurs restent sujet à
des perturbations (tel que bruit électronique, résonance magnétique, etc.). Ces problèmes
électroniques ajoutés aux contraintes d’acquisition (distorsions, effets de masquage, etc.)
viennent perturber la capture entrainant l’apparition de défauts tels que du bruit, des
points parasites, des trous dans les données acquises, etc.
Ces imperfections sont inhérentes à toute technologie de capture et ne peuvent pas être
corrigées matériellement. Elles nécessitent donc un traitement logiciel particulier. Ainsi,
en même temps que l’apparition des tout premiers capteurs numériques dès le début des
années 90 apparaissent les premières méthodes de restauration telles que le débruitage, la
reconstruction, le suréchantillonnage, etc.
1.2.1 Méthodes de restauration locales
Jusqu’au milieu des années 2000, ces approches s’appuient uniquement sur un traitement
local des données (Figure 1.2). Dans le cadre du traitement des images, cette localité
s’exprime de deux manières différentes :4
Durant les années 90, la puissance de calcul et la capacité de stockage en mémoire restant
limitées, seul des filtres simples pouvaient être évalués. Ainsi, le support du filtre a été
restreint à un support local : un pixel est filtré par rapport aux pixels appartenant à un
voisinage local. C’est à cette époque que sont introduits les filtres par minimisation de la
variation totale, bilatéraux, etc..
Avant le milieu des années 2000, les réseaux de communications ne permettent pas d’échanger
une quantité de donnée importante. Ainsi, les approches de restauration sont réduites
à l’utilisation d’une seule image : un pixel est filtré à partir de l’information contenue dans
l’image à filtrer.
1.2.2 Méthodes de restauration non locales
À partir du milieu des années 2000, les performances de calcul et la quantité de mémoire
présentes sur les ordinateurs ont suffisamment évolué pour que les limitations locales pré-
cédentes soient supprimées.
Dans un premier temps, les méthodes non locales proposent d’étendre le support local
du filtre de restauration à l’ensemble de l’image en faisant l’hypothèse que les données
acquises sont autosimilaires (Figure 1.2). Ainsi, l’information détériorée est restaurée en
utilisant des données similaires présentes en d’autres endroits de l’image. Face à leur
succès en traitement des images, ces méthodes sont progressivement étendues au cas 3D
où l’hypothèse d’autosimilarité peut être supposée de manière équivalente.
Dans un deuxième temps, de nouvelles méthodes plus générales ont permis de combiner
les idées introduites par les méthodes non locales avec la multiplication de la quantité de
données (Figure 1.2). La non localité est désormais définie par rapport à une information
extraite à partir de plusieurs images.
1.3 Problématiques
S’il est vrai qu’il y a eu un développement récent des méthodes non locales, ces dernières
ont principalement été utilisées afin de restaurer des données régulières et structurées
telles que des images. À l’heure actuelle, ces méthodes restent encore peu étendues dans
le cadre de données irrégulières. Dans le cas extrême des nuages de points 3D qui sont à
la fois irréguliers et non structurés, il n’existait au début de cette thèse aucune méthode
de restauration capable d’exploiter la redondance de l’information judicieusement afin de
définir une surface 3D.
Avec la démocratisation des capteurs numériques, la quantité de données transmise sur
les réseaux de communication ne cesse d’augmenter. Le challenge est donc de réussir à
exploiter judicieusement ces grands ensembles d’information. Néanmoins, à l’heure actuelle
seules quelques grosses entreprises possèdent les infrastructures de calcul et de stockage
nécessaires pour y arriver. Bien évidémment, le grand public ne peut avoir à sa disposition
de telles structures. Il faut donc réussir à trouver un moyen pour que cette exploitation
puisse être réalisée sur des systèmes possédant des capacités limitées (par ex. smartphones).1.4. CONTRIBUTIONS 5
Malheureusement, les données accessibles sont généralement brutes, semi-structurées ou
non structurées. Il devient donc nécessaire de trouver un moyen pour les regrouper.
Les évolutions récentes des filtres non locaux tendent à incorporer une problématique
orientée big data en proposant des nouvelles démarches qui analysent l’information de
sorte à extraire un modèle pour améliorer la restauration des données. Malheureusement,
ce type de méthodes reste peu utilisable en pratique à cause du temps qu’il nécessite
pour effectuer l’analyse. Il devient donc nécessaire d’introduire des nouvelles méthodes
non locales qui soient à la fois flexibles pour pouvoir être utilisées sur n’importe quel type
de données et génériques pour être utilisables par une large variété d’applications.
1.4 Contributions
Le point de départ de cette thèse est le débruitage non local de nuages de points. Ce
problème a mis en évidence le besoin de structures dédiées aux traitements non-locaux
des données de dimension deux et supérieure, ainsi que la possibilité de généraliser les
méthodes existantes de restauration non-locale 2D et 3D.
Les principales contributions de cette thèse sont :
– une définition de surface de points capable d’exploiter le caractère autosimilaire d’un
nuage de points. Cette définition permet d’étendre n’importe quelle définition de surface
de points locales précédente.
– une structure de données flexible et générique capable d’apprendre les distributions d’un
grand ensemble d’échantillons avec une capacité de mémoire limitée. Cette structure
permet de définir pour tout voisinage, la gaussienne anisotrope associée aux échantillons
qui sont compris dans ce voisinage.
– une généralisation des méthodes de restauration par filtres collaboratifs appliquées aux
données 2D et 3D qui utilisent la structure de données introduite précédemment pour
apprendre un modèle statistique a priori à partir d’un grand ensemble de données.
1.5 Organisation de la thèse
Dans le Chapitre 2, nous introduisons de manière générale les méthodes de restauration non
locales. Au travers ce chapitre, nous présenterons les méthodes de débruitage par moyenne
non locale, leurs applications aux cas 3D ainsi qu’une analyse générale des méthodes
collaboratives.
Le Chapitre 3 sera consacré à l’adaptation de la méthode de filtrage par moyennes non
locales au cas des nuages de points.
Dans le Chapitre 4, nous introduisons une nouvelle structure capable d’apprendre rapidement
une grande base de données en utilisant uniquement une quantité de mémoire
limitée.
Cette structure sera utilisée au Chapitre 5 pour résoudre différents problèmes de restauration
collaboratifs.6
Finalement, le Chapitre 6 offrira une conclusion générale des contributions de cette thèse
et le Chapitre 7 une ouverture générale des travaux de recherche à venir.
1.6 Prix et Publications
Covariance Tree for 2D and 3D Processing, Thierry Guillemot, Andrés Almansa et
Tamy Boubekeur, Computer Vision and Pattern Recognition (CVPR), Columbus, 2014
Non Local Point Set Surface, Thierry Guillemot, Andrés Almansa et Tamy Boubekeur,
3D Imaging Modeling Processing Visualization Transmission (3DIMPVT), Zurich, 2012
Non Local Point Set Surface, Thierry Guillemot, Andrés Almansa et Tamy Boubekeur,
Symposium on Geometry Processing (SGP), Tallinn, 2012 - Best Poster AwardC h a p i t r e 2
Tour d’horizon des méthodes de
restauration non locales
Dans ce chapitre, nous allons introduire un état de l’art des méthodes non locales. Nous
commençons par présenter un contexte général de la restauration des images ainsi qu’un
historique des méthodes de débruitage par moyenne de valeurs. Cet historique est suivi
d’une analyse des méthodes non locales qui se concentrera sur l’influence des paramètres,
les limitations et les évolutions des méthodes non locales. Nous présentons ensuite, une
généralisation de ces méthodes au cas 3D en nous focalisant sur le débruitage surfacique
et de nuage de points. Finalement, nous introduisons les filtres collaboratifs ainsi que leurs
différentes applications en traitement des images. Durant ce chapitre, nous introduisons
les notions indispensables qui seront utilisées durant l’ensemble de cette thèse. Nous précisons
au lecteur que des analyses de l’état de l’art plus spécifiques aux travaux développés
durant cette thèse seront présentées en début des Chapitres 3, 4 et 5.
2.1 Contexte
Quel que soit le système d’acquisition et la précision de ce dernier, les signaux modernes
restent altérés lors de leur capture. Ces dégradations, généralement dues aux contraintes
matérielles (optique, capteur CCD, etc.), algorithmiques (compression JPEG, etc.) ou
transmissives (satellitaires, internet, etc.), doivent être traitées afin de récupérer au mieux
l’information originalle contenue dans ces signaux. Dans cette partie, nous considérerons
des images discrètes dont chaque élément (pixel) est associé à une couleur (Rouge, Vert,
Bleu - RGB).
Plusieurs hypothèses sont généralement faites afin de modéliser les dégradations subies par
l’image. En particulier, nous supposerons que nous avons accès à une observation dégradée
de l’image qui associe à chaque pixel xi une couleur f(xi) obtenue à partir de la couleur
réelle u(xi) en ajoutant un bruit n(xi) gaussien i.i.d. (indépendant et identiquement distribué)
de variance σ connue :
fi = f(xi) = u(xi) + n(xi) (2.1)
Ce modèle est utilisé de manière standard dans la communauté du traitement des images,
car il est à la fois simple et efficace pour modéliser le bruit dû à l’acquisition de l’image.
78Zone homogène Contour Zone texturée
Images bruitées Poids gaussien Poids bilatéral Poids non local
Figure 2.1: Nous illustrons la définition des poids gaussien, bilatéral et non local pour
trois différentes zones de l’image : une zone homogène, un contour, une zone texturée. Pour
tout ces exemples, les poids sont calculés en fonction du pixel central de chaque image.
Les poids élevés sont représentés en blanc tandis que les poids faibles sont représentés en
noir.
D’autres modèles, par exemple les modèles poissoniens, ne seront pas abordés dans cette
thèse (voir [Bov05] pour plus de détails).
Le principe des méthodes de débruitages consiste à éliminer le bruit ajouté lors de l’acquisition
afin d’estimer une couleur ˆu(xi) proche de la couleur originale u(xi). Pour résoudre
ce problème, des nombreux travaux ont été introduits proposant une minimisation de
la variation totale [ROF92], l’application de filtres de Wiener empiriques [YY85], une
décomposition de l’image en ondelettes [Don95], l’utilisation de voisinages de taille variable
[PS00,KEA02,KFEA04,FKEA04], ou plus récemment une analyse de l’a priori des
textures de l’image par dictionnaire [DFKE09,ZDZS10,YSM10], etc..
Parmi toutes ces méthodes, un grand nombre de filtres peuvent s’exprimer comme une
moyenne sur les pixels de l’image. En considérant un sous-ensemble de pixels N(xi) proches
du pixel d’intérêt xi
, la forme générale de ces filtres peut être exprimée comme une combinaison
des couleurs fj pondérées par les poids wij :
uˆ(xi) = X
xj∈N(xi)
wij fj (2.2)2.1. CONTEXTE 9
Images bruitées Filtrage gaussien
Filtrage bilatéral Filtrage non local
Figure 2.2: Résultat des différents filtrages gaussien, bilatéral et non local appliqués sur
l’image barbara bruitée avec un bruit gaussien de variance 0.08.
Les poids wij sont normalisés : P
xj∈N(xi) wij = 1, et leur définition permet de définir
les caractéristiques du filtre souhaité. Ce dernier peut dépendre de la position spatiale xi
,
de la couleur des pixels fi
, ou de toute autre caractéristique de l’image. En particulier,
l’Équation 2.2 peut être utilisée pour exprimer la convolution par un noyau gaussien φ
d’écart type hp. Dans ce cas, les poids wij sont fonction de l’éloignement spatial entre les
pixels de l’image xj et le pixel d’intérêt xi
:
wij ∝ φ(kxi − xjk
2
/h2
p
) (2.3)
Une analyse du filtre gaussien [BCM05] démontre que l’écart entre l’image originale et
l’image filtrée est directement proportionnel au laplacien de l’image. Il en résulte que
le filtre gaussien permet de récupérer correctement les valeurs des zones homogènes de
l’image, mais floute les bords et les zones texturées (Figure 2.1 et 2.2). Par conséquent,
à cause de ces faibles performances, ce filtre est assez peu utilisé par les systèmes de
débruitage modernes.10
La simplicité de la formulation du filtre gaussien restant très attrayante, de nombreux
travaux ont proposé d’améliorer ses performances afin d’obtenir un débruitage des images
plus efficace. En proposant une approche similaire aux travaux de Lee [Lee83] et de Yaroslavsky
[YY85], Tomasi introduit le filtre bilatéral [TM98] en définissant un poids dépendant
à la fois de la distance spatiale entre les pixels et de la distance entre leurs couleurs
associées (distance colorimétrique). D’une manière totalement équivalente, le filtre bilatéral
peut être vu comme un filtre gaussien défini dans un espace augmenté qui mélange
les positions des pixels xi et leurs valeurs associées fi
. Les poids du filtre sont calculés en
combinant deux noyaux φ, ψ définis respectivement dans les domaines spatial (différence
des positions des pixels) et colorimétrique (différences des couleurs des pixels) :
wij ∝ φ(kxi − xjk
2
/h2
p
)ψ(kfi − fjk
2
/h2
f
) (2.4)
Ces noyaux, généralement gaussiens, sont dépendants de deux paramètres hp et hc utilisés
pour limiter la taille du voisinage spatial et colorimétrique. Désormais seuls les pixels qui
possèdent à la fois des positions et des couleurs proches du point d’intérêt ont un poids
élevé. Par exemple, les pixels proches d’un contour appartenant à une zone différente de
celle du pixel d’intérêt possèdent dans ce cas un poids négligeable. Le filtre bilatéral permet
de débruiter correctement les zones homogènes tout en préservant les bords de l’image.
Néanmoins, l’utilisation d’une unique valeur pour estimer un voisinage colorimétrique reste
trop sensible au bruit de l’image (Figure 2.1 et 2.2). Les zones texturées de l’image restent
donc difficilement récupérables par une telle approche.
Face au succès des méthodes de synthèse de texture [EL99] et d’inpainting [CPT03,CPT04]
utilisant la notion de patch (correspondant à une imagette de l’image considérée), Buades
et coll. [BCM05] (et en même temps [AW05,KB06,AW06]) introduisent le filtre à moyennes
non local (Non Local Means - NL-Means). Ce dernier étend l’idée du filtre bilatéral d’utiliser
la couleur des pixels pour raffiner l’estimation du voisinage en la remplaçant par un
patch (ou imagette) décrivant l’information contenue autour du pixel. Ce patch PW
f,xi
∈ R
dP
de dimension dP = (2W + 1)2
est défini comme l’ensemble des valeurs de f comprises dans
une fenêtre carrée de taille W centrée sur le pixel considéré xi
. Les poids non locaux wij
sont donc définis par l’intermédiaire d’un noyau de pondération φ dépendant de la distance
entre patchs :
wij ∝ φ(kP
W
f,xi − P
W
f,xj
k
2
/h2
) ∝ φ(
X
dP
k=1
kfi+k − fj+kk
2
/h2
) (2.5)
Le paramètre h permet de définir le nombre de voisins utilisés pour le débruitage. Désormais
le poids dépend uniquement de la similarité entre les patchs et non de l’éloignement
spatial entre les pixels (d’où son caractère non local). Il est intéressant de noter qu’une
version dégénérée des NL-Means, où la taille du patch est réduite à un unique pixel, nous
permet d’obtenir une forme équivalente au filtre bilatéral. Tout comme ce dernier, le filtre
NL-Means peut être exprimé de manière équivalente comme un filtre gaussien appliqué
dans l’espace des patchs. Par l’utilisation d’un ensemble de couleurs {fi+k}k∈[[1,dP]], les
poids définis par les NL-Means sont moins dépendants du bruit et permettent d’obtenir
un débruitage de l’image satisfaisant dans les zones homogènes, les contours et les zones
texturées de l’image (Figure 2.1 et 2.2). Cette propriété est due au fait que les images naturelles
présentent une auto similarité affine locale [Ale05]. De par leur formulation simple
et leur capacité de débruitage, les NL-Means sont devenus durant ces dernières années l’un
des filtres les plus utilisés pour le débruitage d’images.2.2. FILTRES À MOYENNES NON LOCALES 11
2.2 Filtres à moyennes non locales
Dans cette partie, nous effectuons une étude plus approfondie des NL-Means. Nous nous intéresserons
en particulier à l’analyse de ses différents paramètres, évolutions et limitations.
Lebrun et. coll. [LCBM12] fait une analyse en profondeur des propriétés mathématiques
de ces filtres et ses généralisations en traitement d’images.
2.2.1 Formulations
Nous rappelons ici la définition des NL-Means telle qu’elle a été introduite par Buades et
coll. [BCM05] :
uˆi =
X
xj∈N(xi)
φ(kP
W
f,xi − P
W
f,xj
k
2
/h2
)fj (2.6)
où N(xi) est un ensemble de pixels voisins de xi
, φ un noyau de pondération, W la taille
des patchs PW
f,xi
centrés sur xi et h le facteur d’autosimilarité. Tous ces paramètres sont
directement liés à la qualité de la restauration. De nombreux travaux ont proposé une
analyse détaillée de leur influence respective.
Noyau de pondération
Le noyau de pondération φ permet de définir le poids de chaque échantillon en fonction
de la similarité de leurs voisinages. La pondération est normalisée de sorte que :
X
xj∈N(xi)
φ(kP
W
f,xi − P
W
f,xj
k
2
/h2
) = 1 (2.7)
Les travaux originels des NL-Means [BCM05, AW05, KB06, AW06] utilisent un noyau de
pondération gaussien. Chaque pixel de la somme possède un poids non nul qui influence
l’estimateur final. L’accumulation des poids des pixels les plus éloignés peut par conséquent
biaiser le débruitage. Par conséquent, n’importe quel point, même le plus éloigné, influence
l’estimateur non local. Pour résoudre ce problème, de nombreux travaux [GLPP08,DAG10,
Sal10a] arrivent à la conclusion qu’il est préférable d’utiliser un noyau à support compact
qui permet d’annuler l’influence des échantillons trop différents.
Dans l’Équation 2.6, le patch PW
f,xi
possède le double rôle de patch de référence (utilisé
pour définir la similarité entre deux patchs) et de patch estimateur (combiné pour définir
la moyenne). Ce pixel particulier possédera donc un poids plus important que les autres
pixels de l’image biaisant par la même occasion l’estimateur non local. Pour résoudre
ce problème, Buades et coll. [BCM05] suggèrent de le remplacer par le poids maximal
des autres pixels utilisés dans la somme. Cette solution n’est pas vérifiée théoriquement,
mais permet d’obtenir de bons résultats pratiques. Zimmer et coll. [ZDW08] proposent
d’annuler l’influence de ce patch particulier. Néanmoins, une telle solution ne permet
pas de concilier le double rôle du patch central. Salmon [Sal10b] résout ce problème en
supprimant la variance du bruit dans la distance euclidienne utilisée pour comparer les
patchs. Ainsi, tout patch qui possède une distance inférieure à la variance du bruit possède
un poids égal à 1.12
Facteur d’autosimilarité
Le facteur d’autosimilarité h définit le degré de similarité des échantillons. Il est choisi de
manière globale et peut être assimilé à la quantité de flou des méthodes locales. Le choix
d’une valeur globale pour ce facteur reste dfficile à choisir, en effet certaines textures de
l’image sont plus redondantes que d’autres. Ce paramètre est donc généralement estimé
par une analyse heuristique sur un ensemble représentatif d’images. Des estimations de h
basées sur l’estimateur SURE (Stein’s Unbiased Risk Estimate) sont néanmoins calculées
globalement par Van et coll. [VDVK09] et localement par Duval et coll. [DAG10].
Taille des patchs
La taille des patchs W correspond au niveau de détail à utiliser pour définir la similarité
entre deux patchs. Augmenter l’échelle W permet de définir une mesure de similarité plus
robuste et moins dépendante du bruit. Malheureusement, cela limite le nombre de patchs
similaires utilisés pour le débruitage et augmente le temps de calcul des NL-Means.
Par conséquent, la taille W doit être idéalement choisie en fonction de la quantité de
bruit et de l’image à traiter. Généralement, elle est déterminée par une analyse statistique
effectuée sur une base d’images représentatives.
Zones de recherche
Initialement, le voisinage N(xi) a été introduit comme un moyen d’accélérer l’estimation
des NL-Means [BCM05]. En effet, le temps de calcul est directement proportionnel au
nombre d’échantillons utilisé par l’Équation 2.6. Nous pourrions penser qu’augmenter la
taille du voisinage améliorerait la qualité de restauration. En effet, nous obtiendrions dans
ce cas un nombre de patchs similaires plus élevé. Malheureusement, nous augmenterions
par la même occasion le nombre de mauvais candidats susceptibles de parasiter le résultat
final. Pour résoudre ce problème, Kervrann et coll. [KB06] proposent de définir un voisinage
adaptatif permettant de récupérer un plus grand nombre de patchs similaires sans
introduire un trop grand nombre de mauvais représentants.
2.2.2 Limitations et améliorations des NL-Means
Les NL-Means sous leur forme originale présentent des limitations. De nombreux travaux
ont été proposés pour enrichir le modèle de départ afin de corriger ces problèmes tout en
améliorant les performances qualitatives et temporelles de la restauration.
L’un des problèmes principaux des NL-Means vient de la redondance des patchs. En effet,
nous avons supposé que le patch était suffisamment bien représenté pour pouvoir être
débruité correctement. Malheureusement, il arrive que certains pixels de l’image soient
moins bien représentés que d’autres. Une première catégorie de méthodes propose entre
autres d’augmenter le nombre de patchs similaires en utilisant le caractère autosimilaire
local des images naturelles [Ale05]. Plusieurs approches [ZDW08, JCSX09] utilisent une
analyse des moments robuste aux bruits afin de rendre les patchs invariants par rotation.2.2. FILTRES À MOYENNES NON LOCALES 13
D’autres travaux [BCM05] suggèrent l’utilisation d’espace échelle afin de simuler l’invariance
par changement d’échelles. Dans ce cas, les patchs calculés sur les différentes images
sous-échantillonnées sont ajoutés à l’ensemble des patchs utilisé classiquement.
La mesure de similarité est faite sur un ensemble de patchs bruités. Idéalement, cette
dernière devrait être effectuée sur des patchs non bruités. Ces données étant inaccessibles,
Buades et coll. [BCM05] ont proposé l’utilisation de la distance euclidienne, car elle permet
d’être peu dépendant du bruit de l’image. D’autres méthodes [BC07,BKC08] proposent de
calculer la similarité sur les patchs débruités de manière itérative. Ces NL-Means itératifs
débruitent l’image en utilisant une mesure de similarité calculée sur des patchs extraits de
l’image qui a été débruitée à l’itération précédente. En d’autres termes, ce type d’approches
permet un regroupement des patchs en fonction de la ressemblance du voisinage débruité
à l’itération précédente.
À l’origine, les patchs utilisés sont centrés sur le pixel d’intérêt xi
. Dans le cas d’un patch
contenant un contour de l’image, la mesure de similarité risque d’être biaisée et donc de
favoriser un côté du contour par rapport à l’autre. Ce phénomène d’adhérence introduit des
poids parasites dans la combinaison finale des pixels. Il en résulte une apparition de halos
autour des bords de l’image. D’autres méthodes [DFKE07, DFKE08, DFKE09, LBM13]
proposent d’utiliser des patchs carrés décentrés pour corriger ces halos en reformulant
l’Équation 2.6 d’une manière équivalente par :
Pˆ W
f,xi =
X
xj∈N(pi)
φ(kP
W
f,xi − P
W
f,xj
k
2
/h2
)P
W
f,xj
(2.8)
L’estimation finale est définie en effectuant des moyennes sur les estimateurs [SS12]. Ce
type de solutions permet d’étendre l’agrégation d’estimateurs [Nem00] au cas des patchs.
Parmi ces méthodes, Deledalle, Salmon et Duval [DDS12] proposent en particulier l’utilisation
d’un estimateur SURE (Estimateur de risque sans biais de Stein - Stein’s Unbiased
Risk Estimate) couplée à l’utilisation de patchs de différentes formes (non carrés). Cette
idée (utilisée de manière similaire par Baraniuk et coll. [MNB12]) permet de tirer parti
de la géométrie locale de l’image tout en étant peu victime du phénomène d’adhérence.
Salmon [Sal10a] propose une étude plus détaillée concernant l’agrégation d’estimateurs
dans le cas des NL-Means.
En plus de ces facteurs limitant la qualité de restauration de l’image, l’un des problèmes
majeurs des NL-Means reste son temps de calcul. De nombreuses approches ont été proposées
afin d’accélérer l’estimation. Certaines proposent une estimation approchée des plus
proches patchs [BSFG09,OA12,KA11,Tas09,HS12], une approximation de l’image filtrée
par regroupement de patchs similaires [AGDL09,ABD10,HST10,GO12], etc. Une analyse
plus détaillée de ce point de l’état de l’art sera proposée en Section 4.1.1.
La simplicité et les performances des NL-Means ont favorisé la généralisation des filtres
non locaux à de nombreux domaines connexes tels que l’imagerie satellitaire [DDT09], la
vidéo [BCM08,AGDL09], l’imagerie médicale [MCCL+08], etc. Nous focaliserons la suite
de notre analyse sur le traitement 3D.14
Figure 2.3: Nous présentons plusieurs exemples de surface numérisée à partir d’objet
réels d’origine humaine. Tous ces objets peuvent être considérés comme autosimilaires du
fait qu’ils présentent un ensemble de structures redondantes. Une telle hypothèse peut être
faite pour la plupart des objets d’orgines humaine ou naturelle.
2.3 Filtres 3D non locaux
Une chaîne d’acquisition 3D permet d’obtenir une surface maillée à partir d’un objet réel.
Cette dernière peut être résumée par deux principales étapes : l’étape d’acquisition et
l’étape de reconstruction. Tout d’abord, l’étape d’acquisition définit à partir de l’objet
réel un nuage de points 3D. Pour ce faire, cette étape utilise généralement des capteurs
automatiques (par ex. systèmes d’acquisitions Kinect), des appareils photo et/ou camé-
ras vidéo couplés à des méthodes de stéréovision [BBH08,BBB+10,BHB+11], etc. Lors de
cette étape, le nuage de points obtenu peut être dégradé par du bruit, des trous, des points
aberrants et/ou des taux d’échantillonnages variables. Ensuite, l’étape de reconstruction
permet de définir une surface maillée à partir du nuage de points acquis. Plusieurs mé-
thodes peuvent être utilisées telles que les Marching Cubes [LC87], la reconstruction de
Poisson [KBH06], etc.
Si elles ne sont pas traitées correctement, les dégradations introduites lors de l’étape d’acquisition
parasitent la reconstruction de la surface maillée. Durant ces dernières années, les
méthodes de débruitage ont donc été particulièrement utilisées afin de corriger les erreurs
apportées par la chaîne d’acquisition. Nous pouvons diviser ces méthodes en deux principales
catégories. La première catégorie, que nous appellerons filtres de nuages de points
est appliquée sur le nuage de points 3D obtenu en amont de l’étape de reconstruction.
Ces filtres permettent d’obtenir une surface maillée résultante de meilleure qualité. La
deuxième, appelée filtre surfacique, est appliquée sur la surface maillée obtenue en aval de
l’étape de reconstruction. Ces filtres sont utilisés dans le cas où l’utilisateur ne peut pas
avoir accès à la chaîne d’acquisition.
La plupart de ces méthodes ont été inspirées des avancées en traitement des images [FDCO03,
JDD03,VB11]. Des hypothèses similaires à celles utilisées pour les images peuvent en effet
être faites concernant les données 3D. En particulier, ces dernières sont considérées de nature
autosimilaire, car elles sont généralement issues d’objets réels d’origines naturelles ou
humaines et possèdent de nombreuses primitives et structures redondantes (Figure 2.3).
Les méthodes non locales ont donc logiquement été adaptées afin d’améliorer la qualité
de la restauration 3D. Pour ce faire, ces dernières nécessitent la définition d’un signal à
débruiter et d’une mesure de similarité adaptée aux données 3D considérées. Contrai-2.3. FILTRES 3D NON LOCAUX 15
rement aux images qui possèdent un échantillonnage régulier et une définition de signal
bruité évidente, les données 3D ne possèdent pas de support pouvant être utilisé pour les
deux définitions précédentes. Plusieurs solutions ont donc été introduites dans le cas des
surfaces et des nuages de points pour définir des notions équivalentes.
2.3.1 Filtres surfaciques non locaux
Yoshizawa et coll. [YBS06] étendent les NL-Means aux filtrages surfaciques comme un
moyen de supprimer les dégradations tout en préservant les structures principales de la
surface maillée. Ils proposent une approche itérative basée sur [FDCO03] qui déplace les
points du maillage xi dans la direction de la normale n(xi). Ce déplacement est calculé
comme une combinaison des valeurs < xi − xj , n(xi) > des points xj ∈ N (xi) compris
dans un voisinage de xi pondérées par rapport à la similarité des surfaces locales autour de
xi et de xj . Dans ce cas, l’utilisation de Radial Basis Functions (RBF) permet de définir
une interpolation de la surface ainsi qu’un repère de comparaison normalisé.
Wang et coll. [WCZ+08] proposent une démarche similaire à [YBS06] en remplaçant la
mesure de similarité sur les RBF par une mesure plus proche des NL-Means classiques
qui utilisent des patchs. Ainsi, ils introduisent un repère normalisé local défini par le plan
tangent à la surface au point du maillage xi orienté par rapport à l’analyse en composantes
principales des points compris dans le voisinage de xi
. Dans ce repère, ils définissent des
patchs de la variation géométrique locale de la surface. Ils utilisent une grille régulière
centrée sur xi dont les valeurs sont calculées en interpolant la hauteur des points du
maillage du voisinage. Pour accélérer le temps de calcul et obtenir de meilleurs résultats,
ils proposent d’effectuer un regroupement des points du maillage par Meanshift [CM02].
Adams et coll. [AGDL09] introduisent leur propre filtre surfacique non local comme une
application de sa structure d’accélération de filtres à hautes dimensions. Ils proposent
d’utiliser une surface de référence. Cette dernière, calculée par application itérative du
filtre laplacien sur le maillage, permet d’associer à chaque point du maillage une valeur
bruitée (correspondant à l’écart entre la surface bruitée et la surface de référence). Dans
leur approche la similarité est calculée en utilisant des histogrammes 2D représentant la
répartition locale des points bruités du maillage appartenant aux différentes zones d’un
descripteur cylindrique.
Morigi et coll. [MRS12] proposent un filtre surfacique différent capable de préserver les
structures principales du maillage par un débruitage non local de la courbure moyenne.
Dans ce cas la mesure de similarité de la géométrie locale est définie par rapport à un
descripteur basé sur la courbure moyenne locale.
2.3.2 Filtres non locaux de nuage de points
Malgré les bonnes performances des filtres surfaciques non locaux, il reste difficile de
corriger les dégradations de l’acquisition après reconstruction de la surface maillée. En
effet, une partie de l’information contenue dans le nuage de point 3D est perdue à ce
moment de la chaîne d’acquisition. Par conséquent, il semble plus judicieux de filtrer le
nuage de points 3D avant de reconstruire une surface. Contrairement aux surfaces maillées,16
les nuages de points 3D ne possèdent aucune information de structure. Cette dernière
est malheureusement indispensable pour définir un signal à débruiter et une mesure de
similarité appropriée indispensables à toute restauration non locale.
Pour résoudre ce problème, Deschaud et coll. [DG10] suggèrent l’utilisation de méthodes de
projection par moindres carrés glissants (Moving Least Square - MLS) [Lev98,ABCO+01]
qui définissent localement une surface à partir d’un nuage de points. Leur approche peut
être résumée par trois principales étapes. Tout d’abord, ils définissent pour chaque point du
nuage un système de coordonnées local défini à partir des vecteurs associés aux deux plus
grands vecteurs propres de la covariance des points. Ensuite, les variations de la surface
autour du point d’intérêt sont approchées localement par un polynôme bivarié exprimé
dans ce repère. Finalement, la position débruitée est estimée comme une combinaison
des points proches pondérée par la similarité de leur polynôme bivarié. Cette démarche
appliquée à chaque point du nuage permet d’obtenir le nuage débruité. Malheureusement,
comme le démontre [Dig12], la paramétrisation du repère local n’est pas suffisamment
stable.
Digne [Dig12] propose de décomposer le nuage de points en une surface grossière et un
champ scalaire bruité en utilisant un filtre isotropique [DMSL11]. Elle propose ensuite de
filtrer le champ scalaire par NL-Means. Pour ce faire, elle utilise un patch qui décrit les
variations locales de la surface définie dans un repère local. La paramétrisation du repère
local est calculée à partir d’une analyse en composantes principales des normales du nuage
plus robuste aux variations de la surface [DM11]. Les valeurs du patch sont calculées par
une interpolation sur une grille des hauteurs des points voisins par RBF.
Plus récemment, une méthode de débruitage de nuage de point par analyse spectrale
collaborative de patchs a été introduite [RDK13]. Ces patchs utilisent un opérateur de
Laplace-Beltrami afin débruiter le nuage d’une manière robuste.
2.3.3 Limitations
Les méthodes non locales ont été introduites pour améliorer la correction des dégradations
introduites lors de l’étape d’acquisition. Ces approches ont été définies pour être utilisées
sur deux types de données : la surface maillée, corrigeant ainsi les erreurs introduites par
l’utilisation d’un nuage de points dégradé lors de l’étape de reconstruction ; le nuage de
points, avant que la surface ne soit définie.
En utilisant la méthode de débruitage surfacique, il devient difficile de récupérer l’information
dégradée, car une partie a été perdue lors de la phase de reconstruction. Par
conséquent, il est préférable d’utiliser les méthodes de débruitage de nuages de points.
Néanmoins, dans ce cas, la reconstruction ne permet pas d’exploiter correctement l’ensemble
de l’information présente dans le nuage de points. En particulier, la propriété
autosimilaire du nuage n’est pas exploitée par la reconstruction de la surface.
Nous introduisons au Chapitre 3 un nouvel opérateur capable de définir une surface implicite
qui exploite correctement le caractère autosimilaire du nuage de points. Nous utilisons
ce dernier pour définir des surfaces maillées, le débruitage de nuage de points et l’intensi-
fication des structures de l’objet.2.4. FILTRES COLLABORATIFS 17
Approche des NL-Means Approches collaboratives
Figure 2.4: Principe des filtres collaboratifs : Nous considérons ici un ensemble d’individus
possédant chacun une caractéristique bruitée (cercle interne à chaque individu). Pour les
NL-Means, un individu ( cercle rouge) utilise les caractéristiques que lui transmettent les
individus voisins (cercle discontinu) pour restaurer la valeur de sa propre caractéristique.
Une telle approche peut utiliser des individus qui ne font pas nécessairement partie de la
même famille que l’individu considéré. Dans le cas des filtres collaboratifs, les individus
sont regroupés en familles (cercles en pointillé). L’information sur les caractéristiques des
individus d’une même famille est mise en commun (cercle bleu au centre de chaque famille),
analysée puis retransmise à l’ensemble des individus de la famille. Dans ce cas, toutes les
valeurs des individus d’une même famille sont restaurées en même temps en utilisant une
information partagée par la famille uniquement.
2.4 Filtres collaboratifs
Les récents travaux sur les filtres non locaux ont permis une généralisation des NL-Means à
des domaines d’applications différents de ceux de la restauration d’images et une évolution
de ces principes originaux pour une meilleure exploitation de la redondance de l’information.
De plus en plus, ces évolutions ont rapproché la restauration non locale d’un autre
genre de filtrage : le filtrage collaboratif.
2.4.1 Principe
Le filtrage collaboratif est un procédé de filtrage de l’information utilisant des techniques
qui impliquent une collaboration entre de multiples agents, points de vue, sources de données,
etc. À l’origine, ces derniers ont été particulièrement utilisés dans le domaine de
l’e-commerce comme un système de recommandation automatique à partir d’une connaissance
de l’intérêt d’un grand nombre d’utilisateurs. De manière générale, ces méthodes
consistent à prédire une information inconnue d’un individu (débruitage, complétion, etc.)
par une analyse détaillée d’un groupe de personnes qui possède des caractéristiques communes
à l’individu considéré. Ce genre d’idées diffèrent d’approches plus simples qui four-18
nissent un score moyen non spécifique exprimant l’intérêt d’un ensemble d’utilisateurs
(basé par exemple sur le nombre de votes).
Ce principe de filtrage a été généralisé au traitement des images par [DFKE07]. L’idée
principale dans ce cas consiste à rassembler les patchs similaires par famille puis de les
débruiter en utilisant l’information commune de la famille à laquelle ils appartiennent. Pour
bien comprendre la différence entre NL-Means et les méthodes collaboratives, considérons
un ensemble d’individus chacun associé à une caractéristique bruitée. Pour les deux types
de méthodes, le but est de débruiter chaque caractéristique à l’aide d’autres individus
(Figure 2.4). Dans le cas des NL-Means, elle est débruitée en combinant les caractéristiques
des individus proches. L’individu en question ne retransmet aucune information qu’il a pu
récupérer de ses voisins. Pour les filtres collaboratifs, les individus sont d’abord regroupés
par familles d’individus proches. Ensuite, les individus d’une même famille se mettent
d’accord mutuellement sur les valeurs débruitées de leurs caractéristiques respectives. En
opposition aux filtres collaboratifs classiques, la collaboration en traitement d’image vient
d’une analyse commune du groupe de patch qui est ensuite utilisée pour améliorer la qualité
de la restauration. Ce type de filtre permet de révéler les détails partagés par l’ensemble du
groupe tout en conservant les caractéristiques uniques de chaque patch. Le patch obtenu
est donc plus proche de la position originale qu’en le débruitant par NL-Means.
2.4.2 Méthodes de restauration collaboratives
Dabov et coll. [DFKE07,DFKE08,DFKE09] sont les premiers à introduire le filtrage collaboratif
pour la restauration des images. Leur méthode, appelée BM3D (Block Matching
and 3D Filtering), se base sur trois principales étapes. Tout d’abord ils empilent les patchs
en les regroupant en fonction de leurs similarités de sorte à former des piles de patchs. Ensuite,
cette pile 3D est débruitée en gardant les fréquences principales d’une transformée
(ondelettes, transformées en cosinus discret) appliquées sur la pile. Un filtrage appliqué sur
cette troisième dimension permet de garder les caractéristiques communes de la famille
tandis que le filtrage des deux autres dimensions permet de garder les caractéristiques
spécifiques à chaque patch. Ainsi, la collaboration vient du fait que les patchs d’une même
famille sont débruités conjointement en considérant l’analyse globale de la pile. Finalement,
les patchs débruités sont agrégés de sorte à définir les valeurs débruitées de l’image.
Ces trois étapes sont itérées deux fois afin d’améliorer la qualité finale du débruitage.
BM3D constitue l’une des méthodes applicatives les plus performantes actuellement pour
le débruitage d’images. Néanmoins, l’influence de ces nombreux paramètres reste difficile
à analyser.
Yu et coll. [YSM12] proposent d’étendre le principe des filtrages collaboratifs à d’autres
problèmes inverses tels que le débruitage, l’amélioration de la résolution ou d’inpainting
en introduisant l’estimateur linéaire par morceaux (Piecewise Linear Estimator - PLE).
Leur idée basée sur les travaux sur les structures parcimonieuses [MBP+09] approxime
l’ensemble des patchs par un modèle de mélange de gaussiennes (Gaussian Mixture Model
- GMM). Les gaussiennes sont ajustées à l’ensemble des patchs inconnus à restaurer via
une Maximisation A Posteriori (MAP) qui utilise un algorithme d’espérance-maximisation
(Expectation Maximisation - EM) itératif. Pour cette méthode il est difficile de trouver le
bon nombre de classes des GMM ainsi qu’une bonne initialisation afin que la procédure2.4. FILTRES COLLABORATIFS 19
EM converge vers un bon minimum de la fonction objectif non convexe. En pratique, le
nombre de gaussiennes est fixé à l’avance à environ une dizaine afin de garder la complexité
du calcul sous contrôle.
Quand l’ensemble des patchs est corrompu par un bruit gaussien de variance σ
2
, l’Équation
2.6 des NL-Means peut être reformulée comme une Espérance A Posteriori (EAP)
bayésienne. Lebrun et coll. [LBM13] reformule les NL-Means pour définir les Non Local
Bayes (NLB) en remplaçant la formulation EAP des NL-Means par une Maximisation A
Posteriori (MAP). Désormais en plus de la moyenne non locale, chaque patch est associé
à une matrice de covariance Σ décrivant la variabilité au sein du groupe de patchs. La
covariance étant bruitée, le côté collaboratif de ce filtre vient du fait que tous les patchs
sont débruités conjointement par l’opération de filtrage de la covariance Σ˜ = Σ−σ
2
Id. En
utilisant une approche similaire aux BM3D, le patch est débruité en deux étapes : la première
étape débruite à partir de variations estimées sur les patchs bruités et la deuxième
à partir des patchs débruités à la première étape. Tout comme BM3D, une phase d’agré-
gation permet de définir un meilleur débruitage des pixels de l’image. Nous proposons
en Section 5.1.1 plus de détails concernant les NLB. Les NLB permettent actuellement
d’obtenir les meilleures performances de débruitage. Néanmoins, leur approche nécessite
une grande quantité de calcul dans la mesure où un modèle gaussien local a besoin d’être
appris deux fois autour de chaque patch. Pour être calculable, l’estimation du voisinage
est approchée par une recherche des k plus proches voisins dans l’espace des patchs.
2.4.3 Généralisation des filtres collaboratifs
Durant ces dernières années, la formulation collaborative des méthodes de débruitage a
permis d’améliorer significativement la qualité de la restauration d’images bruitées. Le
principe introduit par BM3D [DFKE07, DFKE08, DFKE09] a ensuite été amélioré par
NLB [LBM13] en remplaçant la formulation EAP des NL-Means par une formulation
MAP qui permet de mieux récupérer les structures communes d’un groupe de patchs similaires
tout en préservant ses caractéristiques spécifiques. Néanmoins, de telles approches
nécessitent une grande quantité de calculs et sont généralement simplifiées pour pouvoir
être calculables.
De plus, PLE [YSM12] a proposé une généralisation des filtres collaboratifs à d’autres
applications du traitement des images. Cette solution offre d’excellentes performances,
mais utilise une GMM simplifiée pour pouvoir obtenir de bons résultats dans un temps
raisonnable. Par conséquent, une telle approche semble difficilement applicable sur de
grands ensembles de données.
Nous introduisons au Chapitre 4 une nouvelle structure de données capable d’apprendre
les variations d’un grand ensemble de points avec une quantité de mémoire limitée. Elle
représente les variations des données apprises en n’importe quelles positions et échelles
de l’espace des patchs par une gaussienne anisotropique. Une telle structure est définie
comme une approche hybride entre PLE et NLB.
Nous utilisesons cette structure au Chapitre 5 pour reformuler des problèmes de restauration
2D et 3D d’un point de vue d’une MAP collaborative. En outre, nous apprendrons20
les variations de grandes bases de données avec une quantité de mémoire limitée afin de
mieux restaurer des données dégradées.C h a p i t r e 3
Surface de points non locale
Dans ce chapitre, nous proposons de définir la première surface qui exploite l’autosimilarité
présente dans un nuage de points (Non Local Point Set Surfaces — NLPSS). Nous
commencerons par décrire dans la Section 3.1 une généralisation des méthodes de surface
de points. En Section 3.2, nous introduisons notre opérateur de projection non local ainsi
que l’ensemble des outils nécessaires à sa définition. Nous montrerons en Section 3.3 que
notre approche permet de retrouver les caractéristiques importantes de l’objet tout en
comblant l’information manquante par une augmentation locale du ratio signal sur bruit.
Finalement en Section 3.4, nous proposons différentes améliorations possibles pour notre
opérateur non local.
3.1 Contexte
3.1.1 Acquisition 3D
Avec la démocratisation des appareils d’acquisition 3D, il est devenu aujourd’hui facile de
numériser des objets réels avec une haute précision. Généralement sous la forme de nuages
de points bruts corrompus par du bruit, des points aberrants, des trous et/ou des taux
d’échantillonnages variables, ces acquisitions doivent être traitées pour définir des surfaces
maillées exploitables.
Les méthodes basées points ont donc été introduites comme un moyen d’améliorer la
qualité des données acquises sans pour autant faire de choix concernant la nature de la
surface sous-jacente. Les surfaces de nuages de points (Point Set Surfaces — PSS) ont été
définies en ce sens, et permettent de faire le lien entre les nuages de points et les surfaces
maillées. Elles introduisent une représentation surfacique lisse non maillée essentiellement
définie par l’ensemble des points fixes d’un opérateur de projection.
3.1.2 Travaux existants
Alexa [ABCO+01] introduit initialement les PSS en se basant sur les travaux de Levin
[Lev98,Lev03] qui étend une classe de méthodes d’approximation fonctionnelles de don-
2122
nées parcimonieuses — les moindres carrés glissants (Moving Least Squares - MLS) [She68]
— au cas d’approximation de formes. Cette première version des PSS est définie par l’intermédiaire
d’un opérateur de projection itératif. À chaque étape, un point d’évaluation
est projeté sur une surface localement définie par un polynôme bivarié paramétré sur
un plan qui approxime les données. Ces deux derniers sont estimés localement par une
minimisation non linéaire du carré de la distance des données aux points d’évaluation.
Amanta et coll. [AK04] démontre qu’il est possible de définir une surface d’aussi bonne
qualité en effectuant une moyenne pondérée des positions, sans utiliser de polynôme bivarié
ou de minimisation non linéaire. Ils introduisent une fonction de distance signée
permettant une représentation implicite de la surface. Cette représentation peut être utilisée
par différents algorithmes de remaillage comme les Marching Cubes [LC87] ou une
triangulation de Delaunay restreinte [BO05] pour définir une surface polygonale.
Adamson et coll. [AA04a] exploitent cette idée pour introduire un modèle simple de surface
de nuages de points (Simple Point Set Surfaces — SPSS). Dans le cas de nuages de points
munis de normales, le plan local de projection peut être estimé par une combinaison linéaire
pondérée des positions et des normales. Si le nuage de point ne comporte pas de normales,
une analyse en composantes principales [HDD+94] permet d’équiper chaque point du nuage
avec une normale estimée. Avec les SPSS, Adamson [AA04b] introduit trois procédures
différentes pour estimer itérativement la projection d’un point sur la surface : l’orthogonale
qui projette le point d’évaluation précisément au terme de calculs sophistiqués, la basique
d’une faible complexité, mais peu précise, et l’orthogonale approximative qui constitue un
bon compromis entre simplicité et précision.
Fleishman et coll. [FCOS05] améliorent cette définition en introduisant une formule implicite
des moindres carrés glissants (Implicit Moving Least Squares - IMLS) qui préserve les
bords anguleux de la surface. Alexa et Adamson [AA09] proposent une surface de point
hermitienne (Hermite Point Set Surfaces — HPSS) qui limite les effets de réduction des
méthodes précédentes. Au lieu de projeter le point sur un seul plan, il est projeté sur
l’ensemble des plans définis par chaque échantillon voisin. Ensuite la position est calculée
par une combinaison pondérée de ces différentes projections permettant de définir une
combinaison hermitienne.
La procédure d’estimation du plan peut devenir rapidement instable quand le nuage de
points n’est pas assez dense par rapport à la taille du support de l’opérateur ou quand
les taux d’échantillonnage du nuage de points sont trop variables. Guennebaud et coll.
[GG07] proposent de remplacer le plan par une sphère algébrique définissant une nouvelle
surface de points algébrique (Algébraic Point Set Surfaces — APSS). Ce modèle est ensuite
amélioré en contraignant les gradients de la sphère algébrique à correspondre aux normales
des échantillons [GGG08].
Les méthodes précédentes ne sont pas adaptées pour définir une surface à partir d’un nuage
de points corrompu par des points aberrants. En utilisant une méthode de régression par
noyau qui ajuste itérativement les poids de chaque échantillon, Öztireli et coll. [ÖGG09] introduisent
une nouvelle formule implicite et robuste des moindres carrés glissants (Robust
Implicit Moving Least Square - RIMLS). En plus d’une résistance aux points aberrants,
cette définition permet une meilleure préservation des caractéristiques de la surface. Nous
vous renvoyons vers [CWL+08] pour un état de l’art plus complet sur les surfaces MLS.3.1. CONTEXTE 23
Figure 3.1: Gauche : Le SPSS [AA04a] définit une surface à partir d’un nuage de points
X muni de normales par l’intermédiaire d’un opérateur Π qui projette pour tout x ∈ R
3
sur
un plan estimé localement de normale n(x). Droite : L’opérateur de projection Π introduit
une fonction implicite f(x) dont l’ensemble des valeurs nulles définissent la surface de
l’opérateur (en orange).
3.1.3 Généralisation des PSS
Jusqu’à la fin de ce chapitre, nous considérerons comme entrée des PSS un nuage de points
X = {xi
, ni} où xi ∈ R
3
correspond à la position spatiale d’un point et ni ∈ R
3
est la
normale qui lui est associée. D’après la procédure de projection orthogonale approximative
introduite par Adamson et Alexa [AA04b], l’ensemble des définitions PSS précédentes
peuvent s’exprimer à l’aide d’un opérateur de projection Π :
MLSX : R
3 → R
3
, x → Π(x) (3.1)
Chaque point d’évaluation x est projeté sur une primitive Q localement estimée par
moindres carrés (e. g. plan pour le SPSS, sphère algébrique pour l’APSS) :
Π(x) = x − f(x)n(x) (3.2)
Cette formulation permet de mettre en évidence la distance implicite f(x) entre x et sa
projection sur Q et n(x) la normale PSS définie en cet emplacement. Q est paramétrée
sur X par rapport à x à une échelle t liée à la taille du support choisie pour le noyau de
pondération spatial sous-jacent.
Par exemple dans le cas des SPSS (Figure 3.1), cette définition générale peut être exprimée
par :
n(x) =
P
xi∈X wt(x, xi)ni
k
P
xi∈X wt(x, xi)nik
c(x) =
P
xi∈X wt(x, xi)xi
P
xi∈X wt(x, xi)
f(x) =< x − c(x), n(x) >24
Figure 3.2: Gauche : les opérateurs PSS conventionnels définissent la surface en considé-
rant un voisinage local. Face aux conditions réelles de capture, ce point de vue purement
local devient insuffisant pour définir une surface correcte. Droite : le principe de notre
algorithme est d’exploiter le caractère autosimilaire des nuages de points pour augmenter
localement le ratio signal sur bruit et ainsi proposer une définition de surface plus adaptée
aux conditions de capture.
Le noyau de pondération spatial wt(x, xi) est généralement défini à partir d’une fonction
à support compact polynomiale par morceaux g :
wt(x, xi) = 1
Zt(x)
g(
1
t
kx − xik)
Zt(x) est choisie de manière à assurer la somme unitaire des poids P
xi∈X wt(x, xi) = 1.
Le paramètre t associé à wt correspond au paramètre de filtrage de la surface : plus t
est grand, plus la surface résultante est lisse. Faire varier t permet de décomposer le PSS
à différentes échelles. Au cours de ce chapitre, nous appellerons respectivement Πt
(x),
f
t
(x) et n
t
(x) l’opérateur de projection, la distance implicite et la normale définie par
l’opérateur PSS à cette échelle t.
3.1.4 Problématique
Dans tous les modèles PSS, le choix de la taille du support du noyau spatial induit la
qualité de la surface résultante : une taille élevée lissera la surface en éliminant les défauts
introduits lors de l’acquisition, et à l’opposé une taille fine fera ressortir les détails importants
de l’objet sans débruiter la surface. Malheureusement, il est difficile de trouver une
taille de support idéale pour satisfaire le compromis lissage/préservation des caractéristiques
de l’objet car le problème est restreint à un point de vue strictement local.
Pour résoudre ce problème de manière adéquate, nous proposons de ne plus nous limiter
à un point de vue strictement local, mais d’utiliser l’information apportée par l’ensemble
du nuage lors de la projection d’un point d’évaluation. Comme le montre la Figure 3.2,
une telle approche permet d’augmenter le ratio information/bruit et ainsi de résoudre les
ambiguïtés dues aux défauts du nuage de points.
Ainsi, nous proposons de définir une surface de points non locale (Non Local Points Set
Surfaces — NLPSS) qui possède les avantages suivants :3.2. SURFACES DE POINTS NON LOCALES 25
1. Définition d’une surface non locale : Notre définition n’est pas restreinte au
débruitage de nuages de points dans le sens où nous proposons un nouvel opérateur
PSS exploitant l’autosimilarité du nuage et qui peut être utilisé pour de la reconstruction,
du débruitage et d’autres traitements plus génériques sur un ensemble non
organisé du nuage de points.
2. Généralisation : Nous proposons une extension de toutes les méthodes PSS précé-
dentes en leur incorporant une propriété non locale.
3. Dégénérescence : Notre définition dégénère en la définition traditionnelle du PSS
sur lequel il se base dans le cas de faible autosimilarité.
3.2 Surfaces de points non locales
Dans cette partie nous allons définir notre opérateur non local de surface de points. Pour
pouvoir introduire cette définition, nous introduirons trois notions :
1. Signal : De par la nature non structurée des nuages de points, il n’est pas possible
de définir un signal en considérant directement leur positions spatiales des points
du nuage. Nous introduirons un signal adapté qui contient les défauts du nuage sur
lequel nous appliquerons les méthodes non locales.
2. Descripteur local : La comparaison de deux sous-ensembles d’un nuage de points
doit être peu sensible à la nature des nuages de points et aux défauts introduits
lors de l’acquisition. Nous définirons un descripteur local adapté au nuage de points
défini dans un repère local normalisé.
3. Fonction de pondération : Nous proposerons une fonction de pondération tenant
compte de la quantité d’information non locale qui est présente.
3.2.1 Principe général
En considérant une échelle t0 suffisamment large, le PSS peut être décomposé en une surface
grossière St0
et un champ scalaire de déplacement résiduel m(xi)n
t0 (xi) qui contient
les caractéristiques du nuage de points contaminées par le bruit. L’idée principale de notre
approche est d’utiliser les méthodes non locales pour supprimer le bruit du champ scalaire
résiduel, et, simultanément, calculer la projection (interpolation) à une échelle fine pour
tous les points d’évaluation x ∈ R
3
.
Nous appliquons tout d’abord un opérateur de projection PSS local Πt0 à une échelle large
t0 pour définir une surface grossière St0
. Nous ajoutons ensuite à St0 un champ scalaire
de déplacement fin mNL(x)n
t0 (x) défini par une approximation non locale de la distance
résiduelle m(x) entre la surface grossière et la reconstruction de X . Les différentes étapes
de notre approche sont présentées figure 3.3.
Nous introduisons donc la première définition de surface de points non locale (Non Local
Point Set Surfaces — NLPSS) par l’opérateur de projection :
ΠNL(x) = Πt0
(x) − mNL(x)n
t0
(x) (3.3)
Nous présentons Figure 3.4 notre schéma de projection non local.26
+
Estimation non locale
PSS à échelle grossière
Figure 3.3: Nous utilisons un opérateur PSS grossier sur notre nuage de points d’entrée
X pour décomposer le signal en une surface grossière St0
(en vert) et un champ scalaire de
déplacement résiduel m. Ce dernier étant éventuellement bruité et défini seulement aux
points du nuage de points original, nous approximons ces valeurs en tout point de la surface
grossière mNL par une méthode non locale qui améliore la qualité de l’approximation
en exploitant le caractère autosimilaire du nuage. Notre surface non locale SNL est par
conséquent définie en ajoutant à la surface grossière le champ scalaire de déplacement
approximé.
3.2.2 Carte de déplacement
Le champ scalaire de déplacement m(x) est défini par la distance résiduelle entre la surface
grossière St0
et X . Pour tout x = xi ∈ X :
m(xi) = D
xi − Π
t0
(xi), n
t0
(xi)
E
= f
t0
(xi) (3.4)
Malheureusement, la nature parcimonieuse du nuage de points et les défauts introduits
par l’acquisition 3D font que le champ de déplacement est défini seulement pour les points
du nuage xi ∈ X et peut être bruité.
Dans le but de débruiter ces valeurs et d’étendre sa définition pour tous les points x ∈ R
3
,
nous considérons une moyenne pondérée non locale des m(xi) :
mNL(x) = X
xi∈X
wNL(x, xi)m(xi) (3.5)
Ainsi nous allons devoir introduire une mesure de similarité wNL entre les voisinages
locaux des deux points x et xi
. Pour cela, nous introduirons un descripteur 3D défini par
l’intermédiaire de repères locaux pour faciliter leur comparaison.
3.2.3 Fonction de pondération
Dans cette partie nous allons introduire une mesure de similarité entre deux sous-ensembles
du nuage de points. Par conséquent nous allons introduire un patch qui décrit localement3.2. SURFACES DE POINTS NON LOCALES 27
Figure 3.4: Notre définition permet de projeter tout point x ∈ R
3 par l’intermédiaire de
l’opérateur ΠNL. x est projeté dans un premier temps sur la surface grossière (représentée
en vert) en Πt0 (x). La projection ΠNL(x) sur la surface NLPSS (représentée en rouge)
est définie en ajoutant la valeur du champ scalaire de déplacement débruité mNL dans la
direction de la normale grossière n
t0 (x).
le champ scalaire de déplacement dans un repère normalisé tangent à la surface grossière
St0
.
Descripteur 3D
Figure 3.5: Gauche : Nous définissons la mesure de similarité entre deux sous-ensembles
du nuage de points par l’intermédiaire d’un patch de taille l = 5δ (où δ correspond à l’écart
moyen entre les points) avec n = 2 centré en Πt0
(x). L’ensemble des points qui composent
le patch sont disposés sur le plan tangent à la surface St0 définie par la normale nt0
(x).
Droite : Les valeurs du patch sont calculées en utilisant la surface St1
(en bleu). Les valeurs
colorées du patch représentent les différences locales entre St0
(en vert) et St1
.28
La définition de notre patch est présentée figure 3.5. Pout tout point x ∈ R
3
, notre patch
local de déplacement est défini par un ensemble de dimension (2n + 1) × (2n + 1) points
D = [[−n, n]]2 ⊂ Z
2
. Ces points sont localisés dans un carré de taille l × l défini par
l’intermédiaire d’un systeme de coordonnées local centré en xt0 = Πt0 (x) dont deux axes
définissent le plan tangent à la surface grossière en xt0
. Pour (i, j) ∈ D, chaque point xi,j
du patch a une valeur Pxt0
(i, j) correspondant à la valeur de déplacement m(xi,j ).
Comme nous l’avons expliqué section 3.2.2, les valeurs de la carte de déplacement ne sont
connues que pour les points du nuage x = xi ∈ X . Par conséquent, nous approximons les
valeurs de m(xi,j ) en utilisant un PSS local pour définir une surface St1
à une échelle fine
t1 ≪ t0. Ici, St1
représente une surface peu débruitée et interpolée de X .
Les valeurs Pxt0
correspondent donc à la projection des points du patch sur la surface fine
St1
:
Pxt0
(i, j) = f
t1
(xi,j ) ∀(i, j) ∈ D. (3.6)
Pour que la distance entre les points xi,j et St0
soit négligeable par rapport à Pxt0
, nous
choisissons la taille du patch l ≈
t0
3
.
Orientation du repère
Pour comparer les descripteurs locaux d’une manière similaire, nous introduisons un repère
orthonormé local (u, v, n
t0 ). Pour bien définir le patch de distance, les deux axes u, v
appartiennent au plan tangent à la surface grossière St0
au point xt0
. Par conséquent notre
patch est défini à une orientation près. Pour que cette dernière reste robuste au bruit et
au taux d’échantillonnage, nous la choisissons en fonction des directions principales de
courbures de la surface. Digne [Dig12,DM11] a montré qu’il était possible de les calculer
par une simple analyse en composantes principales des normales. Le vecteur propre associé
à la plus grande valeur propre est tangent à la direction principale.
Nous estimons la moyenne nm et la matrice de covariance Σn des normales en considérant
un sous-ensemble de points X˜ autour de xt0
:
nm =
1
|X | ˜
X
ni∈X˜
ni (3.7)
Σn =
1
|X | ˜
X
ni∈X˜
(ni − nm).
t
(ni − nm) (3.8)
Le vecteur propre u˜ associé à la plus grande valeur propre de la matrice de covariance Σn
n’appartient pas nécessairement au plan tangent à la surface St0
. Par conséquent, nous
redéfinissons les directions u et v par v =
n
t0∧u˜
knt0∧u˜k
et u =
v∧n
t0
kv∧nt0 k
. Désormais, le repère
(u, v, n
t0 ) est défini à une direction près.
Si nous définissons, les moments mk d’ordre k du patch par :
mk =
X
i,j
< (xi,j − xt0
), u >
k
. < (xi,j − xt0
), nt0 >
mk =
X
i,j
< (xi,j − xt0
), u >
k
.Pxt0
(i, j)
(3.9)3.2. SURFACES DE POINTS NON LOCALES 29
Nous utilisons le moment m1 d’ordre 1 pour lever l’ambiguïté sur la direction de u lors du
calcul du patch. La direction pour le vecteur u est obtenue de telle sorte que m1 > 0.
Mesure de similarité
1
0similarity
Figure 3.6: Résultats de notre mesure de similarité par rapport à un point appartenant
à un bord de l’objet (gauche) et à un point appartenant à un plan (droite) représenté dans
chaque cas en blanc. Les couleurs représentent la similarité entre le point de référence et
les autres points de l’objet, allant du rouge (très similaire) au bleu (peu similaire).
Pour deux points y, z ∈ R
3
, nous définissons la distance entre leurs patchs associés par :
d(y, z) = 1
2n + 1
kPyt0
− Pzt0
k2 (3.10)
La mesure de similarité correspondante est définie par l’intermédiaire d’un paramètre h :
wNL(y, z) = 1
ZNL(y)
exp
−
d(y, z)
2
h
2
!
(3.11)
La constante de normalisation ZNL(y) assure que P
xi∈X wNL(y, xi) = 1. Le paramètre h
permet d’ajuster la mesure en fonction de l’autosimilarité du nuage de points.
Nous présentons figure 3.6 les résultats de notre mesure de similarité entre un point de
référence et l’ensemble des points de l’objet.
3.2.4 Opérateur de projection non local
Notre opérateur de projection ΠNL(x) est défini en utilisant la distance implicite fNL(x)
d’un point x ∈ R
3 à la surface de points non locale :
ΠNL(x) = x − fNL(x)n
t0
(x) (3.12)
La distance implicite non locale est définie par :
fNL(x) = f
t0
(x) −
X
xi∈X
wNL(x, xi)m(xi) (3.13)30
Dégénérescence du noyau de pondération non local
Pour des points x dont le facteur d’autosimilarité est faible, notre définition aura tendance
à ne pas débruiter suffisamment le point résultant introduisant ainsi des artefacts dans la
définition de notre surface non locale. Dans ces cas-là, l’utilisation de PSS locaux semble
plus adaptée. Notre définition précédente peut être facilement modifiée pour tenir compte
de cette particularité. Pour cela, nous ajoutons au noyau non local wNL un noyau spatial
wt (correspondant à la définition locale des PSS). Notre nouveau noyau de pondération
w˜NL permet de combiner l’information locale et non locale par l’intermédiaire d’un facteur
de contrôle α :
w˜NL(x, xi) = 1
Z(x)
(αZt(x)wt(x, xi) + ZNL(x)wNL(x, xi)) (3.14)
La constante de normalisation Z(x) est choisie pour assurer une somme unitaire. Dans
cette formule, quand x fait partie d’un ensemble très représenté, le terme non local domine,
permettant d’augmenter la qualité du débruitage et d’améliorer la résolution. Au contraire,
si x appartient à une zone peu représentée, le terme spatial domine, assurant ainsi une
meilleure completion des trous du nuage. Le paramètre α permet de choisir l’impact du
noyau non local par rapport au noyau local dans la définition de la surface finale.
Noyau à support compact
Lors du calcul de la projection non locale, dû à l’utilisation d’un noyau gaussien, chaque
point xi ∈ X possède un poids wNL non nul. Par conséquent, la somme des points de poids
faibles ne peut plus être considérée comme négligeable. Ce phénomène est d’autant plus
important que le paramètre h est élevé (ce qui aura pour conséquence de rendre similaires
l’ensemble des patchs de l’image).
En traitement des images, cette somme est généralement réduite à un sous ensemble de
pixels locaux autour du point d’évaluation. Dans ce cas, l’impact des points similaires
dans la somme finale est plus significatif. Malheureusement, une telle démarche peut dif-
ficilement être appliquée au cas des nuages de points. En effet, il est plus intéressant de
considérer le nuage de points dans sa totalité permettant, par conséquent, de débruiter les
caractéristiques du nuage les plus rares.
Ainsi, pour limiter l’impact des points parasites, nous remplaçons le voisinage local par
l’ensemble des k patchs qui sont les plus similaires. Le poids des autres points du nuage
est imposé à zéro. Cette démarche permet à la fois d’obtenir des résultats d’une meilleure
qualité et une accélération du temps de calcul.
3.3 Résultats
3.3.1 Détails d’implémentation et performance
Nous avons implémenté notre algorithme en C++. La recherche des k plus proches patchs
telle que nous l’avons décrite section 3.2.4 est accélérée par l’utilisation d’un algorithme3.3. RÉSULTATS 31
Figure 3.7: Nuage de points original Fandisk (gauche) qui a été bruité par un bruit
uniforme (droite) permettant de simuler un système d’acquisition 3D de basse qualité.
de recherche approximatif des plus proches voisins : FLANN [ML12,ML09]. Pour mieux
représenter les différences des résultats, nous présenterons les surfaces NLPSS maillées
finement. L’entrée de notre algorithme restera malgré tout un nuage de points muni de
normales et non une surface maillée.
3.3.2 Analyse des paramètres
Dans cette partie nous allons présenter en détail l’influence des paramètres de notre opérateur
non local. Pour permettre une meilleure analyse des résultats, nous utiliserons, jusqu’à
la fin de cette section, le même objet Fandisk comme entrée des différents algorithmes. Le
nuage de points original a été bruité artificiellement avec un bruit uniforme de variance
égale à l’espacement moyen entre les points du nuage (Figure 3.7). Toutes les mesures
d’écart des surfaces résultantes seront effectuées par rapport au maillage original.
Échelle grossière
L’échelle grossière t0 est utilisée pour définir la surface grossière St0
ainsi que le champ scalaire
de déplacement résiduel bruité m(x). Pour que l’utilisation des méthodes non locales
ait du sens, cette dernière doit définir un signal autosimilaire bruité dont les variations
principales sont liées aux traits principaux de l’objet considéré. Nous présentons Figure 3.8
différents choix pour l’échelle t0 ainsi que le champ scalaire résiduel et les surfaces NLPSS
associées.
Le choix idéal pour l’échelle t0 (représenté en vert sur la Figure 3.8) est dépendant de la
quantité de bruit appliqué à l’objet. Si nous choisisson une valeur de t0 trop faible (cas
t0 = 5), la surface grossière résultante exhibera uniquement les structures de bruit locales
introduisant un champ scalaire dont les variations ne sont pas liées à l’aspect de l’objet
considéré. De la même manière, si t0 est trop large (cas t0 = 30) les lignes caractéristiques
de l’objet seront filtrées excessivement entraînant l’apparition de variations parasites dans
le champ de déplacement résiduel.32
Surface grossière Distance résiduelle
bruitée
Distance résiduelle
débruitée
NLPSS
2.5 10
-2
Déplacement:
-2.5 10 0
-2
Figure 3.8: Évolution de la surface NLPSS en fonction de l’échelle grossière t0. Cette
dernière permet de définir une surface dont le bruit et les caractéristiques principales ont
été lissés et a fortiori une carte de déplacement résiduel contenant les variations principales
de l’objet. Un choix idéal pour le paramètre t0 a été représenté en vert.3.3. RÉSULTATS 33
Surface fine Écart entre la surface
grossière et fine
NLPSS
1.5 10
-2
Déplacement:
-1.5 10 0
-2
Figure 3.9: Évolution de la surface NLPSS en fonction de l’échelle fine t1. Cette dernière
permet de définir la carte d’écart entre la surface grossière St0
et St1 utilisée par nos patchs
pour définir la mesure de similarité de deux sous-ensembles du nuage de points. Un choix
idéal pour le paramètre t1 a été représenté en vert.
Par conséquent, la valeur t0 idéale doit être choisie de manière à définir un champ scalaire
dont les variations correspondent à l’aspect de l’objet. En pratique, si la valeur de t0 est
choisie entre 10 et 20 fois l’écart moyen des points du nuage.
Échelle fine
L’échelle fine t1 définit une surface fine St1 utilisée par notre mesure de similarité pour
estimer les variations des patchs. Pour définir une surface d’une meilleure qualité, t1 doit
être choisi de manière à ce que la mesure de similarité soit peu dépendante des structures34
locales de bruits. En Figure 3.9, nous présentons différents choix pour t1, la carte d’écart
entre St0
et St1
ainsi que les surfaces NLPSS associées.
Une fois encore, le choix idéal de l’échelle t1 (représenté en vert sur la Figure 3.9) dépend
du niveau de bruit appliqué à l’objet. Elle doit être choisie suffisamment petite par rapport
à t0 de manière à approcher les caractéristiques de l’objet tout en lissant les structures
locales de bruit. Pour des valeurs de t1 faibles (cas t1 = 3), la mesure de similarité rassemblera
des structures locales de bruits similaires exagérant ainsi les variations parasites de
l’objet. Au contraire pour des valeurs de t1 élevées (cas t1 = 10), la mesure de similarité
associera ensemble des traits non similaires de l’objet tendant à introduire des artefacts
et à uniformiser les traits principaux de la surface NLPSS résultante.
Choisir une valeur de t1 supérieure à t0, n’aurait pas de sens et résulterait d’un mauvais
choix de t0. De plus, prendre t1 = t0 définirait un ensemble de patchs égaux rendant
impossible toute mesure de similarité de deux sous-ensembles du nuage de points. En
pratique, nous choisissons t1 ≈ 0.5t0 .
Opérateur PSS local sous-jacent
Notre opérateur NLPSS est défini pour étendre n’importe quel opérateur PSS local afin
d’exploiter le caractère autosimilaire des nuages de points. Nous présentons en Figure 3.10
une comparaison des surfaces non locales générées en considérant différents opérateurs
PSS locaux.
La qualité de notre NLPSS est très dépendante du choix du PSS local sous-jacent. Ce
dernier permet de définir la surface grossière et la surface fine à partir du nuage de points
(Figure 3.11). Il est important de noter que les propriétés intéressantes des PSS locaux
sont transmises au NLPSS. Ainsi, un opérateur qui préserve les bords d’un objet produira
un NLPSS qui les préserve également (cf. NLPSS basé sur le RIMLS). Notre définition
permet également de corriger les imperfections introduites par les PSS locaux. Dans le cas
du SPSS et HPSS qui exagèrent les caractéristiques principales d’un objet sans filtrer les
structures de bruits locales, notre NLPSS réussit à définir une surface les supprimant tout
en préservant les arêtes et les coins de l’objet.
Malheureusement, notre définition est très dépendante de la qualité de la surface grossière :
toutes les discontinuités introduites par l’opérateur PSS local à échelle grossière seront
difficilement corrigées par notre approche. De manière équivalente, un PSS local capable de
définir une surface fine qui préserve les caractéristiques principales d’un objet définira une
mesure de similarité plus précise. Mesure qui est utile pour définir une surface non locale
de meilleure qualité. L’APSS et le RIMLS qui génèrent des surfaces grossières exemptes
de défauts remarquables et des surfaces fines préservant les caractéristiques de l’objet
définissent des NLPSS idéaux. En pratique, nous utilisons l’APSS comme opérateur de
notre NLPSS car il donne de manière générale les meilleurs résultats.3.3. RÉSULTATS 35
Resultat Local NLPSS Erreur Local Erreur NLPSS
SPSS HPSS APSS RIMLS
7.0 10
-3 0 Erreur
Figure 3.10: Comparaison des surfaces NLPSS utilisant différents opérateurs PSS sousjacents
et des surfaces PSS originales. Les erreurs ont été calculées par rapport au Fandisk
original.36
Échelle fine Échelle grossière
SPSS HPSS APSS RIMLS
Figure 3.11: Surfaces fines St1
et grossières St0 utilisées par notre NLPSS pour étendre
les PSS conventionnels.
NLPSS
Figure 3.12: Évolution de la surface NLPSS en fonction de la taille du patch l. Cette
taille est utilisée pour définir la taille des détails qui doivent être pris en compte lors
du débruitage par les méthodes non locales. Si cette dernière est choisie trop fine, notre
approche non locale dégénère en une approche bilatérale. La définition du patch sur un
plan tangent à la surface grossière St0
, implique que le paramètre l ne doit pas être choisi
supérieur à l’échelle fine t1. Le choix idéal pour l a été représenté en vert.
Taille du descripteur
La largeur l des patchs permet de sélectionner la taille des traits de l’objet présents dans
le nuage de points que notre NLPSS doit récupérer. En Figure 3.12, nous présentons
différents choix pour la taille l du descripteur ainsi que les surfaces NLPSS résultantes.3.3. RÉSULTATS 37 NLPSS Temps (s)
5
10
15
Figure 3.13: Évolution de la surface NLPSS en fonction du nombre de points n par patch.
Les surfaces résultantes sont peu influencées par le nombre de points compris dans chaque
patch. Néanmoins, le temps de calcul pour estimer ces dernières augmente linéairement
avec le nombre de points. En définitive, des patchs de taille 5 × 5 semblent être un bon
compromis qualité/temps de calcul.
Il est intéressant de noter que pour des valeurs faibles de l (cas l = 1), notre approche non
locale dégénère en un simple opérateur de projection bilatéral [TM98, JDZ04]. La surface
NLPSS résultante aura donc tendance à s’accrocher aux valeurs du champ scalaire résiduel
les plus proches. Pour des valeurs de l plus élevées (cas l = 4), la mesure de similarité est
peu influencée par le bruit présent dans le nuage de points résultant en une suppression
des variations locales dans les zones plates.
Néanmoins, à cause de l’approximation de la surface grossière par un plan tangent à
la surface (cf. Section 3.2.3), l doit être choisie inférieure à t1. Pour des valeurs de l
supérieures à t1 (cas l = 10) les variations décrites par les patchs ne correspondent pas
aux variations réelles entre la surface grossière et la surface fine. Ainsi, la mesure de
similarité est faussée ce qui entraîne l’apparition d’artefacts dans la surface NLPSS. En
pratique, nous choisissons l variant entre 3 et 5 fois l’écart moyen des points du nuage.
Nombre de points par patch
Le nombre de points du patch n est utilisé pour décrire plus précisément les variations
locales de la surface. Figure 3.13, nous présentons une analyse du temps de calcul des38
Distance résiduelle
débruitée
NLPSS
1.0 10
-2
Déplacement:
-1.0 10 0
-2
Figure 3.14: Évolution de la surface NLPSS en fonction du degré d’autosimilarité h du
nuage de points. Ce dernier permet de sélectionner le degré de débruitage des caracté-
ristiques principales de l’objet. Si ce dernier est choisi trop faible, les caractéristiques de
l’objet resteront bruitées. À l’opposé, pour des valeurs trop élevées ces dernières seront
complètement lissées. Le choix idéal (représenté en vert) correspond au degré de filtrage
de notre méthode. L’utilisateur peut interagir avec ce paramètre sans contrainte de temps
de calcul.
patchs en fonction de la qualité de la surface NLPSS associée à des nombres de points
différents par patchs.
De toute évidence, augmenter le nombre de points par patch permet de définir une mesure
de similarité plus fiable en contrepartie d’un temps de calcul élevé. En pratique, l’influence
du nombre de points par patchs reste négligeable. Ainsi, le choix d’un nombre points par
patch faible s’impose. Dans de rares cas, le choix de patch 3 × 3 peut être insuffisant pour
décrire correctement la différence entre les surfaces grossière et fine. Par conséquent, nous
avons opté pour des patchs 5 × 5 ce qui constitue un bon compromis qualité/temps de
calcul.
Facteur d’autosimilarité du nuage
Le paramètre h définit le degré de similarité présent dans le nuage de points et correspond
au facteur de filtrage du nuage de points. Nous présentons Figure 3.14 différents choix
pour h ainsi que le champ scalaire résiduel débruité et les surfaces NLPSS associées.3.3. RÉSULTATS 39
Pour des valeurs h ≈ 0 (cas h = 0.1), la mesure de similarité aura tendance à différencier
l’ensemble des patchs ce qui s’exprimera en pratique par des poids qui tendent vers
0. Comme la somme des poids de l’équation 3.11 est assurée d’être unitaire, les points
prendront la valeur m(xi) du point pi
le plus similaire. Par conséquent, le champ scalaire
résiduel ne sera pas débruité et la surface non locale résultante approximera le bruit
contenu dans le nuage. De même, pour des valeurs trop faibles de h (cas h = 10), les
lignes singulières de l’objet seront peu débruitées. À l’opposé des zones plates, ces zones
sont plus rares dans l’objet entraînant un débruitage plus faible. À l’opposé, si h est choisi
trop grand (cas h = 100), les poids de l’équation 3.11 seront tous égaux entraînant une
uniformisation du champ scalaire de déplacement résiduel.
La valeur idéale de h (représentée en vert sur la Figure 3.14) doit être choisie par l’utilisateur
et correspond au facteur de filtrage de notre méthode. Une fois l’ensemble des patchs
calculés et les k plus proches patchs déterminés, l’estimation d’une surface pour différentes
valeurs de h n’est pas coûteuse. Ainsi, l’utilisateur peut intéragir avec le paramètre h sans
contrainte sur le temps de calcul.
Facteur de dégénérescence local
L’utilisation du facteur α de l’équation 3.14 nous permet de choisir des valeurs h moins
élevées. Ainsi, les traits peu présents dans l’objet sont mieux préservés et les artefacts
introduits par les éléments les plus rares de l’objet sont lissés par l’opérateur local. En
Figure 3.15, nous présentons l’évolution de la surface NLPSS pour différentes valeurs de
α.
Lorsque α = ∞, l’équation 3.15 dégénère simplement en une définition locale des PSS.
Au contraire quand α = 0, le résultat obtenu correspond à la surface NLPSS. Les valeurs
intermédiaires de α permettent d’obtenir une combinaison de ces deux surfaces. Pour des
valeurs croissantes de α, les traits les moins présents dans le nuage sont les premiers à être
remplacés par les valeurs des PSS locaux permettant d’améliorer la qualité de la surface
NLPSS résultante. Ainsi, comme le montre la figure 3.15 pour des valeurs croissantes de
α, les coins, les arêtes puis finalement les zones plates vont être remplacés par les PSS
locaux.
La valeur idéale dépendra de la présence de points peu autosimilaires dans le nuage. Il
est intéressant de noter que changer la valeur du facteur α ne nécessite que peu de calcul
supplémentaire. En effet l’équation 3.2.4 peut s’exprimer comme une combinaison linéaire
des points des nuages résultants de l’opérateur PSS local et non local.
Choix pratique
Parmi les sept différents paramètres que possède notre NLPSS, seulement deux d’entre
eux ont besoin d’être réellement choisis par l’utilisateur : le facteur d’autosimilarité h et
le facteur de dégénérescence α.
En pratique, pour des nuages de points issus de scanners 3D dont l’écart moyen entre
les points est défini par ¯δ, les meilleurs résultats sont obtenus pour des NLPSS basés sur
l’APSS dont l’échelle grossière t0 = 12¯δ, l’échelle fine t1 = 7¯δ et les patchs de taille l = 4¯δ40
NLPSS PSS local NLPSS dégénéré
Figure 3.15: Évolution de la surface NLPSS en fonction du facteur α. Ce paramètre
est complémentaire au paramètre h et permet de remplacer les structures peu débruitées
(peu autosimilaires) par leurs versions débruitées en utilisant l’opérateur PSS sous-jacent.
Pour des valeurs croissantes de α notre définition remplace en premier les structures peu
autosimilaires pour finir par les caractéristiques les plus présentes dans le nuage de points.
Nous pouvons par conséquent faire un compromis entre localité (pour les structures peu
autosimilaires) et similarité (pour les structures très autosimilaires). Calculer les surfaces
résultantes pour différentes valeurs de α est possible sans avoir besoin d’estimer de nouveau
l’ensemble des patchs et les k plus proches voisins. α peut donc être choisi interactivement
par l’utilisateur.3.3. RÉSULTATS 41
i) Calcul de la surface grossière ii) Calcul des patches iii) Calcul des plus proches patches iv) Calcul des valeurs débruitées
Temps de calcul avec accélération
5
10
15
10000 50000 100000
Temps (s)
Temps de calcul sans accélération
Temps (s)
150
300
10000 50000 100000
Figure 3.16: Gauche : Temps de calcul des différentes étapes de notre approche estimés en
utilisant un seul cœur. Notre approche est plus longue que les opérateurs PSS précédents,
car elle nécessite un plus grand nombre de projections (dû aux projections successives sur
la surface grossière et sur la surface fine). Droite : Temps de calcul des différentes étapes
de notre approche en utilisant différents outils d’accélération (parallélisation, GPU). En
pratique, nous avons grandement accéléré le temps de calcul (20x) permettant de définir
une utilisation plus interactive de notre NLPSS.
sont définis avec une précision de 5 × 5 points. De plus, dans la mesure où ces paramètres
sont fixés, le calcul des patchs du nuage peut être effectué une fois pour toutes. Ainsi, les
surfaces résultantes peuvent être générées rapidement pour différentes valeurs de h et α.
3.3.3 Performances
Notre approche non locale reste plus lente que des méthodes PSS conventionnelles. Ces
performances inférieures peuvent s’expliquer par : (i) un nombre de projections sur les
surfaces plus conséquent que les approches locales, (ii) la nécessité de comparer l’ensemble
des patchs entre eux. Nous présentons en Figure 3.16, l’évolution des temps de calcul pris
par chacune des étapes de notre algorithme en fonction du nombre de points à projeter.
Certains paramètres du NLPSS influencent directement le temps de calcul, comme les
échelles t0 et t1 du PSS sous-jacent. Ces dernières sont directement liées à la taille du
voisinage nécessaire pour estimer les projections sur les surfaces grossières et fines. Ainsi,
plus ce voisinage est grand, plus le temps de calcul est élevé. De la même manière, le
nombre de points influence le nombre de projections nécessaires (Figure 3.13). Néanmoins
comme nous l’avons expliqué en Section 3.3.2, le nombre de points par patch est fixé car il
influence peu la qualité de la surface résultante. Pour estimer rapidement le voisinage d’un
point donné, chaque PSS est basé sur un ball-tree tels qu’il est introduit par Guennebaud
et coll. [GGG08]. De même, pour accélérer la comparaison des patchs, la moyenne non
locale définie par l’Équation 3.13 est limitée à une recherche approximée des 500 plus
proches voisins du patch considéré par FLANN [ML12,ML09].
Pour une meilleure interactivité avec l’utilisateur, ces temps de calcul sont grandement
diminués (Figure 3.16) grâce à des outils de parallélisation CPU et GPU. De plus, notre
approche peut être divisée en quatre étapes successives : (i) calcul de la surface grossière,
(ii) estimation des patchs, (iii) calcul approché des plus proches voisins et (iv) calcul des
valeurs débruitées (réglage de h et α). Comme les paramètres utilisés par notre approche42
Original SPSS HPSS
APSS RIMLS NLPSS
Figure 3.17: Comparaison entre les reconstructions PSS locales et notre NLPSS obtenues
à partir d’un nuage de point 2D.
peuvent être généralisés, seule l’étape ( iv) nécessite une interaction réelle avec l’utilisateur.
De plus, une fois les étapes précédentes estimées, cette dernière peut être calculée
rapidement (comme le montre le graphique de droite de la Figure 3.16) sans avoir besoin
de réappliquer la chaîne complète. Les valeurs idéales de h et α peuvent donc être choisies
interactivement par l’utilisateur.
3.3.4 Analyse de la qualité de la surface
Les opérateurs PSS conventionnels essayent d’extraire une surface à partir d’un voisinage
purement local. Comme le montre la Figure 3.17 qui présente différentes reconstructions de
surfaces PSS à partir d’un nuage de points 2D synthétique, ce point de vue ne permet pas
de conserver les caractéristiques présentent dans le nuage de points d’entrée supprimant
par la même occasion les symétries originales du nuage d’entrée. En utilisant un point
de vue plus global, notre NLPSS permet de générer une surface capable de conserver les
symétries présentes dans l’objet original.
Dans le cas d’un nuage de points réel issu d’un scanner 3D (Figure 3.18), les opérateurs
PSS conventionnels doivent, en plus, faire un compromis entre la préservation des caracté-
ristiques principales de l’objet et la suppression du bruit. Ce problème est particulièrement
visible pour les SPSS qui tendent à trop filtrer les arêtes et pour le HPSS qui exagère les
structures locales de bruits. D’autres opérateurs, comme l’APSS, possèdent un fort pouvoir
débruitant, mais doivent être utilisés à des échelles de filtrage fines pour éviter une sup-3.3. RÉSULTATS 43
Original SPSS HPSS APSS RIMLS NLPSS
Figure 3.18: Comparaison entre différentes surfaces obtenues par des PSS locaux et notre
NLPSS obtenues à partir du modèle 3D scanné Ramesses
pression complète des arêtes de l’objet. Malheureusement, à de telles échelles, ce dernier
est incapable de supprimer complètement le bruit. Contrairement aux autres opérateurs,
le RIMLS a été défini pour extraire les arêtes tout en supprimant le bruit de l’objet. Cette
définition fournit de bons résultats dans le cas d’objets purement géométriques possédant
des arêtes vives (par ex. objets manufacturés). Malheureusement, dans le cas d’objets réels,
le RIMLS tend à exagérer les caractéristiques de l’objet.
En comparaison, notre NLPSS réussit à éliminer le bruit introduit par la numérisation sans
altérer les structures présentes dans l’objet. Cet avantage est dû à l’utilisation de l’information
non locale qui peut augmenter localement le rapport signal sur bruit. Contrairement
au RIMLS qui exagère les structures, notre opérateur NLPSS réussit à générer une surface
qui est proche du nuage d’entrée.
Il est important de comprendre que notre définition de surface non locale est plus gé-
nérale qu’une simple combinaison d’un algorithme de filtrage de nuage de points (par
exemple [DM11,Dig12]) et d’un modèle de reconstruction de surface existant. Pour mieux
appréhender les différences fondamentales entre ces deux types d’approches, nous présentons
en Figure 3.19 deux reconstructions de surfaces différentes. Dans le premier cas, la
surface est définie en utilisant L’APSS à partir d’un nuage de points préalablement dé-
bruité par un algorithme de débruitage non local. Dans le deuxième cas, la surface est
directement définie en utilisant notre NLPSS. La première approche réussit à débruiter
les points en exploitant l’autosimilarité du nuage, mais reste incapable de reconstruire une
surface en exploitant l’autosimilarité du nuage. Ainsi, la surface résultante ne permet de
compléter les trous en respectant le caractère périodique du nuage original. Au contraire,
notre modèle NLPSS est capable de reconstruire la surface pour chaque point en exploitant
l’autosimilarité et la redondance des structures du nuage de points. De manière similaire,
une troisième approche, qui consisterait à reconstruire une surface directement à partir
des points du nuage puis à utiliser une méthode non locale de débruitage de maillage surfacique
[FDCO03,YBS06,WCZ+08,MRS12], n’exploiterait pas totalement l’autosimilarité
du nuage tout en introduisant des problèmes de définition.
Comme le montre la Figure 3.20, dans le cas de nuages très épars et bruités, les modèles
PSS existants peuvent difficilement générer une surface correcte à des tailles de filtrage44
Largeur du patch :
NL APSS
NLPSS
Figure 3.19: Comparaison des surfaces obtenues en utilisant l’APSS [GGG08] à partir
d’un nuage de points débruité par un algorithme de filtrage non local et la surface obtenue
directement avec notre définition de surface NLPSS.
Nuage de points original APSS RIMLS NLPSS
Figure 3.20: Comparaison entre différentes surfaces obtenues en utilisant des opérateurs
PSS locaux et notre NLPSS sur un modèle d’étoile 3D synthétique.
petites. Pour résoudre ce problème, les modèles de PSS conventionnels doivent augmenter
leur niveau de filtrage, supprimant par conséquent toute l’information de basse échelle
présente dans le nuage. Contrairement à ces définitions, notre NLPSS est capable de
générer une surface plus stable. Cette propriété est due à (i) l’utilisation d’une surface
grossière comme base à notre surface qui définit une structure topologique à notre PSS
et (ii) la moyenne non locale qui est capable de débruiter des structures fines et de les
rajouter sur la surface grossière sans introduire de fausses structures comme le font les
modèles de PSS conventionnels.
En Figure 3.21 et 3.22, nous présentons les surfaces obtenues par notre NLPSS à partir de
nuages de points bruités issus de scanners 3D. Il est intéressant de noter que notre NLPSS
est capable d’utiliser l’ensemble de l’information pour compléter les trous du nuage de3.3. RÉSULTATS 45
Original NLPSS
Figure 3.21: Illustration du pouvoir débruitant de notre NLPSS sur le nuage de points
3D Dragon (413k points) acquis par numérisation 3D.
Original NLPSS
Figure 3.22: Application du NLPSS sur le nuage de points Ramesses (350K points) issu
d’une numérisation 3D. Notre approche est capable de combler les trous de l’objet en
utilisant l’autosimilarité présente dans le nuage de points.
points. Cette propriété est illustrée en Figure 3.22) où l’information inconnue du visage
d’un relief est complétée par l’information connue d’un relief similaire présent sur la statue.
Néanmoins, cette propriété reste très dépendante de la qualité de la surface grossière sousjacente.46
Figure 3.23: Application de notre opérateur NLPSS au cas du débruitage de nuages de
points. Nous avons utilisé le jeu de données Pyramid (120k points) issue de [DAL+11]
Figure 3.24: Application de notre NLPSS pour définir une surface maillée en utilisant
un algorithme de type Marching Cubes [LC87].
3.3.5 Applications
Filtrage de nuages de points
Une des applications les plus évidentes des PSS est le filtrage de nuages de points. En
considérant un nuage de points bruités, l’opération de débruitage du nuage consiste à
remplacer chaque point xi ∈ X du nuage par leur projection x˜i = ΠNL(xi) sur la surface
définie par l’opérateur de projection ΠNL définie par l’Équation 3.12. Ainsi, le nuage
débruité est défini par P˜ = {x˜i}. Nous présentons en Figure 3.23, le résultat du débruitage
obtenu par NLPSS.
Reconstruction de surface
L’une des utilisations majeures des opérateurs PSS est de définir une surface maillée à
partir de la définition implicite de la surface. Nous définissons la surface comme la 0-3.4. LIMITATION ET POSSIBLES AMÉLIORATIONS 47
Figure 3.25: Application de notre NLPSS à l’édition de surfaces. Le paramètre β permet
de moduler à quel point le champ scalaire de déplacement doit être ajouté à la surface
grossière. Gauche : pour des valeurs β > 1, ces détails sont exagérés. Droite : pour des
valeurs β < 0, ces derniers sont inversés.
surface de la distance implicite fNL définie par l’Équation 3.13. La surface maillée est
obtenue en utilisant un algorithme de Marching Cubes. Nous présentons en Figure 3.24 la
surface NLPSS maillée obtenue à partir d’un nuage de points bruités.
Améliorations des détails
Pour illustrer le potentiel de notre NLPSS, nous proposons une utilisation de notre dé-
finition pour l’édition de surfaces. Comme nous l’avons expliqué en Section 3.2.1, notre
opérateur NLPSS est défini par une surface grossière sur laquelle nous ajoutons un champ
scalaire de déplacement. Nous pouvons modifier la fonction implicite fNL définie en Équation
3.13 en multipliant le champ scalaire de déplacement par un champ scalaire continu
β(x) :
fNL(x) = f
t0
(x) − β(x)
X
xi∈X
wNL(x, xi)f
t0
(xi) (3.15)
Par conséquent, β(x) permet de décrire pour chaque x à quel point les détails fins fNL(x)
sont ajoutés à la surface grossière St0
. Les détails sont ajoutés à la surface grossière pour
des valeurs de β(x) > 0, et exagérés si β(x) > 1. Des valeurs de β(x) négatives permettent
de supprimer les détails de la surface grossière, inversant de la même manière les caractéristiques
de l’objet. Ainsi, l’utilisateur peint directement sur la surface grossière St0
les
valeurs de β(x) choisissant, de la même manière, les éléments de l’objet qu’il souhaite
exagérer. Nous présentons en Figure 3.25 une illustration de cette démarche.
3.4 Limitation et possibles améliorations
Dans cette partie nous avons défini un opérateur PSS capable d’exploiter le caractère
autosimilaire des nuages de points pour définir une surface. Notre définition est capable48
Figure 3.26: Gauche : Notre approche non locale peut résulter en l’apparition de halos
sur la surface. Centre : Une solution simple pour résoudre ce problème consiste à définir
différentes surfaces NLPSS en utilisant des patchs décentrés. Droite : Une simple moyenne
de ces différentes valeurs débruitées permet de limiter les effets des halos introduits.
d’améliorer la qualité des surfaces définies par des opérateurs PSS locaux en augmentant
le rapport signal/bruit. Néanmoins, les résultats de notre opérateur sont très dépendants
de l’aspect autosimilaire du nuage à traiter. Plus le nuage de points présentera de parties
similaires, plus la qualité de la surface générée par notre approche sera élevée. Dans le cas,
peu probable, d’absence d’autosimilarité dans le nuage de points, notre NLPSS obtiendra
des résultats identiques à l’opérateur PSS local sous-jacent (Section 3.2.4).
Il est courant que l’utilisation de patchs par les méthodes non locales introduise des oscillations
ou halos autour des arêtes des images. Le même phénomène peut être observé sur
les surfaces définies par notre approche autour des arêtes vives de l’objet (Figure 3.26). Ce
problème peut s’expliquer par le phénomène d’adhérence des patchs. [LBM13] proposent
une solution simple pour résoudre ce problème. Elle consiste à faire une moyenne des différentes
cartes débruitées en considérant des patchs décentrés. Nous présentons en Figure
3.26 une extension de cette solution à notre NLPSS. Cette solution permet d’éliminer les
halos et d’améliorer la qualité de la surface résultante au prix de temps de calcul plus
coûteux.
Pour définir notre mesure de similarité (Section 3.2.3), nous avons utilisé une distance
euclidienne entre les patchs. Cette distance nous permet de définir des surfaces NLPSS
correctes, mais reste néanmoins trop sensible au bruit et aux points aberrants. Remplacer
la norme L2 par une norme L1 permettrait de définir une surface moins sensible aux points
aberrants. Il serait intéressant de redéfinir les patchs en ajoutant pour chaque point projeté
la normale associée à cette projection. Ainsi, la distance entre les patchs correspondrait à
une distance L2,1 qui tient compte à la fois des variations des positions et des normales. Une
telle approche revient à étendre les patchs de manières "géodésique" plus qu’euclidienne
permettant ainsi de différencier les caractéristiques intrinsèques de l’objet tout en étant
moins sensibles au bruit.
En comparaison avec les définitions de PSS conventionnelles, le NLPSS requiert un temps
de calcul supérieur. Ce phénomène s’explique par la nécessité de projeter plus de points
que les méthodes PSS précédentes et de rechercher les patchs les plus similaires. Durant3.4. LIMITATION ET POSSIBLES AMÉLIORATIONS 49
ces dernières années, beaucoup de travaux se sont fixés comme objectif d’accélérer le calcul
des filtres à moyennes non locales (Section 4.1.1). Un point important de notre travail futur
consistera à essayer d’adapter ces méthodes au cas des nuages de points et à utiliser les
technologies de parallélisation offerte par les cartes graphiques modernes pour que notre
approche soit utilisable en temps réel.
Pour conclure, notre NLPSS permet le remplissage de trous d’une taille similaire à celle
utilisée pour définir les patchs de surface. Pour des trous d’une échelle supérieure, une
telle approche n’est pas suffisante. Il est donc nécessaire d’utiliser une méthode itérative
d’inpainting de surfaces. Malheureusement, de telles méthodes restent difficile à calculer
et nécessitent la connaissance d’un a priori sur les surfaces 3D.C h a p i t r e 4
Arbre de covariances
Dans ce chapitre, nous présentons une structure de données capable d’apprendre les variations
de grands ensembles d’échantillons en utilisant une quantité de mémoire limitée.
En Section 4.1, nous présentons un historique des méthodes d’accélérations des filtres à
hautes dimensions. Dans la Section 4.2, nous introduisons une version simplifiée de notre
arbre définie dans un domaine spatial. Cette version est ensuite étendue en Section 4.3 en
distinguant deux domaines : spatial et des attributs. Les performances de notre structure
sont ensuite analysées en Section 4.4. Finalement, nous proposons en Section 4.5 diverses
améliorations de notre structure de données.
4.1 Contexte
4.1.1 Filtrage à hautes dimensions
Avec l’apparition des nouvelles technologies et de nouvelles capacités de calculs, le filtrage
à hautes dimensions est devenu durant ces dernières années une brique fondamentale pour
une variété d’applications telles que le débruitage [BCM05], la récoloration [CPD07], le
suréchantillonage [KCLU07], la manipulation de détails [BPD06,FAR07], le filtrage spatiotemporel
[BM05]. Implémentés naïvement, de tels filtres restent difficiles et lents à calculer
et nécessitent d’être accélérés. Ainsi, le rapport entre le temps de calcul et la qualité des
résultats obtenue est devenu un enjeu important pour les communautés de la vision par
ordinateur, du traitement des images et de la photographie calculatoire.
De nombreuses approches ont été introduites afin d’accélérer leur estimation. Parmi
elles, une première catégorie de méthodes propose une accélération par estimation d’un
champ approché des k-plus proches voisins comme par exemple PatchMatch [BSFG09]
(récemment étendu à d’autres domaines [NFP+13, CFGS12, BRR11] et accéléré par kdtree
[HS12], l’utilisation d’images intégrales [OA12], l’utilisation d’une transformée de Fourier
[WGY+06, DDS12], la réduction de la dimensionnalité des patches par les filtres de
Haar [KA11] ou une analyse en composantes principales [APG07,Tas08,Tas09], la limitation
de la recherche à un voisinage 2D local (utilisé en pratique par [BCM05,LBM13]).
Ces méthodes restent néanmoins trop spécifiques aux problèmes de traitement des images
et peuvent difficilement être étendues au cas 3D. De plus, les approches de débruitage par
5152
filtres collaboratifs, définissant une meilleure restauration de l’image que les approches
par moyenne non locale, ne peuvent être accélérées par une estimation approchée des
k-plus proches voisins. Par conséquent, nous focaliserons notre étude sur l’utilisation de
structures d’accélération qui permettent une réduction de la complexité computationnelle
des filtres au prix d’approximations visuelles résultantes.
4.1.2 Travaux existants
Parmi tous les filtres non linéaires, le filtre bilatéral [TM98] a été l’un des premiers à avoir
été accéléré car il constitue une approximation intéressante des filtres anisotropes [Bar02].
Durand et Dorsey [DD02] sont parmi les premiers à proposer une accélération de ce filtre
appliquée à l’affichage d’images à grande dynamique (High Dynamic Range - HDR). Leur
idée principale est de réduire la complexité du filtre en utilisant une approximation linéaire
par morceaux du filtre bilatéral, ce qui revient à appliquer un filtre gaussien, plus rapide à
calculer, sur un sous-échantillonnage du domaine spatial. Ces valeurs sous-échantillonnées
sont ensuite interpolées pour obtenir le signal filtré.
En remarquant que le filtre bilatéral peut être exprimé par un filtre gaussien appliqué dans
un espace de dimensions supérieures, Paris et Durand [PD06] introduisent la grille bilaté-
rale. Cette dernière sous-échantillonne le signal à filtrer par des voxels de taille uniforme
en exprimant le signal à filtrer comme une variété linéaire par morceaux définie dans un
espace qui associe le domaine spatial et colorimétrique (appelé par la suite espace augmenté).
Pour rendre l’accélération plus performante, l’espace colorimétrique est réduit à
une unique dimension. Néanmoins, les distances en chrominance ne sont pas respectées ce
qui introduit des effets de flou parasites. Ce problème est résolu dans une version ultérieure
de leurs travaux [PD09] par l’utilisation de toutes les dimensions colorimétriques. La grille
bilatérale, définissant désormais un volume 5D, nécessite une quantité de mémoire et en
temps supérieur. En particulier pour des échelles de filtrage faibles, cette méthode devient
impraticable.
Adams et coll. [AGDL09] proposent de remplacer le pavage régulier par un pavage adaptatif
de l’espace augmenté. Ils introduisent une structure d’accélération indépendante de
l’échelle de filtrage, le kd-tree gaussien (Gaussian KD-Tree - GKD-Tree), en se basant sur
les travaux de Aray et coll. [AMN+98]. Ils proposent de paver l’espace augmenté avec des
voxels de tailles non uniformes en utilisant un kd-tree [Ben75] qui regroupe les échantillons
proches. Les valeurs des voxels sont estimées par diffusion des valeurs des échantillons qui
lui sont proches (splatting), filtrées entre elles (blurring) et finalement interpolées pour
définir les valeurs filtrées de chaque échantillon (slicing). Cette approche peut être gé-
néralisée à l’accélération de l’ensemble des filtres non linéaires à poids gaussiens (filtre
gaussien, bilatéral, à moyenne non locale, etc.). Ultérieurement, Adams et coll. [ABD10]
étendent leurs travaux en pavant l’espace avec des simplexes et en stockant les valeurs de
ces derniers dans une table de hachage. Ainsi, la structure d’accélération permet d’appliquer
des filtres non linéaires de hautes dimensions avec une complexité linéaire par rapport
au nombre de points et polynomiale par rapport à la dimensionnalité du filtre.
Dans le cas des filtres à très hautes dimensions, la complexité polynomiale par rapport aux
nombres de dimensions des précédentes approches ne permet pas qu’elles soient appliquées
en temps réel. He et coll. [HST10] proposent de réduire la dimensionnalité du problème4.1. CONTEXTE 53
en comparant indirectement chaque pixel de l’image par rapport à leur relation à un
guide. Même si cette approche permet une accélération significative, elle introduit des
artefacts dus à l’utilisation d’une distance non euclidienne. De la même manière, Gastal et
Oliveira [GO11] proposent, dans le cas des filtres bilatéraux, l’utilisation d’une transformée
de l’image qui déforme la géométrie du domaine spatial 2D du signal à filtrer de sorte
que la distance spatiale entre deux points de l’espace déformé corresponde à la distance
géodésique dans l’espace augmenté 5D. Ainsi, le filtre bilatéral est approximé par un filtre
gaussien appliqué dans le domaine spatial.
Ces travaux sont ensuite généralisés au cas de filtres de plus hautes dimensions [GO12].
Gastal et Oliveira démontrent que le signal à filtrer peut rarement être défini par une
variété linéaire. Par conséquent, l’utilisation de voxels n’est pas adaptée pour obtenir un
sous-échantillonnage correct de l’espace. À la place, ils proposent l’utilisation de variétés
non linéaires adaptatives qui sont définies en appliquant récursivement un filtre passebas
sur les échantillons du signal. Le signal filtré est estimé en utilisant une approche
similaire au GKD-Tree [AGDL09] : les valeurs des variétés sont estimées par diffusion des
valeurs des échantillons (splatting), puis filtrées entre elles indépendamment des valeurs
des autres variétés (blurring) et finalement interpolées pour définir les valeurs filtrées de
chaque échantillon (slicing). Cette approche permet d’obtenir une complexité qui est à la
fois linéaire par rapport à la dimensionnalité du filtre et du nombre d’échantillons.
4.1.3 Problématique
Si l’on devait résumer les progrès de ces dernières années, le calcul de filtres non linéaires
a été accéléré de deux manières : (i) en redéfinissant les filtres non linéaires par des
filtres linéaires exprimés dans des espaces augmentés qui associent les domaines spatial et
colorimétrique (ii) en interpolant une version sous-échantillonnée du signal filtré adapté
à l’échelle de filtrage. Même si les structures d’accélérations associées sont aujourd’hui
capables d’appliquer en temps réels des filtres non linéaires à hautes dimensions, elles ne
peuvent pas être utilisées pour accélérer le calcul de filtres probabilistes collaboratifs tels
que les Non-Local Bayes. De plus, elles doivent être entièrement reconstruites pour chaque
modification des paramètres de filtrage.
D’un autre point de vue, avec l’augmentation de la quantité d’information, peu de mé-
thodes à l’heure actuelle exploitent réellement l’information contenue dans les grandes
bases de données ou au prix d’une quantité de mémoire et de calculs beaucoup trop importante.
Les structures d’accélération de filtrage non linéaire actuelles ne sont pas conçues
pour être directement exploitées sur ces bases.
Nous proposons d’associer les avancés récentes sur les structures d’accélération des filtres
non linéaire avec les dernières avancées du domaine non local. Nous proposons une nouvelle
structure de données, plus générale qu’une simple structure d’accélération, capable d’apprendre
les distributions locales d’un grand ensemble d’échantillons en les représentant
par des gaussiennes anisotropes. Contrairement aux méthodes qui représentent les distributions
d’échantillons par un modèle de mixture de gaussiennes de nombre fini [YSM12],
ces gaussiennes sont estimées en fonction de la région de l’espace considéré.54
Ainsi, nous introduisons l’arbre de covariance (Covariance Tree - CovTree) qui possède les
caractéristiques suivantes :
1. Apprentissage de grande base de données : En utilisant une approche similaire
aux structures d’accélérations des filtres non linéaires, l’ensemble des échantillons est
réparti en sous-ensembles adaptés représentés par des gaussiennes indépendantes du
nombre d’échantillons.
2. Optimisation de la mise à jour des données : L’ajout d’un échantillon dans
notre structure n’entraîne pas la reconstruction complète de la structure. Seules les
gaussiennes qui décrivent les distributions de chaque sous-ensemble sont modifiées.
L’ajout d’un point dans notre structure permet d’améliorer l’estimation des statistiques
des distributions sans changer la quantité de mémoire utilisée.
3. Estimation des distributions locales à différentes échelles : Contrairement
aux structures d’accélération des filtres non linéaires, notre CovTree a été conçu
pour être indépendant des paramètres d’échelles. Ainsi, l’estimation des distributions
locales peut être effectuée en un temps raisonnable sans avoir besoin de reconstruire
entièrement la structure.
4. Généralisation de la structure d’apprentissage : Notre approche est générique
et peut être appliquée dans un espace de dimensions arbitraires. Pour être utilisable
par un plus grand nombre d’applications, elle est définie en utilisant deux
domaines distincts : un domaine spatial (utilisé pour calculer une distance entre les
échantillons) et un domaine des valeurs (utilisé pour exprimer les statistiques sur les
distributions).
Notre structure d’apprentissage est beaucoup plus générique qu’une simple structure d’accélération
de filtres collaboratifs. Comme nous le montrerons dans le chapitre 5, cette
dernière peut être utilisée pour des applications 2D et 3D variées.
4.2 Arbre de Covariance Simplifié
Pour mieux appréhender les idées fondamentales de notre approche, nous introduisons
dans cette section une version simplifiée de notre CovTree qui sera utilisé pour apprendre
les distributions d’échantillons dans un espace fini. Elle nous permettra d’introduire les
principes sous-jacents à notre structure de données.
Néanmoins, cette définition reste trop spécifique pour être utilisée en pratique. Par consé-
quent, nous introduisons en Section 4.3 une définition plus générique de notre CovTree
utilisable pour résoudre des problèmes de restauration variés.
4.2.1 Principe
Idée générale
Considérons un ensemble d’échantillons P = {pi} où pi ∈ S ⊂ R
dS . Notre CovTree est
défini comme une structure de données qui apprend localement la distribution des points
de P à partir d’un sous-échantillonnage adaptatif (cellules) de S. Pour n’importe quelle4.2. ARBRE DE COVARIANCE SIMPLIFIÉ 55
Figure 4.1: Gauche : Nous illustrons le principe de notre CovTree sur un nuage de points
pi extrait d’une courbe 2D pour un voisinage centré en q et de rayon σq. Droite : Le but de
notre CovTree est d’apprendre la distribution des points P et de modéliser la répartition
des points qui sont compris dans ce voisinage par une gaussienne anisotrope représentée
par une moyenne µˆ et une matrice de covariance Σˆ .
requête de position q ∈ S et échelle σq ∈ R, la structure retourne la gaussienne anisotrope
correspondante à la distribution locale des échantillons de P appris.
En Figure 4.1, nous illustrons les entrées et sorties de notre Cov-Tree dans le cas où P
correspond à un nuage de points 2D issu d’une courbe. Dans ce cas, les pi définis dans un
espace S = R
2
représentent les positions des points du nuage. Notre CovTree permet donc
d’apprendre la répartition des points du nuage et fournit pour n’importe quel voisinage
euclidien, la gaussienne anisotrope correspondante à la distribution des points du nuage
compris dans ce voisinage.
Dans le cas où P correspond à l’ensemble des patchs d’une image bruitée, cette structure
de donnée simplifiée peut être utiliser pour estimer le résultat de filtres collaboratifs tels
que les Non Local Bayes [LBM13].
Représentation des distributions locales
Pour apprendre les distributions des échantillons de P, nous effectuons une analyse statistique
de sous-ensembles C ⊂ P d’échantillons locaux. L’idée fondamentale de notre
CovTree est de remplacer ces sous-ensembles par leurs statistiques respectives. Dans cette
partie, nous fournissons une analyse de pouvoir synthétique de ces dernières et de leur
impact sur les performances de notre CovTree.
En considérant que l’ensemble des points de C sont compris dans une boule de rayon
négligeable, la distribution peut être représentée correctement par une simple moyenne
des points de C. Cette solution est utilisée pour accélérer le calcul des filtres à hautes
dimensions [AGDL09] car pour des échelles inférieures à l’échelle de filtrage, il est inutile de
conserver de plus fines variations des échantillons. Comme nous le présentons en Figure 4.2,
cette solution est équivalente à conserver l’ensemble des échantillons de P en mémoire pour
des échelles de filtrage fines. De plus, comme la moyenne ne fournit aucune information56
(a) Nuage de points 2D
(c) Représentation par des gaussiennes isotropes
(b) Représentation par des moyennes
(d) Représentation par des
gaussiennes anisotropes
Figure 4.2: Différentes représentations statistiques du nuage de points 2D. (a) Nuage
de points 2D original. (b) Utiliser une moyenne par cellules pour représenter un nuage de
points revient à garder l’ensemble des points du nuage pour des tailles de cellules faibles et
ne permet de représenter efficacement les variations du nuage à de grandes échelles. (c) En
utilisant des gaussiennes isotropes, la modélisation devient plus fiable à des échelles fines,
mais reste malgré tout trop grossière pour représenter la distribution à des échelles élevées.
(d) Nous proposons l’utilisation de gaussiennes anisotropes qui permettent de représenter
correctement les distributions à de grandes échelles avec un nombre de gaussiennes limitées.
sur les variations des échantillons qu’elle représente, elle ne peut être utilisée correctement
à de larges échelles pour représenter la distribution de grands ensembles de données.
Pour de grandes échelles comme la moyenne ne fournit aucune information variationnelle,
il devient difficile de représenter correctement la distribution des échantillons d’un grand
ensemble de données.
Pour des ensembles d’échantillons de C distribués de manière isotrope dans une boule,
l’approche précédente peut être améliorée en associant à la moyenne des points de C une
variance. La distribution peut par conséquent être modélisée par une gaussienne isotrope.
Désormais, la représentation dépend directement de la répartition des données et non
de l’échelle de filtre à appliquer. Comme nous l’illustrons en Figure 4.2, cette contrainte
d’isotropie reste difficile à satisfaire pour des échelles élevées. De plus, elle revient à garder
en mémoire l’ensemble des échantillons pour des échelles fines.
Les deux approches précédentes ne sont pas suffisantes pour apprendre les distributions
d’échantillons. Par conséquent, nous préférons les représenter par l’intermédiaire de gaussiennes
anisotropes. Nous associons donc chaque sous-ensemble C à sa moyenne µ et sa
matrice de covariance Σ. Comme nous le démontrons en Figure 4.2, ce choix permet de4.2. ARBRE DE COVARIANCE SIMPLIFIÉ 57
Figure 4.3: Notre CovTree est basé sur trois étapes principales. Construction : à partir
d’un ensemble d’échantillons, nous construisons un arbre binaire qui partitionne l’espace
en fonction des positions des échantillons {pi} pour créer des cellules de taille σb. Apprentissage
: chaque nœud apprend les distributions statistiques locales modélisées par des
noyaux anisotropes en propageant l’ensemble des échantillons à travers l’arbre en fonction
de leur position pi et ajoutant une contribution pondérée des pi au noyau de chaque
nœud de l’arbre traversé. Requête : pour toute requête constituée d’une position q ∈ S et
échelle σq ∈ R, notre CovTree modélise la distribution locale des données apprises en q
et à l’échelle σq par une gaussienne multivariée définie par sa moyenne µˆ et sa matrice de
covariance Σˆ .
représenter correctement les distributions des échantillons à des échelles fines et élevées.
De plus, l’utilisation d’une gaussienne anisotrope nous permet de diminuer la quantité de
mémoire nécessaire, d’augmenter le pouvoir descriptif de notre CovTree et d’être plus indé-
pendant des contraintes d’échantillonnages (complétion des trous/données manquantes).
Chaîne de traitement
Notre approche, résumée en Figure 4.3, peut être divisée essentiellement en trois étapes.
Ces dernières peuvent être comparées avec les trois étapes de splatting, blurring, slicing
utilisé par les travaux sur l’accélération de filtres à hautes dimensions [PD09, ABD10,
GO12].
1. Construction : Nous effectuons un sous-échantillonnage hiérarchique pyramidal de
S basé sur les échantillons de P jusqu’à l’obtention de cellules de taille σb. Il en
résulte un arbre binaire dont chaque nœud (correspondant à un sous-espace de S)
est associé à un noyau anisotrope modélisant la distribution statistique des points
de P appartenant à la cellule spatiale correspondante (Section 4.2.2).
2. Apprentissage : Nous apprenons les distributions de points par propagation (entraînement)
des données à travers l’arbre binaire. Chaque point est classifié en considérant
sa position et ajoute une contribution pondérée au noyau anisotrope de chaque
nœud de l’arbre qu’il traverse (Section 4.2.3).
3. Requête : Pour toute requête définie par une boule de centre q ∈ S et échelle
σq ∈ R, notre CovTree fournit la distribution des données apprises correspondant
à ce voisinage. Elle est modélisée par une gaussienne multivariée représentée par58
(a) Partionnement par grille (b) Partionnement par kd-tree (c) Partionnement par bsp-tree
Figure 4.4: Nous proposons ici différents partitionnements de l’espace. (a) : Une grille
régulière permet de définir des cellules régulières. Ces dernières sont définies indépendamment
des données qu’elles contiennent résultant des cellules vides ou mal définies. (b) : Le
kd-tree définit un partitionnement hiérarchique de l’espace dont les partitions sont faites
dans des directions indépendantes des données à apprendre. Il ne crée pas de cellules
vides, mais ne tient pas compte de l’anisotropie des données. (c) : Notre bsp-tree définit
un partitionnement hiérarchique de l’espace qui permet de tenir compte de l’anisotropie
des données à apprendre.
une une moyenne µˆ et d’une matrice de covariance Σˆ interpolée en q à l’échelle σq
(Section 4.2.4).
Il est important de comprendre que σb et σq sont liés à la quantité d’informations que nous
voulons récupérer. L’application successive des trois étapes de construction, d’apprentissage
et de requête est approximativement équivalente à estimer une matrice de covariance
avec un noyau gaussien de taille √
2σq.
Pour prévenir tout problème de calcul σq doit être choisi plus grand que σb, suffisamment
large pour outrepasser le bruit, mais suffisamment petit pour capturer les structures
locales. Généralement, σb ≈ σn et σq ≥ σn.
4.2.2 Construction
Pavage adapté de l’espace
Durant l’étape de construction, nous définissons un partitionnement de l’espace S en
cellules spatiales. Ces cellules doivent être adaptées à la distribution des échantillons de P
afin de respecter les variations topologiques de P (et d’obtenir un meilleur apprentissage
des données). Nous fournissons dans cette partie une analyse de plusieurs solutions pour
partitionner l’espace et de leur impact sur les performances du CovTree.
Une des solutions les plus faciles est de diviser l’espace en un ensemble de cellules régulières
par l’intermédiaire d’une grille [PD06, PD09]. Malgré sa simplicité de mise en œuvre,
utiliser ce schéma de subdivision pour notre CovTree présente trois problèmes (Figure 4.4).
Tout d’abord, la quantité de mémoire utilisée est d’autant plus grande que l’espace S est
de dimension élevée et que la taille des cellules est faible. Ensuite, les cellules sont définies
indépendamment du signal à considérer, ainsi, les gaussiennes anisotropes ne sont pas
nécessairement représentatives des variations des échantillons. Le problème majeur vient4.2. ARBRE DE COVARIANCE SIMPLIFIÉ 59
du fait que ces cellules ne contiennent pas obligatoirement des échantillons et accaparent
inutilement de l’espace mémoire.
Pour résoudre ce problème, il est plus judicieux d’utiliser des structures de subdivision
hiérarchique telle que le kd-tree [AGDL09]. Ce dernier est défini comme un arbre binaire
dans lequel chaque nœud est associé à un sous-espace de S. Chaque nœud interne de l’arbre
divise l’espace en deux demi-espaces distincts selon un hyperplan normal à la direction
de plus grande variation des points. Cette direction est choisie parmi les directions d’un
repère orthonormé fixe de l’espace S définie indépendamment de P. Une fois encore, les
cellules spatiales échouent à capturer l’anisotropie des données correctement (Figure 4.4).
Les échantillons, regroupés de manière inadéquate, définissent des distributions locales de
P parasites. De plus, le partitionnement ainsi défini est différent pour tout changement
d’orientation.
Par conséquent, nous définissons notre CovTree par l’intermédiaire d’une structure de
partitionnement binaire de l’espace, le bsp-tree [FKN80], qui divise l’espace en deux sousespaces
distincts par l’intermédiaire d’un hyperplan orienté selon la direction de plus
grande variation des données d’entrées. Les cellules ainsi obtenues ne sont pas nécessairement
parallélépipédiques et permettent de tenir compte de l’anisotropie des données
à apprendre (Figure 4.4). Les gaussiennes anisotropes résultantes permettent de mieux
représenter le signal.
Algorithme
Nous divisons l’espace par l’intermédiaire d’un bsp-tree dont chaque nœud est associé à un
sous-espace C ⊂ S, un sous-ensemble d’échantillons pj ∈ P ∩ C et à un rayon de cellule
ηr (utilisé pour apprendre les distributions à différentes échelles). Chaque nœud interne
de l’arbre divise l’espace en deux demi-espaces distincts par l’intermédiaire d’un plan de
coupe {ηc, ηd} dont la normale ηd est définie comme le vecteur propre normalisé associé
à la plus grande valeur propre de la covariance des {pj} et ηc par la moyenne des {pj}.
En pratique, ηd est estimé avec une complexité linéaire par rapport à la dimension de S
et au nombre d’échantillons en utilisant la méthode de la puissance itérée. Le rayon de
cellule est défini par :
ηr = max
pj
kpj − ηck (4.1)
L’ensemble des points {pj} est partagé en deux sous-ensembles par rapport à leur distance
signée au plan (pj − ηc)
tηd. Les deux sous-branches du nœud η sont ensuite construites
en se basant sur ces deux sous-ensembles.
En initialisant le nœud racine avec l’ensemble des données d’entrée {pi}, nous appliquons
récursivement ce schéma de subdivision tant que le rayon de cellule ηr > σb. Par consé-
quent, l’utilisateur peut choisir la précision d’apprentissage de notre CovTree (ainsi que la
quantité de mémoire qu’il va utiliser) en modifiant la valeur du paramètre σb. L’Algorithme
1 présente le pseudo-code de cette étape de construction.60
Algorithm 1: Construction de l’arbre
Fonction ConstruireNœud(C ⊂ P, σb ∈ R)
Entrées: C un sous-ensemble de P, σb l’échelle d’arrêt
Sorties: η le nœud créé
Allouer un nouveau nœud η
// Estimation des paramètres de la cellule
ηd ← le vecteur associé à la plus grande valeur propre de cov(C)
ηc ← mean
pi∈Ck
(pi)
ηr ← max
pi∈Ck
kpi − ηck
si ηr ≤ σb alors
Marquer η comme feuille de l’arbre
sinon
// Répartition des points dans les deux sous-espaces
Cgauche ← {pi ∈ Ck,(pi − ηc)
tηd ≤ 0}
Cdroit ← {pi ∈ Ck,(pi − ηc)
tηd ≥ 0}
// Création des deux sous-arbres
ηgauche ← ConstruireNœud(Cgauche, σb)
ηdroit ← ConstruireNœud(Cdroit , σb)
fin
retourner η
fin
4.2.3 Apprentissage
Algorithme
Une fois la structure de l’arbre initialisée, nous pouvons calculer les statistiques de chaque
cellule en propageant l’ensemble des données d’apprentissage {pi} à travers l’arbre. En
partant de la racine, les points traversent l’arbre jusqu’à atteindre une feuille. Le parcours
est effectué en considérant les positions des points pi
. Les gaussiennes anisotropes associées
à chacun des nœuds η traversés sont enrichies des valeurs pi pondérées par un poids
wi = φ
kpi−ηck
ηr
. Ce poids est défini grâce à une approximation compacte, linéaire par
morceaux du noyau gaussien φ centré en ηc et de variance ηr :
φ(x) =
4 − 0.75x
2
(2 − x) si 0 < |x| ≤ 1
0.25(2 − x)
3
si 1 < |x| ≤ 2
0 sinon
(4.2)
Pour simplifier les deux étapes d’apprentissage et de requête, la moyenne et la covariance
des échantillons ne sont pas directement conservées en chaque nœud. A la place, nous4.2. ARBRE DE COVARIANCE SIMPLIFIÉ 61
Algorithm 2: Apprentissage des variations locales
Fonction ApprendreVariations(p, η)
Entrées: p un point à ajouter dans la structure, η un nœud de l’arbre
// Calcul des poids w par approximation d’une gaussienne de variance ηr
w ← φ
kpi−ηck
ηr
// Mise à jour des statistiques de chaque nœud
wη := wη + w
w2η := w2η + w.w
µη
:= µη + w.p
Ση := Ση + w.p
tp
// Apprentissage des statistiques à une échelle inférieure
si η n’est pas une feuille de l’arbre alors
si (p − ηc)
tηd ≤ 0 alors
ApprendreVariations(p, ηgauche)
sinon
ApprendreVariations(p, ηdroit)
fin
fin
fin
stockons une somme partielle µη
, une somme croisée partielle des positions Ση et deux
constantes de normalisation wη et w2η :
wη := wη + wi
w2η := w2η + wi
.wi
µη
:= µη + wi
.pi
Ση := Ση + wip
t
ipi
(4.3)
La moyenne et la covariance représentatives des variations du nœud peuvent être retrouvées
à partir de ces quatres variable. L’Algorithme 2 présente le pseudo-code de l’étape
d’apprentissage.
Complétion des données d’apprentissage
De manière générale, le même ensemble de points P est utilisé lors de l’étape de construction
et d’apprentissage. Néanmoins, il est possible d’utiliser un sous-ensemble représentatif
P
′ ⊂ P différent pour définir un partitionnement de l’espace S lors de l’étape de construction.
Cette approche possède deux avantages : (i) le partitionnement de l’espace peut être
défini plus rapidement (en particulier dans le cas d’une large base de données), (ii) il n’est
pas nécessaire de connaître l’ensemble des données pour commencer l’apprentissage des
données (par ex. traitement vidéo).
De plus, comme nous utilisons une analyse statistique partielle (nous stockons en mémoire
uniquement des sommes partielles et non directement les statistiques), il devient possible62
d’ajouter au fur et à mesure des échantillons par l’intermédiaire de l’Équation 4.3. Chaque
point ajouté durant l’étape d’apprentissage augmente la précision des distributions apprises
par chaque cellule. L’avantage d’une telle approche est que l’espace mémoire utilisé
reste constant quel que soit le nombre d’échantillons rajoutés. En effet, nous ne gardons
pas en mémoire l’ensemble des échantillons, mais uniquement les quatre variables wη, w2η,
µη
et Ση.
Cette propriété peut être utilisée pour apprendre la distribution d’échantillons issus d’une
grande base de données. Notre structure représente localement la répartition des échantillons
par l’intermédiaire de gaussiennes multivariées utilisant peu d’espace mémoire.
Cette propriété sera utilisée en Section 5.2 pour approcher l’a priori sous-jacent aux patchs
des images naturelles.
4.2.4 Requête
Accélération de la requête
Pour tout voisinage de centre q ∈ S et de rayon σq ∈ R, la gaussienne anisotrope est
estimée par une combinaison des données apprises sur chaque nœud de l’arbre avec des
poids décroissants par rapport à l’éloignement au centre de la requête q. Pour accélérer
le calcul de cette estimation, il suffit de sélectionner uniquement les nœuds qui possèdent
les poids les plus élevés.
Certaines méthodes [AGDL09] proposent par exemple un schéma de requête à importance
des échantillons. L’idée principale est de distribuer un nombre d’échantillons à travers
l’arbre jusqu’à atteindre les feuilles en favorisant les nœuds de poids les plus élevés. Cette
démarche peut être perçue comme une méthode de Monte-Carlo qui propage les points
dans l’arbre de manière probabiliste de sorte à atteindre les nœuds les plus proches. Même
si une telle démarche fonctionne relativement bien pour des espaces de basses dimensions
(car peu d’échantillons sont nécessaires pour estimer correctement les distributions), pour
des espaces de dimensions élevées il devient nécessaire de faire un choix entre précision de
l’estimation et temps de calculs. En effet le nombre d’échantillons nécessaires pour avoir
une précision de l’estimation suffisante est plus élevé.
Par conséquent, ce genre d’approche ne peut être utilisé dans notre CovTree. Pour ré-
soudre ce problème, nous proposons d’utiliser l’apprentissage des distributions à différents
niveaux de l’arbre et le rayon ηr associé à chaque nœud. Cette démarche nous permet de
limiter le parcours en profondeur de l’arbre, le nombre de nœuds à explorer et d’être plus
indépendant de l’échelle de la requête σq.
Algorithme
Une fois notre CovTree complètement construit et appris, nous utilisons un schéma de requête
pour estimer la gaussienne anisotrope décrivant la distribution des données apprises
pour n’importe quel voisinage centré en q ∈ S d’échelle σq ∈ R.
Tout d’abord, nous collectons l’ensemble des nœuds η qui intersecte la boule [q, σq]. Pour
ce faire, chaque requête traverse l’arbre jusqu’à atteindre une feuille ou un nœud vérifiant4.2. ARBRE DE COVARIANCE SIMPLIFIÉ 63
Algorithm 3: Interroger l’arbre
Fonction InterrogerArbre(q, σq)
Entrées: q ∈ S un point requête et σq une échelle de requête
Sorties: la gaussienne anisotrope N (µˆ, Σˆ )
// Requête de l’arbre en commençant par la racine η0
{w, ˆ wˆ2, µ, Σ} ←CalculerVariations(q, σq, η0)
// Estimation des paramètres de la gaussienne multivariée
µˆ ← 1
wˆµ
Σˆ ← wˆ
2−wˆ2
wˆ
(Σ − wˆµˆ
tµˆ)
retourner N (µˆ, Σˆ )
fin
Fonction CalculerVariations(q, σq, η)
Entrées: q ∈ S un point requête, σq une échelle de requête et η un nœud de
l’arbre
Sorties: µ, Σ, ˆw et ˆw2
si ηr ≤ σq où η est une feuille de l’arbre alors
// Calcul des poids w par approximation d’une gaussienne de variance σq
w ← φ
kq−ηck
σq
// Ajout des variations du nœud η
wˆ := ˆw + w
wˆ2 := ˆw2 + w
2
µ := µ + wµη
Σ := Σ + wΣη
sinon
// Ajout des variations du nœud η en résultat
si (q − ηc)
tηd ≤ σq alors
{w, ˆ wˆ2, µ, Σ} := {w, ˆ wˆ2, µ, Σ}+CalculerVariations(q, σq, ηgauche)
sinon
{w, ˆ wˆ2, µ, Σ} := {w, ˆ wˆ2, µ, Σ}+CalculerVariations(q, σq, ηdroit)
fin
fin
retourner {w, ˆ wˆ2, µ, Σ}
fin
ηr > σq. Lors de la propagation de la requête, nous considérons que chaque cellule est
élargie de σq. Ainsi pour des distances au plan de coupe |(q − ηc)
tηd| < σq, les deux
sous-arbres gauche et droit sont explorés.64
Au final, la distribution en q est estimée par une combinaison des distributions des nœuds
collectés {µi
, Σi} pondérées par des poids wi définis à partir de l’approximation du noyau
gaussien φσq
centré en q et de variance σq :
wˆ =
X
i
wiwηi
wˆ2 = ˆw
2−
X
i
wiw2ηi
µˆ =
1
wˆ
X
i
wiµηi
Σˆ =
wˆ
wˆ2
X
i
wiΣηi − wˆµˆ
tµˆ
(4.4)
Si σq est choisi suffisamment large, la gaussienne anisotrope obtenue décrit la distribution
de l’ensemble des données apprises. L’Algorithme 3 présente le pseudo-code de l’étape de
requête.
4.3 Généralisation
Dans la partie précédente, nous avons présenté une version simplifiée de notre CovTree
qui permet d’apprendre la distribution d’un ensemble de points d’un espace de dimension
arbitraire. Pour une majorité d’applications de notre CovTree, cette définition reste trop
limitée. Nous proposons dans cette section de la généraliser en utilisant deux domaines
distincts : le domaine spatial S qui définit les distances entre les différents échantillons de
l’espace et le domaine des attributs R qui associe chaque échantillon à une valeur.
4.3.1 Notations
Soit un domaine spatial S ∈ R
dS et un nuage de points P = {pi}i∈[[1,N]] de N échantillons.
Nous allons considérer une correspondance f : S → R associant à chaque échantillon de
position spatiale pi ∈ S, une valeur fi du domaine des attributs R ∈ R
dR.
Pour une meilleure compréhension, il peut être utile de considérer f comme une fonction.
Néanmoins, notre structure ne requiert pas que la correspondance f soit connue explicitement,
bien définie ou unique pour n’importe quel p ∈ S. L’association entre les p
et les f est apprise à l’aide de notre approche à partir d’une base de données de paires
d’échantillons (pi
,fi).
Une telle représentation peut par exemple être utilisée pour représenter des images RGB
associant à chaque pixel de l’image pi = (xi
, yi)
T une valeur couleur fi = (ri
, gi
, bi)
T
,
des nuages de points 3D définis par leurs positions spatiales et normales pi = fi =
(xi
, yi
, zi
, nx
i
, n
y
i
, nz
i
)
T
, etc.4.3. GÉNÉRALISATION 65
(a) Population (pi
, fi
) (b) Principe de notre CovTree généralisé
f0
f5
f2
f1
f7
f6
f4
f3
f0
f5
f2
f1
f7
f6
f4
f3
{f1 f3 f6 f4 f7 {
Figure 4.5: Gauche : Considérons une foule dont chaque individu possède une position
spatiale pi définie dans le domaine spatial S et un attribut fi défini dans le domaine des
attributs R. À l’aide de notre CovTree généralisé, nous apprenons la répartition des {fi}
par rapport à leur position spatiale {pi} et à différentes échelles spatiales. Droite : Ainsi en
considérant un sous-ensemble spatial de centre q ∈ S de taille σq ∈ R (représenté en Vert),
notre structure de données permet d’estimer la distribution des attributs des individus qui
sont compris dans ce voisinage en la modélisant par une gaussienne multivariée définie dans
l’espace des attributs R. Cette dernière est définie par une moyenne µˆ ∈ R et une matrice
de covariance Σˆ ∈ R × R.
4.3.2 CovTree généralisé
Principe général
Tout comme sa version simplifiée, la version généralisée de notre CovTree permet d’apprendre
des distributions pour différentes échelles et de fournir pour tout voisinage requête
une gaussienne anisotrope modélisant la distribution des données locales apprises comprise
dans ce voisinage. Cette structure est définie par l’intermédiaire d’un domaine spatial S
(utilisé pour définir le voisinage des échantillons) et d’un domaine des attributs R (utilisé
pour définir les distributions). Ainsi, tout regroupement des échantillons et requête
de voisinage sont effectués dans S alors que les distributions apprises et résultantes sont
définies dans R.
Cette différence étant difficile à appréhender, nous proposons une illustration du principe
du CovTree généralisé ainsi que la distinction entre les deux domaines S et R en Figure
4.5 considérons une population d’individus possédant une position spatiale pi ∈ S (correspondant
à leur position dans l’espace) et un attribut fi ∈ R associé (correspondant
aux valeurs inscrites dans chaque individu). Ici, nous ne posons aucune condition sur le
lien qui existe entre pi et fi
. Par l’intermédiaire de notre CovTree généralisé, nous souhaitons
analyser les variations des attributs associés à un sous-ensemble d’individus de cette
foule. Cette distribution d’attributs sera modélisée par l’intermédiaire d’une gaussienne
anisotrope.66
Applications
S
R Méthode de reconstruction
Gaussien 1D Position des pixels Niveau de gris Moyenne
(xi, yi) (gi)
Gaussian 3D Position des pixels Valeur couleur Moyenne
(xi, yi) (ri, gi, bi)
Bilateral Position des pixels + Valeur couleur Valeur couleur Moyenne
(xi, yi, ri, gi, bi) (ri, gi, bi)
NLM patches autour du pixel Valeur couleur EAP
Pxi,yi
(ri, gi, bi)
NLB Patches Patches MAP
Pxi,yi Pxi,yi
Completion de trous pyramidal Patches basse résolutions Patches hautes résolutions MAP
PSS Point 3D Point 3D Moyenne
xi, yi, zi
n
x
i , n
y
i , n
z
i
xi, yi, zi
n
x
i , n
y
i , n
z
i
NLPSS Patches 3D Champs scalaire EAP
Pxi,yi,zi
vi
NLB-PSS Patches 3D Patches 3D + champs scalaire MAP
Pxi,yi,zi
(Pxi,yi,zi , vi)
Table 4.1: Notre CovTree est très flexible : Cette table montre comment définir les domaines spatiaux
S et des attributs
R ainsi que
la méthode de reconstruction à utiliser.4.3. GÉNÉRALISATION 67
Les regroupements des individus (sous-ensembles) sont définis dans le domaine spatial S,
c’est-à-dire en considérant uniquement les positions spatiales pi de chacun de ces individus.
Ensuite, les distributions de ces différents regroupements sont estimées en considérant
uniquement les attributs fi associés à chaque individu de ce sous-ensemble. Par conséquent,
la gaussienne anisotrope résultante correspond uniquement aux variations dans l’espace
des attributs R de ce sous-ensemble d’individus (et non de leur position spatiale pi).
Notre CovTree généralisé permet donc d’apprendre de grandes bases de données de couples
d’échantillons exemples (pi
,fi) et fournit pour tout voisinage spatial q ∈ S de rayon σq ∈ R
la distribution des attributs associée à ces échantillons représentés par une gaussienne
anisotrope définie dans R. Il est possible de retrouver la version simplifiée de notre CovTree
en confondant les deux domaines spatiaux et des attributs : S = R.
Problèmes de restauration simple
Avant de présenter les modifications apportées par la version généralisée de notre CovTree,
nous illustrons ici quelques problèmes de restauration simple qui peuvent être traités par
notre structure :
1. Convolution gaussienne : Considérons une image à niveaux de gris bruitée
u˜(x, y) = u(x, y)+n(x, y). Dans ce cas dS = 2 (correspondant aux deux coordonnées
spatiales) et dR = 1 (correspondant au niveau de gris). En supposant l’image homogène,
un a priori de la valeur ˜u(x, y) peut être estimé à partir des valeurs ˜u(x
′
, y′
)
d’un ensemble de voisins p = (x
′
, y′
) proche du point requête q = (x, y). Dans ce cas,
la convolution gaussienne peut être définie comme Estimation A Posteriori (EAP)
de cet a priori.
2. Filtre Bilateral : Considérons désormais une image bruitée couleur ˜u(x, y) =
u(x, y) + n(x, y). En définissant dS = 5 (correspondant aux deux coordonnées spatiales
(x, y) plus trois canaux couleurs (r, g, b)) et dR = 3 (les trois canaux couleurs
(r, g, b)). Cette fois l’estimation de la valeur débruitée obtenue est plus fine, en effet,
les points (x, y) proches d’un contour pourront être rejetés grâce à l’information de
couleur qui a été ajoutée au domaine spatial S.
3. Filtre Non-Local : Pour des images hautement texturées, la supposition d’image
lisse des deux précédentes illustrations n’est plus valable. Dans ce cas, les filtres non
locaux supposent que l’ensemble des patchs d’une image texturée appartiennent à
une variété lisse de basse dimension. En prenant pi = fi comme l’ensemble de tout
les patchs de l’image, un patch requête q peut être débruité par les NLB [LBM13]
en calculant une gaussienne multivariée à partir d’un ensemble de patchs voisins
{pj , pj ∈ N(q)} proches de la requête q. Cette distribution gaussienne est utilisée
pour estimer le patch débruité via une Maximisation A Posteriori (MAP) Bayesienne.
En complément des exemples précédents, nous présentons en Table 4.1 d’autres problèmes
de restauration qui peuvent être modélisés par cette structure.
4.3.3 Algorithme généralisé
Les principes sous-jacents et les différents explications proposées pour définir la version
simplifiée de notre CovTree 4.2 restent toujours valables dans sa version généralisée. Ainsi,68
Algorithm 4: Construction de l’arbre généralisé
Fonction ConstruireNœud(C ⊂ pi
, σb ∈ R)
Entrées: C un sous-ensemble de pi
, σb l’échelle d’arrêt
Sorties: η le nœud créé
allouer un nouveau nœud η
// Estimation des paramètres de la cellule
ηd ← le vecteur associé à la plus grande valeur propre de cov(C)
ηc ← mean
pi∈Ck
(pi)
ηr ← max
pi∈Ck
kpi − ηck
si ηr ≤ σb alors
Marquer η comme feuille de l’arbre
sinon
// Répartition des points dans les deux sous-espaces
Cgauche ← {pi ∈ Ck,(pi − ηc)
tηd ≤ 0}
Cdroit ← {pi ∈ Ck,(pi − ηc)
tηd ≥ 0}
// Création des deux sous-arbres
ηgauche ← ConstruireNœud(Cgauche, σb)
ηdroit ← ConstruireNœud(Cdroit , σb)
fin
retourner η
fin
nous présenterons uniquement dans cette section les différences entre les opérateurs simplifiés
et les opérateurs généralisés. Pour que le lecteur appréhende bien ces différences,
nous fournissons le pseudo-code généralisé de chaque étape dans leur intégralité.
Construction
Durant l’étape de construction, nous définissons un partitionnement de l’espace spatial S.
Seules les positions spatiales pi des couples d’échantillons interviennent ici pour définir
des cellules représentatives. En effet, comme nous l’avons illustré en Figure 4.5, notre
structure de données fournit une analyse statistique des variations des attributs en fonction
de regroupements spatiaux (et non en fonction des attributs). Par conséquent, le critère
d’arrêt σb ∈ R correspond désormais à une échelle spatiale. L’Algorithme 4 fournit le
pseudo-code de l’étape de construction généralisée.
Apprentissage
Désormais, l’apprentissage des distributions des échantillons est effectué sur le domaine
des attributs. Comme l’arbre est défini en considérant le domaine spatial S, chaque couple
d’échantillons (pi
,fi) explore l’arbre en fonction de sa position spatiale pi
. Chaque échan-4.4. ANALYSE ET TEMPS DE CALCUL 69
Algorithm 5: Apprentissage des variations locales généralisé
Fonction ApprendreVariations(p,f, η)
Entrées: p un point à ajouter dans la structure, η un nœud de l’arbre
// Calcul des poids w par approximation d’une gaussienne de variance ηr
w ← φ
kpi−ηck
ηr
// Mise à jour des statistiques de chaque nœud
wη := wη + w
w2η := w2η + w.w
µη
:= µη + w.f
Ση := Ση + w.f
t
f
// Apprentissage des statistiques à une échelle inférieure
si η n’est pas une feuille de l’arbre alors
si (p − ηc)
tηd ≤ 0 alors
ApprendreVariations(p,f, ηgauche)
sinon
ApprendreVariations(p,f, ηdroit)
fin
fin
fin
tillon ajoute une contribution partielle pondérée de ces attributs fi
. Le poids est défini par
l’approximation de la gaussienne φ et dépend de la distance spatiale entre pi et le centre
spatial de la cellule ηc.
Lors de cette étape, chaque nœud de l’arbre est associé à une gaussienne anisotrope définie
dans le domaine des attributs R, exprimant la distribution des attributs fi des échantillons
qu’il contient. L’Algorithme 5 présente le pseudo-code de l’opérateur d’apprentissage.
Requête
Pour toute requête définie par une position spatiale q ∈ S et échelle spatiale σq ∈ R,
notre CovTree fournit la distribution des attributs de l’ensemble des échantillons appris
appartenant à ce voisinage spatial par l’intermédiaire d’une gaussienne multivariée définie
dans R. Par conséquent la moyenne µˆ et la matrice de covariance Σˆ estimée par notre
CovTree seront respectivement de dimensions dR et dR × dR. L’Algorithme 6 présente le
pseudo-code de l’étape de requête généralisée.
4.4 Analyse et temps de calcul
Dans cette section, nous analysons la complexité et les temps de calcul de chaque étape
de notre CovTree. Cette analyse est effectuée indépendamment des applications possibles70
Algorithm 6: Interroger l’arbre
Fonction InterrogerArbre(q, σq)
Entrées: q ∈ R un point requête et σq une échelle de requête
Sorties: la gaussienne anisotrope N (µˆ, Σˆ )
// Requête de l’arbre en commençant par la racine η0
{w, ˆ wˆ2, µ, Σ} ←CalculerVariations(q, σq, η0)
// Estimation des paramètres de la gaussienne multivariée
µˆ ← 1
wˆµ
Σˆ ← wˆ
2−wˆ2
wˆ
(Σ − wˆµˆ
tµˆ)
retourner N (µˆ, Σˆ )
fin
Fonction CalculerVariations(q, σq, η)
Entrées: q ∈ S un point requête, σq une échelle de requête et η un nœud de
l’arbre
Sorties: µ, Σ, ˆw et ˆw2
si ηr ≤ σq où η est une feuille de l’arbre alors
// Calcul des poids w par approximation d’une gaussienne de variance σq
w ← φ
kq−ηck
σq
// Ajout des variations du nœud η
wˆ := ˆw + w
wˆ2 := ˆw2 + w
2
µ := µ + wµη
Σ := Σ + wΣη
sinon
// Ajout des variations du nœud η en résultat
si (q − ηc)
tηd ≤ σq alors
{w, ˆ wˆ2, µ, Σ} := {w, ˆ wˆ2, µ, Σ}+CalculerVariations(q, σq, ηgauche)
sinon
{w, ˆ wˆ2, µ, Σ} := {w, ˆ wˆ2, µ, Σ}+CalculerVariations(q, σq, ηdroit)
fin
fin
retourner {w, ˆ wˆ2, µ, Σ}
fin
de notre structure de données. Par conséquent, seules les performances temps et mémoire
pour estimer des gaussiennes anisotropes seront prises en compte ici.
Pour une analyse plus détaillée concernant les performances qualitatives de notre CovTree,
nous renvoyons le lecteur en Section 5.1.1 où une implémentation des filtrages collaboratifs
réalisés par l’intermédiaire de notre structure est comparée aux méthodes de l’état de l’art.4.4. ANALYSE ET TEMPS DE CALCUL 71
4.4.1 Complexité
Notre CovTree est basé sur les trois principaux opérateurs de construction, apprentissage
et requête. Nous rappelons que S est un domaine spatial de dimension dS et R un domaine
des valeurs de dimension dR.
Nous proposons d’analyser la complexité temporelle de ces trois principales étapes :
1. Construction : Supposons que nous utilisons Nb points pour définir le partitionnement
de l’espace. Durant cette étape de construction, chacun des Nb points apparaît
une seule fois dans chaque nœud de l’arbre. À chaque division est effectuée une
analyse en composantes principales pour déterminer la direction de plus grande variation.
Cette dernière est accélérée par la méthode des puissances qui estime le
vecteur propre principal avec une complexité O(2mdSNb) ou la constante m = 3.
Ainsi, en considérant que notre arbre possède Kb nœuds l’étape de construction
complète prend O(dSNblog(Kb)).
2. Apprentissage : Supposons que nous utilisons Nl échantillons pour apprendre les
distributions des données (e. g. Nl >> Nb). Comme les Nl points parcourent l’arbre
en partant de la racine jusqu’à atteindre une feuille en n’explorant qu’une seule
des deux sous-branches de chaque nœud, la classification des points prend donc
O(NldSlog(Kb)). Pour chaque nœud rencontré, les matrices de covariance et moyenne
sont mises à jour ce qui requiert un temps de O(Nld
2
Rlog(Kb)). L’étape d’apprentissage
totale requiert donc O(Nl(dS + d
2
R)log(Kb)).
3. Requête : Supposons que nous utilisons Nq points en requête de notre arbre. Tout
d’abord nous effectuons la recherche des Kq plus proches nœuds demandant une
complexité de O(NqdSKq). Ensuite, l’estimation des gaussiennes anisotropes né-
cessite O(Nqd
2
RKq). Au total, notre étape de requête possède une complexité de
O(Nq(dS + d
2
R)Kq).
Le coût mémoire de notre structure dépend uniquement du nombre de nœuds créés lors
de l’étape de construction. En effet chaque point appris lors de l’étape d’apprentissage ne
fait que mettre à jour les données apprises par chaque nœud de l’arbre sans prendre plus
de mémoire. Par conséquent, le coût total en mémoire de notre structure de données est
O(Kbd
2
R).
4.4.2 Discussion
Il est intéressant de noter que l’arbre peut être construit sur un ensemble d’échantillons
différents de ceux de la base d’apprentissage. De toute évidence pour que cette propriété
soit intéressante, il est nécessaire que l’ensemble utilisé pour la construction soit significatif
par rapport à l’ensemble des échantillons de l’étape d’apprentissage. Outre l’accélération
évidente qu’apporte la diminution du nombre d’échantillons, notre structure permet un
apprentissage progressif des données. Il devient possible de raffiner la précision des distributions
pour un budget mémoire constant en apprenant des données supplémentaires.
Cette propriété est l’un des aspects principaux de notre CovTree. Nous pouvons donc apprendre
la distribution d’échantillons issue de grandes bases de données tout en contrôlant
la quantité mémoire nécessaire à son apprentissage. Cette propriété permet également de72
1
5.5
10
128 256 512 1024
Temps (s)
Facteur de filtrage
Figure 4.6: Temps de calcul (en seconde) pour estimer 5.105
requêtes (excluant les étapes
de construction et d’apprentissage qui sont exécutées une seule fois) par notre CovTree
pour différentes échelles σq. Le temps est mesuré en se contraignant à l’utilisation d’un
seul cœur de calcul sur un PC avec un processeur 2.4 GHz Intel Xeon avec 12 GB de
mémoire.
pouvoir réapprendre et/ou mettre jour les distributions sans pour autant avoir besoin de
reconstruire complètement l’arbre.
Une fois les données apprises, l’arbre peut être réutilisé pour différentes applications sans
avoir besoin de recommencer son apprentissage complet. Cette propriété, particulièrement
utile dans les technologies mobiles qui possèdent des capacités limitées, est possible grâce à
notre algorithme de requête. L’estimation d’une gaussienne anisotrope pour tout voisinage
de centre q ∈ S et toute échelle σq ∈ R ne requiert pas de recalculer l’arbre.
Nous présentons en Figure 4.6 la courbe des temps de calcul pour interroger notre CovTree
pour différentes échelles σq. Il est intéressant de noter que le temps requis pour
résoudre une requête reste peu affecté par la taille σq de la requête. Cet avantage est dû à
l’apprentissage des distributions à différentes échelles qui permet de limiter le nombre de
nœuds (et du coup la complexité de calcul) nécessaires pour évaluer une requête. Comme
nous le montrons en Figure 4.7, pour des échelles σq faibles, le parcours de l’arbre est
uniquement effectué en profondeur. Pour des échelles σq élevées, au lieu de parcourir un
grand nombre de nœuds (et ainsi de renvoyer les variations d’un grand nombre de feuilles),
notre démarche permet d’effectuer un parcours en largeur de l’arbre tout en limitant son
exploration en profondeur. Le pire des cas correspond aux échelles σq de taille moyenne.
En effet, la requête doit effectuer un parcours en largeur et en profondeur. Il en résulte un
grand nombre de nœuds à explorer pour pouvoir estimer cette requête.
4.5 Limitations et possibles améliorations
Dans ce chapitre, nous avons introduit une nouvelle structure de données capable de traiter
une famille continue de gaussiennes multivariés locales. Notre structure est efficace pour
apprendre de grandes quantités d’échantillons avec peu d’espace mémoire et permet une
estimation rapide des requêtes. Le modèle extrait varie continûment sur un domaine de valeurs
R quand le point requête varie sur un domaine spatial S (potentiellement différent).
En plus de la position, différentes échelles peuvent être spécifiées à la requête permet-4.5. LIMITATIONS ET POSSIBLES AMÉLIORATIONS 73
Figure 4.7: Notre requête accélérée permet de limiter le nombre de nœuds du CovTree
à explorer (en vert) pour estimer une distribution anisotrope locale. (a) Quand la requête
possède une échelle σq large, seuls les nœuds supérieurs de l’arbre sont explorés. (b) Pour
des valeurs plus petites de σq, l’arbre est parcouru plus en profondeur tout en limitant
son parcours en largeur.
tant de définir différents degrés de localité spatiale pour le modèle statistique extrait.
Cette structure de données sera utilisée dans le chapitre suivant pour résoudre différents
problèmes de restauration.
Néanmoins, notre structure de données peut être améliorée. En effet, lors de la construction
de l’arbre, nous définissons un partitionnement de l’espace par l’intermédiaire d’un bsp-tree.
Par rapport à d’autres structures de partitionnement, cet type d’arbre permet de mieux
gérer l’anisotropie des données. Néanmoins, il n’offre aucune garantie sur la conservation
de la topologie des échantillons que nous souhaitons apprendre. Par conséquent, les sousespaces
définis de cette manière ne sont pas obligatoirement les plus significatifs pour
représenter la variété sous-jacente aux données. Il en résulte une augmentation significative
du nombre de nœuds pour représenter les échantillons ainsi qu’une mauvaise estimation
des matrices de covariances correspondantes. Ce genre de problème peut être résolu par
l’utilisation de structures de partitionnement qui respectent la topologie des données.
Dans tout ce chapitre, nous avons fait la supposition que l’ensemble des échantillons étaient
connus à l’avance ou qu’une partie suffisamment significative était connue. Pour de nombreuses
applications où les échantillons arrivent au fur et à mesure (par ex. traitement
vidéo, internet), il est impossible de définir un sous-ensemble significatif sans connaître
l’intégralité des données. Ce type de problèmes peut être géré par notre structure de données
en modifiant l’étape de construction. Une solution possible serait de partitionner
l’arbre progressivement en fonction des données qui sont fournies en entrée de l’arbre. Il
faut donc distinguer trois cas : (a) quand le nombre d’échantillons d’un nœud est trop
faible, il est nécessaire de garder en mémoire l’ensemble des échantillons (b) quand le
nombre d’échantillons d’un nœud est trop élevé le sous-espace correspondant doit être
divisé en deux (c) sinon il faut garder en mémoire la distribution des échantillons. Malheureusement,
une telle solution ne permet pas de résoudre les problèmes concernant la
propagation des données apprises d’un nœud à ses enfants.74
Une autre amélioration possible de notre structure de données serait de faire évoluer les
données apprises avec le temps. Considérons le cas où un ensemble d’échantillons a besoin
d’être appris à des temps {t0, t1, . . . , tn} (par ex. flux vidéo). Nous supposons que pour deux
temps consécutifs tk, tk+1, les variations entre échantillons à apprendre sont faibles. Au
temps tk+1, il est intéressant de conserver partiellement les données apprises au temps tk.
Nous proposons d’introduire un facteur d’oubli 0 ≤ α ≤ 1. Ce dernier serait multiplié aux
données apprises à chaque changement de temps pour permettre de simuler une persistance
mémorielle. Pour α = 0, l’ensemble d’échantillons appris est oublié d’un temps à l’autre.
Pour α = 1, l’ensemble des échantillons est gardé en mémoire indéfiniment. Pour toutes
valeurs de α, les données sont oubliées au fur et à mesure et remplacées par les nouveaux
échantillons. Une telle solution suppose que le partitionnement de l’espace spatial S n’a
pas besoin d’être mis à jour, ce qui est rarement vérifiable en pratique.C h a p i t r e 5
Filtrage collaboratif généralisé
Dans cette partie, nous présentons plusieurs applications de restauration d’images et de
surfaces 3D basées sur notre structure de données, le CovTree, introduite au Chapitre 4.
En Section 5.1, nous proposons d’appliquer notre CovTree au débruitage d’images pour
calculer l’algorithme des Non Local Bayes. Cette section nous permet de valider les performances
qualitatives de notre structure de données, en comparant les performances des
Non Local Bayes obtenues par notre CovTree et leur implémentation originale [LBM13].
En Section 5.2, nous utilisons notre CovTree pour apprendre un grand ensemble de patchs
non bruités de sorte à définir un a priori des images naturelles. Nous l’utilisons pour amé-
liorer le débruitages des images et pour définir la reconstruction d’images échantillonnées
aléatoirement. En Section 5.3, nous introduisons les problèmes et les idées principaux pour
pouvoir étendre les filtres collaboratifs au cas des nuages de points 3D. Dans cette section,
nous utilisons les outils développés au Chapitre 3, pour étendre les NLPSS au cas des
Non Local Bayes. Nous présentons également comment définir une base de données 3D
appliquée à l’augmentation de la résolution du nuage de points.
5.1 Débruitage d’images par filtre collaboratif
Durant ces dernières années, les différentes évolutions des filtres non locaux ont permis
de développer un nouveau type de filtre : les filtres collaboratifs. Contrairement aux approches
par NL-Means qui débruitent les patchs de l’image sans se soucier d’une information
globale, ce type de filtre effectue une analyse commune de l’information basée sur des
regroupements de patchs similaires. Ces méthodes permettent d’extraire les détails communs
d’un groupe tout en préservant les caractéristiques spécifiques du patch considéré.
Nous allons particulièrement nous intéresser aux NLB (Non Local Bayes) [LBM13] car
ils exploitent l’information commune par l’intermédiaire d’une analyse de la moyenne et
de la covariance du groupe de patchs. Malheureusement, comme il est coûteux et difficile
d’effectuer des regroupements directement dans l’espace des patchs, ces statistiques sont
généralement approchées de sorte que le filtre reste calculable.
La formulation des NLB étant particulièrement adaptée, nous proposons, dans cette section,
de les accélérer par l’intermédiaire de notre CovTree généralisé (Section 4.3.3). Cette
application nous permet d’étendre au cas des NLB certaines accélérations classiques des
7576
NL-Means (telle que la réduction de la dimensionnalité globale des patchs par une analyse
en composantes principales [APG07, Tas08, Tas09]) et de fournir une analyse qualitative
des performances de notre CovTree.
5.1.1 Non Local Bayes
Principe
Considérons un ensemble P = {fi} de patchs de dimension dP obtenu à partir d’un ensemble
de patchs non bruités P˜ = {ri} corrompu par un bruit additif ni gaussien d’écart
type σn :
fi = ri + ni
La probabilité du bruit qui est rajoutée à chaque patch correspond donc à une gaussienne
isotrope d’écart type σn.
Introduit par Lebrun et coll. [LBM13], les NLB débruitent un patch d’intérêt q ∈ R
dP en
utilisant une Maximisation A Posteriori (MAP) bayésienne. Cette maximisation, équivalente
à projeter le patch q localement sur la variété de patchs non bruités, suppose que les
variations probabilistes des patchs s’expriment par une gaussienne anisotrope N (µq
, Σq)
de moyenne µq
et de matrice de covariance Σq. Ne pouvant être directement calculée sur
un ensemble de patchs non bruités, cette gaussienne est estimée à partir des patchs bruités
{fi}.
Les NLB sont basés sur trois principaux opérateurs inspirés des travaux concernant les
BM3D (Block Matching 3D) [DFKE07,DFKE08,DFKE09] :
1. Regroupement : un groupe de patchs N(q) similaires à q est formé en considérant
une distance quadratique normalisée. Le voisinage est défini à la fois dans l’espace
des patchs et dans l’espace spatial (distance pixelique entre les centres des patchs).
Cette restriction permet de rendre la recherche des patchs similaires calculables pour
de grandes images, car elle devient indépendante de la taille de l’image. De plus, pour
ne pas être trop sensible aux patchs parasites, le groupe est généralement limité aux
k plus proches patchs.
2. Débruitage collaboratif : les variations des patchs associés au groupe sont modélisées
de manière probabiliste par une gaussienne anisotrope N (µq
, Σq) qui est
ensuite utilisée pour définir un estimateur par MAP du patch débruité. Lors de cette
étape, chaque patch est débruité indépendamment les uns des autres.
3. Agrégation : chaque pixel de l’image, commun à plusieurs patchs, est associé à
plusieurs valeurs débruitées. Une valeur débruitée finale est donc obtenue par une
moyenne sur l’ensemble des valeurs débruitées.
Débruitage itératif
Afin d’améliorer les performances du débruitage et d’estimer une gaussienne anisotropique
N (µq
, Σq) non biaisée, ces trois étapes sont itérées deux fois.
Lors de la première itération, le patch d’intérêt q est débruité en considérant l’ensemble des
patchs bruités {fi}. La gaussienne anisotrope correspond donc aux variances de l’ensemble5.1. DÉBRUITAGE D’IMAGES PAR FILTRE COLLABORATIF 77
des patchs bruités. Afin de débruiter conjointement les patchs du groupe tout en obtenant
une modélisation des patchs non bruités, la matrice de covariance Σq est filtrée par un
facteur σ
2
d
correspondant à la variance du bruit estimée que contient l’image (σd ≈ σn) :
Σ′
q = Σq − σ
2
d
Id. L’estimateur de débruitage NLB(1) est défini pour tout patch bruité q
associé à une moyenne µq
et une matrice de covariance Σq calculée sur l’ensemble {fi}
par :
NLB(1)(q, µq
, Σq) = µq + [Σq − σ
2
d
Id]Σ−1
q
(q − µq
) (5.1)
Les patchs bruités {fi} sont donc débruités une première fois par :
ˆr
(1)
i = NLB(1)(fi
, µfi
, Σfi
) (5.2)
Durant la deuxième itération, le patch d’intérêt q est débruité en considérant l’ensemble
des patchs {ˆr
(1)
i
}. La gaussienne anisotrope décrit donc, désormais, les variations de
l’ensemble des patchs débruités autour du patch d’intérêt débruité une première fois
q
(1) = NLB(1)(q, µq
, Σq). L’estimateur de débruitage NLB(2) est défini pour tout patch
bruité q associé à une moyenne µq(1) et une matrice de covariance Σq(1) calculée sur
l’ensemble {ˆr
(1)
i
} par :
NLB(2)(q, µq(1) , Σq(1) ) = µq(1) + Σq(1) [Σq(1) + σ
2
d
Id]
−1
(q − µq(1) ) (5.3)
Les patchs bruités {fi} sont donc débruités une deuxième fois par :
ˆr
(2)
i = NLB(2)(fi
, µˆr
(1)
i
, Σˆr
(1)
i
) (5.4)
Critère d’homogénéité
Lors du calcul de l’Équation 5.1, certaines instabilités peuvent apparaître lorsque σd ≤ σn.
Ces instabilités sont dues à l’estimation de la matrice de covariance débruitée Σ′
q
. Il faut
donc s’assurer par une Analyse en Composantes Principales (ACP) que l’ensemble des
valeurs propres de Σ′
q
restent positives ou nulles. Malheureusement, effectuer une ACP
est d’autant plus coûteux que la dimension de l’espace des patchs dP est élevée. Les NLB
proposent une résolution partielle de ce problème en introduisant un critère d’homogénéité.
Dans le cas où l’ensemble des valeurs propres de Σ′
q
sont négatives, les variations du
groupe dans n’importe quelle direction correspondent uniquement à celles du bruit (cas
d’un groupe de patchs homogène). Par conséquent, le meilleur estimateur pour le patch
débruité est un patch moyen ¯r dont les valeurs sont toutes définies par :
∀k ∈ [[1, dP]], ¯r(k) = X
fi∈N(q)
X
dP
l=1
fi(l) (5.5)
Le critère d’homogénéité permet de vérifier que le patch d’intérêt q n’est pas un patch
homogène avant d’appliquer l’une des deux Équations 5.1 ou 5.3 accélérant ainsi le temps
de calcul. En considérant un ensemble de m valeurs (correspondant à l’ensemble des valeurs
contenues dans chaque patch du groupe), le critère d’homogénéité définit l’écart type des
valeurs du groupe σh :
σ
2
h =
1
m − 1
X
fi∈N(q)
X
dP
k=1
fi(k)
2 −
X
fi∈N(q)
X
dP
k=1
fi(k)
2
(5.6)78
Lorsque σh ≤ σn, le patch débruité est défini par l’Équation 5.5 sinon il reste débruité par
les Équations 5.1 ou 5.3.
Il est important de noter que ce critère permet de résoudre les problèmes d’instabilités
quand l’ensemble des valeurs propres de Σ′
q
sont négatives, mais ne permet pas résoudre
les instabilités de calculs lorsqu’une partie des valeurs propres sont négatives. En pratique,
ce problème reste peu visible, car il est atténué par l’étape d’Agrégation et l’utilisation de
la double itération de l’algorithme.
5.1.2 Débruitage d’images par CovTree
Adaptation des NLB
Nous rappelons que le CovTree, tel qu’il a été introduit en Section 4.3.3, est une structure
de données capable d’apprendre les variations d’un ensemble d’échantillons (pi
,fi) où pi
est une position dans le domaine spatial S et fi est un attribut du domaine des attributs R.
Le domaine spatial S est utilisé pour effectuer des regroupements entre les échantillons et le
domaine des attributs R est utilisé pour analyser les variations des échantillons. Pour toute
requête (q ∈ S, σq ∈ R), la structure retourne la gaussienne anisotrope N (µq,σq
, Σq,σq
)
de moyenne µq,σq ∈ R et de covariance Σq,σq ∈ R × R modélisant les variations des
échantillons compris dans un voisinage spatial N(q, σq).
La formulation des NLB étant particulièrement adaptée pour être calculée par notre CovTree,
nous pouvons faire un parallèle entre les opérateurs du CovTree et les étapes des
NLB. Par exemple, les opérateurs d’Apprentissage et de Requête peuvent être utilisés pour
estimer une gaussienne anisotropique équivalente à celle estimée lors de l’étape de Débruitage
collaboratif. Dans ce cas-là, le domaine des attributs R est défini par l’espace des
patchs. Les attributs appris correspondent donc aux patchs de l’image.
Pour pouvoir appliquer les deux itérations des NLB de manière équivalente, nous devons
utiliser deux CovTree différents. La première est construite et apprise en utilisant
l’ensemble des patchs de l’image bruités {fi} puis utilisée afin de débruiter l’ensemble
des patchs par l’Équation 5.1 pour obtenir un premier débruitage des patchs {ˆr
(1)
i
}. La
deuxième est définie par rapport à l’ensemble des patchs débruités {ˆr
(1)
i
} de sorte à pouvoir
être utilisée par l’Équation 5.3 pour définir le patch débruité final.
La gaussienne anisotropique N (µq,σq
, Σq,σq
) estimée par notre CovTree dépend explicitement
de la taille du voisinage σq considéré. Contrairement aux NLB originaux qui fixent
définitivement cette taille pour accélérer le calcul du filtre, nous pouvons estimer diffé-
rentes images débruitées en changeant la taille σq avec une influence négligeable sur le
temps de calcul total.
Critère de regroupement
La distinction entre le domaine spatial S et celui des attributs R nous permet de définir
différents critères de regroupement. En effet l’étape de Construction de notre CovTree
permet d’effectuer des divisions dans S qui servent à rassembler les échantillons proches.5.1. DÉBRUITAGE D’IMAGES PAR FILTRE COLLABORATIF 79
La Construction du CovTree est donc équivalente à l’étape de Regroupement. La définition
des données spatiales utilisées par notre CovTree permet d’introduire différents types de
regroupement N(q).
Nous introduisons donc trois différents types de voisinage pour les NLB :
1. Voisinage global : nous définissons un domaine spatial S qui est confondu avec
le domaine des attributs R par p = fi
. Dans ce cas, le voisinage N(q) dépend
uniquement de la similarité entre les patchs bruités fi et le patch requête q. Le
domaine spatial S est donc de dimension dS = dP.
2. Voisinage local : afin de définir un voisinage équivalent à celui utilisé dans la version
originale des NLB, nous proposons d’augmenter S avec les coordonnées pixéliques du
centre du patch x = (xi
, yi). Par conséquent, les pi doivent désormais être proches
spatialement de q. Ce voisinage est défini dans un domaine spatial S de dimension
dS = dP + 2.
3. Voisinage local compressé : l’idée ici est d’adapter la réduction de dimensionnalité
des patchs proposée dans le cas des NL-Means [APG07,Tas08,Tas09] au NLB. Nous
proposons donc de réduire les dP dimensions de l’espace des patchs aux l < dP
dimensions principales par une ACP globale de l’ensemble des patchs bruités de
l’image. Dans ce cas, S est de dimension dS = l + 2.
Il est important de noter que seul le domaine spatial S est changé (et a fortiori les regroupements
des différents patchs). En particulier, le domaine des attributs R ne change pas,
ce qui permet de calculer les NLB avec différent types de voisinages sans avoir à modifier
les équations originales.
Critère d’homogénéité
Tout comme dans la version originale des NLB, nous pouvons définir un critère homogène
calculable à partir de la moyenne µq
, la matrice de covariance Σq et des deux constantes
de normalisation wq et w2q estimées par notre CovTree. Dans notre cas, l’écart type des
valeurs du groupe σh est défini par :
σ
2
q =
1
w2
qdP − w2q
(w
2
q − w2q)
Tr(Σq) + wq
µq
2
2
−
w
2
q
dP
X
l=1
µq
(l)
!2
(5.7)
De plus, l’ensemble des valeurs de patch moyen ¯r sont définies par
∀k ∈ [[1, dP]], ¯r(k) = 1
dP
X
dP
l=1
µq
(l) (5.8)
Le critère d’homogénéité tel qu’il a été introduit dans les cas de NLB originaux reste
inchangé dans le cas de l’utilisation de notre CovTree.
5.1.3 Analyse des paramètres
Dans cette partie, nous proposons une analyse des différents paramètres de l’application
du CovTree au débruitage d’images. Nous n’analysons pas ici l’influence de l’échelle d’arrêt
de notre CovTree car il est lié uniquement à la taille mémoire finale utilisée par notre80
structure. Nous n’analysons pas non plus l’influence de la taille des patchs sur la reconstruction,
nous renvoyons donc le lecteur vers une analyse plus approfondie de ce paramètre
effectué par Lebrun et coll. [LBM13].
Facteur de filtrage
Le facteur de filtrage σd correspond à la quantité de bruit que contiennent les patchs
bruités. Nous présentons en Figure 5.1 les restaurations d’une image corrompue par un
bruit gaussien d’écart type σn = 0.08 obtenu pour différentes valeurs de σd. Pour mieux
analyser l’influence de ce paramètre sur la qualité de la restauration finale, une seule
itération des NLB sans utiliser le critère d’homogénéité a été appliquée (Équation 5.1).
Une analyse de la qualité de la restauration de l’image en fonction de l’évolution de ce
paramètre n’est généralement pas effectuée car il est évident que la meilleure restauration
sera obtenue pour des valeurs , σd ≈ σn. Dans notre cas, l’évolution de ce facteur nous
permet d’analyser les performances qualitatives de notre CovTree.
Pour des valeurs de σd trop faibles (cas σd = 0.04), la matrice de covariance Σ′
q =
Σq − σ
2
d
Id n’est pas assez débruitée. Ainsi, le patch débruité obtenu est proche du patch
bruité passé en requête. Pour des valeurs de σd trop élevées (cas σd = 1.00), l’ensemble
des valeurs propres associées à la matrice de covariance Σ′
q
sont nulles. Le patch débruité
obtenu est donc confondu avec la moyenne µq
estimée par notre CovTree. Pour des valeurs
de σd moyennes (cas σd = 0.08), la matrice de covariance Σ′
q
est exploitée efficacement de
sorte à extraire l’information commune à l’ensemble des patchs bruités du groupe. L’image
résultante réussit à supprimer le bruit tout en préservant les détails fins.
Il est important de noter que l’image moyenne (cas σd = 1.00) conserve les caractéristiques
principales de l’image d’entrée. Ainsi, les différentes divisions effectuées par notre structure
de données dans le domaine spatial S respectent la topologie des patchs. L’image moyenne
réussit en effet à flouter les zones homogènes tout en préservant les contours principaux de
l’image. Une grande majorité des détails de l’image ont néanmoins été supprimés, car le
nombre de nœuds de notre structure reste limité. Contrairement à d’autres structures d’accélération
telle que les Gaussian KD-Tree [AGDL09], notre structure utilise des matrices
de covariance pour représenter les variations du groupe. Le pouvoir de représentation des
covariances étant plus important que celui de simples moyennes, le nombre de noeuds né-
cessaire pour apprendre l’information contenue dans l’image est inférieur. Cette propriété
est illustrée dans le cas σd = 0.08 où des détails fins de l’image sont restaurés, confirmant
que les gaussiennes anisotropes estimées lors des étapes d’Apprentissage et de Requête sont
représentatives des variations de chaque groupe de patchs.
Taille du voisinage spatial
Par l’intermédiaire de notre CovTree, on peut estimer une gaussienne anisotrope pour
différentes tailles de voisinage σq. Contrairement au NLB classique, il est possible d’estimer
les gaussiennes anisotropes pour différentes échelles pour un coût équivalent (Section 4.4.2).
Nous présentons en Figure 5.2, les restaurations de trois différentes images bruitées avec
un bruit additif gaussien d’écart type σn = 0.5 obtenues pour différentes tailles σq.5.1. DÉBRUITAGE D’IMAGES PAR FILTRE COLLABORATIF 81
Image originale
Bruit d'écart type 0.08
Figure 5.1: Restauration d’une image corrompue par un bruit gaussien d’écart type 0.08
obtenu pour différents σd. Le choix idéal de σd est représenté en gras.82
Figure 5.2: Restaurations d’une image corrompue par un bruit additif gaussien d’écart
type 0.2 obtenues pour différentes échelles d’estimation de la gaussienne anisotrope σq.
Plus la taille σq est élevée plus la gaussienne anisotrope résultante est grossière. La taille
idéale pour estimer la matrice de covariance est représentée en gras. Contrairement au
NLB, la taille du voisinage peut être changée sans nécessiter de calculs supplémentaires.
Pour des valeurs de σq trop larges (cas σq = 1.5), la gaussienne anisotrope estimée est
trop grossière pour correctement modéliser la variété sous-jacente des patchs débruités.5.1. DÉBRUITAGE D’IMAGES PAR FILTRE COLLABORATIF 83
Bruit écart type 0.08 Crit. global (147-D) Crit. local (147+2-D) Crit. compressé (6+2-D)
PSNR 22.7 dB PSNR 27.6 dB PSNR 28.0 dB PSNR 28.4 dB
Figure 5.3: Comparaison des restaurations obtenues pour différents critères de voisinage.
La première ligne correspond aux débruitages obtenus et la deuxième à l’écart entre le
débruitage et l’image originale.
Par conséquent, l’image restaurée perd toute l’information haute fréquence qu’elle contient
entraînant la création de zones floues.
Pour des tailles σq faibles (cas σq = 0.5), il n’est pas possible d’extraire les caractéristiques
communes à chaque groupe. Ainsi, la gaussienne anisotrope résultante permet de
représenter uniquement les structures de bruit locales ce qui se traduit par l’apparition
d’un bruit de haute fréquence sur les images restaurées. La taille de voisinage idéale (cas
σq = 0.6) doit être choisie par rapport à la quantité de bruit contenue dans les patchs bruités.
Une telle taille permet de limiter l’apparition des hautes fréquences tout en préservant
les caractéristiques de l’image.
Choix du voisinage
Nous présentons en Figure 5.3 différentes restaurations d’une image corrompue par un
bruit additif gaussien d’écart type 0.08 pour différents types de voisinages.
En utilisant un critère global, les regroupements de patchs se font uniquement en considérant
une distance calculée dans l’espace des patchs. L’ensemble des patchs appris étant
bruité, cette distance est très dépendante de la quantité de bruit dans les patchs. Ainsi,
les groupes de patchs contiennent plus facilement des patchs parasites influençant négativement
la qualité de la restauration finale. Un critère global peut donc être difficilement
utilisé dans le cas de patchs bruités.
Pour résoudre ce problème, il suffit d’augmenter de deux dimensions le domaine spatial
correspondant à la position pixelique du centre du patch. Ce critère local permet de limiter84
30.7
31
31.3
1 2 4 8 16 32 64
PSNR(dB)
Dimensionnalité spatiale ( )
Figure 5.4: Évolution du PSNR du débruitage de 20 images par notre CovTree-NLB en
fonction de la réduction par ACP de la dimensionnalité du domaine spatial. La courbe
moyenne est représentée en rouge et l’écart type des données centrées en gris. Les courbes
de PSNR de chaque images présentent des formes similaires et montrent un pic autour des
valeurs dS = 4.
le nombre de points parasites présents dans un groupe. L’image restaurée est donc d’une
meilleure qualité. Dans la version originale des NLB, ce critère est également utilisé afin
d’accélérer le calcul du filtre en rendant indépendante de la taille de l’image l’étape de
Regroupement.
Comme nous le présentons en Figure 5.4, le critère compressé qui effectue une réduction
de dimensionnalité par ACP appliqué sur le domaine S permet non seulement d’accélérer
la recherche, mais de produire également de meilleurs résultats. Ce phénomène peut être
expliqué par le fait que les valeurs propres les plus petites contiennent principalement du
bruit. En gardant uniquement les valeurs propres les plus élevées, la distance entre les
patchs devient donc moins sensible au bruit permettant de définir des regroupements de
patchs plus pertinents.
Schéma itératif
Nous présentons en Figure 5.5, trois images restaurées obtenues après la première itération
(Équation 5.1 puis la deuxième itération (Équation 5.3) des NLB. Les images sont
corrompues avec un bruit additif gaussien d’écart type σn = 0.2.
La première itération des NLB permet de récupérer les caractéristiques principales de
l’image. Étant calculée uniquement sur l’ensemble des patchs bruités, l’estimation des gaussiennes
anisotropes reste néanmoins biaisée entraînant l’apparition d’artefacts de hautes
fréquences et de changements de teinte de certaines zones de l’image.
Appliquer une deuxième itération calculée sur l’ensemble des patchs débruités permet
de corriger ces problèmes. Désormais les variations et les regroupements sont calculés en
considérant une distance entre les patchs qui n’est plus biaisée par le bruit. Les regroupements
formés sont donc plus pertinents et permettent de mieux faire ressortir les détails
communs à chaque groupe de patchs. Les images résultantes obtenues préservent mieux
les caractéristiques.5.1. DÉBRUITAGE D’IMAGES PAR FILTRE COLLABORATIF 85 Première itération des NLB Deuxième itération des NLB
PSNR 24.1 dB
PSNR 24.6 dB PSNR 29.2 dB PSNR 29.6 dB
PSNR 29.0 dB PSNR 29.6 dB
Figure 5.5: Images débruitées obtenues après la première et la deuxième itération de notre
CovTree-NLB à partir de trois images corrompues par un bruit additif gaussien d’écart
type 0.2. Afin de mieux comparer les performances, nous fournissons des agrandissements
des trois images sur les deux lignes centrales.
Néanmoins, lorsque l’information d’un groupe est trop filtrée lors de la première itération,
il devient difficile de récupérer cette information lors de la deuxième itération. Inversement,
si le bruit présent dans le groupe n’est pas totalement éliminé alors il pourra être
considéré comme une caractéristique principale du groupe diminuant ainsi la qualité de la
restauration.86Original NL-Means NLB Original NLB par CovTree Bruit
PSNR 14.7 dB PSNR 14.6 dB PSNR 14.8 dB
PSNR 27.9 dB PSNR 23.8 dB PSNR 28.8 dB
PSNR 29.0 dB PSNR 24.7 dB PSNR 29.5 dB
PSNR 29.2 dB PSNR 24.6 dB PSNR 29.6 dB
Figure 5.6: Résultats de restaurations obtenus pour différents algorithmes de débruitages
non locaux : les NL-Means [GO12], les NLB originaux [LBM13] et notre CovTree-NLB.
Un agrandissement de ces images est proposé en Figure 5.7
5.1.4 Résultats
Nous présentons en Figure 5.6 les résultats obtenus pour trois méthodes : les NL-Means
calculées par l’approche de Gastal et coll. [GO12], les NLB originaux [LBM13] et notre
CovTree-NLB. Ces méthodes sont appliquées à trois différentes images corrompues par
un bruit additif gaussien d’écart type 0.2. Pour mieux percevoir les différences entre les
différentes méthodes, nous présentons en Figure 5.7 des vues détaillées de ces différents
résultats. Les résultats du CovTree sont obtenus sans utiliser le critère d’homogénéité et
en réduisant la dimensionnalité des patchs aux 6 principales dimensions.5.1. DÉBRUITAGE D’IMAGES PAR FILTRE COLLABORATIF 87 Original NL-Means NLB Original NLB par CovTree
PSNR 14.7 dB PSNR 14.6 dB PSNR 14.8 dB
PSNR 27.9 dB PSNR 23.8 dB PSNR 28.8 dB
PSNR 29.0 dB PSNR 24.7 dB PSNR 29.5 dB
PSNR 29.2 dB PSNR 24.6 dB PSNR 29.6 dB
Bruit
Figure 5.7: Comparaison de différents algorithmes non locaux : les NL-Means [GO12],
les NLB originaux [LBM13] et notre CovTree-NLB.88
Dans le cas des NL-Means, les pixels de l’image sont débruités à partir d’une combinaison
de valeurs bruitées. Le poids de chaque élément est calculé en fonction d’une mesure de
similarité évaluée à partir d’un voisinage autour du pixel. Malheureusement, ce voisinage
est défini à partir de l’image bruitée. Par conséquent, la mesure de similarité aura tendance
à rechercher des pixels dans l’image qui possèdent des voisinages qui sont bruités de la
même manière que le patch d’intérêt. Ce phénomène reste peu visible pour des écarts types
σn faibles, mais se traduit par l’apparition d’un bruit résiduel haute fréquence pour des
valeurs de σn élevées. Ce problème est particulièrement visible en Figure 5.7, où il entraine
l’apparition d’imprécisions et la modification des contours de l’image.
Ce problème est corrigé dans les NLB originaux en analysant l’information commune
à un groupe de patchs similaires. À la différence des NL-Means, le filtrage est effectué
collaborativement. Les caractéristiques principales communes à l’ensemble des patchs du
groupe sont donc extraites indépendamment du bruit puis utilisées pour filtrer le patch.
Les NLB permettent donc de mieux préserver les détails principaux contenus dans l’image
sans introduire de bruit haute fréquence.
Notre CovTree-NLB permet d’obtenir des résultats légèrement supérieurs aux NLB originaux.
Nous pouvons expliquer cette différence par l’utilisation du critère de voisinage
local compressé. Il permet de former des groupes de patchs similaires moins dépendants
du bruit. De plus, dans la formulation originale des NLB, la moyenne et la covariance sont
estimées avec un poids constant à partir d’une combinaison des k plus proches voisins.
Dans notre cas, la combinaison est pondérée en utilisant un noyau gaussien qui limite
l’influence des patchs parasites.
En effectuant une comparaison plus détaillée, nous pouvons remarquer que les NLB originaux
ont tendance à créer des zones régulières. Ce problème est dû à l’utilisation du
critère homogénéité qui a tendance à uniformiser l’ensemble des valeurs du patch. Comme
notre CovTree-NLB n’utilise pas le critère d’homogénéité, le patch est remplacé dans notre
cas par la moyenne estimée durant la phase de requête de notre CovTree. Comme nous
l’avons vu précédemment, la moyenne estimée par notre structure permet de bien préserver
les caractéristiques principales. Elle remplace donc les zones régulières qui provoquent
un phénomène de quantification par des variations lisses entre les différentes zones.
Pour conclure, les deux implémentations des NLB produisent des résultats globalement
équivalents. Ce constat nous permet donc d’affirmer que notre CovTree est correctement
défini pour estimer la moyenne et la covariance d’un ensemble d’échantillons pour diffé-
rentes requêtes qui peuvent être utilisées dans des approches telles que les NLB.
5.2 Restauration par dictionnaires
Une propriété intéressante de notre CovTree est qu’il peut être utilisé pour apprendre les
variations à différentes échelles de grandes bases d’échantillons en utilisant une quantité de
mémoire limitée. Nous proposons d’exploiter ce caractère compressif afin de résoudre deux
applications : le débruitage par dictionnaire et la reconstruction d’images échantillonnées
aléatoirement.5.2. RESTAURATION PAR DICTIONNAIRES 89
Figure 5.8: Échantillons de la base de données de façades parisiennes comprenant plus
de 120 images (soit plus de 108 patchs).
5.2.1 Principe général
Avec la démocratisation des capteurs numériques et la facilité d’accès aux réseaux de communication,
il est devenu facile aujourd’hui de récupérer et/ou partager de l’information.
Malgré la multiplication de ces données, il existe encore peu de moyens réussissant à exploiter
cette grande quantité d’informations et d’en extraire des caractéristiques utiles.
Pourtant, l’utilisation d’une telle connaissance pourrait être particulièrement utile dans
des domaines tels que la restauration.
Durant ces dernières années, les méthodes de restauration des images ont proposé des approches
de plus en plus performantes pour réussir à récupérer l’information contenue dans
des images corrompues. Néanmoins, les performances de ces méthodes resteront toujours
limitées du fait que les données sont trop détériorées ou trop rares pour être récupérées.
L’utilisation d’une analyse de l’information commune à de grands ensembles d’images
pourrait donc permettre de résoudre ce problème tout en améliorant la qualité de la restauration.
Cette idée est confirmée dans [LN11] où l’utilisation de grandes bases d’images est proposée
comme un moyen d’apprendre l’a priori sous-jacent aux patchs d’images naturelles. Ce
genre d’approche (appelée shotgun NLM [LCBM12]) a été utilisé pour estimer les limites
fondamentales des méthodes de débruitage non locales. Néanmoins, aucune proposition n’a
été faite afin de rendre ce genre de méthodes calculables dans le cas d’applications réelles.
Une idée similaire a ensuite été proposée par [ZW11]. Elle définit un apprentissage sur une
large base de données par l’intermédiaire d’une approche similaire à celle des PLE [YSM12].
Malheureusement, une telle approche nécessite plusieurs jours pour apprendre l’a priori
sous-jacent.
Nous proposons donc d’utiliser notre CovTree généralisé afin d’apprendre l’a priori sousjacent
aux patchs des images naturelles rapidement et en utilisant une quantité de mémoire
limitée. Une fois encore, cet avantage est possible, car la quantité de mémoire utilisée par90
notre structure de données dépend uniquement de la précision de l’information que l’on
souhaite apprendre et non du nombre d’échantillons à apprendre.
Dans toute cette section, nous considérons un ensemble de 108 patchs non bruités de
dimension 7×7 extraits d’une base de plus de 120 images de façades parisiennes. Ces patchs
seront utilisés lors de l’étape d’Apprentissage de sorte à pouvoir définir une approximation
de l’a priori sous-jacent de l’ensemble des patchs appartenant aux images naturelles. Nous
présentons en Figure 5.8 un sous-ensemble d’images appartenant à cette base de données.
En terme de performance, un tel apprentissage nécessite environ 5 heures de calcul sur un
PC possédant un processeur 2.4 GHz Intel Xeon et utilise 8GB de RAM pour retenir l’ensemble
de la structure de données. En comparaison, ce temps de calcul est bien plus rapide
que les temps de calcul reportés dans [LN11, ZW11] alors que la quantité d’échantillons
apprise par notre structure est largement supérieure.
5.2.2 Débruitage d’images
Principe
Les démarches par NLB restaurent l’image en utilisant uniquement un ensemble de patchs
bruités. Par conséquent, la gaussienne anisotrope utilisée pour modéliser l’a priori sousjacent
représente les variations des patchs bruités. Les NLB résolvent ce problème en
débruitant la matrice de covariance d’un facteur σd et en itérant deux fois leurs différentes
étapes. Néanmoins, l’estimation de la gaussienne reste limitée.
Dans cette section nous proposons de définir une approche similaire à [LCBM12]. Nous
définissons un algorithme de débruitage, le Shotgun NLB, qui utilise un a priori appris
sur une grande base de données à partir notre CovTree. Cette idée a deux principaux
avantages : nous pouvons augmenter le nombre de patchs appris (par rapport aux NLB
classiques) et les données utilisées ne sont pas dégradées par du bruit, permettant ainsi
d’augmenter la précision de la gaussienne anisotropique estimée.
En pratique, nous construisons notre arbre en considérant un critère de voisinage global
(sans coordonnées pixeliques) afin de définir les cellules dans le domaine spatial S. Ensuite,
nous apprenons le modèle gaussien de chaque cellule à partir de l’ensemble des patchs non
bruités provenant de la base de données. Finalement, la matrice de covariance Σq et le
vecteur moyen µq
sont estimés à partir d’un patch bruité q avec un rayon σq proche de
l’écart type du bruit du patch. Contrairement aux NLB classiques, les gaussiens anisotropes
N (µq
, Σq) estimées par la structure sont non bruitées. Par conséquent, nous appliquons
directement l’Équation 5.3 sans avoir besoin de débruiter la matrice de covariance.
Résultats
En Figure 5.9, nous présentons une comparaison d’images filtrées par les NLB originaux, les
CovTree-NLB et notre Shotgun NLB. Les résultats sont obtenus à partir d’images corrompues
par un bruit gaussien additif d’écart type 0.08. Dans cette partie, les CovTree-NLB
sont calculés à partir du critère de voisinage local compressé aux 6 principales dimen-5.2. RESTAURATION PAR DICTIONNAIRES 91
Bruit écart type 0.08 NLB Original (147+2-D) NLB CovTree (147+2-D) Shotgun NLB (147-D)
PSNR 22.4 dB PSNR 30.2 dB PSNR 30.0 dB PSNR 31.1 dB
Figure 5.9: Comparaison des images débruitées obtenues pour différentes versions des
NLB : le NLB original, notre CovTree NLB et notre Shotgun NLB. La deuxième ligne
présente des agrandissements des résultats obtenus sur la première ligne.
sions sans utiliser de critère d’homogénéité. Notre Shotgun-NLB est évalué avec une seule
itération.
Pour mieux illustrer nos propos, nous allons baser nos explications sur les agrandissements
proposés en Figure 5.9 représentant un mur de briques. Ce cas de restauration est particulièrement
difficile, car les détails fins et le bruit de l’image sont confondus. La gaussienne
anisotrope résultante de ce groupe de patchs sera donc principalement composée du bruit
du groupe. En effet, la distance utilisée pour former les groupes de patch aura tendance à
rassembler les patchs par rapport à la similarité de leur bruit respectif plutôt que de l’information
réelle qu’ils contiennent. Les groupes ainsi formés contiendront donc un grand
nombre de patchs parasites qui perturberont l’extraction des caractéristiques communes.
La légère perte de performance de notre CovTree-NLB par rapport aux NLB originaux
est due à ce problème. Les NLB originaux utilisent le critère d’homogénéité pour éviter
d’exacerber les structures de bruits locales. Il permet d’harmoniser l’ensemble des valeurs
quand il est difficile de faire la distinction entre l’information contenue dans le groupe et
le bruit.
Le Shotgun-NLB est particulièrement efficace pour résoudre ce genre de cas. En effet, il
permet d’estimer, en toutes circonstances, des gaussiennes anisotropes représentatives des
variations des patchs non bruités. Pour ce faire, il utilise l’information commune de la base
de patchs non bruités pour définir un a priori qui approche celui des patchs des images
naturelles. Cet a priori peut donc contenir une information sur les caractéristiques fines des
patchs qui se retrouvaient précédemment confondues dans le bruit de l’image. Le ShotgunNLB
permet de restaurer des détails fins de l’image que les filtres classiques ne sont pas
capables de retrouver. De plus amples expérimentations restent néanmoins nécessaires92
pour déterminer si la restauration obtenue est proche de la limite fondamentale présentée
par [LN11].
5.2.3 Reconstruction d’image échantillonnée aléatoirement
Principe
Dans cette section, nous proposons de reconstruire une image à partir d’un sous-ensemble
aléatoire de ces pixels. Comme le proposent entre autres les PLE [YSM12], nous proposons
d’utiliser l’a priori sous-jacent aux patchs des images naturelles qui a été appris par l’intermédiaire
de notre CovTree sur une large base de données pour compléter l’information
manquante.
Considérons un patch q˜ échantillonné aléatoirement à partir d’un patch original q par
un opérateur q˜ = Sq. Ici, l’opérateur S dépend de la position spatiale de q. De manière
équivalente aux filtres NLB, nous allons considérer ici que les patchs de l’image peuvent être
modélisés localement par une gaussienne anisotrope dont la moyenne µq
et la covariance
Σq ont été estimées à partir d’un dictionnaire local. Par conséquent, nous pouvons définir
le patch reconstruit qˆ comme une MAP bayésienne :
qˆ = (ΣqS
HS +
σ
2
2
Id)
−1
(ΣqS
Hq˜ +
σ
2
2
µq
) (5.9)
Dans la minimisation précédente, la gaussienne anisotrope N (µq
, Σq) est estimée autour
du patch complet original q. Ce patch étant bien évidemment inconnu, nous utilisons une
approche itérative basée sur trois étapes pour approcher cette gaussienne :
1. Estimation : le patch qˆt−1 reconstruit à l’itération précédente t − 1 est utilisé en
requête de notre CovTree afin de définir une approximation de l’a priori statistique
local autour de q représentée par une gaussienne anisotrope N (µqˆt−1
, Σqˆt−1
).
2. Reconstruction : le patch qˆt est reconstruit à l’itération t à partir d’une MAP
bayésienne et de la gaussienne anisotrope N (µqˆt−1
, Σqˆt−1
) par :
qˆt = (Σqˆt−1S
HS +
σ
2
2
Id)
−1
(Σqˆt−1S
Hq˜ +
σ
2
2
µqˆt−1
) (5.10)
3. Agrégation : tout comme pour les NLB, un pixel de l’image appartient à plusieurs
patchs de l’image. Par conséquent, le patch qˆt et l’image sont estimés à l’itération t
par une moyenne des valeurs des pixels reconstruits.
En pratique, nous initialisons la reconstruction à partir d’une estimation initiale qˆ0 du
patch complet effectué en utilisant une interpolation cubique basée sur une triangulation
de Delaunay des pixels connus. De plus, pour obtenir une meilleure reconstruction de
l’image, lors de l’étape d’Estimation nous utilisons des échelles de filtrage σqˆ,t = α
tσqˆ,0 de
plus en plus fines à partir d’une échelle grossière σqˆ,0 et d’un facteur d’échelle α ∈ [0, 1].
Résultats
Nous présentons en Figure 5.9 la restauration obtenue à partir d’une image où seulement
20% des pixels échantillonnés aléatoirement ont été conservés. Notre approche est initia-5.2. RESTAURATION PAR DICTIONNAIRES 93
Original 20% pixels originaux Reconstruction cubique Notre reconstruction
PSNR 24.9 dB PSNR 27.2 dB
Figure 5.10: Résultat de la reconstruction d’une image dont 20% des pixels échantillonnés
aléatoirement ont été retenus. Notre approche est initialisée à partir d’une reconstruction
cubique définie sur la triangulation de Delaunay des pixels connus.
lisée par une première interpolation cubique définie sur la triangulation de Delaunay des
pixels connus pour des valeurs α = 0.8 et σqˆ,0 = 0.65.
Comme nous l’avons expliqué précédemment, nous avons théoriquement besoin de
connaître le patch restauré pour pouvoir définir un modèle local des patchs. Pour ré-
soudre ce problème, nous avons introduit une approche itérative qui évalue à chaque étape
une reconstruction de plus en plus fine. Ce schéma itératif est initialisé à partir d’une
restauration grossière de l’image. Il est important de comprendre que tout le cœur de
notre problème de restauration réside dans l’estimation d’une gaussienne anisotrope correcte.
C’est grâce à elle que l’information manquante est comblée. Par conséquent, plus la
requête sera proche du patch original meilleure sera la restauration.
Pour éviter de bloquer les itérations dans des minimums locaux, nous utilisons des échelles
de requêtes σqˆ,t décroissantes. Cette idée nous permet de récupérer des détails de l’image
qui n’était pas nécessairement présents dans l’approximation originale. Ce phénomène est
parfaitement illustré en Figure 5.10 par la restauration des briques ou des carreaux de la
porte de la maison. Malheureusement, une telle solution ne permet pas de résoudre toutes
les ambiguïtés. Les patchs restaurés peuvent parfois être assez éloignés de leur version
originale. Néanmoins, ce problème n’est pas forcément choquant visuellement.
5.2.4 Limitations et possibles améliorations
Dans cette section, nous avons utilisé notre CovTree pour apprendre rapidement la distribution
d’une grande base de données de patchs issues d’images naturelles et avec une94
quantité de mémoire limitée. Nous avons démontré que ce modèle peut être utilisé effi-
cacement pour résoudre des problèmes de restauration par MAP bayésienne tels que le
débruitage ou la reconstruction d’images.
Nous avons fait la supposition que l’a priori sous-jacent est appris sur une base de patchs
non bruités représentatifs des patchs à restaurer. Cette hypothèse n’est pas toujours vérifiée
en pratique. En effet, l’apprentissage est effectué ici sur un ensemble de patchs extraits
d’images différentes. Ces images ne sont pas nécessairement acquises avec des appareils
ou dans des conditions équivalentes. Par conséquent, des changements de teintes ou de
contraste peuvent limiter la qualité de l’apprentissage.
Ce problème peut bien évidemment être résolu en augmentant la quantité d’images apprises.
Mis à part l’augmentation de la quantité de temps nécessaire à l’apprentissage, les
statistiques apprises pourraient être corrompues par l’introduction de patchs aberrants.
Pour résoudre ce problème, une première solution consisterait à apprendre les statistiques
indépendamment des changements de contraste et/ou de teintes. Cette solution reviendrait
en quelque sorte à normaliser les patchs avant de les apprendre. Notre CovTree devrait
donc être modifié pour gérer indépendamment la moyenne et les covariances. Plus simplement,
nous pourrions utiliser l’information contenue dans les patchs corrompus quand
celles de l’a priori ne sont pas suffisante. Cette idée est équivalente à celle de la dégéné-
rescence du noyau non local introduit en Section 3.2.4 pour les NLPSS.
5.3 Restauration de surface 3D
Notre CovTree peut être utilisé pour résoudre des problèmes de restauration d’images tels
que le débruitage ou la reconstruction. Nous proposons d’étendre ces différentes applications
au cas des nuages de points 3D. Pour cela, nous utilisons les principes et outils
introduits pour les NLPSS ainsi que le CovTree dans sa version étendue. Nous présentons
uniquement les idées et les problèmes sous-jacents à la mise en œuvre de ces applications.
5.3.1 Positionnement du problème
Nous rappelons ici les notations introduites au Chapitre 3. Soit X = (xi
, ni) un nuage
de point 3D extrait à partir d’une surface S inconnue, où xi ∈ R
3
est la position d’un
point et ni ∈ R
3
est la normale qui lui est associée. Pour tout point x ∈ R
3
, l’opérateur
PSS Πt projette x sur la surface S
t définie à l’échelle t. Nous appelons respectivement
Πt
(x), f(x) et n(x), la projection de x sur S
t
, la distance implicite et la normale associée.
En appliquant Πt0 à une échelle t0 large, nous obtenons une surface grossière S
t0 et un
champ scalaire résiduel bruité m(xi) défini uniquement pour les points du nuage xi ∈ X
(Section 3.2.2).
De manière générale, adapter les méthodes restaurations MAP non locales pose principalement
deux contraintes :
1. Tout d’abord, elles nécessitent la définition d’un signal corrompu et d’un descripteur
pour définir la mesure de similarité entre deux échantillons. En traitement
des images (et en particulier dans le cas des filtres collaboratifs), c’est le patch qui5.3. RESTAURATION DE SURFACE 3D 95
Figure 5.11: Reconstruction de surface obtenue à partir de notre opérateur NLB-PSS.
possède le double rôle de descripteur et de signal à débruiter. Dans le cas des NLPSS,
le signal est défini par le champ scalaire résiduel bruité m(xi) (uniquement pour tout
xi ∈ X ) et le descripteur par un patch de surface 3D (Section 3.2.3). 1
2. Ensuite, les formulations MAP (par ex. l’Équation 5.1) nécessitent de connaître
le signal corrompu en tout point du domaine. En effet, elles peuvent être
vues généralement comme une projection d’un échantillon corrompu sur une variété
locale (Section 5.1.1). Leur formulation fait donc explicitement intervenir le signal
corrompu. Un tel problème ne se pose pas nécessairement dans le cas de formulations
EAP (par ex. l’Équation des NLPSS).
En conclusion, tout l’enjeu de l’adaptation des restaurations MAP au cas de surface 3D
sera dans la définition d’une valeur du signal corrompue pour tout point de l’espace x ∈ R
3
.
5.3.2 Surface de points par NLB
Nous proposons maintenant de définir un opérateur NLB-PSS qui étend les NLPSS au cas
des NLB. Dans le cas des nuages de points 3D, il est difficile de définir un signal bruité
pour tout x ∈ R
3
. Dans les NLPSS, ce problème a été résolu en utilisant le champ scalaire
résiduel bruité m(pi) qui est uniquement défini pour les points du nuage xi ∈ X . Pour
pouvoir définir un patch de surface 3D, ce signal a été approché par un opérateur PSS
Πt1 à une échelle t1. Πt1 permet de définir une surface S
t1 qui approxime finement X . Le
patch de surface 3D peut donc être considéré comme une approximation peu filtrée du
signal bruité. Il peut donc être débruité par l’Équation 5.1.
Nous définissons l’opérateur NLB-PSS ΠNLB pour tout x ∈ R
3 par :
ΠNLB(x) = x − fNLB(x)n
t0
(x) (5.11)
1. Ces deux notions sont intimement liées aux deux domaines des attributs R et spatial S introduit
dans la version généralisée de notre CovTree. R correspond au signal à débruiter et S aux descripteurs.96
où fNLB(x) correspond à la valeur centrale du patch de surface débruitée définie à partir du
patch de surface bruité Px par l’Équation 5.3. Pour les NLB-PSS, nous n’effectuons aucune
étape d’agrégation En effet, contrairement aux patchs définis en traitement des images, les
patchs de surface ne possèdent aucunes valeurs en commun. En pratique, le NLB-PSS est
accéléré par notre CovTree. Nous le construisons et l’apprenons en considérant l’ensemble
des patchs 2 Pxi
associé à chaque point xi ∈ X . Une requête de notre arbre est donc définie
par un patch de surface Px et un rayon de requête σx ∈ R. Nous présentons en Figure 5.11
les premiers résultats des NLB-PSS.
5.3.3 Restauration de surface par dictionnaire
Comme nous l’avons proposé dans le cas des images, nous pouvons apprendre les variations
d’un ensemble de patchs de surface non bruités afin de définir un a priori des surfaces 3D.
Il peut être utilisé pour des applications telles que le débruitage et la reconstruction de
surface.
Problèmes
Dans les NLPSS, les patchs de surface (Section 3.2.3) sont définis par rapport à une
surface grossière S
t0 (utilisée pour définir les valeurs du patch) et à une largeur de patchs
(employée pour estimer l’orientation du patch). Malheureusement ces deux paramètres
sont dépendants de la résolution du nuage de points considérée. Par conséquent, un nuage
acquis à différentes résolutions ne produira pas des ensembles de patchs qui contiennent
des informations équivalentes.
Dans le cas de grands ensembles de nuages de points, ce problème est d’autant plus présent
que les nuages ne sont pas acquis par le même capteur. Pour résoudre ce problème, nous
proposons d’extraire les patchs du nuage à différentes échelles. La base de données ainsi
constituée sera donc moins dépendante des problèmes d’acquisition. Plus d’expérimentations
sont néanmoins nécessaires pour valider cette hypothèse.
Densification de nuages de points 3D
L’apprentissage de grand ensemble de patchs est particulièrement utile pour augmenter
la résolution d’un nuage de points. Pour pouvoir être défini de manière équivalente aux
problèmes de reconstruction d’image échantillonnée aléatoirement, nous proposons d’introduire
un patch de surface incomplet P˜
x, pour tout x ∈ R
3
, en projetant les points
xj ∈ N(x) ⊂ X sur le plan du patch (Figure 5.12). Une discrétisation du plan permet
de définir les valeurs du patch ainsi qu’un opérateur d’échantillonnage S. Les valeurs sont
obtenues par une combinaison pondérée des m(xj ) et l’opérateur d’échantillonnage comme
la somme des poids reçus dans les cases correspondantes.
2. Pour tout point xi ∈ X , la valeur centrale du patch correspond à la valeur du signal bruité m(xi).
Par conséquent, chaque xi ∈ X est associé à un patch amélioré P
′
xi
. En pratique, notre arbre est donc
construit par rapport à l’ensemble des patchs approchés {Pxi } et appris sur l’ensemble des patchs améliorés
{P
′
xi
}.5.3. RESTAURATION DE SURFACE 3D 97
0.8 0.6 0.8
0.2 0.7 0.2
0.8 0.4 0.8
S =
xj
Figure 5.12: Définition d’un patch de surface incomplet. Les points xj sont projetés sur
le plan du patch. À partir d’une discrétisation du plan, nous obtenons les valeurs du patch
et l’opérateur d’échantillonnage S.
Par conséquent, les patchs incomplets peuvent être reconstruits en considérant une approche
similaire à celle proposée en Section 5.2.3. Une fois l’ensemble des {P˜
xi
} reconstruits
par l’Équation 5.10 un nuage est densifié en ajoutant des points en fonction des
valeurs du patch reconstruit (Figure 5.12).C h a p i t r e 6
Conclusion
À partir du débruitage non local de nuages de points, nous avons mis en évidence le
besoin de structures dédiées aux traitements non-locaux des données de dimension deux et
supérieure, ainsi que la possibilité de généraliser les méthodes existantes de restauration
non-locale 2D et 3D. Pour pouvoir y répondre nous avons introduit les contributions
suivantes :
Surface de point non locale Les opérateurs de surface de points (PSS) conventionnels
permettent de définir une surface à partir d’un voisinage local. Malheureusement face
aux conditions réelles de capture, ce point de vue devient rapidement insuffisant pour
définir une surface correcte. Pour résoudre ce problème, nous avons proposé une nouvelle
définition qui étend toutes les définitions PSS locales précédentes en exploitant le
caractère autosimilaire du nuage de points. Pour ce faire, nous utilisons un opérateur PSS
défini à une échelle grossière pour définir une surface grossière (servant de support à notre
méthode) et un champ scalaire résiduel contenant les caractéristiques bruitées de la surface.
Notre surface non locale est définie en ajoutant à cette surface grossière le champ
scalaire de déplacement résiduel débruité par la méthode des moyennes non locales. La
mesure de similarité entre deux parties du nuage de points est définie par l’intermédiaire
de patchs de surfaces dont les valeurs représentent les variations entre la surface grossière
et une surface calculée par un PSS à échelle fine. Nous avons démontré que notre définition
est capable d’améliorer la qualité des surfaces PSS locales en augmentant le rapport
signal/bruit. Néanmoins ces résultats sont très dépendants du caractère autosimilaire du
nuage à traiter. Dans le cas peu probable, d’absence d’autosimilarité, notre opérateur non
local obtiendra des résultats identiques à ceux de l’opérateur PSS sous-jacent. En pratique,
l’estimation de notre opérateur non local est accélérée par GPU permettant une utilisation
plus interactive.
Arbre de covariances Avec l’augmentation de la quantité d’information, peu de mé-
thodes à l’heure actuelle exploitent réellement l’information contenue dans les grandes
bases de données ou au prix d’une quantité de mémoire et de calculs beaucoup trop
importante. Comme solution, nous introduisons le CovTree, une nouvelle structure de
données capable d’apprendre les distributions locales d’un grand ensemble d’échantillons
en les représentant par des gaussiennes anisotropes. Cette structure est définie par l’in-
99100
termédiaire de trois principales étapes. Tout d’abord, nous construisons un arbre binaire
à partir d’un ensemble d’échantillons qui partitionne l’espace en fonction de la position
des différents échantillons. Ensuite, nous apprenons les distributions statistiques locales
de chaque nœud en propageant l’ensemble des échantillons à travers l’arbre en fonction de
leur position et ajoutant une contribution pondérée des points au noyau de chaque nœud
de l’arbre traversé. Finalement, pour toute requête, notre arbre modélise la distribution
locales des données apprises. Pour permettre une utilisation générique, nous définissons
une version généralisée de notre structure par l’intermédiaire de deux domaines : spatial
correspondant au descripteur du point et des attributs correspondant à signal associé.
Par l’intermédiaire d’un schéma de requête adaptatif, il devient possible d’interroger à
n’importe quelle échelle pour des temps sensiblement équivalents.
Restauration collaboratives Les filtres collaboratifs utilisent l’information commune
à des ensembles de patchs similaires afin d’améliorer la qualité de la restauration. Malheureusement,
il est coûteux et difficile d’analyser l’information contenue dans une grande base
de données. Ces approches sont donc généralement simplifiées et limitées à un ensemble de
points réduit. Pour résoudre ce problème, différents ensemble de données sont appris par
l’intermédiaire du CovTree. Nous introduisons différentes applications de débruitages et
de reconstructions de données 2D et 3D. Par rapport aux approches précédentes, il devient
possible d’apprendre un a priori à partir d’une grande base d’échantillons de données non
détériorées. Nous utilisons cet a priori pour améliorer les performances des méthodes de
restauration. Dans cette partie, nous effectuons une analyse qualitative des performances
de notre CovTree qui permet de valider son utilisation.
En conclusion, nos différentes contributions permettent de s’attaquer aux problématiques
soulevées par les évolutions récentes des méthodes de restaurations non locales et de l’augmentation
de la quantité de données. Cette thèse s’inscrit donc au cœur de cette évolution
en proposant quelques éléments de réponse à l’un des enjeux technologiques des années
2010, à savoir : la capture, transmission et traitements de masses de séquences temporelles
de données 2D et 3D.C h a p i t r e 7
Perspectives
Dans cette thèse, nous avons travaillé sur différents thèmes découlant de la restauration
par méthodes non locales d’un ensemble de données 2D et 3D. Au-delà des contributions
techniques proposées, un certain nombre de nouvelles pistes plus générales que celle abordées
en Section 3.4 et 4.5 peut découler de ce travail de recherche.
La définition des NLPSS suppose que le nuage de points 3D est corrompu par un bruit
additif gaussien 3D. Cette supposition est indispensable pour pouvoir utiliser les moyennes
non locales. Néanmoins, à l’heure actuelle, il n’existe (à notre connaissance) aucune analyse
du modèle statistique du bruit introduit par les scanners 3D car il est trop dépendant du
type de capteurs utilisé. Il serait donc intéressant de définir les NLPSS pour des bruits
différents comme c’est proposé en traitement des images dans [DDT09]. Une telle idée
nécessiterait de définir des mesures de similarité spécifiques. Les travaux de Deledalle et
coll. [DDT12] et Desolneux et coll. [DD13] donnent quelques pistes le deuxième étant
particulièrement pertinent car il pourrait permettre de rendre le NLPSS plus robuste aux
points aberrants. Néanmoins, le changement du type de bruit entrainerait nécessairement
un problème dans l’estimation du repère de normalisation des patchs.
L’amélioration des systèmes de captures par agrégation des données 3D du type Kinect
Fusion [IKH+11] pourrait être une autre piste de recherche intéressante. Une telle application
nécessiterait de coupler notre CovTree afin de cumuler les données dans le temps,
avec un système d’acquisition de données 3D en temps réel (tels que Microsoft Kinect par
exemple). Une telle idée nécessite néanmoins de faire évoluer notre CovTree temporellement
(Section 4.5).
101Bibliographie
[AA04a] A. Adamson and M. Alexa. Approximating bounded, nonorientable surfaces
from points. In Proceedings of Shape Modeling Applications, pages 243–252.
IEEE, 2004.
[AA04b] M. Alexa and A. Adamson. On normals and projection operators for surfaces
defined by point sets. In Symposium on Point-Based Graphics, pages 149–
155. Citeseer, 2004.
[AA09] M. Alexa and A. Adamson. Interpolatory point set surfaces - convexity and
hermite data. ACM Transactions on Graphics (TOG), 28(2) :20, 2009.
[ABCO+01] M. Alexa, J. Behr, D. Cohen-Or, S. Fleishman, D. Levin, and C. T. Silva.
Point set surfaces. In Proceedings of the Conference on Visualization, pages
21–28. IEEE, October 2001.
[ABD10] A. Adams, J. Baek, and M. A. Davis. Fast high-dimensional filtering using
the permutohedral lattice. Computer Graphics Forum (CGF), 29(2) :753–
762, 2010.
[AGDL09] A. Adams, N. Gelfand, J. Dolson, and M. Levoy. Gaussian kd-trees for fast
high-dimensional filtering. ACM Transactions on Graphics (TOG), 28(3) :21,
July 2009.
[AK04] N. Amenta and Y. J. Kil. Defining point-set surfaces. ACM Transactions on
Graphics (TOG), 23(3) :264–270, August 2004.
[Ale05] S. K. Alexander. Multiscale methods in image modelling and image processing.
Ph.d. thesis, University of Waterloo, Ontario, Canada, 2005.
[AMN+98] S. Arya, D. M. Mount, N. S. Netanyahu, R. Silverman, and A. Y. Wu. An optimal
algorithm for approximate nearest neighbor searching fixed dimensions.
Journal of the ACM (JACM),, 45(6) :891–923, 1998.
[APG07] N. Azzabou, N. Paragios, and F. Guichard. Image denoising based on adapted
dictionary computation. In International Conference on Image Processing
(ICIP), volume 3, pages 109–112. IEEE, 2007.
[AW05] S. P. Awate and R. T. Whitaker. Higher-order image statistics for unsupervised,
information-theoretic, adaptive, image filtering. In Computer Vision
and Pattern Recognition (CVPR), volume 2, pages 44–51. IEEE, 2005.
[AW06] S. P. Awate and R. T. Whitaker. Unsupervised, information-theoretic, adaptive
image filtering for image restoration. IEEE Trans. Pattern Analysis and
Machine Intelligence (PAMI), 28(3) :364–376, 2006.
[Bar02] D. Barash. Fundamental relationship between bilateral filtering, adaptive
smoothing, and the nonlinear diffusion equation. IEEE Trans. Pattern Analysis
and Machine Intelligence (PAMI), 24(6) :844–847, 2002.
103104
[BBB+10] T. Beeler, B. Bickel, P. Beardsley, B. Sumner, and M. Gross. High-quality
single-shot capture of facial geometry. ACM Transactions on Graphics
(TOG), 29(3) :40, 2010.
[BBH08] D. Bradley, T. Boubekeur, and W. Heidrich. Accurate multi-view reconstruction
using robust binocular stereo and surface meshing. In Computer Vision
and Pattern Recognition (CVPR), pages 1–8. IEEE, 2008.
[BC07] T. Brox and D. Cremers. Iterated nonlocal means for texture restoration.
In Scale Space and Variational Methods in Computer Vision, pages 13–24.
Springer, 2007.
[BCM05] A. Buades, B. Coll, and J.-M. Morel. A non-local algorithm for image denoising.
In Computer Vision and Pattern Recognition (CVPR), volume 2, pages
60–65. IEEE, 2005.
[BCM08] A. Buades, B. Coll, and J.-M. Morel. Nonlocal image and movie denoising.
Springer International Journal of Computer Vision (IJCV), 76(2) :123–139,
2008.
[Ben75] J. L. Bentley. Multidimensional binary search trees used for associative searching.
Communications of the ACM, 18(9) :509–517, 1975.
[BHB+11] T. Beeler, F. Hahn, D. Bradley, B. Bickel, P. Beardsley, C. Gotsman, R. W.
Sumner, and M. Gross. High-quality passive facial performance capture using
anchor frames. ACM Transactions on Graphics (TOG), 30 :75, August 2011.
[BKC08] T. Brox, O. Kleinschmidt, and D. Cremers. Efficient nonlocal means for
denoising of textural patterns. IEEE Transactions on Image Processing,
17(7) :1083–1092, 2008.
[BM05] E. P. Bennett and L. McMillan. Video enhancement using per-pixel virtual
exposures. ACM Transactions on Graphics (TOG), 24(3) :845–852, 2005.
[BO05] J.-D. Boissonnat and S. Oudot. Provably good sampling and meshing of
surfaces. Graphical Models, 67(5) :405–451, 2005.
[Bov05] A. C. Bovik. Handbook of image and video processing. Academic Press, 2005.
[BPD06] S. Bae, S. Paris, and F. Durand. Two-scale tone management for photographic
look. ACM Transactions on Graphics (TOG), 25(3) :637–645, 2006.
[BRR11] M. Bleyer, C. Rhemann, and C. Rother. Patchmatch stereo - stereo matching
with slanted support windows. In British Machine Vision Conference
(BMVC), volume 11, pages 1–11, 2011.
[BSFG09] C. Barnes, E. Shechtman, A. Finkelstein, and D. Goldman. Patchmatch :
a randomized correspondence algorithm for structural image editing. ACM
Transactions on Graphics (TOG), 28(3) :24, 2009.
[CFGS12] X. Chen, T. Funkhouser, D. B. Goldman, and E. Shechtman. Non-parametric
texture transfer using meshmatch. Adobe Technical Report, November 2012.
[CM02] D. Comaniciu and P. Meer. Mean shift : A robust approach toward feature
space analysis. IEEE Trans. Pattern Analysis and Machine Intelligence
(PAMI), 24(5) :603–619, 2002.BIBLIOGRAPHIE 105
[CPD07] J. Chen, S. Paris, and F. Durand. Real-time edge-aware image processing
with the bilateral grid. ACM Transactions on Graphics (TOG), 26(3) :103,
2007.
[CPT03] A. Criminisi, P. Pérez, and K. Toyama. Object removal by exemplar-based
inpainting. In Computer Vision and Pattern Recognition (CVPR), volume 2,
pages II–721. IEEE, 2003.
[CPT04] A. Criminisi, P. Pérez, and K. Toyama. Region filling and object removal by
exemplar-based image inpainting. IEEE Transactions on Image Processing,
13(9) :1200–1212, 2004.
[CWL+08] Z-Q. Cheng, Y-Z. Wang, B. Li, K. Xu, G. Dang, and S-Y. Jin. A survey of
methods for moving least squares surfaces. In Proceedings of conference on
Point-Based Graphics, pages 9–23. IEEE, 2008.
[DAG10] V. Duval, J.-F. Aujol, and Y. Gousseau. On the parameter choice for the
non-local means. Technical Report hal-00468856, 2010.
[DAL+11] J. Digne, N. Audfray, C. Lartigue, C. Mehdi-Souzani, and J-M. Morel. Farman
Institute 3D Point Sets - High Precision 3D Data Sets. Image Processing
On Line (IPOL), 2011.
[DD02] F. Durand and J. Dorsey. Fast bilateral filtering for the display of highdynamic-range
images. ACM Transactions on Graphics (TOG), 21(3) :257–
266, 2002.
[DD13] J. Delon and A. Desolneux. A patch-based approach for removing impulse
or mixed gaussian-impulse noise. Journal on Imaging Sciences (SIAM),
6(2) :1140–1174, 2013.
[DDS12] C.-A. Deledalle, V. Duval, and J. Salmon. Non-local methods with shapeadaptive
patches (NLM-SAP). Journal of Mathematical Imaging and Vision,
43(2) :103–120, 2012.
[DDT09] C.-A. Deledalle, L. Denis, and F. Tupin. Iterative weighted maximum likelihood
denoising with probabilistic patch-based weights. IEEE Transactions
on Image Processing, 18(12) :2661–2672, 2009.
[DDT12] C.-A. Deledalle, L. Denis, and F. Tupin. How to compare noisy patches ?
patch similarity beyond gaussian noise. Springer International Journal of
Computer Vision (IJCV), 99(1) :86–102, 2012.
[DFKE07] K. Dabov, A. Foi, V. Katkovnik, and K. Egiazarian. Image denoising by
sparse 3D transform-domain collaborative filtering. IEEE Transactions on
Image Processing, 16(8) :2080–2095, 2007.
[DFKE08] K. Dabov, A. Foi, V. Katkovnik, and K. Egiazarian. Image restoration by
sparse 3D transform-domain collaborative filtering. In Proceedings of Electronic
Imaging 2008, page 681207, 2008.
[DFKE09] K. Dabov, A. Foi, V. Katkovnik, and K. Egiazarian. BM3D Image Denoising
with Shape-Adaptive Principal Component Analysis. In Signal Processing
with Adaptive Sparse Structured Representations (SPARS), 2009.106
[DG10] J.-E. Deschaud and F. Goulette. Point cloud non local denoising using local
surface descriptor similarity. IAPRS, 2010.
[Dig12] J. Digne. Similarity based filtering of point clouds. Computer Vision and
Pattern Recognition (CVPR), 2012.
[DM11] J. Digne and J.-M. Morel. Numerical analysis of differential operators on raw
point clouds. Numerische Mathematik, pages 1–35, 2011.
[DMSL11] J. Digne, J.-M. Morel, C.-M. Souzani, and C. Lartigue. Scale space meshing
of raw data point sets. Computer Graphics Forum (CGF), 30(6) :1630–1642,
2011.
[Don95] D. L. Donoho. De-noising by soft-thresholding. IEEE Transactions on Information
Theory, 41(3) :613–627, 1995.
[EL99] A. A. Efros and T. K. Leung. Texture synthesis by non-parametric sampling.
In Proceedings of International Conference on Computer Vision (ICCV), volume
2, pages 1033–1038. IEEE, 1999.
[FAR07] R. Fattal, M. Agrawala, and S. Rusinkiewicz. Multiscale shape and detail
enhancement from multi-light image collections. ACM Transactions on Graphics
(TOG), 26(3) :51, 2007.
[FCOS05] S. Fleishman, D. Cohen-Or, and C. T. Silva. Robust moving least-squares fitting
with sharp features. ACM Transactions on Graphics (TOG), 24(3) :544–
552, 2005.
[FDCO03] S. Fleishman, I. Drori, and D. Cohen-Or. Bilateral mesh denoising. ACM
Transactions on Graphics (TOG), 22(3) :950–953, 2003.
[FKEA04] A. Foi, V. Katkovnik, K. Egiazarian, and J. Astola. A novel anisotropic
local polynomial estimator based on directional multiscale optimizations “.
In International conference of IMA, pages 79–82, 2004.
[FKN80] H. Fuchs, Z. M. Kedem, and B. F. Naylor. On visible surface generation by a
priori tree structures. ACM SIGGRAPH Computer Graphics, 14(3) :124–133,
1980.
[GG07] G. Guennebaud and M. H. Gross. Algebraic point set surfaces. ACM Transactions
on Graphics (TOG), 26(3) :23, 2007.
[GGG08] G. Guennebaud, Marcel Germann, and M. H. Gross. Dynamic sampling and
rendering of algebraic point set surfaces. Computer Graphics Forum (CGF),
27(2) :653–662, 2008.
[GLPP08] B. Goossens, Q. Luong, A. Pizurica, and W Philips. An improved nonlocal
denoising algorithm. In International workshop on Local and Non-Local
Approximation in Image Processing (LNLA), pages 143–156, 2008.
[GO11] E. S. L. Gastal and M. M. Oliveira. Domain transform for edge-aware image
and video processing. ACM Transactions on Graphics (TOG), 30(4) :69,
2011.BIBLIOGRAPHIE 107
[GO12] E. S. L. Gastal and M. M. Oliveira. Adaptive manifolds for real-time highdimensional
filtering. ACM Transactions on Graphics (TOG), 31(4) :33,
2012.
[HDD+94] H. Hoppe, T. DeRose, T. Duchamp, J. McDonald, and W. Stuetzle. Surface
reconstruction from unorganized points. PhD thesis, University of Washington,
1994.
[HS12] K. He and J. Sun. Computing nearest-neighbor fields via propagation-assisted
kd-trees. In Computer Vision and Pattern Recognition (CVPR), pages 111–
118. IEEE, 2012.
[HST10] K. He, J. Sun, and X. Tang. Guided image filtering. In European Conference
on Computer Vision (ECCV), pages 1–14. Springer, 2010.
[IKH+11] S. Izadi, D. Kim, O. Hilliges, D. Molyneaux, R. Newcombe, P. Kohli, J. Shotton,
S. Hodges, D. Freeman, and A. Davison. KinectFusion : real-time 3D reconstruction
and interaction using a moving depth camera. In Proceedings of
symposium on User interface software and technology, pages 559–568. ACM,
2011.
[JCSX09] Z. Ji, Q. Chen, Q.-S. Sun, and D.-S. Xia. A moment-based nonlocal-means
algorithm for image denoising. Information Processing Letters, 109(23) :1238–
1244, 2009.
[JDD03] T. R. Jones, F. Durand, and M. Desbrun. Non-iterative, feature-preserving
mesh smoothing. ACM Transactions on Graphics (TOG), 22 :943–949, July
2003.
[JDZ04] T. R. Jones, F. Durand, and M. Zwicker. Normal improvement for point
rendering. IEEE Computer Graphics and Applications, 24(4) :53–56, 2004.
[KA11] S. Korman and S. Avidan. Coherency sensitive hashing. In International
Conference on Computer Vision (ICCV), pages 1607–1614. IEEE, 2011.
[KB06] C. Kervrann and J. Boulanger. Optimal spatial adaptation for patch-based
image denoising. IEEE Transactions on Image Processing, 15(10) :2866–2878,
2006.
[KBH06] M. Kazhdan, M. Bolitho, and H. Hoppe. Poisson surface reconstruction. In
Proceedings of Symposium on Geometry processing (SGP), 2006.
[KCLU07] J. Kopf, M. F. Cohen, D. Lischinski, and M. Uyttendaele. Joint bilateral
upsampling. ACM Transactions on Graphics (TOG), 26(3) :96, 2007.
[KEA02] V. Katkovnik, K. Egiazarian, and J. Astola. Adaptive window size image
de-noising based on intersection of confidence intervals (ICI) rule. Journal of
Mathematical Imaging and Vision, 16(3) :223–235, 2002.
[KFEA04] V. Katkovnik, A. Foi, K. Egiazarian, and J. Astola. Directional varying scale
approximations for anisotropic signal processing. In Proceedings in European
Signal Processing Conference (EUSIPCO), pages 101–104. Citeseer, 2004.
[LBM13] M. Lebrun, A. Buades, and J-M. Morel. Implementation of the "Non-Local
Bayes" (NL-Bayes) Image Denoising Algorithm. Image Processing On Line
(IPOL), 2013 :1–42, 2013.108
[LC87] W. E. Lorensen and H. E. Cline. Marching cubes : A high resolution 3d
surface construction algorithm. In Proceedings of SIGGRAPH, pages 163–
169, 1987.
[LCBM12] M. Lebrun, M. Colom, A. Buades, and J-M. Morel. Secrets of image denoising
cuisine. Acta Numerica, 21(1) :475–576, 2012.
[Lee83] J.-S. Lee. Digital image smoothing and the sigma filter. Computer Vision,
Graphics, and Image Processing, 24(2) :255–269, 1983.
[Lev98] D. Levin. The approximation power of moving least-squares. Mathematics
of Computation, 67 :1517–1531, 1998.
[Lev03] D. Levin. Mesh-independent surface interpolation. Geometric Modeling for
Scientifc Visualization(2003), pages 1517–1523, 2003.
[LN11] A. Levin and B. Nadler. Natural image denoising : Optimality and inherent
bounds. In Computer Vision and Pattern Recognition (CVPR), pages 2833–
2840. IEEE, 2011.
[LPC+00] M. Levoy, K. Pulli, B. Curless, S. Rusinkiewicz, D. Koller, L. Pereira, M. Ginzton,
S. Anderson, J. Davis, and J. Ginsberg. The digital michelangelo project
: 3d scanning of large statues. In Proceedings of Computer Graphics and
Interactive Techniques, pages 131–144. ACM, 2000.
[MBP+09] J. Mairal, F. Bach, J. Ponce, G. Sapiro, and A. Zisserman. Non-local sparse
models for image restoration. In International Conference on Computer Vision,
pages 2272–2279. IEEE, 2009.
[MCCL+08] J. V. Manjón, J. Carbonell-Caballero, J. J. Lull, G. García-Martí, L. Martí-
Bonmatí, and M. Robles. MRI denoising using non-local means. Medical
image analysis, 12(4) :514–523, 2008.
[ML09] M. Muja and D. G. Lowe. Fast approximate nearest neighbors with automatic
algorithm configuration. In International Conference on Computer Vision
Theory and Application (VISSAPP), pages 331–340. INSTICC Press, 2009.
[ML12] M. Muja and D. G. Lowe. Fast matching of binary features. In Computer
and Robot Vision (CRV), pages 404–410. IEEE, 2012.
[MNB12] A. Maleki, M. Narayan, and R. G. Baraniuk. Anisotropic nonlocal means
denoising. Applied and Computational Harmonic Analysis, 2012.
[MRS12] S. Morigi, M. Rucci, and F. Sgallari. Nonlocal surface fairing. Scale Space
and Variational Methods in Computer Vision, pages 38–49, 2012.
[Nem00] A. Nemirovski. Topics in non-parametric. Ecole d’Ete de Probabilites de
Saint-Flour, 28 :85, 2000.
[NFP+13] A. Newson, M. Fradet, P. Pérez, A. Almansa, and Y. Gousseau. Towards
fast, generic video inpainting. HAL Technical Report 00838927, June 2013.
[OA12] I. Olonetsky and S. Avidan. Treecann-kd tree coherence approximate nearest
neighbor algorithm. In European Conference on Computer Vision (ECCV),
pages 602–615. Springer, 2012.BIBLIOGRAPHIE 109
[ÖGG09] A. C. Öztireli, G. Guennebaud, and M. H. Gross. Feature preserving point
set surfaces based on non-linear kernel regression. Computer Graphics Forum
(CGF), 28(2) :493–501, 2009.
[PD06] S. Paris and F. Durand. A fast approximation of the bilateral filter using
a signal processing approach. In European Conference on Computer Vision
(ECCV), pages 568–580. Springer, 2006.
[PD09] S. Paris and F. Durand. A fast approximation of the bilateral filter using a signal
processing approach. International Journal of Computer Vision (IJCV),
81(1) :24–52, 2009.
[PS00] J. Polzehl and V. G. Spokoiny. Adaptive weights smoothing with applications
to image restoration. Journal of the Royal Statistical Society (Statistical
Methodology), 62(2) :335–354, 2000.
[RDK13] G. Rosman, A. Dubrovina, and R. Kimmel. Patch-collaborative spectral
point-cloud denoising. In Computer Graphics Forum (CGF). Wiley Online
Library, 2013.
[ROF92] L. I. Rudin, S. Osher, and E. Fatemi. Nonlinear total variation based noise
removal algorithms. Physica D : Nonlinear Phenomena, 60(1) :259–268, 1992.
[Sal10a] J. Salmon. Agrégation d’estimateurs et méthodes à patch pour le débruitage
d’images numériques. PhD thesis, Université Paris-Diderot-Paris VII, 2010.
[Sal10b] J. Salmon. On two parameters for denoising with non-local means. IEEE
Signal Processing Letters, 17(3) :269–272, 2010.
[She68] D. Shepard. A two-dimensional interpolation function for irregularly-spaced
data. In Proceedings of the ACM national conference, pages 517–524. ACM,
1968.
[SS12] J. Salmon and Y. Strozecki. Patch reprojections for non-local methods. Signal
Processing, 92(2) :477–489, 2012.
[Tas08] T. Tasdizen. Principal components for non-local means image denoising.
In IEEE International Conference on Image Processing (ICIP), pages 1728–
1731, 2008.
[Tas09] T. Tasdizen. Principal neighborhood dictionaries for nonlocal means image
denoising. IEEE Transactions on Image Processing, 18(12) :2649–2660, 2009.
[TM98] C. Tomasi and R. Manduchi. Bilateral filtering for gray and color images. In
Proceedings of International Conference on Computer Vision (ICCV), page
839. IEEE Computer Society, 1998.
[VB11] G. Vialaneix and T. Boubekeur. Sbl mesh filter : fast separable approximation
of bilateral mesh filtering. In SIGGRAPH Talks, page 24. ACM, 2011.
[VDVK09] D. Van De Ville and M. Kocher. SURE-based non-local means. IEEE Signal
Processing Letters, 16(11) :973–976, 2009.
[WCZ+08] R. F. Wang, W. Z. Chen, S. Y. Zhang, Y. Zhang, and X. Z. Ye. Similaritybased
denoising of point-sampled surfaces. Journal of Zhejiang UniversityScience,
9(6) :807–815, 2008.110
[WGY+06] J. Wang, Y. Guo, Y. Ying, Y. Liu, and Q. Peng. Fast non-local algorithm
for image denoising. In IEEE International Conference on Image Processing
(ICIP), pages 1429–1432, 2006.
[YBS06] S. Yoshizawa, A. Belyaev, and H.-P. Seidel. Smoothing by example : Mesh
denoising by averaging with similarity based weights. In In Proceedings of
IEEE International Conference on Shape Modeling and Applications, pages
38–44, 2006.
[YSM10] G. Yu, G. Sapiro, and S. Mallat. Image modeling and enhancement via structured
sparse model selection. In IEEE International Conference on Image
Processing (ICIP), pages 1641–1644, 2010.
[YSM12] G. Yu, G. Sapiro, and S. Mallat. Solving inverse problems with piecewise
linear estimators : from gaussian mixture models to structured sparsity. IEEE
Transactions on Image Processing, 21(5) :2481–2499, 2012.
[YY85] L. P. Yaroslavsky and L. P. Yaroslavskij. Digital picture processing. an introduction.
Springer Seriesin Information Sciences, 1, 1985.
[ZDW08] S. Zimmer, S. Didas, and J. Weickert. A rotationally invariant block matching
strategy improving image denoising with non-local means. In Proceedings
of International Workshop on Local and Non-Local Approximation in Image
Processing, pages 135–142, 2008.
[ZDZS10] L. Zhang, W. Dong, D. Zhang, and G. Shi. Two-stage image denoising by
principal component analysis with local pixel grouping. Pattern Recognition,
43(4) :1531–1549, 2010.
[ZW11] D. Zoran and Y. Weiss. From learning models of natural image patches
to whole image restoration. In Proceedings of International Conference on
Computer Vision (ICCV), pages 479–486. IEEE, 2011.Méthodes et structures non locales pour la restauration
d’images et de surfaces 3D
Thierry GUILLEMOT
Résumé : Durant ces dernières années, les technologies d’acquisition numériques n’ont cessé
de se perfectionner, permettant d’obtenir des données d’une qualité toujours plus fine. Néanmoins, le
signal acquis reste corrompu par des défauts qui ne peuvent être corrigés matériellement et nécessitent
l’utilisation de méthodes de restauration adaptées.
Jusqu’au milieu des années 2000, ces approches s’appuyaient uniquement sur un traitement ocal du
signal détérioré. Avec l’amélioration des performances de calcul, le support du filtre a pu être étendu à
l’ensemble des données acquises en exploitant leur caractère autosimilaire. Ces approches non locales
ont principalement été utilisées pour restaurer des données régulières et structurées telles que des
images. Mais dans le cas extrême de données irrégulières et non structurées comme les nuages de
points 3D, leur adaptation est peu étudiée à l’heure actuelle. Avec l’augmentation de la quantité de données
échangées sur les réseaux de communication, de nouvelles méthodes non locales ont récemment
été proposées. Elles utilisent un modèle a priori extrait à partir de grands ensembles d’échantillons pour
améliorer la qualité de la restauration. Néanmoins, ce type de méthode reste actuellement trop coûteux
en temps et en mémoire.
Dans cette thèse, nous proposons, tout d’abord, d’étendre les méthodes non locales aux nuages
de points 3D, en définissant une surface de points capable d’exploiter leur caractère autosimilaire.
Nous introduisons ensuite une nouvelle structure de données, le CovTree, flexible et générique, capable
d’apprendre les distributions d’un grand ensemble d’échantillons avec une capacité de mémoire limitée.
Finalement, nous généralisons les méthodes de restauration collaboratives appliquées aux données
2D et 3D, en utilisant notre CovTree pour apprendre un modèle statistique a priori à partir d’un grand
ensemble de données.
Mots-clefs : non local, restauration, structure de données, débruitages, surface, nuage de points,
filtre collaboratif
Abstract : In recent years, digital technologies allowing to acquire real world objects or scenes
have been significantly improved in order to obtain high quality datasets. However, the acquired signal
is corrupted by defects which can not be rectified materially and require the use of adapted restoration
methods.
Until the middle 2000s, these approaches were only based on a local process applyed on the
damaged signal. With the improvement of computing performance, the neighborhood used by the filter
has been extended to the entire acquired dataset by exploiting their self-similar nature. These non-local
approaches have mainly been used to restore regular and structured data such as images. But in the
extreme case of irregular and unstructured data as 3D point sets, their adaptation is few investigated at
this time. With the increase amount of exchanged data over the communication networks, new non-local
methods have recently been proposed. These can improve the quality of the restoration by using an a
priori model extracted from large data sets. However, this kind of method is time and memory consuming.
In this thesis, we first propose to extend the non-local methods for 3D point sets by defining a surface
of points which exploits their self-similar of the point cloud. We then introduce a new flexible and generic
data structure, called the CovTree, allowing to learn the distribution of a large set of samples with a
limited memory capacity. Finally, we generalize collaborative restoration methods applied to 2D and 3D
data by using our CovTree to learn a statistical a priori model from a large dataset.
Keywords : non local, restauration, data structure, denoising, surface, points set, collaborative filter
Couplage de mod`eles, algorithmes multi-´echelles et
calcul hybride
Jean-Matthieu Etancelin
To cite this version:
Jean-Matthieu Etancelin. Couplage de mod`eles, algorithmes multi-´echelles et calcul hybride.
Analysis of PDEs. Universit´e de Grenoble, 2014. French.
HAL Id: tel-01094645
https://tel.archives-ouvertes.fr/tel-01094645v2
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.THÈSE
Pour obtenir le grade de
DOCTEUR DE L’UNIVERSITÉ DE GRENOBLE
Spécialité : Mathématiques Appliquées
Arrêté ministériel : 7 août 2006
Présentée par
Jean-Matthieu Etancelin
Thèse dirigée par Georges-Henri Cottet
et codirigée par Christophe Picard
préparée au sein du Laboratoire Jean Kuntzmann
et de l’école doctorale MSTII: Mathématiques, Sciences et Technologies
de l’Information, Informatique
Couplage de modèles, algorithmes
multi-échelles et calcul hybride
Thèse soutenue publiquement le 4 décembre 2014,
devant le jury composé de :
M. Stéphane Labbé
Professeur, Université Joseph Fourier, Président
M. Florian De Vuyst
Professeur, École Normale Supérieure de Cachan, Rapporteur
M. Philippe Helluy
Professeur, Université de Strasbourg, Rapporteur
M. Guillaume Balarac
Maître de conférences, Grenoble INP, Examinateur
M. Georges-Henri Cottet
Professeur, Université Joseph Fourier, Directeur de thèse
M. Alexis Herault
Maître de conférences, Conservatoire National des Arts et Métiers, Examinateur
M. Christophe Picard
Maître de conférences, Grenoble INP, Co-Directeur de thèse
M. Christophe Prud’homme
Professeur, Université de Strasbourg, Examinateur
M. Jean-Baptiste Lagaert
Maître de conférences, Université Paris-Sud, InvitéCouplage de modèles, algorithmes
multi-échelles et calcul hybride
Thèse présentée et soutenue publiquement par :
Jean-Matthieu Etancelin
le 4 décembre 2014
Composition du jury :
Président :
Stéphane Labbé,
Professeur, Université Joseph Fourier
Rapporteurs :
Florian De Vuyst,
Professeur, École Normale Supérieure de Cachan
Philippe Helluy,
Professeur, Université de Strasbourg
Examinateurs :
Guillaume Balarac,
Maître de conférences, Grenoble INP
Georges-Henri Cottet,
Professeur, Université Joseph Fourier (Directeur de thèse)
Alexis Herault,
Maître de conférences, Conservatoire National des Arts et Métiers
Christophe Picard,
Maître de conférences, Grenoble INP (Co-Directeur de thèse)
Christophe Prud’homme,
Professeur, Université de Strasbourg
Invité :
Jean-Baptiste Lagaert,
Maître de conférences, Université Paris-Sud
Thèse préparée au sein du Laboratoire Jean Kuntzmann
et de l’école doctorale MSTII : Mathémaiques, Sciences
et Technologies de l’Information, Informatique.
Cette thèse a été effectuée dans le cadre du projet ANR HAMM (ANR-10-COSI-0009).iiRemerciements
Je voudrais exprimer ma gratitude auprès de toutes les personnes, du Laboratoire Jean
Kuntzmann ou d’ailleurs, qui ont contribué à la réussite de cette thèse aussi bien sur le plan
scientifique qu’humain.
Je remercie très chaleureusement mon directeur de thèse, Georges-Henri Cottet, et mon
co-encadrant, Christophe Picard, pour leur disponibilité et leur soutient tout au long de ces
trois années. Votre encadrement a été réel et complémentaire sur le fond et la forme de ces
travaux.
Je remercie l’ensemble des membres de mon jury d’avoir pris le temps d’examiner mon
travail, en particulier Florian De Vuyst et Philippe Helluy, rapporteurs de cette thèse.
Je remercie également Franck, Chloé, Jean-Baptiste et Éric pour les nombreux questionnements
et discussions lors des réunions du groupe de travail. Ces échanges ont été en
grande partie à l’origine des avancées majeures des travaux et ont permis de conserver une
motivation à chaque instant.
Je voudrais adresser ma reconnaissance aux membres de l’équipe des Moyens Informatiques
et Calcul Scientifique du LJK et du mésocentre CIMENT qui ont contribué à la
résolution des nombreux problèmes techniques qui se sont posés tout au long de la thèse.
Je remercie en particulier Franck (encore) pour sa grande disponibilité, surtout le vendredi
après-midi, pour répondre à mes très nombreuses questions techniques. Pour les aspects informatiques,
je remercie aussi Frédéric pour ses nombreuses remises en route de la machine
de calcul du laboratoire. Je voudrais remercier l’ensemble des gestionnaires administratives
du laboratoire qui assurent une présence rassurante pour mener à bien toutes les démarches.
Je remercie l’ensemble des doctorants et post-doctorants sur lesquels on peut compter
pour un repas au RU, un café, des mots fléchés, de bons conseils, une soirée jeux, une
sortie cinéma, une bière, une randonnée, des crêpes, une sortie ski, un footing, un trail,. . .
Pour tout cela, merci à Chloé, Roland, Vincent, Bertrand, Thomas, Madison, Lukáš, PierreOlivier,
Matthias, Nelson, Romain, Morgane, Pierre-Jean, Meriem, Kevin, Gilles, Euriell,
Amin, Kolé, Louis, Federico Z., Mahamar, Abdoulaye, Federico P., Margaux, Olivier, . . .
Merci à Martial pour les très nombreuses « buissonnades » en tout genre dans lesquelles
on se laisse facilement embarquer. Je remercie également les copains de l’INSA pour leur
promptitude à traverser la France et à proposer des hébergements pour passer du bon temps.
Merci à ma famille pour son soutient tout au long de mes études.
Enfin, et non des moindres, merci à Myriam pour tout ces instants que l’on partage au
quotidien.
iiiRésumé
Dans cette thèse nous explorons les possibilités offertes par l’implémentation de mé-
thodes hybrides sur des machines de calcul hétérogènes dans le but de réaliser des simulations
numériques de problèmes multiéchelles. La méthode hybride consiste à coupler des
méthodes de diverses natures pour résoudre les différents aspects physiques et numériques
des problèmes considérés. Elle repose sur une méthode particulaire avec remaillage qui
combine les avantages des méthodes Lagrangiennes et Eulériennes. Les particules sont dé-
placées selon le champ de vitesse puis remaillées à chaque itération sur une grille en utilisant
des formules de remaillage d’ordre élevés. Cette méthode semi-Lagrangienne bénéficie des
avantages du maillage régulier mais n’est pas contrainte par une condition de CFL.
Nous construisons une classe de méthodes d’ordre élevé pour lesquelles les preuves de
convergence sont obtenues sous la seule contrainte de stabilité telle que les trajectoires des
particules ne se croisent pas.
Dans un contexte de calcul à haute performance, le développement du code de calcul
a été axé sur la portabilité afin de supporter l’évolution rapide des architectures et leur
nature hétérogène. Une étude des performances numériques de l’implémentation GPU de la
méthode pour la résolution d’équations de transport est réalisée puis étendue au cas multiGPU.
La méthode hybride est appliquée à la simulation du transport d’un scalaire passif
dans un écoulement turbulent 3D. Les deux sous-problèmes que sont l’écoulement turbulent
et le transport du scalaire sont résolus simultanément sur des architectures multi-CPU et
multi-GPU.
Mots clés: Méthodes pariculaires ; couplage de modèles ; calcul hybride ; écoulements turbulents.
ivAbstract
In this work, we investigate the implementation of hybrid methods on heterogeneous
computers in order to achieve numerical simulations of multi-scale problems. The hybrid
numerical method consists of coupling methods of different natures to solve the physical
and numerical characteristics of the problem. It is based on a remeshed particle method
that combines the advantages of Lagrangian and Eulerian methods. Particles are pushed
by local velocities and remeshed at every time-step on a grid using high order interpolation
formulas. This forward semi-lagrangian method takes advantage of the regular mesh on
which particles are reinitialized but is not limited by CFL conditions.
We derive a class of high order methods for which we are able to prove convergence
results under the sole stability constraint that particle trajectories do not intersect.
In the context of high performance computing, a strong portability constraint is applied
to the code development in order to handle the rapid evolution of architectures and their
heterogeneous nature. An analysis of the numerical efficiency of the GPU implementation
of the method is performed and extended to multi-GPU platforms. The hybrid method
is applied to the simulation of the transport of a passive scalar in a 3D turbulent flow.
The two sub-problems of the flow and the scalar calculations are solved simultaneously on
multi-CPU and multi-GPU architectures.
Keywords: Particle methods; model coupling; hybrid computing; turbulent flows.
vTable des matières
Remerciements iii
Résumé iv
Introduction générale 1
1. Calcul intensif pour la mécanique des fluides 5
1.1. Mécanique des fluides numérique . . . . . . . . . . . . . . . . . . . . . . . . 6
1.1.1. Modèle mathématique . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Équations de Navier-Stokes . . . . . . . . . . . . . . . . . . . . . . 6
Fluides incompressibles . . . . . . . . . . . . . . . . . . . . . . . . 8
1.1.2. Principales méthodes de résolution . . . . . . . . . . . . . . . . . . . 9
Méthodes Eulériennes . . . . . . . . . . . . . . . . . . . . . . . . . 9
Méthodes de Lattice Boltzmann . . . . . . . . . . . . . . . . . . . 12
Méthodes Lagrangiennes . . . . . . . . . . . . . . . . . . . . . . . 13
Qualité des résultats numériques . . . . . . . . . . . . . . . . . . . 16
1.1.3. Exemples d’application . . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2. Calcul intensif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
1.2.1. Augmentation des besoin et des ressources de calcul . . . . . . . . . 18
Ressources de calcul pour les simulations numériques . . . . . . . . 18
Augmentation de la puissance de calcul des machines . . . . . . . 18
Difficulté d’adaptation des codes de calcul . . . . . . . . . . . . . . 20
1.2.2. Mesure de performances . . . . . . . . . . . . . . . . . . . . . . . . . 20
Scalabilité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
Modèle roofline . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Efficacité énergétique . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.2.3. Défi de l’exascale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Pourquoi l’exascale ? . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Principales difficultés . . . . . . . . . . . . . . . . . . . . . . . . . 25
Quelques stratégies . . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.3. Transport de scalaire passif dans un écoulement turbulent . . . . . . . . . . 26
1.3.1. Domaines d’application . . . . . . . . . . . . . . . . . . . . . . . . . 26
1.3.2. Physique du problème . . . . . . . . . . . . . . . . . . . . . . . . . . 27
1.3.3. Formulation mathématique . . . . . . . . . . . . . . . . . . . . . . . 28
viiTable des matières
2. Méthode particulaire pour l’équation de transport 31
2.1. Méthode particulaire avec remaillage . . . . . . . . . . . . . . . . . . . . . . 32
2.1.1. Deux classes de méthodes semi-Lagrangiennes . . . . . . . . . . . . . 32
2.1.2. Principe général de la méthode particulaire avec remaillage . . . . . 33
2.1.3. Cas monodimensionnel . . . . . . . . . . . . . . . . . . . . . . . . . . 36
2.1.4. Lien avec la méthode des différences finies . . . . . . . . . . . . . . . 37
2.1.5. Construction des formules de remaillage . . . . . . . . . . . . . . . . 39
Construction à partir des moments discrets . . . . . . . . . . . . . 39
Construction à partir de B-splines . . . . . . . . . . . . . . . . . . 39
Extrapolation à partir de noyaux réguliers . . . . . . . . . . . . . . 40
2.1.6. Exemple d’implémentation . . . . . . . . . . . . . . . . . . . . . . . . 42
2.2. Advection semi-Lagrangienne d’ordre élevé . . . . . . . . . . . . . . . . . . . 42
2.2.1. Construction de formules de remaillage d’ordre élevé . . . . . . . . . 42
Utilisation des poids de remaillage . . . . . . . . . . . . . . . . . . 45
Précision numérique du schéma d’Horner . . . . . . . . . . . . . . 46
2.2.2. Consistance de la méthode semi-Lagrangienne . . . . . . . . . . . . . 47
Advection par un schéma d’Euler . . . . . . . . . . . . . . . . . . . 50
Advection par un schéma de Runge-Kutta du second ordre . . . . 50
Cas d’une seule particule par cellule . . . . . . . . . . . . . . . . . 51
2.2.3. Stabilité de la méthode semi-Lagrangienne . . . . . . . . . . . . . . . 51
Advection à vitesse constante . . . . . . . . . . . . . . . . . . . . . 52
Advection à vitesse non constante . . . . . . . . . . . . . . . . . . 56
3. Méthode hybride pour le transport turbulent 59
3.1. Idée générale d’une méthode hybride . . . . . . . . . . . . . . . . . . . . . . 59
3.1.1. Méthode hybride en méthode numérique . . . . . . . . . . . . . . . . 60
3.1.2. Méthode hybride en résolution . . . . . . . . . . . . . . . . . . . . . 60
3.1.3. Méthode hybride en matériel . . . . . . . . . . . . . . . . . . . . . . 61
3.2. Application au transport turbulent . . . . . . . . . . . . . . . . . . . . . . . 61
3.2.1. Méthodes spectrale et différences finies . . . . . . . . . . . . . . . . . 61
3.2.2. Méthodes spectrale et semi-Lagrangienne . . . . . . . . . . . . . . . 62
3.2.3. Méthodes semi-Lagrangiennes et architecture hybride . . . . . . . . . 62
4. Développement d’un code multiarchitectures 65
4.1. Développement d’une librairie de calcul scientifique . . . . . . . . . . . . . . 66
4.1.1. Conception préliminaire . . . . . . . . . . . . . . . . . . . . . . . . . 66
Découpage sémantique des concepts mathématiques . . . . . . . . 66
Différents niveaux d’abstraction . . . . . . . . . . . . . . . . . . . 67
Couplage faible et cohésion forte . . . . . . . . . . . . . . . . . . . 67
Schéma d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.1.2. Conception détaillée . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
4.1.3. Fonctionnement de la librairie . . . . . . . . . . . . . . . . . . . . . . 70
Langages de programmation . . . . . . . . . . . . . . . . . . . . . 70
Dépendances externes . . . . . . . . . . . . . . . . . . . . . . . . . 71
Fonctionnement global . . . . . . . . . . . . . . . . . . . . . . . . . 72
viiiTable des matières
4.2. Calcul générique sur carte graphique . . . . . . . . . . . . . . . . . . . . . . 72
4.2.1. Description du matériel . . . . . . . . . . . . . . . . . . . . . . . . . 72
Fonctionnement des cartes graphiques . . . . . . . . . . . . . . . . 72
Architecture des cartes graphiques . . . . . . . . . . . . . . . . . . 74
4.2.2. Différentes méthodes de programmation . . . . . . . . . . . . . . . . 75
Programmation par directives . . . . . . . . . . . . . . . . . . . . . 75
Programmation directe . . . . . . . . . . . . . . . . . . . . . . . . 76
4.2.3. Les modèles de programmation OpenCL . . . . . . . . . . . . . . . . 76
4.2.4. Analyse de performances par le modèle roofline . . . . . . . . . . . . 80
4.3. Utilisation de cartes graphiques dans la librairie . . . . . . . . . . . . . . . . 82
5. Mise en œuvre sur cartes graphiques 85
5.1. Implémentations GPU de méthodes semi-Lagrangiennes . . . . . . . . . . . 86
5.1.1. Méthodes semi-Lagrangiennes . . . . . . . . . . . . . . . . . . . . . . 86
5.1.2. Deux types d’interpolations . . . . . . . . . . . . . . . . . . . . . . . 86
5.2. Implémentation et performances . . . . . . . . . . . . . . . . . . . . . . . . 89
5.2.1. Adéquation de la méthode au matériel . . . . . . . . . . . . . . . . . 89
5.2.2. Préambule à l’étude des performances . . . . . . . . . . . . . . . . . 91
5.2.3. Initialisation des particules . . . . . . . . . . . . . . . . . . . . . . . 94
Copie . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Transposition XY . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Transposition XZ . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
5.2.4. Advection et remaillage . . . . . . . . . . . . . . . . . . . . . . . . . 98
Advection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Remaillage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Noyau complet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
5.3. Application simple GPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.3.1. Transport de scalaire 2D . . . . . . . . . . . . . . . . . . . . . . . . . 107
5.3.2. Transport de scalaire 3D . . . . . . . . . . . . . . . . . . . . . . . . . 111
6. Implémentation sur architectures hétérogènes 115
6.1. Lien entre la méthode et l’architecture hybride . . . . . . . . . . . . . . . . 116
6.1.1. Description d’une machine hybride . . . . . . . . . . . . . . . . . . . 116
6.1.2. Différents niveaux de parallélisme . . . . . . . . . . . . . . . . . . . . 117
6.1.3. Stratégie d’utilisation . . . . . . . . . . . . . . . . . . . . . . . . . . 118
6.2. Application multi-GPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
6.2.1. Mécanisme de communication . . . . . . . . . . . . . . . . . . . . . . 119
6.2.2. Performances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
6.3. Transport turbulent d’un scalaire passif . . . . . . . . . . . . . . . . . . . . 126
6.3.1. Application hybride . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
6.3.2. Exploitation d’une machine hétérogène . . . . . . . . . . . . . . . . . 128
6.3.3. Résultats et performances . . . . . . . . . . . . . . . . . . . . . . . . 129
Conclusion générale 135
Bibliographie 139
ixTable des matières
A. Formules de remaillage de type Λp,r 145
A.1. Formules de type Λ2,r . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
A.2. Formules de type Λ4,r . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
A.3. Formules de type Λ6,r . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
A.4. Formules de type Λ8,r . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
B. Publications 157
B.1.. High order semi-Lagrangian particle methods for transport equations : numerical
analysis and implementation issues . . . . . . . . . . . . . . . . . . . 159
B.2.. Multi-scale problems, high performance computing and hybrid numerical methods
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
xIntroduction générale
La réalisation de simulations numériques est une activité majeure dans les secteurs de
la recherche et de l’industrie. Une simulation numérique permet d’obtenir une solution à
un problème mathématique qu’il n’est généralement pas possible de résoudre analytiquement.
Ces problèmes sont constitués d’équations modélisant un phénomène à étudier. Les
premières simulations numériques datent du milieu du XXe
siècle lorsque l’informatique
commence à être utilisée dans ce but. En 1955, Fermi et al. réalisent une des premières
simulations numériques d’un système dynamique monodimensionnel constitué de 64 masses
reliées par des ressorts. Depuis, l’usage des calculateurs n’a cessé de se développer avec
l’essor de l’informatique et des machines de calcul.
D’une part, les objectifs des simulations numériques sont de permettre une validation
des modèles physiques et mathématiques utilisés pour l’étude d’un phénomène, par rapport
à la théorie et à d’éventuelles données expérimentales. D’autre part, elles servent d’outils de
conception et d’optimisation à des fins industrielles et permettent d’éviter le recours à de
nombreux et coûteux modèles réduits et prototypes. L’explosion de la puissance de calcul
développée par les machines parallèles au cours des dernières décennies permet la réalisation
de simulations numériques de plus en plus précises et complexes tout en conservant des
temps de calculs comparables. Ainsi, dans le domaine de la mécanique des fluides, l’évolution
des simulations numériques contribue fortement à l’amélioration de la compréhension
de phénomènes complexes comme la turbulence. En effet, les machines sont capables de
traiter des résolutions toujours plus grandes, ce qui permet d’accroître la finesse des résultats,
en particulier pour des Simulations Numériques Directes (DNS en anglais). De même,
des études de fluides complexes (non Newtoniens, biologiques, alimentaires, . . .) ou de problèmes
multiphysiques (interaction fluide-structure, combustion, plasma, . . .) font appel à
des schémas numériques plus complexes et dont la mise en œuvre nécessite d’importantes
ressources de calcul. Enfin, dans le cadre d’applications graphiques pour le cinéma ou les
jeux vidéos, les capacités des machines actuelles permettent une utilisation de véritables modèles
de fluide plutôt que des approximations afin d’augmenter le réalisme des écoulements
dans des temps de calcul compatibles avec les contraintes de l’application.
Les simulations numériques reposent à la fois sur une ou plusieurs méthodes numériques
et sur un code de calcul qui transcrit ces méthodes sur les machines de calcul. Le choix de la
méthode de résolution dépend essentiellement de l’adéquation entre la nature du problème
à résoudre, les caractéristiques attendues pour les solutions et les spécificités de la méthode.
Le code de calcul met en œuvre les algorithmes issus de la méthode.
1Introduction générale
Le rôle de l’informatique est primordial pour l’obtention d’un code de calcul efficace. La
qualité d’une méthode se mesure à la fois à travers les résultats qu’elle produit, mais aussi à
son implémentation. L’efficacité numérique d’un code se mesure, entre autres, par le temps
de calcul nécessaire à l’obtention de la solution en fonction de la qualité désirée. Ainsi,
l’implémentation d’une méthode nécessite une attention particulière dans le but d’exploiter
au mieux les ressources informatiques disponibles. Le développement d’un code efficace
dans un contexte de calcul à hautes performances est un véritable défi sur des machines
hétérogènes et massivement parallèles. Par conséquent, les méthodes numériques doivent
non seulement être adaptées aux caractéristiques des problèmes à résoudre, mais également
aux architectures des machines sur lesquelles elles seront implémentées. En particulier,
l’aspect hétérogène des composants (CPU, GPU, coprocesseurs, . . .) doit être pris en compte
dès la conception de l’algorithme de résolution et de l’élaboration de la méthode numérique.
Dans cette thèse, nous considérons un problème de transport de scalaire passif dans un
écoulement turbulent comme cadre applicatif. De nombreuses applications sont concernées
par ce type de problème notamment dans les domaines de l’environnement, de l’industrie
ou de la biologie (Shraiman et al., 2000). Le scalaire transporté peut représenter une quantité
réelle comme une concentration en espèce chimique ou en bactéries, ou bien abstraite
comme une interface entre deux fluides. Dans ce travail nous nous limitons à l’étude du
transport de scalaires passifs qui n’influent pas sur l’écoulement en retour. En général, la
physique de ce type de problème se caractérise par la présence de plusieurs phénomènes à
différentes échelles (Batchelor, 1958). L’approche envisagée ici est celle d’une résolution par
une méthode hybride. Cette notion nécessite une précision quant au sens du mot hybride
tel que nous l’entendons. Une méthode hybride consiste à résoudre les différents aspects
physiques à l’aide d’une ou plusieurs méthodes numériques adaptées en fonction de leurs
caractéristiques respectives. La méthodologie employée dans cette thèse est de chercher à
exploiter les spécificités des aspects physiques des problèmes par la mise en place d’une
méthode hybride (Gotoh et al., 2012 ; Lagaert et al., 2014).
Une des problématiques traitées dans ce manuscrit concerne l’exploitation de l’analogie
entre l’aspect hybride de la méthode numérique et la nature hétérogène des machines de
calcul. Nous nous intéressons à exécuter les différents éléments de résolution sur différents
composants des machines. Nous en exposerons les raisons dans le chapitre 6. La mise en
œuvre d’une stratégie hybride sera explorée en combinant des méthodes numériques de
diverses natures, des résolutions différentes et une implémentation sur architecture hétérogène.
L’approche suivie repose sur une implémentation sur cartes graphiques d’une méthode
particulaire avec remaillage. Cette dernière permet, entre autres, de résoudre naturellement
des équations de conservations sans imposer de condition de type Courant-Friedrichs-Lewy
mais une condition de stabilité moins restrictive permettant l’usage de plus grands pas
de temps. L’utilisation de cette méthode conduit, à travers la présence d’une grille sousjacente,
à des algorithmes et des structures de données régulières, ce qui est parfaitement
adapté à l’emploi de cartes graphiques. Enfin, nous utiliserons la puissance de calcul offerte
par les GPU pour proposer une extension à un ordre élevé de la méthode particulaire avec
remaillage. L’analyse des schémas numériques se base sur une approche similaire à celle employée
pour l’étude de schémas aux différences finies (Cottet et al., 2006). Un des aspects
informatiques considéré est lié à la nécessité du développement d’un code de calcul portable
et non spécifique à une architecture afin de supporter l’évolution rapide des matériels et des
librairies.
2L’enchaînement des six chapitres de ce manuscrit reprend une démarche classique du
calcul scientifique. En partant de la description des modèles puis des méthodes numériques et
de leurs spécificités, on aboutit à l’implémentation générique multicœur GPU et hybride sur
des machines hétérogènes combinant des processeurs multicœurs et des cartes graphiques.
La progression et la répartition des différents chapitres sont schématisés par la figure 1.
Chapitre 1
Chapitres 2 et 3
Chapitre 4 Chapitres 5 et 6
Modèle physique
Modèle mathématique
Modèle numérique
Modèle algorithmique
Implémentation
Validation
Observations
Expériences
Figure 1. – Cycle de résolution d’un problème en mathématiques appliquées
Dans un premier chapitre, les modèles mathématiques pour la modélisation de fluides
Newtoniens seront exposés. Nous présenterons également quelques méthodes numériques
usuelles. Elles font appel à des ressources informatiques dont l’évolution, en termes de
capacité et d’architecture, joue un rôle important dans le développement des codes de calcul.
Une description des applications envisagées et notamment le transport de scalaire passif
dans un écoulement turbulent terminera ce chapitre. Le second chapitre sera consacré à la
description de la méthode particulaire avec remaillage. À travers une revue bibliographique
de son évolution et de ses utilisations, nous exposerons l’analogie entre cette méthode et
celle des différences finies. Cette revue sera complétée par une extension à un ordre élevé
faisant intervenir la construction de formules de remaillage appropriées. Une analyse des
schémas numériques en termes de consistance et de stabilité sera également développée.
Dans un troisième chapitre, nous introduirons, à partir de travaux existants, la stratégie
hybride envisagée pour la résolution de problèmes de transport de scalaire. Son application
à un contexte de machine de calcul hétérogène sera abordé. Le quatrième chapitre sera
consacré aux détails du développement d’une librairie de calcul scientifique portable et
multiarchitecture. En particulier, nous verrons comment une conception souple simplifie
l’utilisation de composants comme les cartes graphiques. Le chapitre cinq est dédié aux
détails techniques de l’implémentation sur cartes graphiques de la méthode particulaire avec
remaillage. Les choix d’implémentation seront éclairés par l’analyse de travaux similaires
existants. Ce chapitre sera illustré par des exemples de transport de scalaire dans des cas
où la vitesse est analytique afin de valider la méthode et d’en exposer les performances. Le
3Introduction générale
sixième chapitre sera consacré à l’extension multi-GPU de la méthode. Une analyse de la
stratégie de couplage entre la méthode hybride et l’architecture hétérogène des machines
de calcul sera donnée à travers un exemple de transport turbulent de scalaire passif. Enfin,
nous terminerons ce manuscrit par un chapitre de conclusion donnant lieu à une critique
des travaux effectués ainsi qu’à un énoncé des perspectives dégagées par cette étude.
41. Calcul intensif pour la
mécanique des fluides
Le contexte des travaux de cette thèse est celui des mathématiques appliquées, au point
de rencontre d’une application, d’une méthode numérique et d’un code de calcul. À partir
d’observations de phénomènes naturels ou artificiels, des modèles physiques sont élaborés
puis mis en équations sous la forme de modèles mathématiques. La spécialisation de ces
modèles par rapport à une situation concrète se fait par la spécification de divers paramètres,
de conditions initiales et de conditions aux limites des modèles. Ils expriment ainsi
les conditions d’observations des phénomènes et le contexte expérimental des reproductions
en laboratoire. Dans le cadre de simulations numériques, les modèles mathématiques sont
discrétisés selon une ou plusieurs méthodes numériques conduisant à l’expression d’algorithmes
qui sont implémentés dans des codes de calcul. L’exécution de ces codes sur des
machines de calcul permet d’une part de valider les méthodes et les modèles par rapport
aux phénomènes physiques mais aussi d’explorer les configurations qui ne sont pas aisément
observables ou mesurables.
Ce premier chapitre est dédié à la présentation du contexte mathématique de la mécanique
des fluides à travers la construction du modèle des équations de Navier-Stokes. Nous
donnerons ensuite quelques méthodes de résolution classiques. Dans un second temps, nous
verrons que la mise en pratique des méthodes numériques est étroitement liée à l’exploitation
des ressources de calcul. Une forte contrainte de portabilité et d’adaptivité pèse sur les
algorithmes et leurs implémentations du fait de la rapidité à laquelle les technologies des
machines évoluent. Afin de garantir une certaine pérennité pour les codes de calcul, il est
nécessaire de prendre en compte, dès la conception, non seulement les types ressources et
les technologies actuelles mais aussi à venir, en particulier dans la perspective de l’exascale.
Dans ce cadre, une grande importance est attachée à l’évaluation des performances des
implémentations et à des comparaisons d’algorithmes dont nous donnerons quelques mé-
triques couramment utilisées. Enfin, nous détaillerons les modèles physiques des applications
envisagées pour ce travail.
51. Calcul intensif pour la mécanique des fluides
1.1. Mécanique des fluides numérique
L’objectif de la mécanique des fluides est d’analyser et de comprendre les comportements
de fluides, qu’ils soient liquides ou gazeux, lorsqu’ils sont en mouvement et éventuellement
en présence d’obstacles ou de structures avec lesquels ils interagissent. La majeure partie
des problèmes de mécanique des fluides sont issus de l’ingénierie avec notamment l’industrie
aéronautique et plus généralement les domaines des transports, de l’énergie, du génie civil
et des sciences de l’environnement. Des applications portant sur l’étude de fluides moins
conventionnels sont également considérées en biologie et par l’industrie agro-alimentaire.
La modélisation mathématique de ces problèmes conduit à des systèmes d’équations trop
complexes pour être résolus formellement. Dans de nombreux cas, la démonstration formelle
de l’existence de solutions à ces système reste encore un problème ouvert. Une modélisation
numérique de ces problèmes permet d’approcher une solution par l’utilisation de méthodes
numériques.
Les équations de Navier-Stokes permettent de décrire de manière générale le comportement
d’un fluide en se basant sur des principes physiques de conservation de masse, de
quantité de mouvement et d’énergie.
1.1.1. Modèle mathématique
Équations de Navier-Stokes
Conservation de la masse : Ce principe fondamental de la physique stipule que la masse
totale contenue dans un système fermé reste constante au cours du temps. La matière, ou
l’énergie, du système considéré peut éventuellement changer de forme ou se réarranger dans
l’espace. La variation temporelle de la masse totale contenue dans un volume Ω est égale
au bilan de masse traversant la frontière du domaine, ∂Ω :
d
dt
Z
Ω
ρdx
= −
I
∂Ω
ρu · nds,
où ρ est la masse volumique, u la vitesse et n la normale extérieure unitaire à la surface
du volume de fluide Ω. L’équation se réécrit de manière équivalente sous sa forme locale :
∂ρ
∂t + div(ρu) = 0. (1.1)
Conservation de la quantité de mouvement : De même, la variation temporelle de la
quantité de mouvement d’un système, notée ρu, est égale à son bilan sur la frontière auquel
s’ajoutent d’éventuelles forces F. On note u : u le produit tensoriel de u avec lui-même.
Cela se traduit par la relation :
d
dt
Z
Ω
ρudx
= −
I
∂Ω
ρu : u · nds +
Z
Ω
Fdx,
ou encore sous forme locale :
∂ρu
∂t + div(ρu : u) = F.
61.1. Mécanique des fluides numérique
Le développement de cette équation se simplifie avec l’équation de conservation de la
masse (1.1) pour donner :
ρ
∂u
∂t + (u · ∇)u
= F.
Les forces F s’exerçant sur un volume de fluide se décomposent en deux termes selon leur
nature :
F = div σ¯¯ + fe
.
Les forces extérieures qui agissent sur l’ensemble du système sont notées fe
, et les forces
générées par les contraintes internes du fluide dépendent du tenseur des contraintes totales
σ¯¯ qui se décompose également en deux termes :
σ¯¯ = −PI
¯¯ + τ¯¯ , (1.2)
où P est la pression, I
¯¯ le tenseur identité et τ¯¯ le tenseur des contraintes. Ainsi on obtient
la formulation suivante :
ρ
∂u
∂t + (u · ∇)u
= −∇P + div τ¯¯ + fe
. (1.3)
Loi de comportement : Le tenseur des contraintes τ¯¯ issu de la décomposition du tenseur
des contraintes totales (1.2) permet de modéliser le comportement d’un fluide en particulier.
Dans le cadre de fluides Newtoniens, le tenseur des contraintes est proportionnel au taux
de déformations :
τ¯¯ i,j = ν
∂ui
∂xj
+
∂uj
∂xi
,
avec ν la viscosité dynamique du fluide. Lorsque la viscosité ne dépend pas de l’espace, on
a :
div τ¯¯ = ν (∆u − ∇ div u). (1.4)
Équations de Navier-Stokes : Dans le cadre général, les équations de Navier-Stokes
constituent un système d’équations aux dérivées partielles obtenues à partir des équations de
conservation de masse, (1.1), de quantité de mouvement (1.3) et de la loi de comportement
du fluide (1.4).
∂ρ
∂t + div(ρu) = 0,
ρ
∂u
∂t + (u · ∇)u
= −∇P + ν (∆u − ∇ div u) + ρfe
.
(1.5)
Les inconnues du problème sont la vitesse u, la masse volumique ρ, et la pression P. Une
troisième équation est alors nécessaire pour obtenir un modèle complet. Une équation de
conservation de l’énergie est généralement utilisée. Les forces extérieures sont à préciser
selon le cas d’étude.
71. Calcul intensif pour la mécanique des fluides
Formulation vitesse-vorticité : Dans bon nombre d’écoulements, les zones d’intérêts,
où se forment et évoluent des tourbillons, sont généralement de petite taille relativement au
domaine d’étude et se localisent, entre autres, dans les couches limites et les sillages. Il est
naturel d’employer une formulation adaptée. La vorticité de l’écoulement ω est un champ
vectoriel défini comme le rotationnel du champ de vitesse.
ω = rotu (1.6)
On obtient la formulation vitesse-vorticité en appliquant l’opérateur rotationnel à la
seconde équation du système (1.5) :
ρ
∂ω
∂t + (u · ∇) ω
= ρ(ω · ∇)u + ν∆ω + ρ rot fe
. (1.7)
Fluides incompressibles
Hypothèse d’incompressibilité : Dans de nombreux cas, les fluides considérés ont une
très faible compressibilité. Un fluide est dit incompressible lorsque que la variation de volume
sous l’effet d’une pression extérieure est négligée. Cette hypothèse n’est valide que lorsque
la vitesse du fluide est inférieure à la vitesse du son dans ce fluide. Dans ce cas, la densité
ρ est approchée par une constante, l’équation (1.1) se réduit à :
div u = 0, (1.8)
et la loi de comportement (1.4) se simplifie en :
div τ¯¯ = ν∆u. (1.9)
L’obtention d’un champ de vitesse à divergence nulle, vérifiant (1.8), est généralement
effectuée par l’utilisation d’une méthode de projection. Cette méthode a été introduite par
Chorin (1968) et Temam (1968) et se base sur une décomposition du champ de vitesse selon
une composante à divergence nulle et une composante à rotationnel nul :
u = u∇ + ∇φ, avec div u∇ = 0 et rot ∇φ = 0.
En pratique, un champ de vitesse intermédiaire u
∗ à divergence non nulle est obtenu par la
méthode de résolution puis la fonction scalaire φ est obtenue par résolution d’une équation
de Poisson :
div u
∗ = ∆φ,
et enfin le champ de vitesse incompressible est calculé simplement par : u = u
∗ −∇φ. Dans
le cas de la formulation vitesse-pression, la pression peut jouer le rôle de la fonction scalaire
φ.
Équations de Navier-Stokes pour les fluides Newtoniens incompressibles : À
l’aide de l’hypothèse d’incompressibilité (1.8) et pour une loi de comportement correspondant
à un fluide Newtonien (1.9), le système générique (1.5) se réécrit :
div u = 0,
ρ
∂u
∂t + (u · ∇)u
= −∇P + ν∆u + ρfe
.
(1.10)
81.1. Mécanique des fluides numérique
La formulation vitesse-vorticité conduit au système suivant :
div u = 0,
ω = rotu,
ρ
∂ω
∂t + (u · ∇) ω
= ρ(ω · ∇)u + ν∆ω + ρ rot fe
.
(1.11)
La vorticité et la vitesse sont couplées par la relation ω = rotu, ou bien, de façon équivalente,
par une équation de Poisson, en utilisant ∇ · u = 0 :
(
∆ψ = −ω,
u = rot ψ.
(1.12)
1.1.2. Principales méthodes de résolution
Dans cette section nous donnons quelques unes des méthodes de résolution classiques des
équations précédentes. La plupart de ces méthodes ne se restreignent pas à la mécanique des
fluides et sont utilisées pour résoudre des problèmes aux dérivées partielles plus généraux.
Méthodes Eulériennes
Dans le cas des méthodes Eulériennes, la discrétisation des équations se fait par un
découpage du domaine de calcul en un maillage, structuré ou non. Un maillage structuré se
caractérise par une connectivité régulière des éléments, ce qui permet un accès efficace aux
données des éléments voisins. Dans le cas non structuré, une table de connectivité définissant
les relations de voisinage est nécessaire et permet alors une meilleure discrétisation de
géométries complexes.
Différences finies La plus ancienne et la plus simple de ces méthodes est celle des différences
finies. Elle a été formalisée par Euler en 1768. La méthode est construite sur la
définition de la dérivée :
U
0
(x) = lim
h→0
U(x + h) − U(x)
h
,
qui se généralise sous la forme d’un développement limité :
U(x + h) = U(x) + hU0
(x) + h
2
2
U
00(x) + · · · (1.13)
Lorsque la quantité h représente une distance entre deux points d’une grille et que la
quantité U est approchée en chaque point xi par U(xi) = Ui
, le développement précédent,
tronqué au premier ordre, donne le schéma aux différences finies du premier ordre décentré
en amont suivant :
U
0
i =
Ui+1 − Ui
h
+ O(h). (1.14)
Il est possible de combiner différents développements d’ordres plus élevés pour construire
des schémas d’ordre plus élevés ou approcher des dérivées d’ordres supérieurs. Ces schémas
91. Calcul intensif pour la mécanique des fluides
peuvent être étendus pour l’approximation de variables multidimensionnelles, puis à la
discrétisation de dérivées partielles. Le cas des grilles non uniformes se traite en prenant un
paramètre h dépendant de la grille. Au point d’indice i, on a hi = xi+1 − xi
.
Ainsi la méthode conduit à un calcul relativement simple à mettre en œuvre, dans les cas
explicites, avec un schéma identique sur chaque point du domaine. Dans les cas implicites,
il est nécessaire de résoudre un système linéaire. L’inconvénient majeur de cette méthode
est la difficulté de prise en compte de géométries complexes.
Volumes finis La méthode des volumes finis, est aujourd’hui très largement utilisée,
notamment par les industriels dans les domaines de l’aéronautique et de l’hydrodynamique.
Cette popularité vient, entre autres, du fait que le caractère conservatif des équations est
traduit directement dans la discrétisation. De plus cette méthode s’adapte parfaitement à
de nombreux problèmes qu’ils soient en domaines fermés ou ouvert et sur des discrétisation
spatiales structurées ou non.
Cette méthode permet de résoudre une équation de conservation, sous forme intégrale :
∂
∂t Z
Ω
UdΩ + I
S
F · dS =
Z
Ω
QdΩ, (1.15)
où U représente le vecteur des variables conservatives, F est un flux et Q un terme source.
La discrétisation de ces équations repose sur le découpage du domaine de calcul en petits
volumes de contrôle ΩJ autour d’un point de maillage J. L’équation (1.15) se discrétise
donc sur chaque volume élémentaire par la relation suivante :
∂
∂t (UJΩJ ) + X
Ωk∈ voisins de Ωj
Fk,j · Γk,j = QJΩJ , (1.16)
puis est intégrée entre deux instants consécutifs tn et tn+1. Les quantités UJ et QJ
sont les
valeurs moyennées sur ΩJ à l’instant tn. Ainsi, il est possible d’utiliser un schéma d’inté-
gration en temps implicite ou explicite. L’application de ce schéma nécessite une méthode
de calcul des flux Fk,j traversant la face Γk,j commune aux éléments de maillage Ωj et Ωk.
En plus du calcul des flux en chaque face du maillage, la méthode nécessite un calcul
direct, dans le cas explicite en temps, ou la résolution d’un système, pour le cas implicite.
Le principal inconvénient de cette méthode est la difficulté de la montée en ordre.
Éléments finis La méthode des éléments finis est issue du domaine de la mécanique des
structures. Elle repose sur des principes bien plus abstraits que ceux des deux méthodes
précédentes. L’espace est discrétisé en un ensemble de cellules appelés éléments et se base
sur une formulation intégrale du problème.
Le point clé de la méthode consiste à exprimer le problème sous forme variationnelle,
à partir de sa formulation intégrale. Cette formulation variationnelle du problème fait intervenir
des espaces fonctionnels qu’il est nécessaire de décrire avec précision ainsi que les
normes qui leur sont associées afin de pouvoir déterminer certaines propriétés de convergence.
Les espaces fonctionnels utilisés définissent des classes d’éléments finis sur les élé-
ments de maillage. À partir de ce maillage, le plus souvent non structuré, il est nécessaire de
101.1. Mécanique des fluides numérique
définir des fonctions d’interpolation des variables du problème sur les éléments du maillage.
La discrétisation de la formulation variationnelle sur ces éléments conduit à l’obtention
d’un système linéaire creux dont la taille dépend de la finesse du maillage. L’approximation
d’une quantité u sur un élément se fait par combinaison linéaire des fonctions de base vI
pour chaque nœud I de l’élément.
u˜(x) = X
I
uIvI (x). (1.17)
Selon l’ordre d’approximation, les nœuds sont définis aux sommets, sur les arrêtes ou encore
à l’intérieur des éléments du maillage.
Une fois la discrétisation effectuée, la solution est calculée par l’inversion d’un système
linéaire dont la taille dépend du nombre d’éléments et du nombre de degrés de libertés associé.
Le cadre mathématique de cette méthode permet de réaliser des études des propriétés
numériques des schémas, une montée en ordre assez aisée ainsi que la prise en compte
de géométries complexes. Toutefois, le système linéaire obtenu, peut parfois être difficile
à résoudre. Pour cela des méthodes itératives avec préconditionnement sont généralement
employées. D’autre part, l’inversion d’un système de grande taille creux n’est pas parallélisable
aisément sans utiliser de méthodes additionnelles, de décomposition de domaine
par exemple. Dans le cas des équations de Navier-Stokes, les variables ne sont pas exprimées
dans les mêmes espaces fonctionnels. L’introduction de contraintes supplémentaires
entre les classes d’éléments finis utilisés pour discrétiser la vitesse et la pression permettent
d’assurer la convergence.
Cette méthode n’est pas la plus adaptée pour la résolution de problèmes dont la physique
est dominée par l’advection. Dans un contexte de mécanique des fluides, elle est utilisée
essentiellement pour des simulations de fluides complexes.
Méthodes spectrales Le principe général des méthodes spectrales est de transformer
l’ensemble du problème dans un espace spectral. Pour ce faire, on exprime les variables du
problème dans cet espace, par exemple en séries de Fourier tronquées :
u(x, t) = X
N/2
k=−N/2
uˆk(t)e
ik·x
,
avec uˆk(t) les coefficients de Fourier tels que :
uˆk(t) =
1
2π
3 Z 2π
0
u(x, t)e
−ik·xdx.
Avec ces représentations, le système d’équations à résoudre se réécrit pour les uˆk. On aboutit
généralement à un système d’équations différentielles ordinaires complexes ne dépendant que
du temps. Les équations dans l’espace spectral sont généralement plus simples à résoudre que
dans l’espace réel et permettent une précision numérique très importante même avec un petit
nombre de coefficients. Néanmoins, il est assez difficile de traiter, avec cette méthodes, des
domaines non périodiques ainsi que des géométries complexes. De plus, les transformations
dans l’espace spectral impliquent un calcul global sur l’ensemble du domaine.
111. Calcul intensif pour la mécanique des fluides
L’utilisation de méthodes spectrales nécessite quelques précisions quant à leur mise en
œuvre sur des équations non linéaires. En effet, un produit de fonctions ou des termes
non linéaires dans l’espace réel conduisent à des opérations de type convolution en espace
complexe. Dans le cas discret, une erreur d’aliasing apparaît lors du calcul de ces termes
de manière directe. Il existe différentes techniques de suppression de cette erreur. La règle
des 3/2 est couramment utilisée et son principe est de réaliser les transformées de Fourier
discrètes sur M points au lieu de N, avec M > 3N/2. Les coefficients de Fourier des termes
du produit de convolution pour des nombres d’ondes supérieurs à N/2 sont simplement pris
égaux à zéro. De même, le résultat est tronqué aux N premiers coefficients permettant, par
transformée inverse, d’obtenir les valeurs réelles. En 3D, des erreurs d’aliasing doubles et
triples sont corrigées par des des troncatures adaptées (Canuto et al., 1987).
Méthodes de Lattice Boltzmann
Cette classe de méthode n’est pas basée sur la résolution des équations de Navier-Stokes
mais sur une équation de Boltzmann qui modélise l’évolution cinétique de particules de
fluide (Chen et al., 1998). La méthode de Lattice Boltzmann dérive d’un modèle discret
de dynamique particulaire sur une grille qui peut être vu comme un automate cellulaire
(Lattice gaz method). Le principe de base de cette méthode est de modéliser l’évolution
d’une fonction de distribution de la vitesse des particules f en fonction d’un opérateur de
collision Ω pour les interactions entre particules :
fi(x + ei
, t + ∆t) = fi(x, t) + Ωi(f(x, t)). (1.18)
Cette équation est donnée pour chaque direction i de la grille utilisée. La figure 1.1 représente
les vecteurs ei utilisés dans des grilles courantes. La notation DxQy est employée
pour référencer ces grilles où x est la dimension de l’espace et y le nombre de vecteurs ei
considérés.
(a) Grille D2Q9 (b) Grille D3Q15
Figure 1.1. – Exemple de grilles pour la méthode Lattice Boltzman
Les grandeurs macroscopiques de l’écoulement sont retrouvées à partir des moments de
f :
ρ =
X
i
fi et ρu =
X
i
fiei
.
Dans le cas le plus simple, un modèle de collision de Bhatnagar-Gross-Krook (BGK)
permet d’exprimer Ωi comme une relaxation vers une distribution à l’équilibre f
eq
i
en un
temps caractéristique τ :
Ωi =
f
eq
i − fi
τ
,
121.1. Mécanique des fluides numérique
avec :
f
eq
i = ρwi
1 + 3ei
· u +
9
2
(ei
· u)
2 −
3
2
u
2
, (1.19)
où les wi sont des poids associés à chaque direction ei
.
Le schéma numérique obtenu est local et la mise en œuvre est généralement réalisée en
deux étapes. Dans un premier temps, le membre de droite de l’équation (1.18) est évalué
avec le modèle de collision (1.19). Dans un second temps, l’équation (1.18) est résolue dans
une étape de propagation des fonctions de distribution.
Méthodes Lagrangiennes
De manière générale, les méthodes Lagrangiennes sont adaptées à la résolution d’équations
de conservation de la forme :
d
dt
Z
Ω
U(x, t)dx =
Z
Ω
F(x, t, U, ∇U, . . .)dx. (1.20)
Elles se distinguent des méthodes Eulériennes par le fait que la discrétisation spatiale du
domaine de calcul par un ensemble de particules suit la dynamique du système contrairement
au cadre Eulérien où le maillage reste fixe. On définit la dérivée Lagrangienne d’une fonction
f à partir de la trajectoire d’un point de l’écoulement.
Df
Dt
(x(t), t) = ∂f
∂t (x, t) + dx
dt
· ∇f(x, t)
=
∂f
∂t (x, t) + (u · ∇)f(x, t)
(1.21)
Dans un cadre Lagrangien, les variables sont discrétisées sur un ensemble de particules
qui correspondent à un volume élémentaire du domaine. Le principe général est que les
particules portent des quantités correspondant aux variables du problème. Une quantité U
est ainsi approchée par l’ensemble des particules selon la formule :
U(x) = Z
Ω
U(y)δ(x − y)dy, (1.22)
ou sa forme discrète régularisée :
U(x) '
X
p
UpWε(x − xp). (1.23)
La quantité portée par la particule p, est donnée par sa valeur moyenne :
vpUp =
Z
Vp
U(x)dx,
sur le volume Vp. La fonction Wε, qui apparaît dans l’équation (1.23) est une fonction de
régularisation dont le choix et les propriétés sont propres à chaque méthode. Dans tous les
cas, elle est construite de telle sorte que sa limite quand ε tend vers 0 soit la mesure de
Dirac δ.
131. Calcul intensif pour la mécanique des fluides
Au cours de la résolution, les particules sont déplacées relativement au champ de vitesse
puis interagissent pour donner une nouvelle répartition des quantités transportées qui
conduisent à un nouveau champ de vitesse. La position de chaque particule, xp, est solution
d’une équation de mouvement :
dxp
dt
= u(xp, t). (1.24)
D’autre part, la discrétisation de l’équation (1.20) donne le système d’équations différentielles
:
dUp
dt
= vpFp, (1.25)
où Fp représente le terme source local à la particule p. La difficulté de ces méthodes réside
dans le calcul du second membre de cette équation, en particulier le terme Fp, à partir des
particules. Différentes approches sont possible et conduisent à des méthodes comme SPH
et Vortex, détaillées plus loin. Enfin, le volume des particules varie selon l’équation :
dvp
dt
= vp div u(xp). (1.26)
Une propriété remarquable des méthodes particulaires est que la stabilité du schéma
numérique ne dépend pas explicitement du maillage ou de la distance entre deux particules
contrairement aux méthodes Eulériennes dont le pas de temps est contraint par une condition
de Courant Friedrichs Lewy, notée CF L, dont la constante C est souvent inférieure à
1.
CF L =
∆t||u||∞
∆x
6 C (1.27)
Dans le cas des méthodes particulaires, la contrainte sur le pas de temps dépend du gradient
du champ de vitesse et consiste en l’inégalité suivante :
LCF L = ∆t||∇u||∞ 6 C (1.28)
En pratique, la constante C, appelée quelquefois nombre LCFL (pour Lagrangian CFL),
conduit à une condition moins restrictive que la condition de CFL (1.27). Cela permet géné-
ralement d’utiliser de plus grands pas de temps que dans le cas d’une méthode Eulérienne,
le nombre de CFL obtenu peut alors atteindre des valeurs de plusieurs dizaines.
Méthode SPH Dans la méthode Smoothed Particle Hydrodynamics (SPH), les dérivées
spatiales des variables sont calculées sur les particules à partir d’une régularisation de la
mesure de Dirac, à l’aide d’un noyau Wε. Pour tendre vers la mesure de Dirac lorsque ε
tend vers 0, la fonction Wε est construite à partir d’une fonction d’intégrale égale à 1, à
symétrie radiale et à support compact de rayon supérieur à ε (Liu et al., 2010). Enfin le
noyau Wε doit être suffisamment régulier pour approcher les dérivées spatiales des variables
intervenant dans le calcul des forces.
Le principe suppose qu’en plus de l’équation d’approximation (1.23), on dispose d’approximations
des dérivées obtenues à partir des dérivées de Wε :
∇U(xi) '
X
p
U(xp)∇Wε(xi − yp
)vp. (1.29)
141.1. Mécanique des fluides numérique
Ainsi, avec un schéma d’intégration en temps explicite et une discrétisation du membre
de droite de l’équation (1.20), on obtient le schéma de résolution globale. Les sommes dans
les équations (1.23) et (1.29) impliquent des interactions entre toutes les paires de particules.
Cependant, la compacité du support de la fonction Wε permet de ne considérer que les
particules les plus proches du point de calcul courant à l’aide d’un tri des particules. Les
particules dont le support du noyau d’interpolation intersecte le bord du domaine nécessitent
un traitement particulier en fonction des conditions limites. L’inconvénient majeur de cette
méthode est la difficile montée en ordre du schéma de résolution.
Méthode vortex La méthode vortex est une méthode Lagrangienne adaptée à la résolution
des équations de Navier-Stokes en formulation vitesse et vorticité (1.11). Les particules
portent alors la vorticité de l’écoulement, selon l’approximation (1.23) :
ω(x) = X
p
ωpWε(x − xp). (1.30)
La méthode développée par Chorin (1973) et Leonard (1980) conduit à résoudre le système
d’équations différentielles suivant :
dxp
dt
= u(xp), (1.31a)
dωp
dt
= ωp∇u(xp) + ν∆ω(xp). (1.31b)
Le champ de vitesse est alors obtenu en résolvant l’équation de Poisson (1.12) en fonction
de la vorticité portée par les particules :
u(x) = u∞ +
Z
Ω
Kε(x − y)ω(y)dy. (1.32)
Le noyau Kε est une régularisation d’un noyau obtenu par le rotationnel de la solution
fondamentale de l’équation de poisson. Ce noyau s’exprime comme la convolution de la
fonction de Green pour l’opérateur laplacien et du champ de vorticité. D’autre part, le
gradient du champ de vitesse est obtenu par :
∇u(x) = Z
Ω
∇Kε(x − y)ω(y)dy.
Différentes techniques peuvent être employées pour discrétiser le terme de diffusion des
équations (1.31). Nous pouvons citer par exemple la méthode de marche aléatoire, Randomwalk,
introduite par Chorin (1973) ou encore la méthode PSE, Particle Strength Exchange
par Degond et al. (1989) et Cottet et al. (1990).
La discrétisation du terme d’étirement au second membre de l’équation (1.31b) et de
l’équation de Poisson par une équation de Biot-Savart (1.32) nécessitent l’évaluation d’interactions
entre toutes les paires de particules, ce qui engendre une complexité en O(N2
)
pour N particules. Une complexité en O(N) est possible en utilisation une méthode FMM
(Fast Multipole Method). Cette dernière consiste en un algorithme hiérarchique, basé sur
un arbre, permettant de traiter des problèmes à N corps par une approximation des interactions
combinant des développement locaux et multipôles du noyau Kε (Cheng et al.,
1999).
151. Calcul intensif pour la mécanique des fluides
Méthode particulaire avec remaillage Cette méthode faisant l’objet du chapitre 2,
nous donnons ici uniquement l’idée générale de la méthode. Le remaillage est employé dans
les méthodes particulaire, en particulier les méthodes Vortex, et consiste en une redistribution
des particules sur une grille (Koumoutsakos et al., 1995). Il permet d’assurer le recouvrement
nécessaire au maintient des propriétés de convergence de la méthode. La méthode
obtenue lorsque le remaillage est effectué systématiquement à chaque itération s’apparente
à une méthode semi-Lagrangienne explicite. Ainsi, après une advection des particules de
manière Lagrangienne, une étape de remaillage permet de redistribuer les quantités portées
par les particules sur une grille sous-jacente. Enfin les termes d’étirement et de diffusion
ainsi que l’équation de Poisson peuvent être résolus sur cette grille.
Qualité des résultats numériques
Toutes ces méthodes de résolution reposent sur une approximation numérique des variables
et des équations. Le principe commun est de discrétiser le domaine de calcul en
divers éléments : grille, maillage ou particules. Dans tous les cas, la solution est donnée sur
ces éléments discrets. Ainsi, l’augmentation du nombre d’éléments conduit à un meilleur
niveau de détail de la solution. Une discrétisation temporelle plus fine permet également
une meilleure description de la solution. Cependant, les pas de temps sont généralement
choisis les plus grands possibles tout en veillant à préserver la stabilité du schéma.
D’autre part, la plupart des méthodes permettent une estimation de l’erreur d’approximation
des équations par le schéma numérique. Cette erreur s’exprime généralement en
fonction des résolutions spatiales et temporelles de la discrétisation. En contrepartie de
l’amélioration de la précision et du niveau de détail des solutions, le coût de calcul augmente
avec la résolution. Ce coût provient du nombre d’opérations arithmétiques à réaliser
mais aussi du stockage et de l’accès aux données. En pratique, l’obtention de résultats pour
une résolution plus fine permet généralement une plus grande précision dans la prise en
compte des phénomènes physiques, ce qui contribue à une meilleure compréhension des
mécanismes mis en jeu.
La conséquence de ce phénomène est que les ressources informatiques nécessaires à un
raffinement des solutions numériques deviennent importantes et que les stratégies mises en
œuvre pour l’implémentation des méthodes ont un impact direct sur cette augmentation de
qualité numérique.
1.1.3. Exemples d’application
Dans ce paragraphe nous donnons quelques exemples d’implémentation des méthodes
décrites précédemment dans un contexte de calcul à haute performance. L’objectif est simplement
d’illustrer comment sont employées les différentes méthodes numériques à travers
les quantités de ressources de calcul nécessaires.
Récemment, une méthode de volumes finis a été implémentée par Rossinelli et al. (2013)
pour la simulation de la coalescence de 15 000 bulles de vapeur. Les auteurs ont réalisé
des simulations allant jusqu’à 13.1012 points de calcul en utilisant 1,6 millions de cœurs
CPU. Les performances obtenues sont, en partie, dues à l’utilisation de schémas numériques
161.2. Calcul intensif
d’ordre élevés en espace ce qui conduit à un nombre d’opérations par itérations élevé. Les
auteurs emploient également des techniques permettant d’augmenter la localité des données
ainsi que des opérations vectorisées spécifiques à la machine utilisée.
L’écoulement autour d’un modèle complet de voiture a été étudié par Jansson et al.
(2011) en utilisant une méthode de résolution par éléments finis. Le domaine de calcul est
discrétisé par 4,5 millions de points et 24 millions d’éléments et les solutions sont obtenues
en utilisant 3 000 cœurs CPU. Cette étude montre que les résultats obtenus par une
méthode par éléments finis associée à simulation aux larges échelles adaptative et à un raf-
finement automatique de maillage sont comparables, voire meilleurs, que certains modèles
de turbulence.
Enfin, une comparaison de méthodes spectrales et vortex est réalisée par Yokota et al.
(2013) sur 4 000 cartes graphique pour des résolutions de 69 milliards de particules ou points
de calcul dans le cadre de simulations de turbulence homogène. Dans cet article, les auteurs
montrent les limites des méthodes spectrales lors de l’utilisation d’un très grand nombre
de cartes graphiques. En particulier, les opérations non locales des transformées de Fourier
engendrent un coût de communication très important, ce qui n’est pas le cas en utilisant une
méthode multipôle rapide (Fast Multipole Method). Ainsi, l’étude montre que la méthode
FMM permet d’atteindre une efficacité parallèle bien meilleure que les méthodes spectrales
sur plusieurs milliers de cartes graphiques.
Ces études montrent l’importance d’une bonne exploitation des ressources informatiques.
En général, les méthodes numériques ne sont pas directement adaptées à de grandes machines
de calcul car les coûts de communication deviennent prohibitifs. Ainsi, il est nécessaire
de prendre en compte ces architectures au niveau de la méthode numérique développée.
L’implémentation de méthodes numériques, nécessaire à la résolution de nombreux problèmes
physiques, est indissociable des ressources informatiques disponibles. En particulier
lorsque les applications considérées nécessitent un haut niveau de détail des solutions, ce
qui implique un coût de calcul élevé.
1.2. Calcul intensif
Le calcul intensif est un domaine de l’informatique qui consiste à utiliser des supercalculateurs
pour des applications relevant généralement du calcul scientifique. L’objectif est
d’exploiter au maximum de leurs performances l’ensemble des ressources disponibles pour
obtenir la solution d’un problème numérique.
On distingue deux contextes d’utilisation intensive des ressources de calcul. Le premier,
que nous considérerons par la suite, consiste à résoudre un seul problème sur un ensemble
de ressources d’une machine de calcul. Dans ce cas, la méthode numérique employée est
distribuée sur les éléments de calculs de manière collaborative, ce qui implique des communications
entre les éléments. Une machine de calcul est constituée de différents niveaux
hiérarchiques de ressources. Elle est composée de nœuds de calcul interconnectés sur lesquels
est installé un système d’exploitation. Un nœud comprend généralement de la mémoire vive,
un disque local, des processeurs et éventuellement des accélérateurs, coprocesseurs ou cartes
graphiques. Ces ressources sont partagées par les différents processeurs multicœurs. Les uti-
171. Calcul intensif pour la mécanique des fluides
lisateurs se partagent la machine et peuvent réserver des ressources selon leurs besoins par
l’intermédiaire d’un gestionnaire de ressources.
D’un autre côté, pour des calculs d’optimisation, des études de sensibilité par rapport
à des paramètres ou des calculs de quantification d’incertitudes, le problème initial est de
taille relativement modeste mais il doit être résolu un très grand nombre de fois à partir
de données initiales différentes . Pour cela, des grilles de calcul sont utilisées, comme
par exemple dans le projet Folding@home de l’Université de Standford. Dans ce cadre, un
réseau composé d’un très grand nombre de machines grand public est constitué à travers
Internet par les utilisateurs volontaires et est en perpétuelle évolution au gré des connexions
et déconnexions des utilisateurs. Les différentes exécutions sont indépendantes et ne nécessitent
pas de communications entre elles. Une des difficultés techniques rencontrées dans
ce contexte est que les machines présentent de très nombreuses caractéristiques différentes
notamment en termes de matériels et de systèmes d’exploitation.
1.2.1. Augmentation des besoin et des ressources de calcul
Ressources de calcul pour les simulations numériques
Comme nous l’avons vu en section 1.1.2, l’obtention de nouveaux résultats physiques
permettant une meilleure compréhension des phénomènes se fait par une amélioration de
la précision et du niveau de détail des résultats numériques. Pour la plupart des méthodes
cela implique une complexité plus grande aussi bien en terme de calcul qu’en terme de
quantité de données. Le temps de calcul est directement lié à cette complexité et augmente
rapidement avec la résolution. C’est pourquoi il est nécessaire, pour rendre réalisable cette
augmentation, que le temps de calcul soit le plus faible possible.
Par exemple, lorsque l’on souhaite simplement doubler la résolution dans toutes les
directions spatiales d’un problème tridimensionnel, on obtient un facteur 8 sur le nombre
total d’éléments. Ce qui implique un facteur au moins égal à 8 sur l’empreinte mémoire du
code. De même, la complexité algorithmique du code est multipliée par un facteur 8, 16 ou
64 selon que la complexité s’exprime en O(N), O(N ln(N)) ou O(N2
). Cela implique que
le coût total de calcul devient rapidement assez élevé et justifie le recours à des techniques
de parallélisation mises en places dans le cadre du calcul intensif.
Deux points de vue sont envisageables. D’une part, pour un problème donné, l’augmentation
des ressources allouées à sa résolution permettent de réduire le temps nécessaire à
l’obtention de la solution. D’autre part, à temps de calcul constant, une solution plus précise
est obtenue en augmentant conjointement les ressources et la taille du problème.
Augmentation de la puissance de calcul des machines
Loi de Moore Une caractéristique marquante de l’évolution de l’informatique est la loi
de Moore, énoncée en 1965 par un des cofondateur d’Intel, G. Moore. En considérant la
complexité de fabrication des circuits intégrés ainsi que leur coût en fonction du nombre de
transistors, Moore postule que le nombre de transistors par puce double chaque année. Il
observe par la suite, en 2005, que cette croissance est légèrement plus faible mais tout de
181.2. Calcul intensif
même exponentielle. Nous illustrons cette loi en figure 1.2 où le nombre de transistors par
processeur en fonction des dates de mise sur le marché suit une tendance exponentielle. Il
103
104
105
106
107
108
109
1010
1970 1975 1980 1985 1990 1995 2000 2005 2010 2015
Nombre de transistors par puce
Année de mise sur le marché
CPU
GPU
Tendance : 1.4
x
Tendance : 1.6
x
Figure 1.2. – Évolution du nombre de transistors par processeurs.
est à noter que les processeurs graphiques suivent également une tendance similaire.
Top500 Depuis 1993, le projet Top500 établit un classement mondial des 500 machines
les plus performantes. La figure 1.3 montre l’évolution de la puissance de calcul théorique
développée par ces machines. Sur cette figure sont représentés les machines de rang 1 et
500 ainsi que quelques composants introduits sur le marché en 2012 et 2013. Ces courbes
conduisent à deux remarques : en 8 ans, une machine donnée passe de la première à la
dernière place du classement ; sur la même durée, la puissance totale de la dernière machine
du classement est disponible en un seul composant sur le marché grand public. Ainsi, une
machine de bureau standard récente dispose de la puissance de calcul de la première machine
du classement il y a 20 ans.
La tendance de ces courbes laisse suggérer que le régime de l’exascale sera vraisemblablement
atteint d’ici 2020 (Shalf et al., 2010 ; Dongarra et al., 2011 et 2014). Il correspond
à la construction et à l’exploitation de systèmes capables d’exécuter 109 GFLOPS. C’est un
défi majeur dans la communauté du calcul haute performance. Dans les années 90, l’augmentation
de la puissance des machines était principalement due à l’augmentation de la
fréquence des processeurs et à la diminution de leurs taille. Ce mécanisme a atteint ses
limites principalement à cause d’une trop forte densité d’énergie dans les composants. Par
la suite, seule l’augmentation du nombre de processeurs par machine a permis de poursuivre
cette évolution. Désormais, la tendance serait plutôt à l’augmentation du nombre de cœurs
par processeurs comme c’est le cas, entre autres, avec les cartes graphiques et la dernière
génération de processeurs Intel Xeon Phi.
191. Calcul intensif pour la mécanique des fluides
10−1
100
101
102
103
104
105
106
107
108
109
1993 1995 1997 1999 2001 2003 2005 2007 2009 2011 2013 2015
Petascale
Exascale
8 ans 8 ans
8 ans 12 ans
8 ans
Puissance théorique (GFLOPS)
Année de publication
Top500 #1
Top500 #500
GPU
Coprocesseur
CPU
Machine standard
Figure 1.3. – Évolution du classement du TOP500
Difficulté d’adaptation des codes de calcul
Le détail des caractéristiques des machines du Top500 montre une hétérogénéité de composants
depuis ces dernières années. En effet, bon nombre de machines de ce classement
ne contiennent pas seulement des processeurs mais aussi des accélérateurs, que ce soit des
cartes graphiques ou des coprocesseur. La difficulté majeure de l’exploitation de ces élé-
ments est que le développement et l’optimisation des codes de calculs ne fait pas appel aux
mêmes techniques que sur une machine homogène. De plus, les techniques de programmation
sont parfois différentes entre les processeurs et les accélérateurs. Ce qui implique une
réécriture du code. D’autre part, la réutilisation d’un code sur une architecture plus récente
conduit parfois à des temps de calculs plus grands dans les cas où aucune adaptation n’est
réalisée. Ce travail est assez lourd et ne peut pas être réalisé pour chaque nouvelle architecture.
Toutefois, cette difficulté est atténuée par l’utilisation de langages portables pour
le développement de codes multiarchitectures.
1.2.2. Mesure de performances
Dans le cadre du calcul intensif, il est important de pouvoir comparer les différentes implémentations
et codes de calculs et d’en mesurer les performances. Pour cela des métriques
spécifiques sont utilisées.
La première métrique utilisée est la puissance brute développée par un algorithme. Cette
grandeur est exprimée par le nombre d’opérations sur des nombres réels à virgules flottante
réalisées par secondes d’exécution. On utilisera la notation FLOPS pour désigner cette unité,
également notée FLOP s−1 dans la littérature. Cette mesure est notamment utilisée pour
établir le classement du Top500, En pratique, le nombre d’opérations effectuées lors d’une
201.2. Calcul intensif
exécution peut être obtenu par un outil de profilage et dépend fortement du compilateur,
des options de compilations employées ainsi que de l’architecture utilisée.
Scalabilité
Scalabilité forte Lors de la parallélisation d’un code, la performance maximale atteignable
est bornée par la loi d’Amdahl donnée par Rodgers (1985). L’accélération maximale
dépend de la proportion de code parallélisable, notée p ∈ [0; 1]. Le temps de calcul total,
pour un problème de taille fixe, sur n processeurs Tn est donné en fonction du temps de
calcul séquentiel T1 par : Tn = T1(1−p+p/n). Le facteur d’accélération, Sn, égal au rapport
entre le temps de calcul sur n processeurs et le temps de calcul sur un seul processeur est
alors donné par l’expression :
Sn =
T1
Tn
=
1
1 − p + p/n < n. (1.33)
On remarque que lorsque le nombre de processeurs devient grand, le rapport tend vers
(1 − p)
−1
. Cela signifie que l’accélération maximale, lorsque la partie parallélisable devient
négligeable, est bornée par la partie non parallélisable du code. De manière optimale, pour
p = 1, on attend que le facteur d’accélération du code soit égal au nombre de processeurs.
La performance d’un code peut être mesurée en réalisant une étude de scalabilité forte. Il
s’agit d’étudier l’évolution du facteur d’accélération du code pour un problème de taille fixe
en faisant augmenter les ressources employées à la résolution. Généralement, ces résultats
sont présentés sur un graphe donnant le rapport T1/Tn en fonction de n. Une scalabilité
idéale conduit à l’obtention d’une droite de pente égale à 1.
Scalabilité faible On peut également considérer l’évolution du facteur d’accélération
lorsque l’augmentation des ressources est réalisée simultanément avec une augmentation de
la taille des données du problème. Dans ce cas, la loi de Gustafson-Barsis (Gustafson, 1988)
conduit à une décomposition du temps de calcul sur n processeurs en une partie séquentielle
ts et une partie parallèle tp, Tn = ts + tp. Ainsi, le temps de calcul de ce problème sur un
seul processeur est égal à T
(n)
1 = ts + ntp et le facteur d’accélération est donné par :
Sn =
T
(n)
1
Tn
= n −
ts
ts + tp
(n − 1) (1.34)
De même que précédemment, on représente Sn en fonction de n dans un graphe. Dans
le cadre d’une étude de scalabilité faible, à chaque Sn correspond une taille de problème
contrairement à la scalabilité forte où l’étude complète est réalisée pour une même taille de
problème. Dans le cas idéal, le temps de calcul est entièrement dédié à la partie parallèle,
ts = 0, on obtient une droite de pente 1.
Le temps de calcul séquentiel du problème associé à n processeur, T
(n)
1
, peut parfois
devenir prohibitif et même impossible à obtenir lorsque n est grand. Pour cela, on pose
l’hypothèse que ce temps est proportionnel au temps de calcul séquentiel du problème
unitaire T
(n)
1 = nT(1)
1
. On représente alors le facteur d’accélération par :
S˜
n =
T
(1)
1
Tn
=
T
(n)
1
nTn
= 1 −
ts(n − 1)
n(ts + tp)
. (1.35)
211. Calcul intensif pour la mécanique des fluides
Modèle roofline
Les architectures multicœurs se caractérisent par le partage d’une mémoire entre les
différents cœurs dans lesquelles la bande passante est parfois un facteur limitant les performances.
Le modèle roofline, introduit par Williams et al. en 2009, est un modèle de visualisation
de performances basé sur l’intensité opérationnelle d’une implémentation. Cette
grandeur est définie comme le nombre d’opérations en virgule flottante par Byte de donnée
transférée entre les unités de calcul et la mémoire globale. La quantité de données échangées
entre les unités de calculs et la mémoire du système est constituée des accès en lecture
et écriture. Ce modèle permet de représenter graphiquement les performances de calcul
en fonction de l’intensité opérationnelle. Le graphe, en échelle logarithmique, présente la
performance atteignable en fonction de l’intensité opérationnelle selon la formule :
P
A = min(P, B × I), (1.36)
avec P
A la puissance atteignable en GFLOPS, P la puissance crête théorique de la machine,
également en GFLOPS, B la bande passante théorique en GByte/s et I l’intensité
opérationnelle du code en FLOP/Byte. L’intensité opérationnelle dépend de la machine et
du code et peut être calculée à partir des compteurs présents dans le matériel et éventuellement
accessibles via un outil de profilage. Dans certains cas, il est possible d’approcher cette
intensité par un comptage des opérations du code. Le modèle conduit à la représentation
donnée en exemple en figure 1.4.
On détermine si une implémentation est bornée par la bande passante, comme pour
l’intensité IA, ou par la puissance de calcul théorique, comme pour IB. Cela donne une
borne de performance maximale atteignable pour une implémentation donnée. Une première
stratégie d’optimisation pour un algorithme donné consiste à se déplacer vers une
intensité opérationnelle plus grande, flèches horizontales sur la figure 1.4. Elle consiste en
une optimisation de l’implémentation pour limiter les accès à la mémoire globale afin de
maximiser la puissance atteignable. La seconde stratégie consiste à optimiser le code pour
diminuer le temps de calcul. En effet, la performance atteinte lors d’une exécution correspond
à un point sur le graphe. Visuellement, les optimisations visent à déplacer ce point
vers la borne théorique le long d’une demi-droite correspondant à l’intensité opérationnelle
de l’implémentation évaluée. Cette seconde stratégie est représentée par les flèches verticales
sur la figure 1.4.
Efficacité énergétique
Dans le cadre de l’étude de l’impact environnemental des machines, la puissance de
calcul est mise en regard de la consommation électrique. En particulier, depuis fin 2007, le
classement du Green500 ordonne les éléments du Top500 en fonction de leur performance
énergétique qui est exprimée en MFLOPS par watt consommé au cours d’un calcul. La
figure 1.5 donne l’évolution des machines de rang 1 et 500 du classement Green500 ainsi
que, à titre de comparaison, du Top500.
La figure 1.6 représente les 150 premières machines des classements du Top500 et
Green500 par groupes de couleurs selon le type d’accélérateurs ou selon l’architecture.
Comme le montre Subramaniam et al. (2013), dans leur analyse de la consommation énergétique
des super-calculateurs l’utilisation d’accélérateurs graphiques, GPU, ou de coprocesseurs
semble contribuer fortement à l’amélioration de l’efficacité énergétique. À titre de
221.2. Calcul intensif
0.1
1
10
100
1000
0.1 IA 1 IA0 10 IB 100
Borne calcul
Borne bande passante
Puissance atteignable (GFLOPS)
Intensité opérationnelle (FLOP/Byte)
Roofline
Figure 1.4. – Exemple de modèle roofline.
100
101
102
103
104
2007 2008 2009 2010 2011 2012 2013 2014 2015
Efficacité énergétique (MFLOPS/W)
Date de publication des classements
Green500 - #1
Green500 - #500
Top500 - #1
Top500 - #500
Figure 1.5. – Évolution de l’efficacité énergétique des machines.
231. Calcul intensif pour la mécanique des fluides
comparaison, les ordres de grandeurs de puissance consommée sont illustrés par des maté-
riels usuels.
Le code de couleurs utilisé sur la figure 1.6 permet de distinguer quatre types d’architecture.
L’architecture classique correspond à une machine constituée de processeurs
multicœurs traditionnels et ne contenant aucun accélérateur. L’architecture BlueGene se
distingue de la précédente par un nombre bien plus grand de processeurs, par une faible
fréquence des processeurs et une faible quantité de mémoire des nœuds. Ces deux dernières
caractéristiques permettent à ce type de machine d’être extrêmement efficace en termes de
performance énergétique. Les machines dotées de coprocesseurs représentées sur la figure 1.6
sont constituées de processeurs multicœurs Xéon Phi comportant jusqu’à 61 cœurs de calcul
et qui ont été introduits récemment par Intel. La machine à coprocesseurs la plus efficace
est constituée de processeur PEZY-SC contenant 1 024 cœurs qui sont développés par la
société japonaise PEZY Computing. Enfin, le second type d’accélérateur est représenté par
les GPU dont les caractéristiques seront détaillées dans le chapitre 4.
105
106
107
108
10−1
100
101
20 MW
1 MW
0.1 MW
éolienne
motrice de TGV
voiture
Puissance de calcul (GFLOPS)
Efficacité énergétique (GFLOPS/W)
Top500
Green500
GPU
Coprocesseur
BlueGene
Classique
Figure 1.6. – Comparaison des performances énergétiques des 150 premières machines du
Top500 et Green500 selon le matériel (classements de novembre 2014).
1.2.3. Défi de l’exascale
Pourquoi l’exascale ?
Comme nous l’avons vu précédemment, l’amélioration de la qualité des simulations numériques
nécessite des résolutions plus importantes, afin d’obtenir de nouveaux résultats
pour améliorer la compréhension et la prise en compte de phénomènes physiques. Cela
permet ensuite d’envisager une complexification des modèles physiques puis des modèles
241.2. Calcul intensif
mathématiques et numériques dans le processus itératif schématisé en figure 1. De ce point
de vue, ces simulations ont besoin de ressources de calcul toujours plus importantes. D’autre
part, les classements du Top500 et Green500 nous montrent que la puissance des supercalculateurs
est en augmentation, apportant ainsi une réponse à ces besoins en ressources de
calcul. Cette réponse permet d’envisager la simulation de problèmes physiques encore plus
complexes.
Toutefois, les applications sont encore loin d’exploiter toute la puissance offerte par ces
calculateurs. La littérature ne fait état que de très peu d’applications capables d’atteindre le
PFLOP. Des simulations d’interactions gravitationnelles en astrophysique entre 1012 corps
atteignant 4.45 PFLOPS ont été obtenues par Ishiyama et al. (2012), soit 42% de la puissance
maximale de la machine pour leurs configuration. Plus récemment, une performance
de 11 PFLOPS a été atteinte par Rossinelli et al. (2013) pour la simulation de la coalescence
de 15 000 bulles de vapeur sur 13.1012 points de calcul en utilisant 1.6 millions de cœurs
CPU. Cette performance correspond à 55% de la puissance de la machine. Enfin, 4096 cartes
graphiques ont permis à Yokota et al. (2013) d’atteindre 1.08 PFLOPS en simple précision,
soit 25% de la puissance maximale théorique.
Principales difficultés
Le développement d’applications capables d’exploiter une telle puissance se confronte
à de nouvelles problématiques dont nous reprenons quelques éléments, d’après Dongarra
et al. (2011).
Concurrence L’architecture des machines de l’exascale, basée sur des composants multicœurs
ayant un très grand nombre de cœurs, soulève de nombreuses difficultés quant à
l’utilisation des mécanismes et des algorithmes actuels notamment en terme de synchronisation
des différents processus ou encore d’accès aux données. En effet, les architectures
multicœurs ont la particularité de partager une même mémoire entre l’ensemble des cœurs
ce qui rend complexe l’accès aux données, à travers une hiérarchie de caches, qui ont éventuellement
été modifiées dans le même temps. Leur originalité est qu’elles disposent d’une
quantité de mémoire disponible par cœur de calcul plus faible que dans les architectures
classiques. L’augmentation du nombre de cœurs par processeurs conduit à une diminution
de la mémoire disponible par cœurs.
Les accès à des données distantes, non présentes sur la mémoire associée à un processus,
deviennent rapidement très coûteux pour un très grand nombre de cœurs. Ce qui pose la
question de l’élaboration d’algorithmes de communications et de synchronisations distants
adaptés à ces architectures.
Énergie La consommation énergétique de ces supercalculateurs devient un problème
non seulement au niveau de l’alimentation électrique globale des machines mais aussi du
refroidissement des composants. Une limite de faisabilité d’une consommation de 20 MW
a été proposée dès 2008 par Bergman et al. et détaillée plus récemment par Subramaniam
et al. (2013). Les performances énergétiques des algorithmes commencent à être considérées,
en complément des mesures traditionnelles, notamment à travers le classement Green500
et contribuent à une amélioration des performances énergétiques des machines.
251. Calcul intensif pour la mécanique des fluides
Robustesse Les applications déployées sur des machines exascale devront être robustes
aux pannes. En effet, statistiquement, la probabilité qu’un cœur tombe en panne au cours
de l’exécution d’un programme est non négligeable. Des solutions doivent être développées
afin de s’affranchir de la technique traditionnelle de la sauvegarde de l’état complet d’un
programme à un instant donné en vue d’un redémarrage qui devient impossible à mettre en
place dans un tel environnement. De nombreuses techniques sont développées (Dongarra et
al., 2014) afin de pouvoir, d’une part, détecter les pannes et les erreurs introduites dans les
résultats et, d’autre part, effectuer un redémarrage local des processus en échec en utilisant
les données locales pour reconstruire une solution au moment de la panne. Dans ce contexte
l’exécution devient non reproductible.
Quelques stratégies
Les contraintes de ce passage à l’échelle permettent, par nécessité, de dégager quelques
stratégies au niveaux des algorithmes et des méthodes numériques employées. Ces straté-
gies sont détaillées de manière exhaustive par Dongarra et al. (2014). Les auteurs soulignent
notamment que l’utilisation de modèles couplés, de méthodes d’ordre élevé ou de parallé-
lisation en temps permettent d’aboutir à des implémentations susceptibles de s’adapter à
l’architecture des machines. L’intérêt est de pouvoir introduire des considérations maté-
rielles dès la spécification des méthodes numériques et même au niveau de la modélisation
mathématique du problème. D’autre part, au niveau des algorithmes, l’accent est mis sur
la scalabilité des solveurs, l’utilisation d’algorithmes multiniveaux et de librairies de calcul
existantes pour lesquelles les optimisations par rapport aux architectures auront été
réalisées de manière très pointue.
Le cadre applicatif de la mécanique des fluides s’adapte assez bien aux caractéristiques du
calcul intensif. En effet, à travers une application, nous allons pouvoir employer une méthode
de résolution ayant de bonnes propriétés de parallélisation dans l’optique de l’exploitation
de serveurs de calculs hétérogènes. Le développement et l’implémentation de cette méthode
numérique est réalisé dans le cadre défini par l’application que nous détaillons ci-après.
1.3. Transport de scalaire passif dans un écoulement
turbulent
1.3.1. Domaines d’application
De très nombreux phénomènes physiques sont basés, au moins en partie, sur le transport
d’un ou plusieurs scalaires par un écoulement turbulent. Les scalaires correspondent à des
quantités de diverses natures (Shraiman et al., 2000). Dans le domaine de l’environnement,
le scalaire peut représenter un polluant transporté par l’air ou l’eau (Michioka et al., 2008).
En biologie il peut s’agir de l’évolution des concentrations de certaines molécules chimiques,
comme les phéromones, que de nombreuses espèces utilisent pour communiquer ou se repérer
(Murtis et al., 1992) ou encore la concentration de bactéries et de leur nourriture
(Taylor et al., 2012). Le domaine de l’ingénierie est concerné par de nombreux problèmes
261.3. Transport de scalaire passif dans un écoulement turbulent
de ce type, notamment en combustion. Dans ces problèmes, plusieurs scalaires peuvent
être transportés simultanément comme les différentes concentrations en réactifs chimiques
ou encore la fraction de mélange entre le combustible et l’oxydant (Pitsch et al., 2008). La
température est un autre exemple de quantité scalaire, importante dans l’étude de systèmes
de refroidissements (Kuczaj et al., 2010).
Un transport de scalaire peut également être utilisé comme outil de modélisation. Par
exemple, le transport d’une fonction levelset permet de modéliser les interfaces dans un
fluide multiphasique (Tryggvason et al., 2011) ou un objet en mouvement (Sethian et al.,
2003).
1.3.2. Physique du problème
Généralement, le scalaire a une influence sur l’écoulement dans lequel il est transporté.
Par exemple dans les cas où on considère la densité d’un fluide multiphasique, ou encore
lors du transport de concentrations en réactifs chimiques dans une réaction de combustion.
Dans certaines applications, les effets du scalaire sur l’écoulement deviennent négligeables,
ce qui est le cas dans le transport de petits éléments comme des polluants, molécules ou
colorants. Le scalaire est alors passif dans l’écoulement et n’a pas d’effet rétroactif sur le
fluide.
Dans un écoulement turbulent et indépendemment du transport de scalaire, des structures
de différentes tailles se forment. Des structures de grandes tailles sont créées et entretenues
par l’écoulement. Les fluctuations de ces structures génèrent des structures plus
petites qui elles-mêmes génèrent, en cascade, d’autre structures encore plus fines. Un tel
écoulement se caractérise par une large palette de taille de structures s’étalant sur plusieurs
ordres de grandeur. Cependant, à partir d’une certaine échelle, dite de Kolmogorov, les effets
visqueux du fluide deviennent prédominants et engendrent une dissipation de l’énergie
cinétique de l’écoulement (Lesieur, 2008). La longueur de cette échelle ne dépend que des
caractéristiques du fluide dont notamment la viscosité ν. Ainsi, un écoulement turbulent ne
présente pas de structures de tailles inférieures à la longueur de l’échelle de Kolmogorov,
notée ην. Lors d’une simulation directe, DNS en anglais pour Direct Numerical Simulation,
l’écoulement est résolu à toutes les échelles jusqu’à l’échelle de Kolmogorov. Le maillage doit
avoir une longueur de maille suffisamment petite pour capter les plus petites structures de
l’écoulement. Dans les cas où le maillage ne résout pas toutes les échelles, il est nécessaire
de faire appel à un modèle de turbulence permettant de simuler cette dissipation d’énergie
par les petites échelles non résolues (Lesieur et al., 2005 ; Sagaut, 2006).
La dynamique du scalaire se caractérise par deux phénomènes : une dispersion par
convection du scalaire puis sa diffusion. Le premier effet, induit par le fluide turbulent, a pour
conséquence d’étirer les structures du scalaire, de générer des fluctuations à des échelles de
plus en plus petites et d’amplifier ses concentrations locales. De manière similaire au fluide,
l’échelle de Batchelor, notée ηκ, décrit l’échelle de concentration d’un scalaire à partir de
laquelle la diffusion moléculaire devient prédominante (Batchelor, 1958). Là encore, cette
échelle ne dépend que des caractéristiques du fluide, dont la viscosité et du coefficient de
diffusion, noté κ. Cette diffusion permet une dissipation des variations, localement fortes,
du scalaire.
271. Calcul intensif pour la mécanique des fluides
Le nombre de Schmidt, sans dimension, est défini par le rapport entre la viscosité du
fluide et le coefficient de diffusion du scalaire, Sc = ν/κ. Dans la plupart des fluides, le
nombre de Schmidt est grand, au moins égal à 1. Ce nombre permet de relier les échelles
de dissipation du fluide et du scalaire à travers la relation :
ηκ
√
Sc = ην.
En pratique, l’échelle de Batchelor est donc (beaucoup) plus petite que l’échelle de Kolmogorov.
Cela implique que le transport du scalaire développe des structures plus petites que
les plus petites structures développées par le fluide. Pour de grands nombre de Schmidt,
la dynamique du scalaire est essentiellement donnée par l’advection du scalaire sous l’effet
du fluide. Un cadre théorique décrit l’influence du nombre de Schmidt sur des quantités
statistiques du scalaire. En particulier, la décroissance du spectre de variance du scalaire,
en fonction du nombre d’onde k, est modélisé par une loi de puissance en k
−5/3 qui est associée
au transfert d’énergie en cascade vers les petites échelles. Cette décroissance est suivie
d’une loi en k
−1 puis de la dissipation par les plus petites échelles. Cette lente décroissance
renforce la nécessité d’une résolution des petites échelles de l’écoulement.
1.3.3. Formulation mathématique
Un problème de transport d’un scalaire dans un fluide incompressible turbulent est
modélisé par les équations de Navier-Stokes (1.10) pour la partie fluide et une équation
de convection et diffusion pour le transport du scalaire. Ces deux parties sont liées par le
champ de vitesse. Le problème consiste en le système d’équations suivant, en considérant
une densité ρ = 1 et en l’absence de forces extérieures fe = 0 :
div u = 0,
Du
Dt
=
∂u
∂t + (u · ∇)u
= −∇P + ν∆u,
Dθ
Dt
=
∂θ
∂t + (u · ∇)θ = κ∆θ
(1.37)
Les trois inconnues du problème sont le champ de vitesse u, la pression P et le scalaire
passif θ.
Dans le cadre d’un scalaire actif, l’effet sur l’écoulement est généralement pris en compte
à travers une force fθ présente au second membre de la seconde équation du système. Ici,
à travers le couplage faible entre les deux parties, nous obtenons une décomposition du
problème global en deux sous-problèmes quasi indépendants. En effet, le champ de vitesse
peut être vu simplement comme une donnée d’entrée du problème de transport de scalaire.
Conclusion
À partir d’un même problème mathématique, différentes méthodes numériques peuvent
être envisagées. Le choix de l’une ou l’autre dépend des objectifs visés, des applications
considérées et des architectures de calcul disponibles. Dans ce chapitre, nous avons exposé
281.3. Transport de scalaire passif dans un écoulement turbulent
les grandes lignes des méthodes classiques relativement à la résolution d’un problème de
mécanique des fluides. L’utilisation d’une méthode numérique permet de discrétiser un
problème continu pour en approcher une solution. Leur point commun est que la précision de
la solution dépend de la finesse de la discrétisation et de l’ordre d’approximation du schéma
numérique. Ces deux paramètres ont une forte incidence sur le temps de calcul. Ce dernier
peut rapidement devenir prohibitif en l’absence d’utilisation de techniques de parallélisation
et d’optimisation du code. L’exploitation des machines de calcul, dont l’architecture peut
être fortement hétérogène, dans le cadre du calcul intensif, implique une prise en compte
du matériel et des technologies employées dès la conception des algorithmes. L’importance
de cette prise en compte est encore plus grande lors de l’utilisation d’une grande quantité
de ressources, notamment dans la perspective de l’évolution des machines vers l’exascale.
Le transport d’un scalaire passif par un écoulement turbulent nous conduit à résoudre un
problème, composé de deux parties assez indépendantes, présentant plusieurs échelles. Dans
la suite, nous mettons en place une résolution basée sur différentes méthodes ainsi que des
algorithmes multiéchelles.
292. Méthode particulaire pour
l’équation de transport
Comme nous l’avons exposé dans le chapitre 1, la modélisation du transport d’un scalaire
passif dans un écoulement turbulent s’effectue à l’aide un système d’équations continues
constitué des équations de Navier-Stokes et d’une équation d’advection-diffusion du scalaire.
Ces deux équations présentent une équation de transport, une pour la vorticité et l’autre
pour le scalaire. Parmi les différentes techniques de résolution possibles, ce travail se base
sur le développement d’une méthode semi-Lagrangienne. En effet, elle permet de combiner
les avantages des méthodes Lagrangiennes tout en se basant sur une structure de donnée
régulière. Ainsi, cette méthode nous permet de choisir de grands pas de temps pour la
réalisation de simulations numériques tout en bénéficiant de la régularité des données liée
à la présence de la grille sous-jacente.
Dans une première partie de ce chapitre, nous présenterons un état de l’art des méthodes
particulaires semi-Lagrangiennes. Elles consistent en une méthode Lagrangienne avec une
étape de remaillage systématique à chaque itération permettant de remédier aux éventuels
problèmes de distorsions du champ de particules. Elles se distinguent des méthodes semiLagrangiennes
classiques (backward) par une descente des caractéristiques. Cette méthode
particulaire semi-Lagrangienne (forward) explicite peut être formalisée comme un schéma
aux différences finies à travers le remaillage. Une analyse des schémas ainsi obtenus est possible
en utilisant une approche propre à la méthode des différences finies. Nous présenterons
également les différentes techniques de construction des formules de remaillage ainsi qu’un
exemple d’implémentation.
Dans une seconde partie, nous proposerons une méthode systématique pour obtenir des
méthodes particulaires semi-Lagrangiennes d’ordres élevés. L’augmentation de l’ordre est
obtenu par l’utilisation de formules de remaillage ayant une forte régularité et conservant un
grand nombre de moments. Une nouvelle méthode de construction de ces formules permet
de produire des formules d’ordre arbitraire. Des analyses de stabilité et consistance seront
réalisées pour la méthode semi-Lagrangienne utilisant cette classe de formules de remaillage.
312. Méthode particulaire pour l’équation de transport
2.1. Méthode particulaire avec remaillage
2.1.1. Deux classes de méthodes semi-Lagrangiennes
À l’origine, les méthodes semi-Lagrangiennes ont été développées pour la résolution
d’écoulements dominés par l’advection, essentiellement dans le domaine de la météorologie
(Staniforth et al., 1991). Leur principe général est basé sur l’exploitation des caractéristiques
en chaque point d’une grille et de combiner les avantages des méthodes Eulériennes et Lagrangiennes.
En effet, elles reposent sur le fait que la quantité transportée est invariante le
long des caractéristiques. Dans une méthode semi-Lagrangienne rétrograde classique (backward
semi-Lagrangian method en anglais) la résolution consiste à remonter la trajectoire
depuis un point de grille et interpoler la quantité transportée au point de départ. Le résultat
de l’interpolation donne directement la valeur de la quantité au point de grille considéré.
Une seconde classe dont principe est similaire repose sur une descente des caracté-
ristiques est appelée forward semi-Lagrangian method. Après intégration de l’équation de
mouvement, l’étape de distribution de la quantité transportée sur les points de grille est
réalisée de manière implicite et nécessite la résolution d’un système dont la complexité dé-
pend de la nature de l’interpolation employée. La seule différence se situe dans le traitement
des contributions sur les points de grille. Une comparaison avec la méthode classique a été
proposée par Crouseilles et al. (2009) sur différents modèles d’équations de Vlasov pour la
simulation de plasmas. Nous illustrons les deux classes de méthodes par les figures 2.1.
(a) Backward (b) Forward
Figure 2.1. – Méthodes semi-Lagrangiennes
La méthode particulaire avec remaillage que nous détaillons dans la suite de ce chapitre
est très similaire à la méthode forward mais en utilisant un schéma explicite. Notre méthode
permet facilement de monter en ordre et est conservative.
322.1. Méthode particulaire avec remaillage
2.1.2. Principe général de la méthode particulaire avec
remaillage
Une méthode particulaire permet de résoudre une équation de transport :
∂u
∂t + div(au) = 0, (2.1)
où la quantité u est transportée à vitesse a. Comme nous l’avons évoqué en section 1.1.2,
la quantité u est discrétisée sur un ensemble de particules et est approchée en tout point
de l’espace par l’expression :
u(x) = X
p
upWε(x − xp),
avec up la quantité portée par la particule p, Wε une fonction de régularisation et xp la
position d’une particule. L’évolution des particules est soumise au champ de vitesse de
l’écoulement et leurs trajectoires sont données par les équations :
dxp
dt
= a(xp, t).
La présence d’un éventuel second membre dans l’équation de transport (2.1) se traduit
par une équation d’évolution de la quantité transportée par les particules. Par exemple, pour
une équation de transport de vorticité ω à vitesse u, issue des équations de Navier-Stokes :
∂ω
∂t + u · ∇ω = ω · ∇u + ν∆ω,
le second membre conduit aux équations suivantes :
dωp
dt
= ωp∇u(xp) + ν∆ω(xp).
Un inconvénient bien connu des méthodes particulaires est qu’au cours de l’évolution
de la simulation, les particules ont des trajectoires qui suivent le champ de vitesse. Par
conséquent, il peut arriver que ces particules se retrouvent trop éloignées les unes des autres
ou inversement regroupées dans une petite région du domaine. Ainsi, selon les zones de
l’écoulement, on assiste à une dégradation de la représentation des champs par manque ou
excès de particules. Un contrôle du recouvrement des particules est alors nécessaire pour
assurer de la convergence de la méthode. Dans de nombreuses implémentations de cette
méthode, une redistribution des particules sur une grille est appliquée régulièrement au cours
de la simulation afin de garantir un recouvrement suffisant et les propriétés de consistance
de la méthode (Koumoutsakos et al., 1995). Une méthode semi-Lagrangienne est obtenue
lorsque le remaillage est effectué systématiquement après chaque étape d’advection. Cela
permet également une représentation des variables sur la grille et d’exploiter des méthodes
de décomposition de domaine (Cottet, 1991 ; Ould Salihi et al., 2000 ; Cottet et al., 2000 ;
Cocle et al., 2008), d’adaptation automatique de maillage (Bergdorf et al., 2005) ou de
multirésolution basée sur des ondelettes (Bergdorf et al., 2006). Ainsi, les termes au second
membre des équations de transport peuvent être résolus sur la grille et non sur les particules.
332. Méthode particulaire pour l’équation de transport
Par conséquent, la quantité transportée par les particules est conservée lors de l’advection
car la trajectoire des particules suit les caractéristiques et on a :
dup
dt
= 0.
Ainsi, dans ce type de méthode, les particules sont créées au début de chaque étape d’advection
et sont détruites par le remaillage. En pratique, on ne crée des particules qu’aux
points de grille où la quantité transportée par les particules est supérieure à une certaine valeur
seuil fixée à l’avance. Cela permet d’éviter le traitement, par advection puis remaillage,
de particules dont la quantité transportée est nulle ou négligeable.
Le remaillage consiste en une interpolation des particules sur la grille à l’aide d’un
noyau de remaillage, également appelé formule de remaillage. Le cas multidimensionnel
est généralement traité par produit tensoriel de noyaux monodimensionnels. Cependant,
comme nous le verrons par la suite, ces formules ont généralement un coût arithmétique
élevé en 3D si des noyaux avec un large support sont utilisés. La figure 2.2 illustre une étape
de résolution pour un cas 2D où la taille des disques représente les valeurs portées par les
particules. Après un déplacement des particules selon le champ de vitesse représenté par
les flèches en trait épais sur la figure 2.2b, les particules sont remaillées sur les S points de
grille voisins. Les contributions d’une particule sur les points de grille sont représentées par
des flèches en trait fin. La particule colorée sur la figure 2.2a est répartie dans les valeurs
des points de grille colorés selon la contribution sur la figure 2.2c.
(a) Instant t
n (b) Advection et remaillage (c) Instant t
n+1
Figure 2.2. – Remaillage par produit tensoriel
Magni et al. (2012) proposent une alternative à la résolution multidimensionnelle basée
sur un splitting dimensionnel. Cette méthode permet de découpler les directions spatiales à
travers la résolution de problèmes monodirectionnels en alternant les directions. Le splitting
de Strang, d’ordre deux en temps, conduit à résoudre, pour un problème 2D, une première
direction sur l’intervalle [t
n
;t
n+1/2
[, la seconde direction sur un pas de temps complet et revenir
à la première direction pour terminer l’itération sur [t
n+1/2
;t
n+1[. En trois dimensions,
l’algorithme est identique, toutes les étapes sont réalisées sur des demi pas de temps excepté
la troisième direction. Nous illustrons ce splitting dimensionnel en figure 2.3 en utilisant les
342.1. Méthode particulaire avec remaillage
mêmes conventions que pour l’illustration précédente. Dans un souci de clarté, l’exemple
ne concerne qu’un splitting du premier ordre qui, selon le même principe, consiste en une
alternance des directions pour des pas de temps complets. À chaque étape, une particule est
remaillée seulement sur les S points voisins dans la direction concernée, soit respectivement
3S et 5S contributions par particule pour une itération complète de la formule de Strang
en 2D et en 3D, au lieu de S
2
et S
3 pour un remaillage tensoriel.
(a) Instant t
n (b) Advection et remaillage, direction
X
(c) État intermédiaire
(d) Advection et remaillage, direction
Y
(e) Instant t
n+1
Figure 2.3. – Remaillage par splitting dimensionnel du premier ordre
À travers l’utilisation d’un splitting dimensionnel de Strang, la résolution d’une équation
de transport multidimensionnelle se réduit à une succession de problèmes 1D. Cela permet
d’obtenir un coût de calcul proportionnel au nombre de particules dont la constante multiplicative
dépend uniquement de la formule de remaillage. Dans un remaillage tensoriel,
chaque particule contribue une fois par itération à S
3
(S
2
) points de grilles voisins en 3D
(2D). En revanche, dans notre cas, une itération est constituée de plusieurs étapes dans
lesquelles une particule contribue simplement aux S points de grille. D’autres avantages en
termes de complexité algorithmique seront donnés ultérieurement.
352. Méthode particulaire pour l’équation de transport
2.1.3. Cas monodimensionnel
La méthode semi-Lagrangienne d’advection avec remaillage est donnée ici pour une
équation de transport monodimensionnelle :
∂u
∂t +
∂
∂x(au) = 0. (2.2)
On note la vitesse, a et la quantité transportée par les particules, u. À chaque instant, ces
deux variables sont connues en chaque point de la grille.
À chaque itération temporelle de la méthode, les particules sont initialisées à un instant
t
n
, en chaque point de grille x˜
n
i = xi avec u˜
n
i = u
n
i
pour la quantité transportée. Puis l’équation
de mouvement est résolue pour chaque particule à l’aide d’un schéma d’intégration en
temps. La nouvelle position de la particule i, x˜
n+1
i
est la solution du problème suivant :
d˜xi
dt
= a(˜xi) t ∈ [t
n
, tn+1[,
x˜
n
i = xi
.
(2.3)
En pratique, pour chaque particule, le problème (2.3) est résolu par un schéma d’inté-
gration explicite. La vitesse de la particule i, a(˜xi), est supposée constante tout au long de
l’intervalle de temps [t
n
;t
n+1[ et son approximation est notée a˜
n
(˜xi). Dans un cadre multié-
chelle, la vitesse est connue sur une grille plus grossière que celle du scalaire, on utilise alors
une interpolation linéaire du champ de vitesse pour obtenir l’approximation a˜
n
en un point
de la grille fine. Dans le cas d’une même résolution pour les deux grilles, l’approximation
du champ de vitesse sur un point de grille est directement donnée par la valeur de la vitesse
en ce point, sans interpolation, a˜
n
(xi) = a
n
i
. Pour une intégration du premier ordre, avec
un schéma d’Euler, la position de la particule après advection s’exprime par :
x˜
n+1
i = xi + a
n
i ∆t. (2.4)
Comme nous l’avons exposé précédemment, un splitting de Strang du second ordre est
utilisé pour les cas multidimensionnels. Cela implique l’utilisation d’un schéma d’intégration
d’ordre plus élevé afin de conserver le second ordre en temps. En utilisant un schéma de
Runge-Kutta, du second ordre, la position de la particule est donnée par l’expression :
x˜
n+1
i = xi + ˜a
n
xi + a
n
i
∆t
2
∆t. (2.5)
Ici encore, la valeur du champ de vitesse a
n
i
n’est utilisée directement que dans les cas d’une
même résolution pour la vitesse et le scalaire, sinon une interpolation linéaire supplémentaire
est nécessaire.
Après déplacement des particules, l’étape de remaillage permet de redistribuer les quantités
portées par les particules sur la grille. Cette étape est réalisée à l’aide du noyau de
remaillage W :
u
n+1
i =
X
p
u
n
pW
x˜
n+1
p − xi
∆x
!
(2.6)
362.1. Méthode particulaire avec remaillage
2.1.4. Lien avec la méthode des différences finies
Comme nous l’avons vu précédemment, une particule initialement au point de grille
xp se retrouve après advection, par la résolution de (2.3), en position x˜p, transportant la
quantité up. Ensuite la particule est remaillée sur les 2S points de grille voisins de x˜p par
un noyau de remaillage Λp,r. Si on note xi
le point de la grille le plus proche à gauche de
x˜p, la quantité up est distribuée sur les points de grille d’indices [i − S + 1;i + S], comme
l’illustre la figure 2.4.
Particules
Grille
i − 2 i − 1 i i + 1 i + 2 i + 3
x˜p
Figure 2.4. – Remaillage d’une particule pour un noyau de support [−2; 2]
De même, un point de la grille se voit collecter toutes les contributions de particules
situées à sa proximité indépendemment du nombre de particules. En effet, le nombre de
particules par cellules peut changer (c.-à-d. être différent de un) selon les variations locales
du champ de vitesse. Toutefois, les particules ne peuvent se croiser au cours de l’advection
lorsque le pas de temps est contraint par une condition CFL Lagrangienne :
∆t||a
0
||∞ 6 C (2.7)
Particules
Grille
i
Figure 2.5. – Remaillage sur un point de grille pour un noyau de support [−2; 2]
La méthode d’advection suivie d’un remaillage montre une similarité avec la méthode
des différences finies. Nous l’illustrons sur un exemple linéaire simple, lorsque le nombre CFL
des particules, λi = ai∆t/∆x, est inférieur à 1 et que la vitesse est positive. En utilisant la
formule de remaillage à deux points (2.10), les poids sont donnés par :
αi = 1 − λi
, βi = λi
.
Cette configuration est schématisée sur la figure 2.6.
αi−1 βi−1 αi βi
λi−1 λi λi+1
i − 1 i i + 1
i − 1 i i + 1
Instant t
n
Instant t
n+1
Advection
Remaillage
Figure 2.6. – Analogie entre le remaillage et les différences finies
372. Méthode particulaire pour l’équation de transport
À l’issue du remaillage, le point de grille d’indice i collecte des contributions des particules
i − 1 et i :
u
n+1
i = βi−1u
n
i−1 + αiu
n
i
= λi−1u
n
i−1 + (1 − λi)u
n
i
=
a
n
i−1u
n
i−1∆t
∆x
+ u
n
i −
a
n
i u
n
i ∆t
∆x
On reconnaît ici aisément un schéma aux différences finies du premier ordre consistant avec
l’équation de transport :
u
n+1
i − u
n
i
∆t
=
(au)
n
i−1 − (au)
n
i
∆x
Cette approche permet à Cottet et al. (2006) de démontrer le parallèle entre cette
méthode semi-Lagrangienne et le schéma de Lax-Wendroff pour l’équation de Burgers. Les
auteurs distinguent les cas linéaires et non linéaires. Pour une équation à vitesse constante,
l’utilisation d’une formule de remaillage de support [−1.5; 1.5] conservant les trois premiers
moments conduit, lorsque la CFL est inférieure à 1/2, à un schéma aux différences fines de
Lax-Wendroff. Pour une CFL dans [1/2; 1], le schéma obtenu est décentré. Une formule de
remaillage de support [−2; 2] conservant quatre moments est également analysée et conduit
à un schéma d’ordre 3. Le cas non linéaire est bien plus complexe et n’est étudié que pour la
formule Λ2 et une CFL inférieure à 1/2. Le schéma aux différences finies obtenu est d’ordre
deux si les particules sont advectées avec un schéma également d’ordre deux. Un point
intéressant de cette étude est que l’ordre des schémas obtenus ne dépend pas explicitement
de la formule de remaillage mais simplement du nombre de moments qu’elle conserve.
L’exploitation des outils de la méthodologie des différences finies permet à Cottet et
al. (2009b) de développer des limiteurs pour les formules de remaillage Λ2. Les auteurs se
restreignent à des CFL inférieures à 1 dans les cas linéaires et non linéaires pour l’équation
de Burgers. En pratique des CFL plus grandes sont traitées en deux étapes. Les particules
sont d’abord advectées sans remaillage sur la partie entière de la CFL puis advectées et
remaillées avec une CFL inférieure à 1.
Plus récemment, Magni et al. (2012) étendent la construction de formules de remaillage
avec limiteurs d’ordre 2 et 4 corrigées pour pouvoir traiter le cas de grands pas de temps.
En effet, lors d’une advection avec une CFL supérieure à 1, les nombres CFL peuvent
varier d’une particule à l’autre ce qui entraîne une perte de consistance avec l’équation de
transport. L’idée développée consiste en un regroupement des particules en blocs selon leur
nombre CFL local. Les particules d’un même blocs sont remaillées soit avec une formule
de remaillage centrée soit décentrée à gauche. Ainsi, au sein des blocs, la consistance est
assurée directement. Par contre, entre deux blocs de types différents, la consistance de la
méthode nécessite une correction des formules de remaillage selon les nombres CFL locaux
des particules à l’interface entre les blocs. Les corrections consistent en une modification du
nombre de points de grille sur lesquels ces particules sont remaillées. La consistance pour
les grands pas de temps conduit à des formules de remaillage de plus grande complexité
algorithmique du fait de l’étape de construction des blocs et de choix de la correction à
appliquer.
Enfin, Weynans et al. (2013) proposent une extension des formules de remaillage avec
limiteurs dans le cas non linéaire pour une vitesse de signe quelconque. Les auteurs proposent
également une preuve de convergence de la méthode en utilisant leurs schémas. Cette
382.1. Méthode particulaire avec remaillage
démonstration est réalisée dans le cadre de la résolution d’une équation de Burgers. Il s’agit,
à notre connaissance, de la seule preuve de convergence des méthodes particulaires pour
l’équation de Burgers.
2.1.5. Construction des formules de remaillage
Du fait de leur nature, les méthodes particulaires sont adaptées à la résolution d’équations
de conservation. Il est donc impératif que le remaillage, par l’équation (2.6), possède
également ces propriétés de conservation des moments des quantités transportées. Mathé-
matiquement le moment discret d’ordre p d’une quantité u est défini par :
X
i
x
p
i
ui
. (2.8)
Par conséquent, un noyau de remaillage doit satisfaire les égalités de conservation des moments
discrets d’ordre α suivantes :
X
i
x
α
i u
n+1
i =
X
i
x
α
i u
n
i
, 0 6 α 6 p,
ou encore, en utilisant la relation (2.6) :
X
k∈Z
k
αW(x − k) = x
α
, 0 6 α 6 p, x ∈ R. (2.9)
Construction à partir des moments discrets
La première catégorie de noyaux est obtenue directement à partir des relations (2.9) et
les noyaux sont notés Λp, pour un noyau conservant les moments d’ordre 0 à p. Le support
est fixé à une largeur égale à p + 1 et le noyau est défini par une fonction polynomiale par
morceaux de p + 1 polynômes de degrés p. Les p
2 + p coefficients sont alors obtenus de
manière à vérifier les relations (2.9). Cette méthode permet notamment d’obtenir le noyau
d’interpolation linéaire :
Λ1(x) = (
1 − |x| si |x| 6 1
0 sinon
(2.10)
Les quatre premiers noyaux de cette classe sont représentés en figure 2.7. Comme le montre
la figure 2.7, certains de ces noyaux ne sont pas continus. Les pertes de précisions numérique
dues au manque de régularité de ces noyaux ont été étudiées par Cottet et al. (2009b).
L’ordre du remaillage peut être conservé à l’aide de corrections locales.
Construction à partir de B-splines
Une seconde classe de noyaux est obtenue à partir de B-splines régulières (Schoenberg,
1946) :
Mp(x) = 1
2π
Z ∞
−∞
sin ξ/2
ξ/2
p
e
iξxdξ. (2.11)
392. Méthode particulaire pour l’équation de transport
−0.2
0
0.2
0.4
0.6
0.8
1
0 0.5 1 1.5 2 2.5 3 3.5 4
Λ1(x)
Λ2(x)
Λ3(x)
Λ4(x)
Figure 2.7. – Noyaux de remaillage de type Λp
Ainsi un noyau Mp sera de classe C
p−2 avec un support de largeur 2p − 3. La figure 2.8
représente quelques noyaux de type Mp. On remarque que M1 est la fonction chapeau
de support [−1/2; 1/2] et que M2 = Λ1. Cependant, ces noyaux ne permettent qu’une
conservation des deux premiers moments uniquement.
−0.2
0
0.2
0.4
0.6
0.8
1
0 0.5 1 1.5 2 2.5 3 3.5 4
M1(x)
M2(x)
M4(x)
M8(x)
Figure 2.8. – Noyaux de remaillage de type Mp
Extrapolation à partir de noyaux réguliers
En utilisant l’extrapolation de Richarson, Monaghan (1985) produit des noyaux basés
sur les fonctions Mp et leurs dérivées afin d’obtenir des ordres plus élevés en conservant leur
régularité. On construit alors un noyau de la forme W(x) = Pp/2
c=0 ckx
kM
(k)
p (x). Les coeffi-
402.1. Méthode particulaire avec remaillage
cients ck sont obtenus de telle sorte que le nouveau noyau vérifie les conditions suivantes :
Z
W(x)dx = 1,
Z
x
αW(x)dx = 0, 1 6 α 6 p,
ce qui conduit à la résolution d’un système linéaire. Seules les contraintes pour α pair sont
à considérer, car les moments impairs sont nuls par symétrie des noyaux. Par exemple, pour
le noyau M4, on est ramené à la résolution du système :
R
M4(x)dx
R
xM0
4
(x)dx
R
x
2M4(x)dx
R
x
3M0
4
(x)dx
c0
c1
=
1 −1
1/3 −1
c0
c1
=
1
0
,
dont la solution est c0 = 3/2 et c1 = 1/2. On obtient donc le noyau noté M0
4
. Par construction,
ce noyau est de classe C
1
, comme M4 est C
2
, mais il conserve les moments jusqu’à
l’ordre 3. Il est utilisé dans la plupart des implémentations depuis la fin des années 90
(Koumoutsakos, 1997 ; Ould Salihi, 1998).
M0
4
(x) = 1
2
3M4(x) + x
dM4
dx
(x)
M0
4
(x) =
1 −
5
2
|x|
2 +
3
2
|x|
3
si |x| 6 1
1
2
(1 − |x|)(2 − |x|)
2
si 1 < |x| 6 2
0 sinon
(2.12)
−0.2
0
0.2
0.4
0.6
0.8
1
0 0.5 1 1.5 2 2.5 3 3.5 4
M0
4(x)
M0
5(x)
M0
8(x)
Figure 2.9. – Noyaux de remaillage type M0
p
Un comparatif de ces différents noyaux est donné dans le tableau 2.1 en termes de
moments conservés, de régularité, de largeur de support et de degré polynomial.
412. Méthode particulaire pour l’équation de transport
Nom Moment maximal conservé Régularité Support Degré
Λ1 1 C
0
[−1; 1] 1
Λ2 2 - [−1, 5; 1, 5] 2
Λ3 3 C
0
[−2; 2] 3
Λ4 4 - [−2, 5; 2, 5] 4
M1 1 - [−0, 5; 0, 5] 0
M2 1 C
0
[−1; 1] 1
M4 1 C
2
[−2; 2] 3
M8 1 C
6
[−4; 4] 7
M0
4
2 C
1
[−2; 2] 3
M0
5
3 C
2
[−2, 5; 2, 5] 4
M0
8
4 C
4
[−4; 4] 7
Tableau 2.1. – Comparatif des différents noyaux de remaillage de la littérature.
2.1.6. Exemple d’implémentation
La principale implémentation de méthodes semi-Lagrangiennes (également appelées mé-
thodes particules-grille) a été proposée par Sbalzarini et al. (2006). La librairie PPM (Parallel
Particle-Mesh) repose sur une unification de méthodes de grilles et de méthodes particulaires
à travers des interpolations entre les particules et la grille. Cette librairie propose
une interface pour l’exploitation de machines à mémoire distribuée de manière transparente
pour l’utilisateur. Le parallélisme est géré par des méthodes de décomposition de domaine
et d’adaptation de charge. Des algorithmes efficaces pour l’évaluation des interactions entre
particules, des méthodes de grilles globales utilisant des FFT et des solveurs multigrille ainsi
que des interpolations entre les particules et la grille conduisent à de bonnes performances
numériques.
Dans la suite de ce chapitre nous exposons une méthode de construction de formules
de remaillage dont les propriétés de régularité et du nombre de moments conservés sont
choisis arbitrairement. Nous considérons ensuite ces formules dans des études de consistance
et de stabilité des schémas ainsi obtenus. Nous observons que l’ordre de la méthode
semi-Lagrangienne dépend directement du nombre de moments conservés par la formule
de remaillage ainsi que de sa régularité. Les détails techniques des étapes d’advection et
remaillage propres à l’implémentation seront donnés dans les chapitres 5 et 6.
2.2. Advection semi-Lagrangienne d’ordre élevé
2.2.1. Construction de formules de remaillage d’ordre élevé
Une caractéristique intéressante des noyaux de type Λp est la propriété d’interpolation
suivante :
Λp(x) = (
1, si x = 0
0, si x ∈ Z
∗
.
(2.13)
422.2. Advection semi-Lagrangienne d’ordre élevé
Cette propriété permet une conservation exacte de la quantité remaillée pour les particules
dont la position coïncide avec un point de grille, en particulier si la vitesse est nulle. En
pratique, l’utilisation de noyaux possédant cette propriété donne des résultats plus précis.
Cependant, les noyaux réguliers de type Mp et M0
p perdent cette propriété. Dans cette
section, nous donnons une méthode de construction de noyaux de remaillage d’ordre élevé,
réguliers et vérifiant la propriété (2.13). Le principe est similaire à celui employé pour la
construction des noyaux de type Λp, donnée en Section 2.1.5. Il s’agit de trouver une fonction
vérifiant les propriétés suivantes :
P1 : parité ;
P2 : support compact [−S, S] ;
P3 : polynomiale par morceaux de degré q sur les intervalles entiers ;
P4 : régularité C
r
;
P5 : conservation les moments jusqu’à l’ordre p, selon l’égalité (2.9) ;
P6 : vérification de la propriété d’interpolation (2.13).
Ces propriétés conduisent à l’expression d’une régularité des noyaux Λp,r en terme d’espaces
fonctionnels :
Λp,r ∈ C
∞ (]l, l + 1[), l ∈ Z,
Λp,r ∈ Wr+1,∞(R) = n
f ∈ L
∞(R), ∀l ∈ N
∗
, l 6 r + 1, D
l
f ∈ L
∞
o
,
(2.14)
où Dlf est la dérivée d’ordre l de f au sens des distributions.
Les propriété P1, P2 et P3 permettent de restreindre la recherche à seulement S polynômes
de degré q, soit S(q + 1) coefficients inconnus. Le noyau s’écrit donc de manière
générale :
Λp,r(x) = (
Qi(x), si i 6 |x| < i + 1, i = 0 . . . S − 1
0 sinon,
avec
Qi(x) = X
q
k=0
c
i
k
|x|
k
.
Avec ces notations, la propriété P4 implique que q > r ainsi que les (r + 1)(S + 1)
contraintes de raccords entre les polynômes aux points de coordonnées entières du support :
Q
(j)
i
(i + 1) = Q
(j)
i+1(i + 1), 0 6 j 6 r, 1 6 i 6 S − 1,
Q
(j)
0
(0) = (
1 si j = 0
0 sinon
, 0 6 j 6 r,
Q
(j)
S−1
(S) = 0, 0 6 j 6 r.
Les p+ 1 égalités polynomiales imposées par la propriété P5 se traduisent par (1+p)(q + 1)
contraintes sur les coefficients polynomiaux. Cependant, par parité des noyaux, les moments
432. Méthode particulaire pour l’équation de transport
Nom Moment maximal conservé Régularité Support Degré
Λ2,1 2 C
1
[−2; 2] 3
Λ2,2 2 C
2
[−2; 2] 5
Λ4,2 4 C
2
[−3; 3] 5
Λ4,4 4 C
4
[−3; 3] 9
Λ6,4 6 C
4
[−4; 4] 9
Λ6,6 6 C
6
[−4; 4] 13
Λ8,4 8 C
4
[−5; 5] 9
Tableau 2.2. – Comparatif de quelques noyaux de remaillage de type Λp,r.
d’ordre impair ne conduisent pas à des contraintes supplémentaires car elles sont vraies
quelque soient les coefficients c
i
k
. On ne retient donc que (1 + [p/2])(q + 1) contraintes.
Enfin, la propriété d’interpolation conduit à S − 1 contraintes supplémentaires, les valeurs
aux points de coordonnées 0 et S étant redondantes avec les contraintes issues de P4. Nous
avons donc au total S(r + 2) + (1 + [p/2])(q + 1) + r contraintes. Des solutions uniques sont
envisageables si :
S(q + 1) 6 S(r + 2) + (1 + [p/2])(q + 1) + r. (2.15)
Pour un couple de (S, q) donné et en considérant l’ordre p et la régularité r comme fixés,
l’ensemble de ces contraintes conduit à un système linéaire dont les inconnues sont les
coefficients polynomiaux c
k
i
. Comme les contraintes de conservation des moments d’ordre
impair sont vérifiées par parité, un choix naturel est de prendre p pair. Dans ce cas, en
prenant S = 1 + p/2, l’inégalité 2.15 est vérifiée car S(r + 2) + r > 0. Expérimentalement,
nous obtenons des solutions uniques en prenant, en plus des deux hypothèses précédentes,
q = 2r + 1. Les noyaux obtenus par cette méthode sont notés Λp,r. Nous retrouvons le
noyau M0
4 = Λ2,1 ainsi que le noyau Λ4,2 qui a été introduit par Bergdorf et al. (2006) sous
la notation M000
6
. Les caractéristiques des noyaux utilisés dans la suite sont résumées dans
le tableau 2.2 et leurs expressions sont données en annexe A. Une représentation de ces
noyaux est donnée en figure 2.10.
Cette méthode de construction de formules de remaillage permet de contrôler explicitement
le nombre de moments conservés p ainsi que la régularité du noyau r. Ces deux
paramètres, nous le verrons au cours de l’analyse de consistance qui suit, sont en lien direct
avec la précision du schéma et l’ordre numérique de la méthode. Ainsi, une méthode d’ordre
élevé sera obtenue en utilisant des formules avec p et r grands. Cependant, l’augmentation
du nombre de moments conservés par les formules de remaillage conduit à un élargissement
du support des noyaux. Cela a pour conséquence qu’un plus grand nombre de points de
grille seront contenus dans le support de la formule impliquant une plus grande complexité
en terme d’accès aux données lors de l’implémentation. D’autre part, l’augmentation de la
régularité de la formule implique une augmentation du degré des polynômes constituant
les noyaux. L’incidence de cette augmentation se traduit par une plus grande complexité
numérique lors de l’évaluation de ces fonctions pour le calcul des poids de remaillage.
442.2. Advection semi-Lagrangienne d’ordre élevé
−0.2
0
0.2
0.4
0.6
0.8
1
0 0.5 1 1.5 2 2.5 3 3.5 4
Λ2,1
Λ2,2
Λ4,2
Λ4,4
Λ6,4
Λ6,6
Λ8,4
Figure 2.10. – Noyaux de remaillage de type Λp,r
Utilisation des poids de remaillage
En pratique, on exprime les poids de remaillage en fonction de la distance entre la
particule et le point de grille le plus proche. Le support est découpé en intervalles de
longueur égale à la distance entre deux points de grille sur lesquels la formule s’identifie à
un polynôme. Ainsi, on a exactement un point de grille dans chaque morceau d’intervalle,
ce qui conduit à l’expression de 2S poids de remaillage. La figure 2.11 illustre l’obtention
des poids de remaillage pour une formule Λ2,1, de support de longueur 4.
Λ2,1(x) =
1 −
5
2
|x|
2 +
3
2
|x|
3 = p0(|x|) 0 6 |x| < 1
2 − 4|x| +
5
2
|x|
2 −
1
2
|x|
3 = p1(|x|) 1 6 |x| < 2
0 |x| > 2
Particules
Grille
xi
y
x˜p
Λ2,1(x)
x
x
x
x
p1(−x) p0(−x) p0(x) p1(x)
-2 -1 0 1 2 x
y
α(y) β(y) γ(y)
δ(y)
Figure 2.11. – Obtention des poids de remaillage pour une formule de support [−2; 2]
452. Méthode particulaire pour l’équation de transport
Lorsque xi est le point de grille le plus proche de coordonnée inférieure à x˜p, y est défini
comme la distance normalisée entre ces deux points : y = (˜xp − xi)/∆x, y ∈ [0; 1]. De ce
fait, on obtient les poids en fonction de y :
α(y) = Λ2,1(−1 − y) = p1(y) = y + y
2 −
1
2
y
3
,
β(y) = Λ2,1(−y) = p0(y) = 1 −
5
2
y
2 +
3
2
y
3
,
γ(y) = Λ2,1(1 − y) = p0(1 − y) = 1
2
y + 2y
2 −
3
2
y
3
,
δ(y) = Λ2,1(2 − y) = p1(1 − y) = −
1
2
y
2 +
1
2
y
3
.
Les poids sont donnés pour les formules de type Λp,r en annexe A. Pour les formules
d’ordre élevé, les poids de remaillage sont de degré assez grand. Une implémentation efficace
de l’évaluation de ces polynômes est réalisée par la méthode de Horner :
α(y) = y(y(−y + 2) − 1)/2,
β(y) = (y
2
(3y − 5) + 2)/2,
γ(y) = y(y(−3y + 4) + 1)/2,
δ(y) = y
2
(y − 1)/2.
Ainsi ce schéma permet de minimiser le nombre d’opérations arithmétiques pour l’évaluation
de ces polynômes en évitant notamment le calcul des termes en y
n
. L’évaluation d’un
polynôme de degré q ne nécessite que 2q additions et multiplications au lieu des q(q + 1)/2
pour un algorithme naïf.
Précision numérique du schéma d’Horner
Lors de l’évaluation d’un polynôme par le schéma d’Horner, la précision numérique
atteinte, en tenant compte des erreurs d’arrondi, dépend du degré et du conditionnement
du polynôme. L’erreur relative pour l’évaluation d’un polynôme p(x) = Pq
i=0 aix
i par un
schéma de Horner est bornée par (Higham, 2002) :
|p(x) − Horner(p, x)|
|p(x)|
6 Kq cond(p, x) = Kq
Pq
i=0 |ai
||x
i
|
|
Pq
i=0 aix
i
|
.
La constante Kq dépend du degré q du polynôme et de l’erreur relative lors de l’arrondi des
nombres en virgule flottante, u = 2−53 en double précision selon la norme IEEE-754. De
manière générale, on a :
Kq = γ2q =
2qu
1 − 2qu
,
et lorsque des opérations FMA (Fused Multiply and Add) sont disponibles, comme c’est le cas
sur la plupart des GPU, l’erreur est plus faible. En effet dans une FMA, la multiplication et
l’addition sont effectuées en une seule opération arithmétique conduisant à une seule erreur
d’arrondi au lieu de deux, la constante s’écrit alors :
Kq = γq =
qu
1 − qu
.
462.2. Advection semi-Lagrangienne d’ordre élevé
Les polynômes permettant de calculer les poids de remaillage pour les formules Λp,r ont
un conditionnement qui augmente fortement au voisinage de 1. Cela conduit à des erreurs
pouvant être assez grandes lorsque les particules s’approchent d’un point de grille par position
inférieure (y → 1). Ce phénomène est d’autant plus marqué que l’ordre des formules
est élevé. Nous représentons sur la figure 2.12 la borne d’erreur relative pour les poids de
remaillage pour trois des formules couramment utilisées.
0 0.2 0.4 0.6 0.8 1
y
Λ6,4
p3(y)
p2(y)
p1(y)
p0(y)
p0(1 − y)
p1(1 − y)
p2(1 − y)
p3(1 − y)
0 0.2 0.4 0.6 0.8 1
y
Λ4,2
p2(y)
p1(y)
p0(y)
p0(1 − y)
p1(1 − y)
p2(1 − y)
10−16
10−14
10−12
10−10
10−8
10−6
10−4
10−2
100
0 0.2 0.4 0.6 0.8 1
Précision relative
y
Λ2,1
p1(y)
p0(y)
p0(1 − y)
p1(1 − y)
Figure 2.12. – Erreur numérique maximale du schéma de Horner pour l’évaluation des
poids de remaillages pour les formules Λ2,1, Λ4,2 et Λ6,4 en double précision
(sans FMA)
Dans le cadre de ce travail, nous avons conservé le schéma de Horner pour l’implémentation
de ces formules.
2.2.2. Consistance de la méthode semi-Lagrangienne
Dans ce paragraphe nous démontrons la consistance du schéma d’advection et remaillage (2.4)
ou (2.5) et (2.6) lorsque la formule de remaillage est de type Λp,r, définie en section 2.2.1.
Cette démonstration est présentée dans un article paru en 2014 dans ESAIM : Mathematical
Modelling and Numerical Analysis pour un schéma d’Euler, inclus en annexe B. Nous
détaillons ici le cas d’une approximation d’ordre deux de la vitesse lors de l’advection. La
démonstration suit une démarche similaire à celle de l’article, la seule différence est que les
développements sont conservés à un ordre quelconque.
472. Méthode particulaire pour l’équation de transport
Proposition 2.1
Soit un noyau de remaillage Λp,r de support [−S; S], vérifiant les contraintes de régularité
(2.14), la propriété d’interpolation (2.13) ainsi que l’égalité de conservation des
moments (2.9) jusqu’à un ordre p. Soient un champ de vitesse a et un scalaire u suffisamment
réguliers tels que u soit solution de l’équation de transport (2.2). Lorsque la condition
(2.7) est vérifiée, α est l’ordre d’approximation du champ de vitesse et β = inf(p, r),
nous avons :
u(xi
, tn+1) = u
n+1
i + O(∆t
α+1) + O(∆t∆x
β + ∆x
β+1). (2.16)
De plus, dans le cas où chaque cellule contient une seule particule, β = p.
Démonstration de la proposition 2.1 : L’indice p d’une particule peut être réfé-
rencé à partir de l’indice i et d’un décalage k de telle sorte que xp = xi + k∆x
et ainsi :
u(xp, tn
) = X
β
j=0
k
j∆x
j
j!
∂
ju
∂xj
(xi
, tn
) + O(∆x
β+1). (2.17)
Ici, nous nous plaçons dans le cadre d’une grille cartésienne uniforme où xi+k =
xi + k∆x. De même, la position des particules devient :
x˜
n+1
p = xi + k∆x + ˜a
n
i+k∆t,
qui se réécrit en posant λi = ˜a
n
i ∆t/∆x, le nombre CFL local :
x˜
n+1
p − xi
∆x
= k + λi+k.
La règle de dérivation des fonctions composées, se généralise par :
(f ◦ g)
(m)
(x) = X
|q|=m
m!cq
f
(q1+···+qm)
◦ g
(x)
Ym
s=1
g
(s)
(x)
qs
,
cq =
1
q1!1!q1 q2!2!q2 · · · qm!m!
qm
,
où q est le multi-indice q = (q1, q2, . . . , qm) tel que |q| = q1 + 2q2 + · · · + mqm.
En utilisant cette formule, en posant ν = ∆t/∆x et en prenant g(xi) = k + λi =
k + νa˜
n
(xi), on obtient que :
Λp,r(k + λi)
(m) =
X
|q|=m
m!cqΛ
(q1+···+qm)
p,r (k + λi)ν
q1+···+qm Ym
s=1
a˜
n (s)
qs
. (2.18)
Le développement de Λp,r(k + λi+k) au voisinage de k + λi à l’ordre r est obtenu
en utilisant la relation (2.18). Cependant, comme Λp,r ∈ Wr+1,∞(R), cela implique
que ||Λ
(β+1)
p,r ||∞ < ∞ pour 0 6 β 6 r. Par conséquent, le développement est donc
482.2. Advection semi-Lagrangienne d’ordre élevé
effectué à l’ordre β = inf(p, r) :
Λp,r(k + λi+k) = X
β
m=0
k
m∆x
m
m!
X
|q|=m
m!cqΛ
(q1+···+qm)
p,r (k + λi)ν
q1+···+qm Ym
s=1
a˜
n (s)
qs
+ O
∆x
β+1||Λ
(β+1)
p,r ||∞||a˜
(β+1)||∞
X
|q|=β+1
ν
q1+q2+···+qβ+1
.
(2.19)
D’autre part, comme q1+q2+· · ·+qβ+1 6 |q|, alors ν
q1+q2+···+qβ+1 6 ν
β+1 6 ν
β+1+ν,
le résidu précédent se réécrit en :
O
∆t
β+1 + ∆x∆t
β
.
Finalement, l’approximation du schéma (2.6) est obtenue à partir du produit des
relations (2.17) et (2.19), noté Ek :
u
n+1
i =
X
k
u(xk, tn
)Λp,r(k + λi+k)
=
X
k
X
β
m=0
k
m∆x
m X
|q|=m
cqΛ
(q1+···+qm)
p,r (k + λi)ν
q1+q2+···+qm Ym
s=1
a˜
n (s)
qs
X
β
j=0
k
j∆x
j
j!
∂
ju
∂xj
(xi
, tn
)
+ O
∆t
β+1 + ∆x∆t
β + ∆x
β+1
=
X
k
Ek + O
∆t
β+1 + ∆x∆t
β + ∆x
β+1
.
Le produit des deux sommes d’indices m et j des termes Ek se regroupent :
X
k
Ek =
X
β
m=0
j=0
∆x
m+j
j!
∂
ju
∂xj
(xi
, tn
)
X
|q|=m
cq
X
k
k
m+jΛ
(q1+···+qm)
p,r (k + λi)ν
q1+q2+···+qm Ym
s=1
a˜
n (s)
qs
.
Par dérivation de la relation (2.9), on a :
X
k
k
αΛ
(δ)
p,r(k + x) = α!
(α − δ)!(−1)δ
(−x)
α−δ
si 0 6 δ 6 α 6 β.
Par conséquent, on a également :
X
k
k
m+jΛ
(q1+···+qm)
p,r (k + λi)ν
q1+q2+···+qm = di,m+j,qν
m+j
,
avec :
di,s,q =
s!(−1)q1+···+qm
(s − (q1 + · · · + qm))!(−a˜
n
i
)
s−(q1+···+qm)
, si 0 6 q1 + · · · + qm 6 s 6 β.
492. Méthode particulaire pour l’équation de transport
Ce qui permet d’aboutir à :
X
k
Ek =
X
β
m=0
j=0
∆x
m+j
j!
∂
ju
∂xj
(xi
, tn
)
X
|q|=m
cqdi,m+j,qν
m+j Ym
s=1
a˜
n (s)
qs
=
X
β
m=0
j=0
∆t
m+j
j!
∂
ju
∂xj
(xi
, tn
)
X
|q|=m
cqdi,m+j,q Ym
s=1
a˜
n (s)
qs
.
Finalement, la troncature du schéma à l’ordre α en temps donne :
u
n+1
i =
Xα
m=0
j=0
∆t
m+j
j!
∂
ju
∂xj
(xi
, tn
)
X
|q|=m
cqdi,m+j,q Ym
s=1
a˜
n (s)
qs
+ O
∆t
α+1 + ∆x∆t
β + ∆x
β+1
.
(2.20)
Advection par un schéma d’Euler
Les couples (m, j) possibles pour la première somme tels que m + j 6 α + 1 sont
(0, 0), (0, 1) et (1, 0). Pour m = 0, le multi-indice q se réduit à un simple indice égal
à 0. L’expression (2.20) devient :
u
n+1
i = u(xi
, tn
)− ∆ta˜
n
i
∂u
∂x(xi
, tn
)− ∆t(˜a
n
i
)
0u(xi
, tn
) +O
∆t
2 + ∆x∆t
β + ∆x
β+1
.
D’autre part, si le champ de vitesse est approché à l’ordre 1, on a a˜
n
i = a(xi
, tn
), ce
qui donne :
u
n+1
i = u(xi
, tn
) − ∆t
∂an
i u
∂x (xi
, tn
) + O
∆t
2 + ∆x∆t
β + ∆x
β+1
. (2.21)
Puis, en utilisant l’équation de transport (2.2) on aboutit au résultat :
u
n+1
i = u(xi
, tn+1) + O
∆t
2 + ∆x∆t
β + ∆x
β+1
. (2.22)
Advection par un schéma de Runge-Kutta du second ordre
Dans ce cas, en plus des termes présents pour le cas du schéma d’Euler, on ajoute
les termes correspondants aux couples (m, j) = (0, 2), (1, 1) et (2, 0).
u
n+1
i = u(xi
, tn
) − ∆ta˜
n
i
∂u
∂x(xi
, tn
) − ∆t(˜a
n
i
)
0u(xi
, tn
)
+
∆t
2
2
(˜a
n
i
)
2 ∂
2u
∂x2
(xi
, tn
) + 4˜a
n
i
(˜a
n
i
)
0 ∂u
∂x(xi
, tn
)
+ 2((˜a
n
i
)
02 + ˜a
n
i
(˜a
n
i
)
00)u(xi
, tn
)
+ O
∆t
3 + ∆x∆t
β + ∆x
β+1
.
502.2. Advection semi-Lagrangienne d’ordre élevé
Pour une approximation du second ordre, on a a˜
n
i = a(xi + a(xi)∆t/2). Les
développements de a˜
n
i
sont réalisés à l’ordre maximal puis injectés dans l’expression
précédente :
∆ta˜
n
i = ∆tan
i +
∆t
2
2
a(xi)a
0
(xi) + O(∆t
3
),
∆t(˜a
n
i
)
0 = ∆ta0
(xi) + ∆t
2
2
a(xi)a
00(xi) + ∆t
2
2
a
02
(xi) + O(∆t
3
),
∆t
2
(˜a
n
i
)
00 = ∆t
2
a
00(xi) + O(∆t
3
),
u
n+1
i = u(xi
, tn
) − ∆t
a
n
i
∂u
∂x(xi
, tn
) + (a
n
i
)
0u(xi
, tn
)
+
∆t
2
2
(a
n
i
)
2 ∂
2u
∂x2
(xi
, tn
) + 3˜a
n
i
(˜a
n
i
)
0 ∂u
∂x(xi
, tn
)
+ ((˜a
n
i
)
02 + ˜a
n
i
(˜a
n
i
)
00)u(xi
, tn
)
+ O
∆t
3 + ∆x∆t
β + ∆x
β+1
.
Par simplifications on obtient :
u
n+1
i = u(xi
, tn
) − ∆t
∂an
i u
∂x (xi
, tn
) + ∆t
2
2
∂
∂x
∂an
i u
∂x
(xi
, tn
)
+ O
∆t
3 + ∆x∆t
β + ∆x
β+1
.
(2.23)
Puis en utilisant l’équation de transport (2.2) on obtient finalement :
u
n+1
i = u(xi
, tn+1) + O
∆t
3 + ∆x∆t
β + ∆x
β+1
. (2.24)
Cas d’une seule particule par cellule
Dans ce cas, le développement (2.19) peut être effectué à n’importe quel ordre,
en particulier à l’ordre β = r. La suite des calculs reste identique.
2.2.3. Stabilité de la méthode semi-Lagrangienne
Les démonstrations de la stabilité de la méthode sont données dans l’article Cottet et al.
(2014) inclus en annexe B. Les preuves sont basées sur les propriétés de décroissance des
noyaux qui sont vérifiées pour les méthodes d’ordre 2 et 4. Nous proposons ici une approche
permettant de démontrer la propriété de stabilité linéaire de la méthode pour les noyaux
de type Λp,r jusqu’à p = 8.
512. Méthode particulaire pour l’équation de transport
Advection à vitesse constante
Dans un premier temps, la stabilité du schéma est analysée pour un champ de vitesse
constant en espace. La démonstration se base sur le nombre CFL local : λ = a∆t/∆x,
constant. Nous définissons les suites de fonctions suivantes, pour k ∈ Z :
αk(λ) = Λp,r(k + λ), (2.25)
Ak(λ) = X
i
αi(λ)αi+k(λ). (2.26)
Les noyaux de remaillage étant à support compact, seuls quelques éléments de ces suites
sont non nuls.
Proposition 2.2
Les suites αk(λ) et Ak(λ) vérifient :
X
k,l
(k − l)
qαk(λ)αl(λ) = 0, et X
k
k
qAk(λ) = 0, q 6 p. (2.27)
Démonstration de la proposition 2.2 : Le membre de gauche de la première équation
se développe en :
X
k,l
(k − l)
qαk(λ)αl(λ) = X
k,l
X
q
m=0
C
m
q k
ml
q−mαk(λ)αl(λ).
La propriété (2.9) étant vérifiée pour les formules de type Λp,r, on a :
X
k,l
k
ml
q−mαk(λ)αl(λ) = (−λ)
m(λ)
q−m,
et donc
X
k,l
(k − l)
qαk(λ)αl(λ) = X
q
m=0
C
m
q
(−λ)
m(λ)
q−m = (λ − λ)
q = 0.
La seconde équation vient du fait que Ak(λ) = A−k(λ).
Proposition 2.3
Pour un champ de vitesse a constant en espace et pour un noyau de remaillage Λp,r
de support [−S; S] vérifiant les contraintes de régularité (2.14), la propriété d’interpolation
(2.13) ainsi que l’égalité de conservation des moments (2.9) jusqu’à un ordre p, le
schéma de remaillage est inconditionnellement stable.
Démonstration de la proposition 2.3 : Soient I un entier tel que λ ∈ [I; I + 1[ et
µ = λ − I ∈ [0; 1[. En posant vi = u
n
i−I
, le schéma (2.6) se réécrit :
u
n+1
i =
X
k
vi+kαk(µ).
522.2. Advection semi-Lagrangienne d’ordre élevé
Montrons que
X
i
u
n+1
i
2
6
X
i
|u
n
i
|
2
.
En utilisant (2.27), il vient :
X
i
u
n+1
i
2
=
X
i
X
k,l
vi+kvi+lαk(µ)αl(µ). (2.28)
La formule de remaillage possède un support [−S; S], par conséquent, seuls quelques
αk(µ) sont non nuls, pour k ∈ [−S; S−1]. Pour alléger les notations, comme µ ∈ [0, 1[
ne joue aucun rôle, il sera omis dans la suite.
X
i
|u
n+1
i
|
2 =
X
i
X
k,l
vi+kvi+lαkαl
=
X
i
X
k
v
2
i+kα
2
k + 2X
k 0
=
X
i
X
k
2
X
S−1
j=1
αkαk+j
|vi+k − vi+k+j
|
2
=
X
k
2
X
S−1
j=1
αkαk+j
X
i
|vi − vi+j |
2
=
2
X
S−1
j=1
Aj
X
i
|vi − vi+j |
2
.
532. Méthode particulaire pour l’équation de transport
La suite consiste à démontrer que R > 0. On définit alors les suites {δJ,i}J=1,...,2S−1
de différences successives telles que :
δ1,i = vi − vi+1,
δ2,i = δ1,i − δ1,i+1,
δJ,i = δJ−1,i − δJ−1,i+1,
(2.29)
ainsi que des sommes de termes de ces suites :
sJ,j =
X
i
X
j−1
k=0
δJ,i+k
2
.
Pour J = 1, on a simplement s1,j =
P
i
|vi − vi+j |
2
, donc R se réécrit :
R =
2
X
S−1
j=1
Ajs1,j . (2.30)
Par définition de sJ,j , on a :
sJ,j =
X
i
X
j−1
k=0
δJ,i+k
2
=
X
i
X
j−1
k=0
δ
2
J,i+k +
X
j−2
k=0
j−X
1−k
l=1
2δJ,i+kδJ,i+k+l
!
= j
X
i
δ
2
J,i +
X
j−1
l=1
(j − l)
X
i
2δJ,iδJ,i+l
.
En utilisant la relation 2δJ,iδJ,i+l = δ
2
J,i + δ
2
J,i+l − |δJ,i − δJ,i+l
|
2
, on obtient que :
sJ,j = j
X
i
δ
2
J,i +
X
j−1
l=1
(j − l)
2
X
i
δ
2
J,i −
X
i
|δJ,i − δJ,i+l
|
2
!
=
j + 2X
j−1
l=1
(j − l)
!X
i
δ
2
J,i −
X
j−1
l=1
(j − l)
X
i
|δJ,i − δJ,i+l
|
2
= j
2X
i
δ
2
J,i −
X
j−1
l=1
(j − l)
X
i
|δJ,i − δJ,i+l
|
2
= j
2X
i
δ
2
J,i −
X
j−1
l=1
(j − l)sJ+1,l.
Ainsi, le second terme de l’expression précédente contient j − 1 termes en sJ+1,l
dont les seconds membres contiennent au maximum j − 2 termes, pour sJ+1,j−1. Le
développement complet de sJ,j fait intervenir j − 1 niveaux de récurrence jusqu’au
542.2. Advection semi-Lagrangienne d’ordre élevé
niveau J + j − 1. On obtient, en posant DJ =
P
i
δ
2
J,i pour alléger les notations, le
développement suivant :
sJ,j = j
2DJ −
X
j−1
l=1
(j − l)sJ+1,l
= j
2DJ −
X
j−1
l=1
(j − l)l
2DJ+1 +
X
j−1
l=1
(j − l)
X
l−1
m=1
(l − m)sJ+2,m
=
X
j
k=1
(−1)k+1Ck,jDJ+k−1.
Avec les coefficients Ck,j définis par :
C1,j = j
2
;
C2,j =
X
j−1
l=1
(j − l)l
2
, si j > 2,
0, sinon ;
C3,j =
X
j−1
l=1
(j − l)
X
l−1
m=1
(l − m)m2
, si j > 3,
0, sinon ;
C4,j =
X
j−1
l=1
(j − l)
X
l−1
m=1
(l − m)
mX−1
n=1
(m − n)n
2
, si j > 4,
0, sinon ;
.
.
.
L’expression (2.30) se réécrit donc :
R =
2
X
S−1
j=1
Aj
X
j
k=1
(−1)k+1Ck,jDk
!
,
puis en permutant les sommes, on obtient :
R =
2
X
S−1
k=1
Dk
2
X
S−1
j=k
(−1)k+1Ck,jAj
. (2.31)
Deux remarques permettent de simplifier la recherche du signe de R. Premièrement,
les Dk étant positifs comme sommes de carrés, le dernier terme de la somme,
pour k = 2S−1, est toujours positif. En effet, ce terme se simplifie en D2S−1A2S−1 =
D2S−1α−SαS−1 et les α−S et αS−1 sont de même signe car on observe que les formules
de type Λp,r présentent une alternance de signe sur chaque intervalle entier.
Les noyaux sont positifs sur l’intervalle [−1; 1], négatifs sur [−2; −1] ∪ [1; 2] et ainsi
sur l’ensemble des intervalles entiers du support. En particulier, il est positif sur l’intervalle
[−S; −S + 1] ∪ [S − 1; S] si S est impair et négatif sinon. Deuxièmement, en
552. Méthode particulaire pour l’équation de transport
remarquant que les coefficients Ck,j se réécrivent comme des combinaisons linéaires
de puissances paires de j :
C2,j =
−j
2
12
+
j
4
12
, C3,j =
j
2
90
−
j
4
72
+
j
6
360
, C4,j =
−j
2
560
+
7j
4
2880
−
j
6
1440
+
j
8
20160
,
les termes de la forme PCk,jAj s’annulent lorsque k 6 [p/2] en utilisant la propriété
de conservation des moments pairs (2.9). Ainsi, si la formule de remaillage conserve
p moments alors les [p/2] premiers termes de la somme d’indice k sont nuls. Ainsi
on obtient la majoration suivante :
R >
2
X
S−2
k=[p/2]+1
Dk
2
X
S−1
j=k
(−1)k+1Ck,jAj
.
Pour toutes les formules de remaillage de type Λp,r, il a été vérifié numériquement
que :
2
X
S−1
j=k
(−1)k+1Ck,jAj > 0 pour k = [p/2] + 1, . . . , 2S − 2
Ainsi nous obtenons que toutes les formules de type Λp,r données en annexe A
conduisent à une méthode stable car R > 0.
Advection à vitesse non constante
Nous donnons ici les grandes lignes de la démonstration de stabilité dans le cas général
qui est détaillée dans l’article Cottet et al. (2014) inclus en annexe B.
Proposition 2.4
Pour un champ de vitesse a suffisamment régulier et pour un noyau de remaillage Λp,r
de support [−S; S] vérifiant les contraintes de régularité (2.14), la propriété d’interpolation
(2.13) ainsi que l’égalité de conservation des moments (2.9) jusqu’à un ordre p et
lorsque le pas de temps est suffisamment petit vérifiant la condition (2.7), il existe une
constance C indépendante de ∆t et ∆x telle que :
X
i
u
n+1
i
2
6 (1 + C∆t)
X
i
|u
n
i
|
2
. (2.32)
Démonstration de la proposition 2.4 : Nous ne donnons ici que l’idée générale de
la démonstration qui est détaillée dans l’article en annexe. Lorsque la vitesse est
non constante et le pas de temps suffisamment petit (2.7), le nombre CFL local est
différent pour chaque particule :
λp =
ap∆t
∆x
.
Les particules peuvent alors être partitionnées selon l’intervalle entier auquel appartient
λp :
JI =
p ∈ Z, λp ∈ [I; I + 1[
. (2.33)
562.2. Advection semi-Lagrangienne d’ordre élevé
Le schéma de remaillage (2.6) se réécrit :
u
n+1
i =
X
I
X
k∈JI
u
n
kΛp,r(λk + k − i).
En posant
RI (i) = X
k∈JI
u
n
kΛp,r(λk + k − i),
le membre de gauche de l’équation (2.32) devient :
X
i
u
n+1
i
2
=
X
i
X
I
RI (i)
2
=
X
i
X
I
R
2
I
(i) +X
i
X
I6=I
0
RI (i)RI
0(i).
L’étude du premier terme est similaire à l’analyse dans le cas à vitesse constante
et se base sur le fait que dans chaque élément de la double somme, les particules
ont un nombre CFL local dans le même intervalle entier. Dans ce cas, on aboutit au
résultat :
X
i
R
2
I
(i) 6
X
i∈JI
|u
n
i
|
2 + C∆t (2.34)
Dans le second terme, il apparaît des produits de la forme :
Λp,r(λk + k − i)Λp,r(λk
0 + k
0 − i), k ∈ JI , k0 ∈ JI
0, I 6= I
0
.
Ces produits sont non nuls seulement dans le cas où les particules son suffisamment
proches après advection. De plus, chaque particule ne contribue que dans, au plus,
2S sommes RI (i). Ainsi on aboutit au résultat :
X
i
X
I6=I
0
RI (i)RI
0(i) 6 C∆t
X
i
|u
n
i
|
2
(2.35)
Finalement, en combinant les résultats (2.34) et (2.35), on aboutit au résultat (2.32).
Conclusion
Dans ce chapitre, nous avons détaillé la méthode de résolution que nous employons pour
résoudre une équation de transport. Nous avons vu comment l’étude des propriétés numé-
riques de la méthode semi-Lagrangienne est réalisée en exploitant la similarité de la méthode
avec celle des différences finies. En particulier, cela nous permet de produire des schémas
numériques à un ordre arbitraire en utilisant des formules de remaillage appropriées. Ces
formules possèdent, par construction, des propriétés de régularité et de conservation de
moments des quantités transportées qui sont directement liées à l’ordre de la méthode.
Cette méthode semi-Lagrangienne permet de résoudre les équations de transport pré-
sentées au chapitre 1. Les autres éléments constituant le problème de transport de scalaire
dans un fluide turbulent tels que les termes d’étirement et de diffusion ainsi que l’équation
de Poisson sont traités par d’autres méthodes. Cela conduit à l’obtention d’une méthode
hybride comme nous le verrons dans le chapitre 3.
573. Méthode hybride pour le
transport turbulent
Dans ce chapitre nous proposons de construire une méthode hybride, utilisant la méthode
semi-Lagrangienne détaillée dans le chapitre 2, pour résoudre un problème de transport
d’un scalaire dans un fluide turbulent, exposé dans le chapitre 1. Comme nous l’avons
mentionné précédemment, ce système présente à la fois un caractère multiéchelle et un
faible couplage entre les sous-problèmes que sont la résolution du fluide et le transport du
scalaire. Ces caractéristiques nous conduisent à l’élaboration d’une méthode hybride qui est
d’une part adaptée à la résolution de ce type de problème et d’autre part capable de traiter
des résolutions importantes sur des machines massivement parallèles.
Dans un premier temps, nous décrirons l’idée générale d’une méthode hybride puis nous
donnerons quelques approches hybrides présentées dans la littérature avant de proposer la
stratégie que nous emploierons par la suite.
3.1. Idée générale d’une méthode hybride
Le principe d’une méthode hybride est d’utiliser différentes méthodes conjointement
afin de résoudre un problème complexe en exploitant les forces de chacune des méthodes.
Ainsi, le problème initial est décomposé selon ses aspects physiques en différentes parties
qui sont résolues avec des méthodes différentes. Même si chacune des méthodes est bien
connue individuellement, comme pour les méthodes exposées en section 1.1.2, le couplage
doit être étudié en détail.
La décomposition du problème global selon ses aspects physiques permet, par exemple
dans le cadre de l’étude d’interactions entre un fluide et une structure, de séparer la ré-
solution du fluide et du solide. De même pour le cas d’un transport de scalaire passif, il
est possible de séparer la résolution du fluide de celle du transport du scalaire. Enfin, nous
avons vu dans les chapitres précédents, que l’emploi d’une méthode semi-Lagrangienne pour
la résolution d’un écoulement fait intervenir une équation de transport de la vorticité ainsi
qu’une équation de Poisson permettant de calculer le champ de vitesse associé. Là encore
une décomposition peut avoir lieu pour séparer la résolution de l’équation de Poisson de
celle de l’équation de transport.
593. Méthode hybride pour le transport turbulent
Ainsi dans une méthode hybride, les différentes parties du problème, issues de la décomposition
selon les aspects physiques et numériques, sont résolues par différentes méthodes.
Trois niveaux d’hybridation peuvent être distingués et sont détaillés dans la suite.
3.1.1. Méthode hybride en méthode numérique
Le premier niveau consiste en l’utilisation de différentes méthodes numériques. Par
exemple, pour la résolution d’un écoulement turbulent, une méthode hybride est utilisée
par Cottet et al. (2002), Cottet et al. (2009b) et Rees et al. (2011). Cette méthode consiste
en une résolution semi-Lagrangienne du transport de la vorticité combinée à une méthode
spectrale pour le calcul du champ de vitesse en fonction du champ de vorticité à partir de
l’équation de Poisson. La résolution de l’équation de Poisson par une méthode spectrale est
une alternative à celle basée sur la loi de Biot-Savart employée dans les méthodes Vortex.
Cette dernière conduit à une résolution directe sur le champ de particules, ce qui constitue
un problème à N corps à travers le calcul des interactions entre les paires de particules. Les
implémentations efficaces nécessitent la gestion d’une structure de données complexe basée
sur des arbres afin de regrouper les particules en fonction de leurs distances pour exploiter
les approximations multipoles rapides (méthodes FMM). Ainsi, la méthode spectrale est
bien plus simple à mettre en œuvre. Ce type de couplage entre méthodes semi-Lagrangienne
et spectrale est utilisé également pour des simulations d’écoulements en présence de solides
rigides, pris en compte par pénalisation (Coquerelle et al., 2008 ; Rossinelli et al., 2010).
D’autre part, dans le cas du transport turbulent d’un scalaire passif, des méthodes hybrides
consistent en une résolution par méthode spectrale de l’écoulement puis un transport
du scalaire par différences finies (Gotoh et al., 2012) ou par une méthode semi-Lagrangienne
(Lagaert et al., 2012 ; Lagaert et al., 2014).
3.1.2. Méthode hybride en résolution
Un second aspect des méthodes hybrides est d’employer des grilles de résolutions diffé-
rentes pour discrétiser les équations présentes dans le modèle. Par exemple, Cottet et al.
(2009a) proposent l’utilisation d’une méthode particulaire hybride en résolution pour le
transport de scalaire. Les auteurs utilisent la même méthode semi-Lagrangienne pour ré-
soudre l’écoulement et le scalaire. Le couplage est réalisé par interpolation du champ de
vitesse pour le transport du scalaire. Dans cette méthode, le scalaire est discrétisé à une
résolution plus fine que les champs de vitesse et de vorticité. Généralement, des modèles
sous-maille sont utilisés dans le cadre de simulations des grandes échelles (LES) pour prendre
en compte la dissipation d’énergie par son transfert vers les petites échelles. Cependant, ce
modèle n’est pas suffisant pour prendre en compte les effets des plus petites échelles de
fluctuations du scalaire qui ne sont pas résolues car de taille inférieure au maillage. Cottet
et al. (2009a) montrent que l’emploi d’une méthode multiéchelle remédie naturellement à
ce problème par une simulation directe des petites échelles du scalaire tout en conduisant
à un coût de calcul similaire.
Les études menées par Gotoh et al. (2012), Lagaert et al. (2012) et Lagaert et al. (2014)
dans le cadre de l’analyse du comportement d’un scalaire transporté par un écoulement de
603.2. Application au transport turbulent
turbulence homogène montrent que cette approche hybride en résolution permet d’obtenir
des résultats cohérents avec le cas d’une méthode spectrale classique, en simple résolution.
En effet, comme nous l’avons souligné dans la partie 1.3, ce problème se caractérise par la
présence de différentes échelles et la résolution du fluide à l’échelle du scalaire n’apporte pas
d’amélioration de la prise en compte de la physique de l’écoulement. Les méthodes utilisées
dans ces travaux seront détaillées plus loin, en section 3.2.
3.1.3. Méthode hybride en matériel
Comme nous l’avons vu dans la partie 1.2, les machines de calcul présentent de nombreuses
architectures différentes. Un dernier niveau de construction d’une méthode hybride
consiste en l’exploitation des différentes architectures d’une même machine. L’idée est de
distribuer les différentes parties du problème sur différents matériels. Par exemple, dans le
cas du transport de scalaire, la résolution du fluide est effectuée sur les processeurs CPU
et le transport du scalaire est résolu sur les cartes graphiques d’une machine hétérogène.
Cette approche sera complétée plus loin dans ce chapitre et sa mise en œuvre détaillée dans
le chapitre 6.
Une combinaison de ces différents niveaux est évidemment possible. En effet, une mé-
thode hybride peut être définie par des résolutions et des méthodes différentes pour les
parties du problème. Les approches semblables de Gotoh et al. (2012) et Lagaert et al.
(2014) illustrent parfaitement ce cas de figure. Dans leurs études, le fluide est résolu par une
méthode spectrale à une résolution grossière et le scalaire par différences finies ou méthode
semi-Lagrangienne à une résolution plus fine. Les nombreuses possibilités de construction
de méthodes hybrides nécessitent quelques précisions quant à l’application au transport
de scalaire passif dans un écoulement turbulent. En effet, les caractéristiques du problème
permettent d’aiguiller les choix pour la mise en place d’une méthode hybride.
3.2. Application au transport turbulent
3.2.1. Méthodes spectrale et différences finies
Dans le cas du transport de scalaire passif, Gotoh et al. (2012) proposent une comparaison
de leur méthode hybride avec une méthode entièrement spectrale. La méthode
hybride consiste en la résolution de l’écoulement à l’aide d’une méthode spectrale alors que
le transport du scalaire est résolu par différences finies d’ordre élevé. L’intérêt majeur de
cette approche est que les opérations non locales sur le scalaire, issues des transformées de
Fourier de la méthode spectrale, sont remplacées par des schémas locaux. Cela permet de
limiter les communications lors de l’exploitation d’un grand nombre de cœurs de calcul. Les
différentes échelles physiques présentes dans les cas à nombre de Schmidt élevé permettent
à Gotoh et al. de réaliser des simulations en multirésolution. Le fluide est calculé sur 2563
points de grille alors que 1 0243 points sont utilisés pour discrétiser le scalaire.
613. Méthode hybride pour le transport turbulent
Une réduction du temps de calcul est obtenue à travers ces différentes simulations. En
particulier, les auteurs obtiennent un facteur d’accélération de 1,4 grâce à l’utilisation de
leur méthode hybride au lieu d’une méthode entièrement spectrale. D’autre part, le fait de
réduire le nombre de points de 1 0243 à 2563 pour la résolution du fluide, pour Sc = 50,
leur permet d’obtenir un facteur d’accélération supplémentaire de 3. L’ensemble des calculs
ont été réalisés en utilisant 4 096 cœurs de calcul.
Une limite de cette approche est que le pas de temps reste limité par la résolution
du maillage du scalaire à travers l’expression d’une condition de CFL. Ainsi, lorsque le
problème est résolu en utilisant des grilles résolutions différentes, les auteurs sont limités à
l’utilisation d’un pas de temps dépendant de celle du scalaire.
3.2.2. Méthodes spectrale et semi-Lagrangienne
Une approche similaire a été proposée par Lagaert et al. (2012) et Lagaert et al. (2014).
Les auteurs utilisent une méthode hybride où le fluide est résolu de façon spectrale couplée
à une méthode semi-Lagrangienne pour le transport du scalaire. L’intérêt majeur est de
pouvoir bénéficier de l’avantage des méthodes particulaires dont le pas de temps n’est pas
contraint par une condition aussi restrictive que la condition CFL des méthodes Eulériennes,
dans certains cas. Cela permet à Lagaert et al. de choisir un pas de temps pour le transport
du scalaire dix fois plus grand que celui du fluide. Ainsi, dans le cas d’un grand nombre
de Schmidt, non seulement les résolutions spatiales sont différentes mais les pas de temps
aussi. Cela permet d’atteindre un facteur d’accélération approchant 40 par rapport à une
méthode entièrement spectrale avec une seule résolution, dans le cas Sc = 50 avec 2563
points pour le fluide et 1 0243 points pour le scalaire.
Toutefois, la méthode semi-Lagrangienne utilisée par Lagaert et al. reste d’un ordre
spatial plus faible (ordre 4) que le schéma aux différences finies d’ordre 8 employé par Gotoh
et al.
3.2.3. Méthodes semi-Lagrangiennes et architecture hybride
Dans ce travail, nous reprenons l’idée de Cottet et al. (2009a) pour l’utilisation d’une
méthode hybride. La méthode que nous utilisons exploite les trois niveaux d’hybridation
exposés plus haut : maillages de résolutions différentes pour le scalaire et l’écoulement, couplage
de méthodes de natures différentes et utilisation d’architectures matérielles différentes
pour la résolution de l’écoulement et du transport du scalaire. Nous exploitons le caractère
multiéchelle du problème avec une méthode hybride en résolution dans laquelle le scalaire
transporté est résolu de manière plus fine que la vorticité. L’écoulement est résolu par une
méthode semi-Lagrangienne pour le transport de la vorticité, avec des différences finies pour
le terme d’étirement et une diffusion spectrale. Nous calculons le champ de vitesse à partir
de la vorticité à l’aide d’un solveur spectral pour l’équation de Poisson. Le scalaire est
également transporté par une méthode semi-Lagrangienne avec une diffusion en différences
finies. Enfin au niveau matériel, le fluide sera résolu sur une architecture multicœurs CPU
classique et nous tirons parti de la puissance de calcul disponible dans les cartes graphiques
pour résoudre le transport du scalaire.
623.2. Application au transport turbulent
Comme toutes les résolutions en temps sont effectuées par méthode semi-Lagrangienne,
cela nous permet de choisir de grands pas de temps contraints uniquement par la condition
de CFL Lagrangienne qui fait intervenir le gradient du champ de vitesse et non la taille de la
grille. D’autre part, comme nous l’avons vu en section 2.2, la méthode d’ordre élevé conduit
à l’utilisation de formules de remaillage d’une forte complexité arithmétique. En effet, le
remaillage d’une particule nécessite l’évaluation de polynômes de degré relativement élevés
en chacun des nombreux point du support. Cette complexité est maîtrisée par l’utilisation
de cartes graphiques. L’intérêt de cette approche est de pouvoir accélérer, à l’aide des GPU,
la partie la plus intensive du code dont la résolution pourra être réalisée en même temps
que l’écoulement par l’utilisation de matériels différents pour chaque partie. D’un point
de vue pratique, lors de l’exploitation de machines de calcul, il est d’usage de réserver les
cartes graphiques par nœuds complets ce qui, sur la plupart des machines, donne accès à un
nombre de cœurs CPU bien plus grand que le nombre de GPU. L’objectif d’une exploitation
efficace des ressources est envisageable à travers une utilisation simultanée des GPU et des
cœurs CPU pour résoudre respectivement le transport du scalaire et le fluide.
Conclusion
Dans ce chapitre, nous avons vu comment une méthode hybride permet d’exploiter les
forces des différentes méthodes en fonction des caractéristiques du problème à résoudre.
Ainsi, la méthode que nous utiliserons par la suite combine la méthode semi-Lagrangienne
exposée dans le chapitre 2 avec des méthodes de grille classiques, différences fines et spectrales.
L’idée principale de cette méthode est de profiter à la fois de la puissance de calcul
développée par les cartes graphiques et de l’algorithme de splitting dimensionnel pour réaliser
des simulations d’ordre élevé pour le transport du scalaire. Les résultats de cette méthode
seront présentés dans le chapitre 6.
634. Développement d’un code
multiarchitectures
L’un des objectifs de cette thèse consiste en l’implémentation sur cartes graphiques de
la méthode particulaire avec remaillage introduite dans le chapitre 2. Cette étape s’inscrit
dans un cadre plus global de construction d’une méthode hybride, dont les principes ont été
donnés dans le chapitre 3, afin d’explorer les possibilités d’une exploitation les ressources de
machines de calcul hétérogènes telles que décrites dans le chapitre 1. Comme nous l’avons
souligné dans le chapitre 2, la méthode semi-Lagrangienne semble être bien adaptée à une
implémentation sur cartes graphiques du fait de la régularité des structures de données et
des algorithmes qui en découlent. De plus, l’utilisation de formules de remaillage d’ordre
élevé conduit à l’exécution de nombreuses opérations arithmétiques simples notamment
pour le calcul des poids de remaillage. Actuellement, de nombreuses machines de calcul
sont équipées de cartes graphiques. Cependant, comme nous l’avons vu dans le chapitre 1,
cette tendance n’est pas immuable et peut éventuellement changer dans les prochaines années
du fait des évolutions technologiques des composants. Par conséquent, dans un souci
de pérennité du code, la librairie que nous développons doit pouvoir être facilement adaptée
à une nouvelle architecture tout en conservant la possibilité d’une exploitation de machines
classiques. D’autre part, la volonté d’une forte portabilité permettant de réaliser des simulations
à la fois sur une machine de bureau, un portable ou une machine de calcul offre
également une grande souplesse pour les différentes étapes de développement, de parallélisation
et de production.
Dans ce chapitre, nous présentons la librairie de calcul que nous utiliserons dans la suite
pour les simulations numériques. Dans un premier temps, nous exposerons la conception
de cette librairie qui est basée sur une stratégie de découpage sémantique en concepts
mathématiques puis en différents niveaux d’abstraction, comme suggéré par Labbé et al.
(2004). Dans un second temps, l’architecture et les moyens de programmation des cartes
graphiques sont détaillés puis nous introduirons les principes du standard de programmation
OpenCL. Enfin, l’intégration des modèles de programmation des GPU à la librairie de
calcul sera rapidement décrite. Cette étape du développement est largement facilitée par la
conception globale de la librairie.
654. Développement d’un code multiarchitectures
4.1. Développement d’une librairie de calcul
scientifique
4.1.1. Conception préliminaire
Bien que de nombreux codes numériques soient encore implémentés dans un paradigme
de programmation impérative, une tendance récente consiste à employer un paradigme de
programmation orientée objet pour le développement de codes de calcul scientifique. L’intérêt
majeur de cette technique est de pouvoir atteindre une forte flexibilité à la fois pour
le développement mais aussi pour l’utilisation. La programmation orientée objet repose
sur une représentation des concepts et des entités du domaine d’application sous la forme
d’objets dont les interactions constituent l’exécution du programme. Le code regroupe un
ensemble de classes permettant de décrire les attributs et les méthodes des objets. L’ensemble
des valeurs des attributs constituent l’état d’un objet et les méthodes expriment les
interactions possibles avec cet objet.
La programmation orientée objet se base sur les quatre concepts fondamentaux que sont
l’encapsulation, l’héritage, l’abstraction et le polymorphisme. Leur mise en œuvre permet,
lors de la conception, de décrire les relations entre les différentes classes. Selon le principe de
l’encapsulation, les interactions avec les objets se font uniquement en utilisant ses méthodes
et non directement ses données. Cela permet de garantir l’intégrité des propriétés de l’objet
en cachant ses données. Par le principe d’héritage, il est possible de créer une classe à partir
de classes existantes pour éventuellement leur ajouter de nouvelles propriétés ou fonctionnalités.
De manière similaire, l’abstraction permet d’exposer uniquement les informations
utiles et de laisser les détails pour des niveaux d’abstractions inférieurs. Cela permet d’accroître
l’efficacité des objets ainsi que de réduire leur complexité. Enfin le polymorphisme
consiste en la redéfinition de méthodes à travers les classes. L’exécution d’une méthode est
réalisée par son plus proche parent dans la hiérarchie de classes si elle n’est pas définie par
la classe de l’objet. L’intérêt de l’utilisation de ce type de paradigme de programmation est
que cela permet aux utilisateurs et développeurs de manipuler des objets aussi proches que
possibles des concepts physiques ou mathématique qu’ils représentent.
La conception d’un programme orienté objet consiste en la description de l’ensemble des
classes avec leurs attributs et leurs méthodes ainsi que leurs relations. En plus de l’héritage,
des relations de composition et d’agrégation figurent parmi les plus couramment utilisées.
Elles permettent de décrire la combinaison de plusieurs éléments pour en former un plus
complexe. La composition se distingue de l’agrégation par une notion de propriété forte. Les
objets qui composent un autre plus complexe n’ont pas d’existence en dehors de ce dernier.
Découpage sémantique des concepts mathématiques
Pour le développement de codes de calculs scientifiques, il est nécessaire d’employer une
méthodologie de conception plus spécifique, comme celle décrite par Labbé et al. (2004).
Dans leur approche, les auteurs se focalisent sur la résolution de systèmes d’équations
différentielles par des méthodes d’algèbre linéaire. Ils aboutissent à une décomposition d’un
problème de résolution d’équations aux dérivées partielles générique en différents concepts :
664.1. Développement d’une librairie de calcul scientifique
Problème : Il correspond au problème mathématique global que l’on cherche à résoudre ;
Opérateur : Généralisation de la notion mathématique d’opérateur, il définit un opérateur
mathématique élémentaire comme le gradient ou le laplacien et, plus généralement,
un terme d’une équation du problème. Il peut être vu comme un sous-problème
élémentaire.
Variable : Ce sont les entités mathématiques mises en relation par les opérateurs au sein
du problème, qu’elles soient données ou inconnues.
Domaine : Il décrit le contexte formel sur lequel sont définies les variables. Il comprend
la spécification d’une géométrie et des conditions aux limites.
Différents niveaux d’abstraction
Toujours en suivant la méthodologie de Labbé et al. (2004), nous introduisons différents
niveaux d’abstractions pour les concepts définis ci-dessus. Le point clé de cette conception
est un découplage des concepts abstraits, des méthodes de résolution et des algorithmes.
Ainsi, l’utilisateur manipule les éléments du niveau d’abstraction le plus élevé, qui correspondent
aux concepts mathématiques des problèmes, opérateurs, variables et domaines.
Un second niveau est constitué des algorithmes de résolution et de la discrétisation des
variables. Enfin, un dernier niveau regroupe les implémentations des méthodes spécifiques
au stockage des données des variables ainsi qu’à l’architecture permettant de réaliser les
calculs. L’intérêt majeur est que les opérations réalisées à un niveau ne dépendent pas de
la manière dont fonctionnent les autres niveaux. En particulier, il est aisé de changer de
méthode de résolution ou d’architecture sans que l’utilisateur n’ait à modifier son code.
Couplage faible et cohésion forte
La structure basée sur un découpage sémantique et en niveaux d’abstraction permet
d’obtenir une forte cohésion des différents composants. Les fonctionnalités de haut niveau
(employées par l’utilisateur) font appel à des fonctions de niveau inférieur jusqu’à arriver
au niveau le plus bas où les calculs sont effectués dans des fonctions élémentaires réalisant
une tâche précise.
Parallèlement, cela permet un couplage faible des différentes parties. A un niveau donné,
les fonctionnalités ne sont pas interdépendantes. Ainsi, les effets de bords sont limités lors du
développement et de la maintenance du code. Du point de vue de l’utilisation, les éléments
sont autosuffisants à travers leurs niveaux d’abstraction.
En suivant ces principes, il est possible de changer d’algorithme pour une méthode donnée
sans avoir à modifier le reste des éléments. De même, plusieurs versions d’un même
algorithme peuvent cohabiter, du moment qu’ils implémentent la même interface. Comme
remarqué dans le chapitre 1, les architectures évoluent rapidement et une implémentation
peut devenir inutilisable en changeant d’architecture. D’où l’importance d’une grande flexibilité
car il sera aisé d’introduire une nouvelle version pour une architecture donnée ou, au
contraire, d’écarter une version incompatible avec l’architecture courante au moment du
déploiement. D’autre part, les choix de conception et de langages doivent garantir une por-
674. Développement d’un code multiarchitectures
tabilité du code suffisante. Ainsi, face à une nouvelle architecture, le code existant devrait
pouvoir être simplement reconfiguré et non réécrit.
Schéma d’utilisation
Du point de vue de l’utilisation, le code se décompose selon les étapes suivantes :
1. Description d’un problème à partir d’un domaine sur lequel sont définies des variables
utilisées par des opérateurs.
2. Initialisation du problème à travers la discrétisation et l’initialisation des variables.
Cette étape consiste essentiellement en l’allocation des zones mémoires ainsi qu’au
branchement des différentes méthodes numériques parmi l’ensemble des versions disponibles.
3. Résolution du problème en appliquant ses opérateurs sur leurs variables.
Ces étapes s’organisent dans le diagramme d’utilisation de la figure 4.1.
Résout
Problème
Applique
Opérateur
Initialise
Problème
Discrétise
Opérateur
Discrétise
Variable
Définit
Problème
Définit
Opérateur
Définit
Variable
Définit
Domaine
Utilisateur
1. Description
2. Initialisation
3. Résolution
Figure 4.1. – Diagramme de cas d’utilisation.
4.1.2. Conception détaillée
Les entités issues du découpage en concepts et en différents niveaux d’abstraction sont
décrites dans le diagramme de classe présenté en figure 4.2.
684.1. Développement d’une librairie de calcul scientifique
Problems
Domains
Operators Variables
Parallelism
Tools
Simulation
current time
current iteration
time step
end time
advance time
Problem
domain
list of variables
list of operators
simulation manager
setUp
solve
<>
Domain
dimension
list of Topologies
Mesh
position
grid
ghosts
Variable
nb components
domain
dict of (Topology, DVariable)
init function
discretize
DVariable
topology
data
<>
Operator
input variables
output variables
discretize
setUp
finalize
<>
DOperator
input discrete variables
output discrete variables
apply
finalize
Topology
domain
mesh
MPI process layout
<< neighbors interface>>
NumMethod
compute
scales fftw h5py numpy mpi4py
External Libraries
n
n n
1
1
n
n
1
1
1
1
n
1
n
1
1
uses
uses
uses uses
uses
Abstract level
Algorithm level
Method level
Figure 4.2. – Diagramme de classe.
694. Développement d’un code multiarchitectures
Domaine
Le domaine correspond à la définition mathématique sur lequel sont définies les variables
et équations du problème. Cette entité nous permet de gérer la distribution des données et
des calcul dans les simulations parallèles. En effet, dans ce cadre, le domaine est distribué
à travers l’ensemble des processeurs et chaque sous-domaine est affecté à un processus.
Variables
Une variable est définie sur un domaine spatial. Les vecteurs et les scalaires ne sont pas
distingués et diffèrent uniquement par leur nombre de composantes. Il est possible d’avoir
différentes discrétisations d’une même variable selon leurs résolutions et leurs découpages
à travers les différents processus. Les données discrètes des variables sont référencées indé-
pendemment de leur stockage par un pointeur.
Opérateurs
Un opérateur est défini à partir de ses variables d’entrée et de sortie. Un opérateur
discret est créé en fonction d’une paramétrisation de la méthode numérique, et fait appel à
un ou plusieurs algorithmes de calcul et méthodes numériques en utilisant les données des
variables discrètes.
Méthodes numériques
Ces entités de bas niveau permettent de réaliser des calculs sur les données numériques
indépendemment de leur emploi et de leur provenance. Les schémas numériques issus des
méthodes de résolution, comme les intégrateurs en temps, les schémas de différences finies
ou les formules de remaillage sont implémentés de manière à traiter des données numériques
à partir d’un espace mémoire générique. En pratique, diverses versions d’une même méthode
selon le stockage des données employé peuvent cohabiter, la version appropriée étant choisie
à l’initialisation des opérateurs.
Problèmes
Comme son équivalent mathématique, un problème est construit à partir d’une liste
d’opérateurs, de variables et de domaines. Il constitue une partie de l’interface utilisateur
de notre librairie et permet de discrétiser l’ensemble des entités ainsi que de piloter la
simulation numérique tout au long de la boucle en temps par l’application successive des
différents opérateurs.
4.1.3. Fonctionnement de la librairie
Langages de programmation
La conception de la librairie de calcul, donnée en sections 4.1.1 et 4.1.2, est indépendante
de tout langage de programmation. Étant données les caractéristiques requises par
704.1. Développement d’une librairie de calcul scientifique
notre code, le choix s’est rapidement tourné vers le langage Python. C’est un langage qui
permet l’utilisation des paradigmes de programmation impératifs, objets et fonctionnels, ce
qui contribue à la flexibilité du code. Python est un langage interprété, ce qui facilite le
développement par l’absence d’étape de compilation. Python est présent par défaut sur de
nombreux systèmes et grâce à un mécanisme de gestionnaire de modules, il est aisé d’installer
les dépendances du code sur n’importe quelle machine et sans les droits d’administrateur
du système. Ce langage est caractérisé par une large base de bibliothèques relatives à de
nombreux domaines, en particulier pour le calcul scientifique. Il tend à être de plus en plus
utilisé pour le développement de codes de calcul parallèles. Toutefois, il présente l’inconvé-
nient, dû à l’aspect interprété, de conduire à des performances numériques de base assez
médiocres dans le cadre d’une utilisation naïve. Il existe de nombreux moyens d’améliorer
ces performances comme les modules NumPy et Cython. Le premier fournit un grand nombre
d’outils et d’algorithmes pour le calcul scientifique. Le second propose des optimisations
plus poussées permettent de retrouver des performances équivalentes à celles obtenues avec
des langages compilés. D’autre part, Python est généralement utilisé comme interface pour
l’utilisation de différentes librairies compilées et optimisées. Le surcoût de la couche Python
est négligeable et on obtient directement les performances de ces librairies. De nombreux
exemples de code de calcul scientifique sont écrits en Python (Pérez et al., 2011 ; Rashed
et al., 2012 ; Logg et al., 2012).
Dépendances externes
Fort de toutes ces caractéristiques, ce langage est en plein essor dans la communauté
scientifique. Cela se traduit par une très forte activité des développeurs qui fournissent
de très nombreux modules sans cesse améliorés. La plupart des librairies traditionnelles
possèdent une interface Python qui sont bien souvent augmentées de fonctionnalités ou
de simplifications inhérentes au langage. En particulier, nous utilisons le module MPI4Py
qui permet d’utiliser la librairie d’envoi de message MPI pour le parallélisme à mémoire
distribuée. De même, la librairie H5py permet l’écriture et la lecture de données numériques
au format HDF5.
Dans le but de l’exploitation de machines de calcul parallèles, nous intégrons différents
niveaux de parallélisme. Nous verrons par la suite que l’utilisation d’une carte graphique
revient à l’expression d’un parallélisme à mémoire partagée. Nous détaillerons également
les mécanismes mis en place pour l’utilisation de machines à mémoire distribuée, à travers
la librairie MPI.
D’autre part, Python permet de réaliser simplement des interfaces avec des langages
compilés comme le C ou Fortran. Cela nous permet d’utiliser les librairies fftw pour les
transformées de Fourier des méthodes spectrales ainsi que l’implémentation en Fortran de
la méthode semi-Lagrangienne développée par Lagaert et al. (2014).
714. Développement d’un code multiarchitectures
Fonctionnement global
Nous achevons cette partie par une illustration de son utilisation à travers un exemple
simple permettant la résolution d’un problème de transport. Un exemple de script minimal
dont la majorité du code concerne l’étape de description du problème est donné en
figure 4.3. Les deux fonctions permettent d’initialiser les variables. Le problème est créé
avec un seul opérateur dont les calculs s’effectuent à une résolution de 1283
lors de chacune
des 10 itérations. Dans cet exemple simple, l’opérateur d’advection se construit sur
ses paramètres de résolution par défaut. En pratique, il convient de donner les détails de
la méthode numérique comme l’ordre d’intégration en temps ou la formule de remaillage et
éventuellement des spécifications en rapport avec l’architecture employée.
Comme le montre l’exemple, l’interface utilisateur ainsi développée permet d’exprimer,
à travers les classes Python, une sémantique proche du langage mathématique. Cela rend
l’utilisation proche de celle proposée par un langage dédié. Un tel langage constitue l’expression
idéale d’une interface utilisateur car il consiste en la définition d’un nouveau langage
de programmation dont la sémantique est issue du domaine d’application du programme.
Ainsi, l’utilisateur exprime ses besoins dans un langage ayant un sens pour l’application,
ce qui conduit à une grande simplicité d’utilisation. Cependant, le développement de ce
langage est assez difficile. Une approche plus simple consiste à embarquer seulement de
nouveaux éléments de syntaxe dans le langage du programme (Mernik et al., 2005).
La librairie décrite précédemment nous permet, de par sa conception, d’intégrer un
module pour l’exploitation de cartes graphiques sans perte de portabilité sur les machines
dépourvues de ce matériel. Les GPU diffèrent sensiblement des processeurs classiques tant
par leurs architectures que par leurs modèles de programmation. Dans cette seconde partie,
nous détaillons le fonctionnement de ces cartes.
4.2. Calcul générique sur carte graphique
4.2.1. Description du matériel
Fonctionnement des cartes graphiques
Les cartes graphiques que nous utilisons aujourd’hui ont été introduites à la fin des
années 90. La fonction principale de ces cartes est de générer des images bidimensionnelles
destinées être affichées sur un écran. Dès le milieu des années 90, les cartes sont capables
de gérer un contenu tridimensionnel et sont principalement pour l’usage des jeux vidéo et
à l’infographie. Dans les années 2000, l’augmentation des performances des cartes grand
public rend ce matériel très compétitif en termes de capacité de calcul, relativement à leur
coût d’achat. Cela conduit à l’émergence du GPGPU, acronyme anglais signifiant calcul
générique sur processeur graphique.
Dans le cadre du rendu 3D, une carte graphique effectue un traitement en chaîne, représenté
en figure 4.4. Premièrement, le Vertex processor, calcule un ensemble de points
724.2. Calcul générique sur carte graphique
Script Python :
im p o r t parmepy a s pp
d e f s 0 ( r e s , x , y , z , t = 0. ):
r e s = . . .
r e t u r n r e s
d e f u0 ( r e s , x , y , z , t = 0. ):
r e s = . . .
r e t u r n r e s
# Domaine
O = pp . Box ( o r i g i n =[0 , 0 , 0 ] ,
l e n g t h =[1 , 1 , 1 ] )
T = pp . Simu ( t i n i t =0. , t e n d =1. ,
n b I t e r =10))
# V a r i a b l e s
u = pp . F i e l d ( domain=O,
v e c t o r=True ,
f o rm u l a=v _ i n i t )
s = pp . F i e l d ( domain=O,
v e c t o r=F a l s e ,
f o rm u l a=s _ i n i t )
# O p e r a t e u r s
a dvec = pp . A d v e c t i o n (
s , v e l o c i t y=u ,
r e s o l u t i o n =[128 , ] ∗ 3 )
# P r o b l ème
pb = pp . P roblem (
o p e r a t o r s =[ advec , ] ,
simu=T)
# I n i t i a l i s a t i o n
pb . s e t u p ( )
# Ré s o l u t i o n
pb . s o l v e ( )
Formalisme mathématique équivalent :
s0(x) = . . .
u0(x) = . . .
Ω = [0; 1]3
T = [0; 1]
u : Ω × T 7→ R
3
u(x, t = 0) = u0(x)
s : Ω × T 7→ R
s(x, t = 0) = s0(x)
∂s
∂t + (u · ∇)s = 0
Figure 4.3. – Exemple de script utilisateur
734. Développement d’un code multiarchitectures
à partir de la géométrie à afficher. Ensuite, les objets tridimensionnels sont projetés sur
un ensemble de pixels afin d’éliminer les parties cachées par la perspective. Les pixels sont
ensuite transformés par le Fragment processor, notamment par l’application de textures.
Enfin, les pixels sont assemblés dans la grille de pixels qui constituent l’image à afficher sur
l’écran. Aux débuts du calcul générique sur GPU, la programmation des cartes s’effectuait
en détournant cet enchaînement d’étapes par le développement de fonctions spécifiques
destinées à être exécutées par le Vertex processor et le Fragment processor.
Vertex
Processor Rasterizer
Fragment
Processor
Output
Assembler Écran
Données brutes
Objets
3D
Pixels
Pixels
Image calculés
Figure 4.4. – Transformations en chaîne pour le rendu graphique
Architecture des cartes graphiques
Ce matériel spécifique est composé de nombreux éléments dont l’architecture diffère des
processeurs classiques. Les composants principaux d’une carte graphique sont le processeur
graphique et la mémoire vidéo. Les processeurs graphiques se caractérisent par un très
grand nombre d’unités de calcul permettant de réaliser les opérations sur les sommets de
la géométrie ainsi que des transformations des pixels. Ces unités sont spécialisées dans le
traitement de données vectorielles jusqu’à quatre composantes (coordonnées spatiales ou
canaux de couleurs d’un pixel). D’autre part, les unités de calculs réalisent de manière
efficace des opérations simples sur ces données comme les additions, multiplications et
produits scalaires. La mémoire vidéo est généralement divisée en deux zones distinctes.
Une première partie permet des accès classiques en lecture et écriture et une seconde est
spécialisée en lecture ou en écriture pour le stockage de données de textures 2D ou 3D.
Comparativement à un processeur classique, un GPU permet un très haut débit de tâches
élémentaires et indépendantes effectuées en parallèle par les unités de calcul (UC dans la
figure 4.5). Ces dernières se partagent différents niveaux de cache. La figure 4.5 compare
les représentations d’un processeur multicœur, 4.5a et d’un GPU, 4.5b. Dans les deux cas,
seul le niveau de cache le plus haut est représenté. Alors que sur CPU, le nombre de cœurs
dépasse rarement la dizaine, il atteint plusieurs milliers sur un GPU. D’autre part, les CPU
peuvent accéder à la mémoire globale du système alors que la mémoire disponible sur un
GPU est généralement inférieure à 8 GByte.
744.2. Calcul générique sur carte graphique
Mémoire
Cache
Contrôleur
UC
UC
UC
UC
(a) CPU
Mémoire
UC
Contrôleur
Cache
(b) GPU
Figure 4.5. – Comparaison haut niveau de l’architecture d’un CPU et d’un GPU
L’intégration de la carte graphique au système principal se fait par une connexion à
la carte mère par PCI Express dont le débit varie de 1 à 16 GByte/s selon la version.
Cela constitue bien souvent un goulet d’étranglement pour les applications car le temps de
transfert des données est bien plus long que le temps de leur traitement sur la carte.
4.2.2. Différentes méthodes de programmation
Le calcul générique sur GPU a été grandement simplifié par les interfaces de programmations.
Elles permettent de s’affranchir de la chaîne de traitement graphique, représentée
en figure 4.4, au profit d’une exploitation directe des ressources des cartes. Le principe gé-
néral d’un calcul sur GPU est de traiter des données régulières (proches d’une image) dont
les algorithmes se décomposent selon un modèle hiérarchique en sous-blocs qui sont euxmêmes
constitués d’un ensemble de tâches élémentaires par unité de donnée. Il existe deux
grandes familles de modèles de programmation des GPU dont les principaux représentants
sont évoqués ci-après.
Programmation par directives
La programmation par directive sur GPU est très similaire à l’utilisation de l’interface
de programmation parallèle OpenMP pour les architectures à mémoire partagée. Les
standards de programmation les plus répandus sont HMPP, introduit par Dolbeau et al.
(2007), et OpenACC, qui est désormais inclus dans OpenMP depuis sa version 4.0 (2013).
Ils permettent d’exécuter des parties du code, le plus souvent des boucles, sur des accéléra-
754. Développement d’un code multiarchitectures
teurs par l’insertion de directives de compilation spécifiques. L’intérêt majeur de ce modèle
est de pouvoir utiliser ces accélérateurs sans avoir à réécrire le code concerné. Cependant
cela empêche une gestion fine de la transcription vers les instructions GPU, cette partie
du travail étant effectuée par le compilateur. Le support est généralement assuré par des
compilateurs commerciaux fournis notamment par CAPS Entreprise pour HMPP ou PGI
pour OpenACC. Toutefois, ce dernier est en cours l’intégration au compilateur libre GCC.
Programmation directe
À l’opposé de la famille précédente, se trouve la programmation utilisant un langage
spécifique. Il en existe plusieurs pour les GPU dont les plus utilisés sont CUDA (Nvidia,
2014) et OpenCL (Khronos, 2014). Le premier est développé par la société Nvidia pour
l’utilisation exclusive de ses cartes. Le second est un standard de programmation ouvert
permettant l’exploitation de processeurs multicœurs, que ce soit des processeurs traditionnels,
des cartes graphiques ou des coprocesseur. Les deux langages sont assez proches et se
basent sur un modèle de programmation qui reflète l’architecture du matériel. Cependant,
OpenCL bénéficie d’une portabilité bien plus grande car il permet d’exploiter non seulement
les cartes graphiques mais aussi les processeurs multicœurs. CUDA comme OpenCL
bénéficient d’interfaces performantes en Python (Klöckner et al., 2012).
4.2.3. Les modèles de programmation OpenCL
Le standard de programmation OpenCL permet de développer des modèles de parallé-
lisme par tâches et de données sur processeurs multicœurs. La librairie fournit une interface
de programmation de haut niveau permettant la gestion des calculs et des ressources ainsi
que le profilage des applications. Les calculs de bas niveau sont implémentés en un langage
basé sur le C99. Une application OpenCL se doit de définir les quatre modèles hiérarchiques
suivants. Les termes techniques sont systématiquement traduits dans cette partie
mais pourront être utilisés en anglais dans la suite.
Le modèle de plateforme
Du point de vue OpenCL, une plateforme est constituée d’un hôte (host) et de un ou
plusieurs appareils (devices). Ces derniers regroupent, de manière générique, bon nombre
de matériel multicœur comme les cartes graphiques mais aussi les processeurs classiques ou
les processeurs spécifiques. L’implémentation consiste en une partie de code exécutée par
la machine hôte (host) et capable d’envoyer et d’exécuter des noyaux de calcul (kernels)
aux appareils (devices). Le code des noyaux est compilé de manière spécifique aux appareils
sur lequel il sera exécuté. Les noyaux sont exécutés par les cœurs (processing elements) de
chaque unité de calcul (compute unit), ce qui reflète l’organisation matérielle des unités de
calculs d’un GPU, comme illustré par la figure 4.6.
764.2. Calcul générique sur carte graphique
Host
Device
Processing element
Compute unit
Figure 4.6. – Modèle de plateforme OpenCL
Le modèle d’exécution
On distingue deux catégories d’unités d’exécution : le programme exécuté par la machine
hôte et les noyaux. À chaque appareil (device) est associé une ou plusieurs files d’attente de
commandes dans lesquelles sont insérées les transferts de données et les appels aux noyaux.
Ces derniers sont définis par un état d’exécution (soumis, en attente, démarré, terminé,
. . .) dont les durées entre transitions sont mesurables par l’outil de profilage intégré. Des
dépendances entre les éléments peuvent être données explicitement, ce qui conduit à l’expression
d’un parallélisme par tâche à travers une exécution asynchrone. La caractéristique
principale est que chaque noyau est exécuté, par un cœur de calcul, comme une fonction
en un point d’un espace d’indice représenté sur la figure 4.7. Cet espace est décomposé en
un ensemble de groupes de travail (work-groups) contenant plusieurs éléments de travail
(work-items). À chaque élément de travail (work-item) est associé un cœur de calcul.
Espace global
Work-group
GX
GY
0 1 2 3· · ·
0 1 · · · NX
0
1
2
3
.
.
.
0
1
.
.
.
NY
· · ·
· · ·
· · ·
.
.
.
.
.
. .
.
.
0 1 2 · · ·
0
1
2
.
.
.
WX
WY
Figure 4.7. – Espace d’indices OpenCL. Espace 2D de taille GX ×GY impliquant NX ×NY
work-groups composés de WX × WY work-items, avec G• = N•W•
774. Développement d’un code multiarchitectures
L’espace d’indices est un espace cartésien mono-, bi- ou tridimensionnel. Chaque élément
de travail (work-item) est identifié de manière unique par ses coordonnées dans l’espace
global ou par le couple des coordonnées du groupe (work-group) et d’une coordonnée locale
au groupe (work-groups), comme illustré par la figure 4.7. Les tailles de l’espace global
et des groupes de travail sont données en paramètres à chaque exécution d’un noyau. Le
parallélisme de données est obtenu en reliant l’espace d’indices et l’indexation des données.
Différents niveaux de synchronisation sont possibles. L’exécution des éléments de travail
(work-items) est concurrente au sein d’un groupe (work-group). Il est possible de synchroniser
les éléments au sein d’un même groupe à l’aide de barrières. Par contre il est impossible
de synchroniser les groupes entre eux, de même qu’il n’est pas possible de spécifier l’ordre
dans lequel ils seront exécutes ni de savoir lesquels seront exécutés simultanément. Du côté
de l’hôte, la synchronisation globale se fait par l’intermédiaire de la file d’attente et de l’état
de chaque noyau de calcul.
Le modèle de mémoire
Dans ce modèle, la mémoire de l’hôte est dissociée de celle des appareils. Cette dernière
est décomposée en quatre région distinctes :
Globale : niveau le plus haut, il est partagé en lecture et écriture par tous les éléments
de travail de tous les groupes (∼ 1 GByte).
Constante : mémoire accessible en lecture seule par les éléments de travail au cours de
l’exécution. De taille assez faible, elle permet de stocker des constantes numériques
(∼ 10 kByte).
Locale : niveau intermédiaire partagé au sein d’un groupe de travail. Ce niveau peut être
utilisé explicitement comme un cache (∼ 10 kByte).
Privée : niveau le plus bas, il est dédié à un élément de travail et inaccessible aux autres
(< 1 kByte).
La mémoire globale ne peut contenir que des Buffers ou des Images. Les premiers sont
des zones mémoires contiguës destinées à un usage générique comme un tableau d’éléments.
Les seconds sont stockés dans la mémoire dédiée aux textures sous la forme d’une structure
de données complexe et dont les accès, en lecture seule ou écriture seule, sont gérés par des
fonctions OpenCL prédéfinies. Ce modèle hiérarchique est schématisé en figure 4.8. Comme
nous le verrons par la suite, une gestion précise des transferts de données entre ces différents
niveaux de mémoire est fondamentale pour l’amélioration les performances.
Le modèle de programmation
Afin d’exploiter tous les modèles définis précédemment, une application OpenCL se
décompose selon trois couches dont il est nécessaire de décrire tous les niveaux. Au niveau de
la plateforme, le programme hôte explore l’architecture disponible et un contexte OpenCL
doit être créé afin de lier le ou les appareils utilisés avec l’hôte et pour créer les files de tâches
associées à chaque appareil. Le compilateur OpenCL permet de compiler les sources des
noyaux de calcul spécifiquement pour un appareil ciblé. Au niveau des modèles de mémoire
et d’exécution, le programme est constitué de la gestion des files d’évènements ainsi que de
784.2. Calcul générique sur carte graphique
Mémoire globale du système
host
Mémoire globale Constante
device
work-group
Mémoire locale
P.
w.i.
P.
w.i.
P.
w.i.
P.
w.i.
Figure 4.8. – Modèle hiérarchique OpenCL pour la mémoire
transferts de données entre les mémoires de l’hôte et des appareils. Un schéma d’exécution
est représenté en figure 4.9. Dans l’idéal, la conception des algorithmes doit permettre une
gestion asynchrone des évènements afin de maximiser l’utilisation des composants. Cette
dernière est maximale lorsque des calculs sont effectués simultanément sur les appareils et
sur l’hôte ainsi que pendant des transferts de données.
. . .
Initialisation OpenCL
Compilation
Transferts
Exécution des kernels
Calculs
Host
Device
Création de la
file d’exécution
Figure 4.9. – Schéma d’exécution OpenCL
La figure 4.9 représente les durées d’exécution à titre d’illustration car les proportions
entre les différentes étapes ne reflètent pas nécessairement les temps observés dans une
application.
794. Développement d’un code multiarchitectures
4.2.4. Analyse de performances par le modèle roofline
En préambule à l’étude des performances de l’implémentation, il est nécessaire d’explorer
les performances atteignables par le matériel. Le code est développé et exploité sur
différents types de machines depuis un portable jusqu’à un serveur de calcul. Une partie des
caractéristiques techniques des cartes graphiques sur lesquelles le code a été exploité sont
présentées dans le tableau 4.1. Les deux premières cartes sont comparables et ont permis
essentiellement les développements du début de ce travail. La carte K20m est bien plus
récente que les deux autres et bénéficie de technologies bien plus avancées.
Carte AMD Radeon AMD Radeon Nvidia
HD 6770M HD 6900 Series K20m
Type de machine portable bureau serveur
Date de mise sur le marché 01/2011 12/2010 01/2013
Taille mémoire (GByte) 1 1 5
Bande passante max. (GByte/s) 57.6 160 208
Puissance (SP) (GFLOPS) 696 2 253 3 519
Puissance (DP) (GFLOPS) Non supporté 563 1 173
Tableau 4.1. – Comparaison de différentes cartes graphiques
Les études de performances des noyaux de calcul présentées dans la suite sont réalisées
à travers le modèle roofline introduit en section 1.2.2. Nous donnons ici le modèle pour
les cartes Radeon 6770M et K20m sur les figures 4.10 en utilisant les données théoriques
mais aussi des mesures de performances par des programmes de test. Les deux données
nécessaires à l’élaboration du roofline sont la bande passante maximale et la puissance de
calcul maximale. La première est obtenue à l’aide d’un kernel réalisant une copie d’un buffer
à un autre. La puissance maximale, quand à elle, est obtenue à partir d’un kernel ayant
une grande intensité opérationnelle. Le kernel que nous utilisons réalise 50 instructions
d’additions et multiplications sur 4 variables de type vecteur à 4 composantes en simple
ou en double précision, le tout dans une boucle de 20 itérations, soit 32 000 opérations par
work-item. Les performances mesurées sont résumées dans le tableau 4.2.
La capacité de certaines cartes graphiques à effectuer des calculs en double précision
est assez récente. La raison principale est que la précision numérique n’est pas une priorité
dans le cadre de l’affichage d’un contenu graphique. La principale contrainte est d’afficher
des images sur l’écran en un temps le plus court possible. Cela est poussé à l’extrême dans
certains modèles qui ne sont pas conformes à la norme IEEE 754 pour le calcul en virgule
flottante. Sur la majorité des cartes, des options de compilations spécifiques permettent
d’autoriser le compilateur à ne pas respecter cette norme. Toutefois, les cartes qui la supportent
possèdent généralement moins de cœurs capables de traiter la double précision que
de cœurs pour la simple précision ce qui conduit à des performances en double précision
bien inférieures à la simple précision.
Le mécanisme ECC, de l’anglais Error Correction Code, activé par défaut sur les cartes
Nvidia permet de vérifier et corriger, à l’exécution, les accès aux données en mémoire et ainsi
remédier à d’éventuelles erreurs dues à des facteurs extérieurs. Ce mécanisme consomme
804.2. Calcul générique sur carte graphique
Théorique
Mesuré
Mesuré (sans ECC)
Simple précision
Double précision 101
102
103
104
1 10 100
Puissance maximale (GFLOPS)
Intensité opérationnelle (FLOP/Byte)
(a) ATI Radeon 6770M
101
102
103
104
1 10 100
Puissance maximale (GFLOPS)
Intensité opérationnelle (FLOP/Byte)
(b) Nvidia K20m
Figure 4.10. – Modèle roofline
Bande passante (GByte/s) ATI Radeon 6770M Nvidia K20m
Théorique 57.6 208
Mesurée 36.9 (64%) 152 (73%)
ECC désactivé – 172 (83%)
Puissance, simple précision (GFLOPS)
Théorique 696 3 519
Mesurée 632 (91%) 3 350 (95%)
Puissance, double précision (GFLOPS)
Théorique – 1 173
Mesurée – 1 173 (100%)
Tableau 4.2. – Performances mesurées.
814. Développement d’un code multiarchitectures
12.5% de la mémoire de la carte et réduit d’environ 12% la bande passante, comme le montre
les résultats du tableau 4.2.
Dans cette dernière partie, nous détaillons la mise en pratique de l’utilisation des cartes
graphiques dans la librairie de calcul ainsi que la principale mesure de performances.
4.3. Utilisation de cartes graphiques dans la librairie
L’implémentation de ces modèles de programmation est réalisée à travers le module
Python PyOpenCL et s’insère dans le diagramme de classe présenté en figure 4.2, page 69.
La figure 4.11 donne les nouvelles classes ainsi que leurs relations avec le modèle existant. Le
modèle de mémoire est implémenté dans la classe GPUDVariable et encapsule un pointeur
vers un objet mémoire GPU ainsi qu’une interface pour les transferts de données avec
l’hôte. Le modèle de plateforme est intégré dans la classe outil ClEnvironment et permet
de créer et de gérer les objets du le contexte et de la file d’attente des appareils ainsi que la
compilation du code OpenCL. Enfin, le modèle d’exécution est décrit par les interactions
entre les GPUDOperators. Les évènements créés par les appels aux kernels sont associés aux
variables et permettent d’exprimer un parallélisme par tâches. L’intérêt majeur de séparer
l’implémentation GPU dans un module distinct est de pouvoir s’affranchir de cette partie
du code sur les machines dépourvues d’accélérateurs et d’implémentation OpenCL et ainsi,
garantir une portabilité suffisante à la librairie. D’autre part, grâce à cette séparation, un
module GPU basé sur le langage CUDA, par exemple, pourrait être intégré à la librairie
sans aucun impact sur le reste du code.
Nous démontrons ici la simplicité d’ajout de la prise en compte d’une nouvelle architecture
particulière à la librairie de calcul. En effet, seuls les éléments dépendants de cette
architecture sont à implémenter.
Conclusion
Dans ce chapitre nous avons obtenu une librairie de calcul présentant une grande souplesse
d’utilisation ainsi qu’une forte capacité d’adaptation à des architectures hétérogènes,
comme les GPU. L’obtention de ces caractéristiques est possible à travers l’utilisation d’un
paradigme de programmation orientée objet ainsi qu’une conception basée sur une stratégie
de découpage sémantique des concepts mathématiques exprimés à travers différents niveaux
d’abstraction. La librairie ainsi conçue permet une grande flexibilité pour le développement
grâce à un faible couplage des différentes parties et à une forte cohésion à travers les niveaux
d’abstraction. Le choix du langage de programmation a été fait en fonction des caractéristiques
de la librairie, qui s’expriment à travers la conception, et les objectifs d’utilisation
du code. Ainsi, le choix s’est porté sur le langage Python dont un des avantages est de
proposer de nombreux modules pour le calcul scientifique comme le module NumPy ainsi que
des interfaces vers des librairies externes comme les modules PyOpenCL pour OpenCL et
MPI4Py pour MPI
824.3. Utilisation de cartes graphiques dans la librairie
Operators Variables
Tools
<>
DOperator <>
NumMethod
DVariable
<>
GPUDOperator
opencl environment
GPUDVariable
gpu data
to host
to device
ClEnvironment
opencl platform
opencl device
opencl context
opencl queue
build sources
GPUKernel
sources
opencl program
compute
CL sources
n
1
n
build
GPU
Figure 4.11. – Diagramme de classe pour le module GPU
L’exploitation des cartes graphiques semble pertinent au regard des reports de puissance
de calcul développée dans la littérature que ce soit de manière théorique par le matériel
en lui-même ou à travers des applications concrètes. Comme nous le verrons dans le chapitre
5, la structure de donnée nécessaire à la mise en œuvre de la méthode particulaire
avec remaillage s’adapte bien à un traitement par cartes graphiques. D’autre part, les sché-
mas numériques associés à la méthode sont compacts et locaux du fait de l’utilisation du
splitting dimensionnel. Le traitement d’un point ne requiert seulement que quelques points
voisins dans une seule direction de l’espace. Enfin, la majeure partie des opérations du remaillage
consistent en des additions et multiplications en nombre réels qui sont effectuées
de manière très efficace par les cartes graphiques.
835. Mise en œuvre sur cartes
graphiques
La méthode numérique, exposée au chapitre 2, semble bien adaptée à l’utilisation de
cartes graphiques dont les principales caractéristiques ainsi que les techniques d’exploitation
ont été détaillés au cours du chapitre 4. L’objectif de ce chapitre est, dans un premier
temps, de présenter les différentes implémentations existantes de méthodes particulaires
avec remaillage sur cartes graphiques afin d’identifier leurs avantages et inconvénients. À
travers l’exploration des travaux existants, l’accent est mis sur les interpolations entre les
particules et le maillage. Une progression se dégage de l’évolution de l’exploitation des
matériels depuis 2008. En effet, les travaux les plus anciens se basent essentiellement sur
les primitives propres au traitement d’images à travers la chaîne de rendu graphique alors
que la tendance actuelle est plutôt à utiliser des structures de données génériques, moins
dépendantes du matériel.
Dans un second temps, nous détaillerons les choix effectués dans le cadre spécifique de la
méthode semi-Lagrangienne d’ordre élevé avec splitting dimensionnel. Ces différents choix
ne dépendent pas du matériel utilisé mais s’appliquent à n’importe quelle carte graphique.
Ainsi, nous conservons le caractère portable de notre code. Une grande partie de ce chapitre
est dédiée à l’étude des performances des principales fonctions des algorithmes issus de la
méthode et de l’impact des optimisations réalisées. Ces dernières sont présentées dans le
cadre concret de la carte graphique K20m mais, dans un souci de portabilité, elles ne sont
généralement appliquées que lors de l’exécution, pendant la phase d’initialisation. En effet,
nous exploitons un des aspects de la programmation sur GPU qui consiste à compiler le
code à l’exécution. Ainsi, le code est développé de manière générique puis, après une prise
de connaissance de la carte employée et de ses caractéristiques, certaines optimisations sont
activées pour la compilation. Sans implémenter une auto-optimisation du code, cette étape
nous permet d’adapter, entre autres, les tailles de l’espace d’indices OpenCL, la charge par
work-item ou encore le schéma d’accès aux données aux spécifications de la carte utilisée.
Enfin, nous illustrerons l’utilisation de la méthode de résolution sur quelques exemples
simples de transport de scalaire en 2D et 3D. Ces exemples permettent une validation de
la méthode de manière qualitative ainsi qu’une description de la répartition des temps de
calcul en vue d’éventuelles optimisations plus poussées.
855. Mise en œuvre sur cartes graphiques
5.1. Implémentations GPU de méthodes
semi-Lagrangiennes
5.1.1. Méthodes semi-Lagrangiennes
Une première implémentation sur GPU d’une méthode semi-Lagrangienne a été proposée
par Rossinelli et al. (2008) pour la simulation de fluides incompressibles en 2D. La diffusion
et l’équation de Poisson sont résolues par différences finies sur la grille et les particules
sont transportées de manière Lagrangienne puis remaillées à l’aide d’une formule du second
ordre M0
4
. Cette implémentation se base sur l’utilisation de la mémoire de textures. Cette
mémoire spécifique aux GPU permet un stockage de pixels de telle sorte que les données
voisines correspondent aux pixels voisins en 2D. Les particules sont représentées par des
pixels où les composantes RGB sont associées respectivement aux positions et la vorticité
des particules. Les auteurs montrent une performance globale de 10 itérations par seconde
pour un problème de taille 1 0242
en simple précision en utilisant une méthode de RungeKutta
du second ordre.
Plus récemment, Rossinelli et al. (2010) présentent des résultats pour des simulations
2D d’écoulements en présence d’obstacles solides. La méthode employée est similaire à celle
utilisée précédemment avec l’ajout de la prise en compte des obstacles par une méthode
de pénalisation. Là encore, le remaillage est effectué par la formule M0
4
en utilisant les
fonctions intrinsèques OpenGL pour le rendu graphique et des textures sont utilisées pour
le stockage des données. L’équation de Poisson est résolue par un solveur spectral utilisant
l’implémentation de la FFT fournie par Nvidia en CUDA dont la résolution occupe 96%
du temps de calcul total. Les simulations considérées pour ces études de performances
impliquent jusqu’à 2 0482 particules en simple précision.
L’inconvénient majeur de l’utilisation des textures est que les données sont arrangées
en tableaux de structures. Ce stockage n’est pas le plus approprié pour des opérations
n’impliquant pas toutes les composantes des éléments. D’autre part, les équivalents 3D de
cette mémoire sont uniquement proposés par les dernières générations de cartes graphiques.
Ainsi, le passage à une méthode de résolution de problèmes 3D nécessite une attention
particulière pour l’exploitation de structures de données essentiellement 2D.
5.1.2. Deux types d’interpolations
Les méthodes semi-Lagrangiennes utilisent deux algorithmes majeurs pour les interactions
entre les particules et le maillage basés sur des interpolations. Une interpolation
maillage-particule permet d’évaluer sur les particules une quantité connue sur le maillage et
inversement pour une interpolation particule-maillage. Le premier type d’interpolation est
utilisé lors de l’advection des particules pour connaître leur vitesse alors que le remaillage
exploite le second type. Stantchev et al. (2008) introduisent les stratégies particle-push
et particle-pull pour réaliser l’étape d’interpolation particule-maillage. Ces deux stratégies
diffèrent au niveau de l’organisation de la charge de travail. La première consiste en un traitement
centré sur les particules dont le principe est de les remailler sur les points de grille
de leur voisinage. Elle permet un calcul simple des points de grille contenus dans le support
865.1. Implémentations GPU de méthodes semi-Lagrangiennes
de la particule à partir de ses coordonnées et permet également, dans un cas tensoriel, une
réutilisation des poids de remaillage. Cependant, des accès conflictuels en mémoire peuvent
survenir lors du traitement en parallèle de plusieurs particules situées dans la même cellule.
La seconde est centrée sur le maillage de telle sorte qu’en chaque point de grille on agrège
les contributions des particules voisines. Le seul avantage de la seconde stratégie est de ne
pas conduire à des accès concurrents en mémoire. Dans cette stratégie, une recherche des
particules les plus proches est nécessaire.
Les méthodes de type particle-in-cell sont basées sur ces interpolations. Pour les interpolations
particule-maillage, la majeure partie des implémentations exploitent des stratégies
particle-pull et relaxent les éventuels problèmes d’accès concurrents par un regroupement
des particules voisines en blocs qui sont traités de manière séquentielle par un même processus.
Ainsi, un tri des particules à deux niveaux est nécessaire, d’abord par blocs puis au
sein d’un bloc. Différentes techniques sont employées comme par exemple le maintien d’une
structure de données triée (Rossi et al., 2012) ou un tri à chaque itération (Kong et al.,
2011). Quelque soit la méthode employée pour le tri, cela implique des réarrangements de
données au gré des déplacements des particules afin d’assurer un haut niveau de localité des
données. Les interpolations de type maillage-particule sont plus simples à mettre en œuvre
puisque l’interpolation se fait sur la grille dont la structure est régulière.
Pour ce qui est des méthodes particulaires avec remaillage, les premières implémentations
GPU exploitaient les primitives OpenGL du rendu graphique. En particulier, Rossinelli et
al. (2008) montrent que le remaillage des particules est bien plus efficace, avec une facteur
d’accélération de 1.5, lorsque qu’il est effectué par le moteur de rendu OpenGL plutôt que
par une implémentation CUDA. Cette implémentation se base sur des objets point-sprites
permettant la génération d’une texture contenant, après exécution du rendu en chaîne, les
sommes des contributions de l’ensemble des point-sprites. Ainsi, l’étape exécutée par le
fragment processor consiste à calculer les pixels de la texture par la formule de remaillage
en fonction de la distance aux point-sprites et de leur valeur. Les auteurs soulignent ici un
inconvénient de l’utilisation du langage CUDA qui est de ne pas permettre une exploitation
des fonctionnalités natives du matériel, en particulier les opérations du rendu graphique.
L’étape du vertex processeur permet, en amont du remaillage, de traiter les conditions aux
bords périodiques par une réplication des particules situées à proximité des bords ainsi que
d’écarter les particules transportant une quantité nulle ou inférieure à un certain seuil.
Cette approche est ensuite complétée (Rossinelli et al., 2010) pour le cas de domaines
ouverts. Les auteurs traitent les particules quittant le domaine local en les écartant au
moment de l’étape du vertex processor qui précède le remaillage. D’autre part, dans leur
implémentation, un remaillage systématique est effectué à chaque itération ce qui fait que
les particules sont toujours situées sur un point de grille au début de l’étape d’advection
et permet ainsi d’éviter une interpolation maillage-particule du champ de vitesse. Une
interpolation reste nécessaire pour la seconde étape du schéma d’intégration Runge-Kutta
du second ordre.
Une étude spécifique de l’interpolation maillage-particule est menée par Rossinelli et al.
(2011) sur des architectures multicœurs CPU et GPU. Comme précédemment, l’implémentation
GPU se base sur un stockage des particules en mémoire de textures. Les données
d’une même particule ne sont plus stockées dans un pixel mais par composantes dans plusieurs
textures. Chaque pixel contient les données de quatre points de grille dans la direction
875. Mise en œuvre sur cartes graphiques
des pixels. Dans leur étude, les auteurs utilisent la formule M0
4 pour une interpolation tensorielle
en 2D. Ainsi dans un traitement ligne par ligne, deux pixels consécutifs contiennent
nécessairement toute l’information pour traiter une particule. Parmi les 8 données lues,
seules 4 sont nécessaires, les auteurs utilisent des poids booléens afin de s’affranchir de
branchements conditionnels. L’inconvénient de cette approche est qu’il est nécessaire de
charger en mémoire 8 éléments (2 pixels) dans la direction des pixels pour n’utiliser que les
quatre éléments du support de la particule. Les auteurs atteignent 72% de la performance
maximale atteignable en simple précision et les performances chutent fortement en double
précision.
Plus récemment, Büyükkeçeci et al. (2012) réalisent une étude des deux types d’interpolations
maillage-particule et particule-maillage basées sur des stratégies respectivement
mesh-pull et particle-push ce qui conduit à des algorithmes centrés sur les particules dans
les deux cas. Les auteurs proposent une implémentation générique dans laquelle les particules
sont réarrangées dans une structure de donnée hiérarchique permettant un stockage
contigu des particules de la même région de l’espace. Cette structure se base sur un traitement
séquentiel des particules dans une même cellule en utilisant autant de copies du
domaine que du nombre maximal de particules par cellule. Cela conduit à n’avoir qu’une
seule particule par cellule et par copie ainsi que des cellules vides. Les cellules vides sont
peuplées de particules factices, écartées à la fin de l’interpolation, ce qui permet d’éviter des
branchements conditionnels. Des études systématiques de performances sont réalisées sur
plusieurs cartes graphiques pour chaque interpolation avec des formules linéaire ou M0
4
et
pour des problèmes 2D et 3D. Les auteurs soulignent que les meilleures performances sont
obtenues pour les cas 3D utilisant la formule M0
4
. Ils montrent des accélérations significatives
du temps de calcul entre leur implémentation GPU et une référence multicœur CPU.
Même si cette implémentation est efficace, les performances globales restent limitées par
l’intégration à la librairie PPM. En effet, l’utilisation de ce remaillage nécessite un transfert
des données en entrée ainsi que de retourner les résultats sur la mémoire de la machine hôte
avant de réaliser les autres parties de la résolution. Le facteur d’accélération obtenu est
généralement inférieur à 10, et même inférieur à 1 dans certains cas, en prenant en compte
ce temps de transfert.
À partir des différentes implémentations existantes de méthodes semi-Lagrangiennes et
en particulier des interpolations entre le maillage et les particules, nous proposons une implémentation
qui exploite les différents aspects inhérents à la méthode considérée. En effet,
l’utilisation d’un splitting dimensionnel est à l’origine de bon nombre de choix présentés
dans ce qui suit. Les données sont stockées dans des tableaux classiques, sans aucune utilisation
de structures de données spécifiques aux cartes graphiques comme les textures ou
les pixels. Après une description de ces choix, nous présentons les performances de chaque
fonction de la méthode pour la carte Nvidia K20m. La restriction à une seule carte permet
de simplifier la présentation des résultats et l’extension à d’autres cartes se fait par
adaptation des configurations aux caractéristiques techniques de ce nouveau matériel. Les
performances sont données dans les métriques adaptées à chaque cas.
885.2. Implémentation et performances
5.2. Implémentation et performances
5.2.1. Adéquation de la méthode au matériel
Les implémentations réalisées dans le cadre de ce travail sont basées, à l’instar de
Büyükkeçeci et al. (2012), sur des stratégies mesh-pull pour les interpolations de type
maillage-particule ainsi que particle-push pour le type particule-maillage. Toutefois, l’utilisation
d’un splitting dimensionnel nous permet d’envisager l’emploi de formules de remaillage
d’ordre élevé ayant un large support. Du point de vue de l’implémentation, cela conduit à un
algorithme avec une localité des données plus forte que dans le cadre de méthodes classiques.
En effet, le traitement d’une donnée (particule ou point de grille) ne nécessite que quelques
données voisines uniquement dans la direction courante. La méthode revient à la résolution
de nombreux sous-problèmes monodimensionnels ce qui pousse naturellement à l’emploi
d’une structure de donnée également 1D. Ainsi, nous utilisons des objets mémoire linéaires
comme les buffers qui correspondent à des tableaux classiques. Le découpage par splitting
dimensionnel permet également de considérer séparément les composantes des vecteurs, en
particulier de la vitesse, lors de l’étape d’advection. Nous employons donc une structure de
donnée en tableaux par composantes et non pas en tableau de structures. En pratique les
composantes d’un vecteur sont stockées sous la forme de plusieurs tableaux de scalaires.
Dans la suite de cette thèse, nous prenons comme convention, sans que cela n’implique
aucune restriction, que les données sont stockées dans un ordre en colonne, à l’instar
du langage Fortran. Le stockage monodimensionnel des données d’un tableau de taille
(NX, NY , NZ) dans un espace de taille NX × NY × NZ est illustré en figure 5.1.
. . .
. . . . . .
. . .
.
.
.
.
.
.
NX
NZ
NY
Tableau 3D : (NX, NY , NZ ) ←→ Tableau 1D : NX × NY × NZ
Figure 5.1. – Convention de stockage des données multidimensionnelles
Ainsi, lors des différentes étapes de splitting, le traitement de la première direction de
stockage des données conduit à des accès contigus en mémoire. Ce qui n’est plus le cas lors
du traitement des autres directions. Afin d’éviter une dégradation des performances due
à ces accès, nous mettons en place des transpositions des données pour le traitement des
différentes directions de l’espace. En effet, les performances des accès en mémoire globale
sont généralement plus faibles lors d’accès avec un saut, même constant, comme représenté
par les flèches vertes et bleues sur la figure 5.1. Ainsi, l’accès aux données est toujours
contigu en mémoire pour toutes les directions. Ce choix conduit à trois remarques à propos
de la mise en œuvre de ces transpositions. Premièrement, le champ de vitesse u n’est
895. Mise en œuvre sur cartes graphiques
utilisé que composantes par composantes dans les étapes de splitting. Lors de l’advection
dans la direction X, seule la composante uX est utilisée. Par conséquent, les composantes
des vecteurs, en particulier de la vitesse, sont toujours stockées de manière a avoir un
accès contigu dans la direction concernée. Deuxièmement, les positions des particules à
l’issue de l’étape d’advection ne changent que dans leur composante correspondant à la
direction courante, les autres composantes restent inchangées car le déplacement est 1D.
Cela nous permet de réduire le vecteur position des particules à un scalaire correspondant
à la composante de la direction courante et ainsi de réduire l’emprunte mémoire de la
méthode. Enfin, en dehors des transpositions, toutes les directions sont traitées de manière
identique. En pratique, le même code s’applique dans toutes les directions moyennant une
paramétrisation des dimensions des tableaux dans les cas de grilles non cubiques.
Comme nous l’avons détaillé au chapitre 2, les trois étapes de résolution consistent en
une initialisation en chaque point de grille, un déplacement puis un remaillage des particules.
Lors de l’étape d’initialisation, la position des particules est directement donnée par
la coordonnée du point de grille associé et la quantité transportée par la particule est simplement
une copie de la valeur au point de grille. Ainsi dans notre implémentation, cette
initialisation est remplacée par une transposition lorsque la direction courante change. En
effet, une simple copie suffit dans le cas contraire car les données sont déjà dans le bon
ordre de stockage.
Les algorithmes 1 à 4 détaillent les étapes d’une itération complète de la méthode. Les
données manipulées sont limitées aux composantes du champ de vitesse, aux valeurs sur la
grille des quantités transportées, à un scalaire pour la position des particules et aux valeurs
transportées par les particules. La figure 5.2 illustre l’algorithme 2 dans le cas d’un splitting
du second ordre en 2D et pour un domaine rectangulaire. Les données manipulées par les
opérations d’advection et de remaillage pour un sous-problème 1D sont représentées par
une bande rouge verticale dans les tableaux.
Algorithme 1 : 2D, splitting d’ordre 1
Direction X :
1. u˜ ← Copie (u)
2. x˜ ← Advection (dt, aX)
3. u ← Remaillage (x˜, u˜)
Direction Y :
4. u˜ ← TranspositionXY (u)
5. x˜ ← Advection (dt, aY )
6. u ← Remaillage (x˜, u˜)
Réarrangement des données :
7. u˜ ← TranspositionXY (u)
8. u ← Copie (u˜)
Algorithme 2 : 2D, splitting d’ordre 2
Direction X :
1. u˜ ← Copie (u)
2. x˜ ← Advection (dt/2, aX)
3. u ← Remaillage (x˜, u˜)
Direction Y :
4. u˜ ← TranspositionXY (u)
5. x˜ ← Advection (dt, aY )
6. u ← Remaillage (x˜, u˜)
Direction X :
7. u˜ ← TranspositionXY (u)
8. x˜ ← Advection (dt/2, aX)
9. u ← Remaillage (x˜, u˜)
Dans tous les algorithmes (1 à 4), les deux premières étapes de chaque direction sont
indépendantes. Ainsi, lors de l’exécution, un parallélisme par tâches pourra être exprimé
et conduira à une exécution simultanée des étapes d’advection et des étapes de copie et
de transposition. Une étape de réarrangement des données apparaît en fin d’algorithme
905.2. Implémentation et performances
Algorithme 3 : 3D, splitting d’ordre 1
Direction X :
1. u˜ ← Copie (u)
2. x˜ ← Advection (dt, aX)
3. u ← Remaillage (x˜, u˜)
Direction Y :
4. u˜ ← TranspositionXY (u)
5. x˜ ← Advection (dt, aY )
6. u ← Remaillage (x˜, u˜)
Direction Z :
7. u˜ ← TranspositionXZ (u)
8. x˜ ← Advection (dt, aZ)
9. u ← Remaillage (x˜, u˜)
Réarrangement des données :
10. u˜ ← TranspositionXZ (u)
11. u ← TranspositionXY (u˜)
Algorithme 4 : 3D, splitting d’ordre 2
Direction X :
1. u˜ ← Copie (u)
2. x˜ ← Advection (dt/2, aX)
3. u ← Remaillage (x˜, u˜)
Direction Y :
4. u˜ ← TranspositionXY (u)
5. x˜ ← Advection (dt/2, aY )
6. u ← Remaillage (x˜, u˜)
Direction Z :
7. u˜ ← TranspositionXZ (u)
8. x˜ ← Advection (dt, aZ)
9. u ← Remaillage (x˜, u˜)
Direction Y :
10. u˜ ← TranspositionXZ (u)
11. x˜ ← Advection (dt/2, aY )
12. u ← Remaillage (x˜, u˜)
Direction X :
13. u˜ ← TranspositionXY (u)
14. x˜ ← Advection (dt/2, aX)
15. u ← Remaillage (x˜, u˜)
dans les cas d’un splitting du premier ordre. Cette étape est nécessaire pour retrouver le
scalaire dans l’ordre de stockage initial de l’algorithme, afin de rendre ces transformations
transparentes. En effet, dans tous les cas, les données du scalaire sur la grille sont stockée
en fin d’algorithme dans le même ordre qu’au début.
Les kernels sont donc développés indépendemment de la direction de résolution. Nous
séparons les développements de kernels de l’étape d’initialisation de ceux du calcul. Les
premiers regroupent les opérations de copie et les transpositions qui ne nécessitent aucun
calcul. Leurs performances sont analysées en terme de bande passante. Les performances
des seconds sont données dans le modèle roofline.
5.2.2. Préambule à l’étude des performances
Sauf mention contraire, dans la suite de ce chapitre, nous présenterons des résultats en
double précision pour la carte Nvidia K20m.
En l’absence d’outils d’optimisation automatique, nous exploitons les caractéristiques du
matériel pour paramétrer les exécutions des kernels. En particulier, le lien entre la taille des
données et l’espace d’indice OpenCL ne suffit pas à déterminer complètement le nombre et
la taille des work-groups. Dans l’état actuel de la librairie, cette paramétrisation des noyaux
est réalisée de manière explicite pour les différents cas d’utilisation tels que le nombre de
dimensions du problème, la précision utilisée et le matériel employé. Les paramètres donnant
les meilleures performances ont été obtenus par petites variations autour de valeurs en
915. Mise en œuvre sur cartes graphiques
1. copie
2. advection
3. remaillage
4. Transposition XY
5. advection
6. remaillage
7. Transposition XY
8. advection
9. remaillage
Direction X, dt/2
Direction Y , dt
Direction X, dt/2
X
Y
Y
X
X
Y
Grille : Particules :
Vitesse
Scalaire Scalaire
Positions
Figure 5.2. – Algorithme pour une itération en 2D, splitting de Strang
925.2. Implémentation et performances
adéquation avec le matériel. Le tableau 5.1 rappelle et détaille les principales caractéristiques
pour la carte K20m. Le vocabulaire employé dans ce tableau est celui du langage CUDA pour
les cartes Nvidia. Pour les cartes ATI, l’architecture est similaire et les warps sont appelés
wavefronts. D’autre part les termes thread et thread block sont les équivalents CUDA de ce
que sont les work-items et work-groups pour OpenCL.
Puissance double (simple) précision 1 173 (3 519) GFLOPS
Cœurs double (simple) précision 832 (2496)
Bande passante 208 GByte/s
Multiprocesseurs (MP) 13
Cœurs double (simple) précision par MP 64 (192)
Mémoire partagée par MP 48 kByte
Registres 32-bit par MP 65536
Nb. Threads par warp 32
Nb. max. de warps par MP 64
Nb. max. de threads par MP 2048
Nb. max. de thread blocks par MP 16
Nb. max. de registres par thread 255
Nb. max. de threads par thread blocks 1024
Tableau 5.1. – Caractéristiques techniques de la carte Nvidia K20m (Nvidia, 2012b ;
Nvidia, 2012a)
De manière générale l’obtention de bonnes performances sur GPU se fait en considérant
finement les caractéristiques du matériel. Comme nous l’avons souligné précédemment, la
mesure des performances se fait par diverses métriques souvent complémentaires comme
la puissance de calcul ou la bande passante. L’occupation est une métrique spécifique aux
cartes graphiques qui permet de mesurer l’utilisation des multiprocesseurs. Lors de l’exécution
d’un kernel, les work-item sont associés aux cœurs physiques de la carte par groupes
constituant un warp. Les multiprocesseurs possèdent un planificateur permettant une exé-
cution simultanée de plusieurs warps. L’occupation est donc simplement le rapport entre le
nombre de warps exécutés simultanément par multiprocesseur et le nombre maximal supporté.
Ainsi, lors d’une exécution d’un kernel, la spécification de l’espace d’index ainsi que la
quantité de mémoire partagée et le nombre de registres utilisés peuvent limiter l’occupation.
Des outils de calcul d’occupation sont proposés à la fois par Nvidia 1
et AMD 2
. Le calcul de
l’occupation nécessite la connaissance du nombre de registres utilisés par work-item. Cette
information peut être obtenue par l’analyse des binaires produits par les compilateurs pour
une carte spécifique. L’option de compilation -cl-nv-verbose permet d’obtenir ce nombre
lors de la compilation avec OpenCL sur une carte Nvidia.
Toutefois, comme le montre Volkov (2010) sur des exemples simples, la maximisation de
l’occupation ne permet pas toujours de maximiser les performances. En effet, le temps que
les unités de calculs mettent à effectuer les opérations arithmétiques ou à réaliser un accès en
mémoire peut être exploité afin d’augmenter les performances. La latence arithmétique peut
1. http://developer.download.nvidia.com/compute/cuda/CUDA_Occupancy_calculator.xls
2. http://developer.amd.com/tools-and-sdks/archive/amd-app-profiler/user-guide/
app-profiler-kernel-occupancy/
935. Mise en œuvre sur cartes graphiques
être cachée en augmentant la charge de travail par work-item afin de bénéficier d’opérations
non interdépendantes pouvant être exécutées simultanément. De même, il est possible de
cacher la latence mémoire en utilisant d’avantage de registres et en réduisant le nombre
de work-item. Ces optimisations au niveau des instructions (Instruction Level Parallelism)
impliquent généralement une augmentation du nombre de registres et une diminution du
nombre de work-item ce qui peut conduire à une diminution de l’occupation. De manière
générale, il n’est pas possible de connaître a priori quelles optimisations sont préférables
entre les instructions et l’occupation. C’est pourquoi dans les résultats qui vont suivre,
les noyaux n’ont pas été optimisés systématiquement à différents niveaux. De plus, dans
un souci de portabilité et de non spécialisation à une carte en particulier, les optimisations
restent générales et basées uniquement sur les connaissances des caractéristiques techniques.
5.2.3. Initialisation des particules
Les étapes d’initialisation des particules se caractérisent par une absence totale de calculs.
Les opérations consistent uniquement en des transferts de données. Ainsi, les performances
sont mesurées en terme de bande passante.
Copie
Cette opération consiste en une simple copie des données entre deux zones mémoire. Une
fonction de copie directe est proposée par l’interface OpenCL. Dans cette comparaison, nous
utilisons la fonction clEnqueueCopyBuffer pour la copie d’un buffer complet vers un autre.
La figure 5.3 illustre le fonctionnement simple de ce kernel. La copie est réalisée directement
par blocs successifs, en pointillés sur la figure. Chaque bloc est traité par un work-group
dont les work-items, en pointillés, traitent un seul élément du tableau. La taille du workgroup
est fixée à 256 work-item ce qui permet d’atteindre une occupation maximale avec 8
warps par multiprocesseur.
Entrée Sortie
Figure 5.3. – Fonctionnement du kernel de copie
La figure 5.4 présente les performances atteintes par le kernel et la fonction OpenCL
pour différentes tailles de tableaux en 2D (5.4a) et 3D (5.4b). Les résultats obtenus sont
comparables et atteignent la bande passante maximale mesurée dès lors que la taille des
tableaux est suffisamment grande. En effet, l’exécution sur des données trop petites ne
permettent pas une occupation maximale de la carte et donc conduit à de mauvaises performances.
Ainsi, nous donnons les performances pour les petites tailles, inférieures à 10242
ou à 1283
, seulement à titre indicatif.
945.2. Implémentation et performances
OpenCL clEnqueueCopyBuffer kernel
0
10
20
30
40
50
60
70
80
322
1282
5122
20482
81922
Max.
0
20
40
60
80
100
120
140
160
10−2
10−1
1 101
102
103
% bande passante théorique
Bande passante (GByte/s)
Taille des tableaux
(MByte)
(a) 2D
0
10
20
30
40
50
60
70
80
323
643
1283
2563
5123
Max.
0
20
40
60
80
100
120
140
160
1 101
102
103
% bande passante théorique
Bande passante (GByte/s)
Taille des tableaux
(MByte)
(b) 3D
Figure 5.4. – Performances des copies
Transposition XY
Nous appelons transposition XY une transposition 2D dans le plan XY . Dans le cas de
données 2D, cela revient à une transposition classique. Cette opération est bien connue et
l’implémentation proposée ici se base sur l’exemple donné par Ruetsch et al. (2009) pour
la transposition d’une matrice de taille 2 0482
en simple précision. Les auteurs présentent
différentes optimisations permettant d’obtenir une bande passante pour la transposition
égale à 70% de celle obtenue pour une copie. Nous étendons cette approche à différentes
tailles de tableaux 2D et 3D en double précision. Pour les données 3D, une telle transposition
est effectuée pour chaque plan dans la direction Z.
La transposition optimale est schématisée en figure 5.5 et fait apparaître les trois niveaux
d’optimisation que nous détaillons ci-après. Les données représentées en rouge et en vert
sont traitées par les work-items d’un même work-group et une boucle permet de compléter
les sous-tableaux en pointillés.
Une transposition naïve, similaire au kernel de copie, réalisant une écriture directe dans
le tableau de sortie conduit à de très mauvaises performances. En effet, une telle implémentation
implique des accès en mémoire globale non contigus. Une solution consiste à utiliser
un tableau intermédiaire en mémoire partagée permettant de réaliser des accès contigus à
la fois en lecture et en écriture pour les tableaux en mémoire globale. Dans ce cas, l’écriture
des données en colonnes dans le tableau de sortie revient à lire des lignes en mémoire locale.
Cependant, cette approche provoque des conflits de banc lors de la lecture des données
en ligne dans la mémoire partagée. Ce phénomène vient du fait que la mémoire partagée
est organisée en différents bancs, dont le nombre est en général égal à 32. Ces bancs ne
permettent qu’un accès séquentiel aux données et on assiste à un conflit lorsque plusieurs
955. Mise en œuvre sur cartes graphiques
processus accèdent simultanément à des données situées dans le même banc, les accès sont
alors effectués de manière séquentielle. Du fait du choix de la taille de cette zone mémoire,
162 ou 322
, les données d’une même ligne sont situées dans le même banc. En suivant
l’exemple de Ruetsch et al. (2009), on alloue une zone de taille 17×16 ou 33×32 pour décaler
les données dans les bancs et ainsi avoir des accès sans conflits. Une autre approche consiste
à accéder aux données du tableau en mémoire partagée dans un système de coordonnées
diagonale (Baqais et al., 2013). Si x et y sont respectivement les indices de ligne et de colonne
du sous-tableau traité par un work-group, les données correspondantes sont stockées aux
indices x
0
et y
0 avec :
x
0 = (x + y)%T avec T la taille du sous-tableau,
y
0 = x.
Ainsi, les accès ne provoquent pas de conflits et la mémoire allouée est entièrement utilisée.
Cependant, cette approche n’a pas été envisagée pour l’instant car la version avec extension
du tableau conduit à des performances satisfaisantes. D’autre part, la réduction d’utilisation
de mémoire partagée n’est pas suffisamment importante pour influencer l’occupation de
manière significative.
Enfin, comme la mémoire partagée, la mémoire globale est organisée en partitions si
bien que le traitement simultanée d’une colonne de sous-tableaux conduit à la lecture de
données dans différentes partitions et à une écriture dans les même partitions. Une structuration
des sous-tableaux en coordonnées diagonales permet des accès non restreints à un
petit nombre de partitions (flèches pointillées sur la figure). Cependant, nos expérimentations
sur des cartes plus récentes que celles utilisées par Ruetsch et al. (2009) montrent
que ce réarrangement en diagonale ne conduit pas à une augmentation significative des
performances.
Mémoire
partagée
Entrée Sortie
Figure 5.5. – Fonctionnement du kernel de transposition XY
La figure 5.6 présente les performances obtenues pour les trois niveaux d’optimisation
de la transposition XY en 2D et 3D pour différentes tailles de tableaux ainsi qu’une implémentation
naïve. La mise en place de ces niveaux d’optimisation conduit à une bande
passante pour la transposition supérieure à 80% de la bande passante maximale mesurée
pour la copie.
965.2. Implémentation et performances
Naif
Mémoire partagée
Mémoire partagée élargie
Mémoire partagée élargie, coord. diagonales
0
10
20
30
40
50
60
70
80
322
1282
5122
20482
81922
Max.
0
20
40
60
80
100
120
140
160
10−2
10−1
1 101
102
103
% bande passante théorique
Bande passante (GBytes/s)
Taille des tableaux
(MByte)
(a) 2D
0
10
20
30
40
50
60
70
80
323
643
1283
2563
5123
Max.
0
20
40
60
80
100
120
140
160
1 101
102
103
% bande passante théorique
Bande passante (GBytes/s)
Taille des tableaux
(MByte)
(b) 3D
Figure 5.6. – Performances des transpositions XY
Lorsque la taille du sous-tableau alloué en mémoire partagée est fixé à 33 × 32, soit
8448Byte, et que les work-groups contiennent 512 work-items, 12 registres sont utilisés ce
qui conduit à une occupation maximale avec l’exécution simultanée de 4 work-groups par
multiprocesseurs.
Transposition XZ
Cette transposition est réalisée de manière similaire à la transposition XY comme illustré
en figure 5.7a. L’opération se réalise par le traitement de sous-tableaux 2D formés dans
les plans XZ successifs. Chacun de ces plans est traité séparément par plusieurs soustableaux
avec l’utilisation d’une mémoire partagée élargie et avec des coordonnées diagonales
pour les différents blocs. Cependant, bien que les accès soient contigus dans une même
colonne des sous-tableaux, le passage d’une colonne à une autre dans les tableaux 3D se fait
avec un saut bien plus important que pour la transposition XY . Ce phénomène pénalise
grandement les performances sur des cartes plus anciennes et une seconde transposition a
été implémentée par sous-tableau 3D, illustré par la figure 5.7b. Le principe reste le même
mais les données sont lues également dans la direction Y , avec un saut bien plus faible.
Comparativement à la version 2D, cela revient à réaliser les transpositions simultanées de
plusieurs plans XZ. Cependant, les dimensions de la zone en mémoire partagée imposent
une taille plus faible pour les work-groups.
Les performances de cette transposition sont représentées sur la figure 5.8. Il apparaît
clairement que l’utilisation d’une transposition par bloc 3D n’est pas optimale du fait d’une
trop faible occupation (16%) induite par une très grande taille de mémoire partagée par
975. Mise en œuvre sur cartes graphiques
Mémoire
partagée
Entrée Sortie
(a) Par tranches 2D
Mémoire
partagée
Entrée Sortie
(b) Par blocs 3D
Figure 5.7. – Fonctionnement du kernel de transposition XZ
work-groups, (163
éléments). La meilleure configuration pour cette transposition est obtenue
pour une occupation de 63%.
5.2.4. Advection et remaillage
Advection
Cette fonction permet de résoudre l’équation de mouvement des particules à partir du
champ de vitesse connu sur la grille. Les particules sont initialisées en chaque point de grille,
leur vitesse en ce point est donc directement lue sur la grille. Les schémas de Runge-Kutta
d’ordre deux et quatre, notés respectivement RK2 et RK4, nécessitent des évaluations du
champ de vitesse à plusieurs positions intermédiaires qui sont réalisées par des interpolations
linéaires de type maillage-particule. Une stratégie centrée sur les particules permet de
réaliser ces interpolations à la volée au cours de l’advection. Ainsi, une particule est traitée
en une seule fois mais nécessite plusieurs accès aux données du champ de vitesse. De plus
le schéma d’accès est inconnu car il dépend du champ de vitesse. Toutefois, du fait de la
condition de non croisement des particules, ces accès restent ordonnés de la même manière
que les particules.
La stratégie de distribution des calculs sur l’espace d’indices des GPU est choisie de
telle sorte qu’un sous-problème 1D est traité par les work-items d’un seul work-group.
Ces sous-problèmes étant indépendants, plusieurs pourront être traités simultanément en
985.2. Implémentation et performances
0
10
20
30
40
50
60
70
80
323
643
1283
2563
5123
Max.
0
20
40
60
80
100
120
140
160
10−2
10−1
1 101
102
103
% bande passante théorique
Bande passante (GBytes/s)
Taille des tableaux
(MByte)
2D Naïf
2D Mémoire partagée
2D Optimisé
3D Naïf
3D Optimisé
Figure 5.8. – Performances des transpositions XZ
fonction de l’occupation des multiprocesseurs de la carte. Les multiples accès aux données
du champ de vitesse peuvent être évités en utilisant une zone en mémoire partagée, comme
illustré sur la figure 5.9. Cela permet, après un remplissage par accès contigus en mémoire
globale, à des accès plus rapides et dont le schéma inconnu est moins pénalisant. Les workitems
réalisent, dans une premier temps, un chargement en mémoire partagée des données
du champ de vitesse nécessaires au traitement d’un problème 1D. Cette opération, qui
s’apparente à une mise en cache, est réalisée de manière collaborative par les work-items et
est nécessairement suivie d’une barrière de synchronisation des processus du work-group.
Dans un second temps, l’intégration du champ de vitesse est réalisée à l’aide d’interpolations.
Intégration
Interpolations
Vitesse
(grille)
Mémoire
partagée
Position
(particules)
Figure 5.9. – Algorithme pour le noyau d’advection
Dans le cas où la grille est identique pour le champ de vitesse et pour les particules, les 3
ou 7 accès aux données de vitesse respectivement pour les schémas RK2 et RK4 nécessaires
au calcul des positions des particules sont effectués en mémoire partagée et bénéficient ainsi
de son temps de latence plus faible. La quantité de données lues et écrites en mémoire
globale pour une étape d’advection est donc indépendante du schéma et est donnée par :
MA,s = 2N
uP, (5.1)
995. Mise en œuvre sur cartes graphiques
où Nu
est le nombre de points de grille du scalaire et P la taille d’un nombre en virgule
flottante (P = 8 en double précision).
On note Na le nombre de points de grille du champ de vitesse. Pour ce qui est du cas
multiéchelle, deux interpolations supplémentaires sont nécessaires. Le cache pour le champ
de vitesse, de Na
X éléments, est complété par une première interpolation linéaire tensorielle
des points de grille dans les directions Y et Z en la coordonnée du sous-problème 1D. Ainsi,
les données du champ de vitesse sont lues plusieurs fois, et conduisent à une quantité totale
exprimée par :
MA,m =
(
(2N
a + N
u
)P pour un problème 2D,
(4N
a + N
u
)P pour un problème 3D.
(5.2)
La seconde interpolation se fait dans la mémoire partagée pour l’évaluation de la vitesse
initiale des particules dont la position est un point de la grille fine.
Le calcul d’un problème 1D étant effectué par un work-group, plusieurs particules
peuvent être traitées par le même work-item. Ainsi les opérations effectuées en dehors de la
boucle interne sont mutualisées pour ces particules. On note nwi le nombre de work-item par
work-group. Les nombres d’opérations nécessaires à la réalisation d’une étape d’advection
simple échelle sont données par :
FA,s =
4N
u pour un schéma d’Euler
12N
u pour un schéma de Runge-Kutta d’ordre 2
32N
u pour un schéma de Runge-Kutta d’ordre 4
(5.3)
Pour les cas multiéchelle, le nombre d’opérations est :
FA,m = FA,s +
(
(4nwi + 3N
a
X)N
u
/Nu
X en 2D
(8nwi + 11N
a
X)N
u
/Nu
X en 3D
(5.4)
Le choix de l’espace d’index se fait en fixant le nombre de particules traitées par un workitem.
Les figures 5.10 représentent les performances pour 1, 2 ou 4 particules respectivement
notées v1, v2 et v4 dans la légende. Dans un souci de clarté, nous ne présentons pas ici
les autres choix qui ont été envisagés d’autant qu’ils ont conduit à des performances plus
faibles. L’augmentation de la complexité arithmétique due à l’augmentation de l’ordre des
schémas se traduit directement par une hausse de la puissance obtenue. Cela sera analysé
par la suite à l’aide du modèle roofline. Une différence structurelle entre les problèmes 2D
et 3D est que la résolution est constituée de sous-problèmes 1D bien plus petits en 3D.
Ainsi, l’usage de la mémoire partagée est plus faible en 3D qu’en 2D et implique donc une
plus grande occupation de la carte pour les grands problèmes. Un traitement de plusieurs
particules par work-item permet de diminuer la taille des work-groups ce qui, là encore
permet une augmentation de l’occupation. Cependant la limite des 1 024 work-items est
rapidement atteinte en 2D. Ce qui explique la chute de performances à partir de 1 0242
.
L’effet inverse se produit en 3D où trop peu de work-items sont assignés ce qui conduit à une
faible occupation en raison de la limite du nombre de work-group exécutables simultanément
par multiprocesseur.
Pour ce qui est de l’advection multiéchelle, nous donnons les performances atteintes pour
différentes tailles de problèmes sur les figures 5.11. Seules les performances de la version
1005.2. Implémentation et performances
Euler v4
Euler v2
Euler v1
RK2 v4
RK2 v2
RK2 v1
RK4 v4
RK4 v2
RK4 v1
0
50
100
150
200
250
300
322
1282
5122
20482
Puissance (GFLOPS)
Taille de problème
(a) 2D
0
50
100
150
200
250
300
323
643
1283
2563
5123
Puissance (GFLOPS)
Taille de problème
(b) 3D
Figure 5.10. – Performances des noyaux d’advection
1015. Mise en œuvre sur cartes graphiques
pour laquelle chaque work-item traite 4 particules sont présentées. Les rapports d’échelle
entre les grilles des particules et celle du champ de vitesse sont fixés à 2, 4 et 8 et conduisent
aux courbes dans l’ordre indiqué par les flèches. Ces résultats montrent que les performances
suivent l’évolution du rapport d’échelle, à taille de grille fine fixée. Cette évolution est, en
partie, due au fait que l’augmentation du rapport d’échelle implique une diminution à la
fois du nombre de données nécessaires pour le calcul, d’après l’équation (5.2), et du nombre
d’opérations arithmétique à réaliser, équation (5.4).
0
50
100
150
200
250
300
1282
5122
20482
Puissance (GFLOPS)
Taille de problème (grille fine)
RK2
RK4
Euler
(a) 2D
0
50
100
150
200
250
300
643
1283
2563
5123
Puissance (GFLOPS)
Taille de problème (grille fine)
RK2
RK4
Euler
(b) 3D
Figure 5.11. – Performances des noyaux d’advection multiéchelle
Le modèle roofline nous permet de réaliser une analyse de performances relativement à
la puissance maximale atteignable. Nous représentons sur les figures 5.12 les résultats pour
quelques tailles de problèmes. En simple échelle, l’intensité opérationnelle FA,s/MA,s est
constante lorsque la taille du problème change. Ces intensités sont représentées par un trait
vertical sur les figures 5.12. Dans le cas multiéchelle, les intensités ne sont plus constantes
et donc les points qui leur correspondent ne sont pas sur les segments verticaux. Afin de
remédier aux effets visuels des échelles logarithmiques du modèle roofline, nous représentons
également les niveaux 0,5 et 0,1 de la puissance maximale atteignable.
Remaillage
Cette étape permet de réaliser l’interpolation particule-maillage en employant une stratégie
centrée sur les particules. À partir de la coordonnée d’une particule, les points de la
grille sur lesquels se remaille la particule sont calculés en fonction de la largeur du support
de la formule utilisée. Les positions sont dépendantes du champ de vitesse donc le schéma
de remaillage en termes d’accès aux données de la grille ne peut pas être connu à priori.
1025.2. Implémentation et performances
Euler RK2 RK4
10
100
1000
0.1 1 10 100 Euler RK2 RK4
50%
10%
Puissance (GFLOPS)
Intensité opérationnelle (FLOP/Byte)
10242
20482
40962
(a) 2D
10
100
1000
0.1 1 10 100 Euler RK2 RK4
50%
10%
Puissance (GFLOPS)
Intensité opérationnelle (FLOP/Byte)
1283
2563
5123
(b) 3D
Figure 5.12. – Modèle roofline pour les noyaux d’advection
Par conséquent, deux particules consécutives peuvent avoir exactement les mêmes points de
remaillage. Cependant, du fait de la régularité des champs de vitesse traités, nous pouvons
poser l’hypothèse que le nombre maximal de particules par cellule reste petit. On supposera
que ce nombre ne dépasse pas deux.
La distribution de l’espace d’index est similaire à celle de l’advection et chaque sousproblème
1D est traité par un work-group. La charge par work-item est modifiée pour
remédier aux éventuels accès concurrents lorsque plusieurs particules sont situées dans la
même cellule. Ainsi, chaque work-item traite au moins deux particules consécutives. En
conservant les mêmes notations que dans le chapitre 2, le support des formules de remaillage
est de largeur 2S. Par conséquent, le remaillage d’une particule nécessite 2S accès en lecture
et autant en écriture pour les points de grille contenus dans son support. Ces nombreux
accès sont effectués dans un tableau temporaire correspondant au sous-problème 1D en
mémoire partagée, comme illustré sur la figure 5.13. Une fois toutes les particules traitées
et après une barrière de synchronisation, les données sont copiées en mémoire globale.
Scalaire
(particules)
Position
(particules)
Scalaire
(grille)
Mémoire
partagée
Λp,r
Figure 5.13. – Algorithme pour le noyau de remaillage
1035. Mise en œuvre sur cartes graphiques
Le nombre d’accès en mémoire globale est donné par l’expression suivante, en fonction
du nombre de composantes remaillées c :
MR = (2c + 1)N
uP. (5.5)
Pour ce qui est du nombre d’opérations en virgule flottante, il dépend de la largeur du
support 2S, de la formule de remaillage et du degré q des polynômes dont l’évaluation est
effectuée par la méthode de Horner en utilisant les opérations FMA de la carte.
FR = (2S(2c + 2q + 1) + 5) N
u
(5.6)
Nous donnons les performances des noyaux pour quelques formules de remaillage. Les
meilleurs résultats ont été obtenus lorsque chaque work-item traite exactement deux particules.
Une augmentation du nombre de particules par work-item implique une occupation
plus faible car la quantité de mémoire employée ne change pas et la taille des work-groups
diminue. Un nombre plus grand implique une utilisation d’un grand nombre de registres et
donc une diminution de l’occupation des multiprocesseurs. Comme pour les noyaux d’advection
on assiste à une chute des performances en 2D à partir d’une taille de 4 0962 à cause
d’une trop grande consommation de mémoire partagée.
0
50
100
150
200
250
300
350
322
1282
5122
20482
Puissance (GFLOPS)
Taille de problème
Λ2,1
Λ2,2
Λ4,2
Λ4,4
Λ6,4
Λ6,6
Λ8,4
(a) 2D
0
50
100
150
200
250
300
350
323
643
1283
2563
5123
Puissance (GFLOPS)
Taille de problème
Λ2,1
Λ2,2
Λ4,2
Λ4,4
Λ6,4
Λ6,6
Λ8,4
(b) 3D
Figure 5.14. – Performances des noyaux de remaillage
Les performances relatives à la puissance maximale atteignable sont représentées dans un
modèle roofline sur les figures 5.15. À l’instar de Büyükkeçeci et al. (2012), nous observons
de plus hautes performances en 3D qu’en 2D essentiellement à cause d’une utilisation du
tableau en mémoire partagée plus efficace du fait de la différence des tailles des sousproblèmes
1D.
1045.2. Implémentation et performances
Λ2,1
Λ2,2
Λ4,2
Λ4,4
Λ6,4
Λ6,6
Λ8,4
10
100
1000
0.1 1 10 100
50%
10%
Puissance (GFLOPS)
Intensité opérationnelle (FLOP/Byte)
10242
20482
40962
(a) 2D
10
100
1000
0.1 1 10 100
50%
10%
Puissance (GFLOPS)
Intensité opérationnelle (FLOP/Byte)
1283
2563
5123
(b) 3D
Figure 5.15. – Modèle roofline pour les noyaux de remaillage
Noyau complet
Une approche regroupant les opérations d’advection et de remaillage en un seul noyau
est également envisagée. Le principal intérêt est de supprimer le tableau en mémoire globale
pour la position des particules. En effet, cette variable intermédiaire est simplement locale
au processus. Cependant, cette approche nécessite deux tableaux temporaires en mémoire
partagée, comme illustré sur la figure 5.16. En pratique, cette implémentation n’est pas
Intégration
Interpolation
Vitesse
(grille)
Scalaire
(particules)
Scalaire
(grille)
Mémoire
partagée
Mémoire
partagée
Λp,r
Figure 5.16. – Algorithme pour le noyau d’advection et remaillage
pertinente pour les grandes tailles de problèmes 2D. Cependant, comme la mémoire partagée
n’est pas un facteur limitant en 3D, son utilisation semble intéressante. Dans ce noyau, nous
réutilisons les fonctions employées précédemment, ce qui conduit à une quantité d’accès
1055. Mise en œuvre sur cartes graphiques
mémoire en simple et multiéchelle :
MAR,s = MR,s = (1 + 2c)N
uP, (5.7)
MAR,m =
(
(2N
a + 2cNu
)P en 2D
(4N
a + 2cNu
)P en 3D.
(5.8)
Pour ce qui est du nombre d’opérations, il est simplement donné par la somme des opérations
des noyaux d’advection et de remaillage. Les performances obtenues sont représentées en
figures 5.17 et dans un modèle roofline en figures 5.18. Nous considérons le cas d’une advection
par un schéma Runge-Kutta d’ordre 2 ainsi que l’utilisation des formules de remaillage
Λ2,1, Λ4,2 et Λ8,4. L’évolution des performances selon la formule de remaillage utilisée est
identique à celle observée pour le noyau de remaillage seul. De même, les performances
pour une advection avec un schéma d’Euler et Runge-Kutta d’ordre 4 sont respectivement
inférieures et supérieures à celles représentées lorsque la formule de remaillage est fixée.
Les courbes notées MS dans la légende correspondent à une advection multiéchelle pour un
facteur d’échelle égal à 4. Comparativement au cas simple échelle, cela induit une petite
augmentation de performances ainsi qu’une augmentation de l’intensité opérationnelle du
noyau qui est renforcée par l’effet de la complexité de la formule de remaillage. Cependant,
une comparaison des performances relatives des modèles roofline avec les noyaux simples
montrent que cette approche n’apporte pas une meilleure efficacité. Toutefois, comme nous
le verrons par la suite, l’utilisation de ce noyau conduit à un temps de calcul légèrement
inférieur à la somme des deux noyaux simples ce qui permet de bénéficier de la réduction
de l’empreinte en mémoire globale.
0
50
100
150
200
250
300
350
322
1282
5122
20482
Puissance (GFLOPS)
Taille de problème
Λ2,1
Λ4,2
Λ8,4
MS Λ2,1
MS Λ4,2
MS Λ8,4
(a) 2D
0
50
100
150
200
250
300
350
323
643
1283
2563
5123
Puissance (GFLOPS)
Taille de problème
Λ2,1
Λ4,2
Λ8,4
MS Λ2,1
MS Λ4,2
MS Λ8,4
(b) 3D
Figure 5.17. – Performances des noyaux d’advection et remaillage pour un schéma RK2
1065.3. Application simple GPU
Λ2,1
Λ4,2
Λ8,4
MS Λ2,1
MS Λ4,2
MS Λ8,4
10
100
1000
0.1 1 10 100
50%
10%
Puissance (GFLOPS)
Intensité opérationnelle (FLOP/Byte)
10242
20482
40962
(a) 2D
10
100
1000
0.1 1 10 100
50%
10%
Puissance (GFLOPS)
Intensité opérationnelle (FLOP/Byte)
1283
2563
5123
(b) 3D
Figure 5.18. – Modèle roofline pour les noyaux d’advection et remaillage pour un schéma
RK2
Les performances individuelles des différents noyaux se retrouvent directement dans les
exécutions du code complet. Ainsi, nous exposons la validité de la méthode et de l’implé-
mentation à travers quelques exemples simples de transport de scalaire. Dans un premier
exemple, la vitesse est donnée par une fonction analytique dépendant de l’espace et du
temps alors qu’elle ne dépend pas du temps dans le second exemple. Le cas multiéchelle est
illustré sur l’exemple 3D. Les résultats des exemples sont analysés de manière qualitative
permettant une validation de la méthode. Les résultats en terme de temps de calcul sont
présentés et comparés entre les différentes fonctions. Dans tous les cas, la vitesse est donnée
en entrée sous la forme des valeurs aux points de grille, permettant ainsi de se placer dans
un cadre général indépendant de la manière dont est calculé le champ de vitesse.
5.3. Application simple GPU
5.3.1. Transport de scalaire 2D
Un premier exemple d’utilisation de la méthode compète sur GPU est réalisé pour le
transport d’une fonction levelset dans un champ de vitesse analytique 2D. Ce champ correspond
à un mouvement de rotation incompressible périodique en temps. Ainsi, la fonction
levelset est déformée au cours du temps puis retrouve sa valeur initiale après un nombre
entier de périodes. Le champ de vitesse est défini par l’expression suivante :
a(x, y, t) =
− sin2
(πx) sin(2πy)
sin(2πx) sin2
(πy)
cos
πt
12
(5.9)
1075. Mise en œuvre sur cartes graphiques
Le scalaire est initialisé par une fonction indicatrice d’un disque de rayon 0,15 centré au point
de coordonnée (0, 5; 0, 75). À chaque itération de la méthode, le champ de vitesse analytique
est évalué sur les points de grille puis la méthode décrite précédemment s’applique avec
une étape d’advection suivie d’un remaillage des particules. Le contour de niveau 0,5 de
la fonction transportée est représenté à différents instants sur la figure 5.19. À l’instant
t = 12, soit après une période, le contour a retrouvé sa forme initiale. La difficulté de
cet exemple réside en la représentation du contour à l’extrémité de la spirale. En effet,
selon la qualité de la méthode employée, la séparation du contour ainsi que l’apparition
d’éventuelles oscillations numériques ne permettent plus de retrouver la condition initiale.
Nous rappelons que le pas de temps est contraint par la condition de CFL Lagrangienne
suivante :
∆t 6
M
|∇a|∞
.
La simulation suivante a été réalisée en utilisant 1 0242 points de grille. La constante M
est prise égale à 0,35, ce qui pour cette résolution, conduit à une CFL équivalente de
|a|∞∆t/∆x = 57. Ainsi, une première validation de l’implémentation est effectuée car
à l’instant t = 12, on retrouve bien la condition initiale en utilisant de grands pas de
temps, comme le montre la figure 5.19. La simulation est réalisée en utilisant un schéma
d’intégration RK2 et une formule de remaillage Λ6,4.
Les temps de calcul par particule, hors initialisation et hors calcul du champ de vitesse,
sont donnés en figure 5.20 pour différentes formules de remaillage et schémas d’advection.
Comme prévu par les performances individuelles des noyaux, les petites résolutions
conduisent à des temps de calcul assez grands. Nous les considérons comme non signifi-
catives car elles ne sont jamais utilisées en pratique dans les applications. Un temps de
traitement compris entre 1,5 et 3 ns est obtenu pour un remaillage avec la formule Λ2,1
et augmente avec l’ordre et la complexité de la formule pour atteindre des valeurs entre 2
et 4 ns pour Λ8,4. Les autres formules conduisent à des temps intermédiaires. Cette figure
propose également une comparaison de la version à un seul noyau de calcul avec celle à
deux noyaux séparés. Cette dernière conduit à des temps de calculs plus élevés mais permet
de traiter des problèmes de plus grande taille. Cela est dû, à l’utilisation d’une plus grande
zone de mémoire partagée pour la version à un noyau. Enfin, la hausse des temps de calcul
lorsque les problèmes traités sont de taille supérieure à 2 0482
est conforme avec la chute
de puissance observée dans la section précédente. Là encore, l’utilisation de la mémoire
partagée est à l’origine de cette évolution notamment à travers une baisse de l’occupation
des multiprocesseurs dans les étapes de calcul.
La figure 5.21 donne la répartition du temps de calcul dans les différentes fonctions
présentées dans la section précédente. Les couleurs claires correspondent à l’étape de splitting
dans la direction X et occupent 2/3 du temps de calcul alors que les teintes foncées
représentent la direction Y et occupent le 1/3 restant. Ces simulations ont été réalisées avec
un splitting de Strang où deux étapes sont nécessaires dans la direction X. Les portions du
temps de calcul attribuées à l’hôte deviennent négligeables lorsque la taille dépasse 4 0962
.
Elles correspondent à des opérations réalisées par le CPU pour la gestion des étapes de
splitting et des lancements de kernels OpenCL. Les opérations d’initialisation à l’aide de
copies et de transpositions n’occupent que 10 à 20% du temps de calcul.
1085.3. Application simple GPU
t = 0
0 0.2 0.4 0.6 0.8 1
0
0.2
0.4
0.6
0.8
1
t = 3
0 0.2 0.4 0.6 0.8 1
0
0.2
0.4
0.6
0.8
1
t = 6
0 0.2 0.4 0.6 0.8 1
0
0.2
0.4
0.6
0.8
1
t = 12
0 0.2 0.4 0.6 0.8 1
0
0.2
0.4
0.6
0.8
1
Figure 5.19. – Exemple de transport de fonction levelset 2D
1095. Mise en œuvre sur cartes graphiques
2
4
8
1
10
1282
10242
20482
40962
61442
Temps de calcul par particule (ns)
Taille des tableaux
1k : RK2, Λ2,1
2k : RK2, Λ2,1
1k : RK4, Λ2,1
2k : RK4, Λ2,1
1k : RK2, Λ8,4
2k : RK2, Λ8,4
1k : RK4, Λ8,4
2k : RK4, Λ8,4
Figure 5.20. – Performances globales de la méthode pour un transport de scalaire 2D
Copie
Transposition XY
Hôte
Advection
Remaillage
Advection et remaillage
0
10
20
30
40
50
60
70
80
90
100
1024
2
2048
2
4096
2
6144
2
1024
2
2048
2
1024
2
2048
2
4096
2
6144
2
1024
2
2048
2
1024
2
2048
2
4096
2
6144
2
1024
2
2048
2
1024
2
2048
2
4096
2
6144
2
1024
2
2048
2
RK2, Λ2,1 RK4, Λ2,1 RK2, Λ8,4 RK4, Λ8,4
X
Y
% du temps de calcul
Taille des problèmes
Figure 5.21. – Répartition du temps de calcul des différentes fonctions pour un transport
de scalaire 2D
1105.3. Application simple GPU
5.3.2. Transport de scalaire 3D
Une application similaire est réalisée en 3D. Le scalaire est initialisé comme la fonction
caractéristique d’une sphère de centre (0, 35; 0, 35; 0, 35) et de rayon 0,15. Le champ de
vitesse, correspondant à une rotation incompressible, est défini par :
a(x, y, z, t) =
2 sin2
(πx) sin(2πy) sin(2πz)
− sin(2πx) sin2
(πy) sin(2πz)
− sin(2πx) sin(2πy) sin2
(πz)
(5.10)
Nous nous intéressons ici à l’évolution de la surface de niveau 0,5 au cours du temps qui
est soumise à une déformation de plus en plus forte. Nous comparons les effets des différentes
formules de remaillage à travers l’évolution du volume représenté par cette surface. La
figure 5.22 représente la surface de niveau 0,5 à l’instant t = 4, pour deux formules de
remaillage différentes. L’utilisation d’une formule d’ordre plus élevé, sur la figure 5.22b,
retarde l’apparition de « trous » ainsi que leur disparition comparativement à l’utilisation
de la formule Λ2,1, sur la figure 5.22a.
(a) Remaillage par Λ2,1 (b) Remaillage par Λ8,4
Figure 5.22. – Exemple de transport de fonction levelset en 3D
L’évolution du volume délimité par la surface de niveau 0,5 est donnée en fonction du
temps pour quelques noyaux de remaillage sur la figure 5.23. Ainsi, les formules d’ordre
élevé préservent mieux le volume ce qui est conforme à l’observation des figures 5.22. Ces
simulations ont été réalisées pour une constante LCFL égale à 0,35 et pour une résolution
de 3203
. Cela équivaut à une CFL de 17,8.
Les temps de calcul pour cette simulation sont donnés sur les figures 5.24 en fonction
de la taille du problème pour différentes formules de remaillage dans les cas simple échelle
et multiéchelle. Les temps de calculs sont indépendants de la taille du problème et sont de
l’ordre de 1 à 2 ns, excepté pour les petites tailles non significatives. Comme pour le cas 2D,
seules les formules de remaillage Λ2,1 et Λ8,4 sont représentées, les autres se répartissent
sur des temps de calculs intermédiaires. Là encore, la version avec un seul noyau de calcul
pour l’advection et le remaillage donne de meilleurs temps de calcul. Contrairement au
1115. Mise en œuvre sur cartes graphiques
0.0105
0.011
0.0115
0.012
0.0125
0.013
0.0135
0.014
0.0145
0 0.5 1 1.5 2 2.5 3 3.5 4
75
80
85
90
95
100
Volume
% du volume initial
Temps
Volume initial
Λ2,1
Λ4,2
Λ6,4
Λ8,4
Figure 5.23. – Évolution du volume défini par le niveau 0,5 d’une fonction levelset
cas 2D, cette version permet de traiter des résolutions plus grandes car l’empreinte en
mémoire globale est plus faible et la mémoire partagée n’est pas limitante. Ainsi la résolution
maximale en simple échelle est de 4483 mais il est possible de traiter une résolution de 5123
pour le scalaire lorsque la résolution de la vitesse est inférieure à 3843
.
Copie
Transposition XY
Transposition XZ
Hôte
Advection
Remaillage
Advection et remaillage
0
10
20
30
40
50
60
70
80
90
100
128
3
256
3
128
3
256
3
128
3
256
3
128
3
256
3
Λ2,1 Λ8,4
% du temps de calcul
Taille des problèmes
(a) Simple échelle
0
10
20
30
40
50
60
70
80
90
100
128
3
256
3
512
3
128
3
256
3
512
3
128
3
256
3
512
3
128
3
256
3
512
3
Λ2,1 Λ8,4
% du temps de calcul
Taille des problèmes
(b) Multiéchelle (Nu = 43Na)
Figure 5.25. – Temps de calcul des différentes fonctions pour un transport de scalaire 3D
1125.3. Application simple GPU
1k : RK2, Λ2,1
2k : RK2, Λ2,1
1k : RK4, Λ2,1
2k : RK4, Λ2,1
1k : RK2, Λ8,4
2k : RK2, Λ8,4
1k : RK4, Λ8,4
2k : RK4, Λ8,4
2
4
8
1
10
643
1283
2563
3843
5123
Temps de calcul par particule (ns)
Taille des tableaux
(a) Simple échelle
2
4
8
1
10
643
1283
2563
3843
5123
Temps de calcul par particule (ns)
Taille des tableaux
(b) Multiéchelle (Nu = 43Na)
Figure 5.24. – Performances globales de la méthode pour un transport de scalaire 3D
Comme pour le cas 2D, nous donnons, sur la figure 5.25, les répartitions du temps
de calcul à travers les différentes fonctions de la méthode. Les contributions issues des
différentes directions de splitting sont différenciées par les nuances de couleurs. Comme
pour le cas 2D, les directions X, Y et Z se partagent le temps de calcul total et en occupent
respectivement les 2/5, 2/5 et 1/5. Les deux premières sont traitées deux fois sur des demi
pas de temps. Les opérations d’initialisation occupent entre 15 et 30% du temps de calcul.
Conclusion
Dans ce chapitre, nous avons présenté une implémentation spécifique aux architectures
multicœurs telle que les cartes graphiques de la méthode semi-Lagrangienne. La straté-
gie d’implémentation a été élaborée en se basant sur les études similaires existantes. Les
différentes fonctions de la méthode ont été étudiées à travers leurs performances respectivement
à des optimisations génériques basées sur les caractéristiques techniques des cartes
graphiques. Ces optimisation peuvent également conduire à de bonnes performances sur
d’autres cartes que celle présentée ici.
Les performances individuelles des noyaux d’initialisation, comme fonctions de manipulation
de données, atteignent jusqu’à 73% de la bande passante maximale pour la copie. Les
transpositions permettent d’obtenir une bande passante respectivement de 64%, 71% et 63%
pour la transposition XY en 2D et 3D et pour la transposition XZ. Ces performances sont
assez satisfaisantes en comparaison avec celles obtenues pour la copie. En effet, les bandes
passantes atteintes pour les transpositions sont supérieures à 86% de celle de la meilleure
1135. Mise en œuvre sur cartes graphiques
copie. Comme pour les noyaux d’initialisation, les performances des noyaux de calcul sont
fortement dépendantes des tailles de tableaux traitées. Pour les tailles les plus adaptées, les
puissances de calcul développées par les noyaux d’advection dans le modèle roofline sont
supérieures 50% de la puissance maximale atteignable et légèrement inférieures dans les cas
multiéchelle. L’augmentation de l’ordre des formules de remaillage implique une augmentation
de puissance de calcul des kernels de remaillage pour obtenir des performances proches
de 50% de la puissance maximale. Pour ce qui est des noyaux réalisant les opérations d’advection
et de remaillage en une seule passe, les performances se situent au voisinage de 20%
de la puissance maximale. Toutefois, ces noyaux montrent un temps de calcul global géné-
ralement meilleur que lorsque deux noyaux séparés sont employés. La quantité de mémoire
partagée requise par ce noyau interdit son usage pour les grandes tailles en 2D. Au contraire,
en 3D, ce noyau permet de traiter de plus grandes résolutions du fait de l’utilisation d’une
plus faible quantité de mémoire globale. Par conséquent, il est préférable d’utiliser la version
en deux noyaux pour les simulations 2D du fait de la limitation en mémoire partagée.
De même, le noyau complet est mieux adapté aux problèmes 3D car il permet de diminuer
l’empreinte en mémoire globale. Enfin, les deux exemples de transport de fonction levelset
proposent une validation qualitative de la méthode.
Bien que ces résultats soient obtenus sur une machine de calcul, des expériences conduisant
à l’obtention de performances similaires sont menées sur des machines de bureau ou
portables, montrant ainsi la portabilité de notre implémentation. Toutefois, nous ne présentons
pas ces résultats dans ce manuscrit par souci de simplification car ces machines sont
dotées de cartes d’anciennes générations n’offrant pas les même facilités de développement.
De plus les cartes sont utilisées par les systèmes d’exploitation pour l’affichage à l’écran.
Sur ces configurations, le calcul est en concurrence avec l’affichage pour l’utilisation des ressources,
ce qui donne lieu à des variations de performances non reproductibles et pouvant
être importantes.
1146. Implémentation sur
architectures hétérogènes
Nous avons vu dans le chapitre 5 que la méthode semi-Lagrangienne, telle que présentée
au chapitre 2 avec splitting dimensionnel et formules de remaillage d’ordre élevé, est
bien adaptée pour tirer profit de l’architecture des cartes graphiques. En effet, l’analyse
des performances dans un modèle roofline montre des puissances de calcul généralement
supérieures à 50% de la puissance maximale atteignable. Les temps de calculs ainsi obtenus
sont assez faibles et incitent à passer à l’échelle avec une exécution parallèle sur plusieurs
cartes graphiques.
L’objectif de ce chapitre est de réaliser des simulations de transport de scalaire passif
dans un écoulement turbulent tel que décrit dans le chapitre 1. La stratégie de résolution,
exposée dans le chapitre 3, vise à exploiter les différentes ressources des machines de calcul
hétérogène en réalisant le calcul du fluide sur des architectures multi-CPU et le transport
du scalaire sur plusieurs GPU. La conception de la librairie, détaillée au chapitre 4, facilite
l’intégration des méthodes de résolution des autres éléments des équations du problème
complet de transport de scalaire passif dans un écoulement turbulent tels que les termes de
d’étirement, de diffusion et l’équation de poisson.
Dans un premier temps, nous détaillerons l’architecture hétérogène considérée ainsi que
les différentes stratégies de parallélisme usuelles. Notre approche se base sur l’exploitation de
toutes les ressources de calcul disponibles en maximisant leur occupation. Cela se traduit par
l’emploi combiné de parallélismes à mémoire distribuée et partagée. Dans un second temps,
nous détaillerons l’adaptation de la méthode à la résolution d’un problème de transport de
scalaire sur une architecture multi-GPU. L’accent sera mis sur l’analyse des performances
des communications entre les cartes à travers l’illustration sur l’exemple de transport de
fonction levelset 3D du chapitre 5. Enfin, nous présenterons la méthode de résolution pour
l’application au transport turbulent de scalaire passif à travers un exemple d’application à
la simulation d’un jet plan turbulent.
1156. Implémentation sur architectures hétérogènes
6.1. Lien entre la méthode et l’architecture hybride
6.1.1. Description d’une machine hybride
Comme nous l’avons évoqué dans le chapitre 1, les machines de calcul parallèles actuelles
sont caractérisées par des architectures hétérogènes regroupant de nombreux processeurs
multicœurs et accélérateurs. Généralement, elles présentent une organisation hiérarchique
de leurs composants. Une machine de calcul est constituée d’un ensemble de nœuds connectés
par un réseau local à très haut débit permettant des vitesses de transfert de plusieurs
dizaines de GByte/s. Un nœud de calcul possède les mêmes caractéristiques qu’un ordinateur
personnel utilisé comme serveur. Ainsi, il est constitué, au minimum, d’un processeur,
de mémoire vive et d’un espace disque. Ces ressources sont gérées par un système d’exploitation
qui lui est propre. Les composants présents sur un nœud varient d’une machine à
l’autre et éventuellement d’un type de nœud à l’autre sur une même machine. De manière
générale, ils contiennent plusieurs processeurs multicœurs et éventuellement des accélérateurs
tels que les cartes graphiques ou des coprocesseurs. Un exemple d’une telle architecture
est donnée en figure 6.1 où les nœuds sont connectés à travers le même réseau et certains
contiennent des accélérateurs.
Cœur CPU
CPU multicœur
Mémoire vive
Accélérateur
Réseau local Nœud
Figure 6.1. – Exemple d’architecture hybride
Dans la suite de ce chapitre, nous utilisons la machine de calcul Froggy du mésocentre
CIMENT 1 qui possède notamment sept nœuds contenant chacun deux processeurs octocœurs
Intel Sandy Bridge EP E5-2670 partageant 32 GByte de mémoire vive et deux
cartes graphiques Nvidia K20m.
1. http://ciment.ujf-grenoble.fr
1166.1. Lien entre la méthode et l’architecture hybride
6.1.2. Différents niveaux de parallélisme
Parmi les paradigmes de programmation parallèle usuels, le parallélisme de données et le
parallélisme par tâches se distinguent par l’organisation des calculs par rapport aux données
à traiter (Dongarra et al., 2003). Dans le premier, on réalise l’exécution simultanée de
tâches identiques sur des données différentes. En revanche, le second consiste en l’exécution
simultanée de tâches différentes sur des données identiques ou non. Ces deux approches sont
couramment employées pour l’exploitation de machines de calcul parallèles hétérogènes, à
travers l’utilisation des librairies telles que MPI et OpenMP. Différentes techniques sont
à considérer pour la mise en œuvre de ces paradigmes selon la nature de la mémoire,
partagée ou distribuée. La littérature étant abondante sur le sujet, dans cette section nous
ne donnerons que quelques éléments concernant l’implémentation de ces paradigmes.
Au sein d’un nœud, la mémoire est partagée par l’ensemble des cœurs des processeurs.
Dans ce contexte, les taches sont distribuées sur l’ensemble des cœurs physiques à l’aide
d’une librairie telle que OpenMP. Ce paradigme permet l’exploitation, au maximum, de
l’ensemble des cœurs CPU d’un seul nœud car les données manipulées doivent être référencées
dans le même espace d’adressage
En complément de cette stratégie se trouve le parallélisme par envoi de message tel que
proposé par le standard MPI. Il permet de réaliser des communications d’un processus à un
autre dans un contexte de mémoire distribuée. Dans le cas général, il n’est pas possible à
un processus de lire ou d’écrire dans une zone mémoire attribuée à un autre processus. Le
principe de ce paradigme est que les données à transmettre sont empaquetées dans un message
qui est envoyé au processus destinataire à travers le réseau de la machine. Une gestion
fine de l’envoi et de la réception de ces messages est nécessaire afin que les données soient
correctement traitées, éventuellement par l’utilisation de zones mémoires temporaires. Une
très grande précision des communications est possible à travers l’utilisation des nombreuses
variantes proposées par la librairie telles que, entre autres, les communications point à
point ou globales ainsi que leurs versions bloquantes ou non. Ce paradigme s’utilise dans un
environnement à mémoire distribuée mais fonctionne également avec une mémoire partagée.
Une implémentation hybride associe plusieurs stratégies de parallélisme pour exploiter
au mieux une architecture donnée. Ainsi, sans tenir compte des accélérateurs dans un
premier temps, les utilisations courantes suivent deux stratégies distinctes pour l’exploitation
de l’ensemble des cœurs CPU d’une machine. L’intégration d’une librairie d’envoi
de message permet une utilisation d’un ensemble de processeurs multicœurs de plusieurs
nœuds d’une machine. Ce fonctionnement se base sur fait que les librairies d’envoi de message,
comme MPI, sont utilisables dans un contexte mixte de mémoire partagée et distante.
Cependant, l’intégration d’un tel parallélisme implique généralement d’importants changements
dans le code. Une réécriture de certaines parties est nécessaire lorsque l’utilisation
de ce paradigme n’a pas été prévue à la conception. La seconde stratégie consiste combiner
des paradigmes spécifiques à un environnement à mémoire partagée et à mémoire distribuée.
Une approche basée sur les librairies MPI et OpenMP est couramment utilisée. Ces
deux stratégies que l’on notera respectivement MPI et MPI+OpenMP permettent d’utiliser
l’ensemble des cœurs CPU d’une machine de calcul. La principale différence est que la mé-
moire partagée par les processus d’un même nœud est gérée par un parallélisme spécifique
dans le cas MPI+OpenMP, ce qui permet une plus grande finesse d’optimisation et donc
1176. Implémentation sur architectures hétérogènes
potentiellement l’obtention de meilleures performances. En revanche, le développement et
le débogage sont généralement plus complexes.
L’ensemble des processus déployés sur les cœurs physiques des nœuds peuvent ne pas
réaliser des opérations similaires sur des données différentes. Un paradigme de parallélisme
par tâches permet d’affecter des ensembles de processus à différentes tâches. Dans ce cas,
au sein d’un même groupe, une tâche est traitée de manière collaborative. En revanche,
deux processus associés à deux tâches distinctes sont amenés à exécuter des instructions
totalement différentes. Toutefois, des communications sont généralement nécessaires pour
échanger des données entre les processus des différentes tâches lorsqu’elles ne sont pas
totalement indépendantes.
L’exploitation des cartes graphiques comme accélérateurs se réalise de manière identique
au cas d’une utilisation exclusive de l’accélérateur, comme présentée au chapitre 5. Un
processus peut exploiter un accélérateur à l’aide des différentes techniques telles que CUDA
ou OpenCL. Les cartes graphiques récentes sont capables de gérer l’exécution d’un ensemble
de tâches provenant de plusieurs processus. Par conséquent, tous les processus placés sur
un même nœud peuvent exploiter une même carte graphique. De même, dans le cas où
plusieurs cartes sont présentes, un même processus peut utiliser simultanément l’ensemble
des cartes graphiques.
Ainsi, les machines hybrides doivent être exploitées en utilisant à la fois un parallélisme
à mémoire distribuée, à mémoire partagée ainsi que des accélérateurs. On complète les
notations précédentes par MPI+OpenCL ou MPI+OpenMP+OpenCL si OpenCL est utilisé
sur les accélérateurs.
6.1.3. Stratégie d’utilisation
La stratégie que nous employons dans ce travail se limite à une exploitation des processeurs
multicœurs à l’aide du seul niveau de parallélisme par envoi de message. Cette
approche, complétée par l’utilisation de la librairie OpenCL, nous permet de traiter à la
fois les cas multi-GPU et hétérogènes. En effet, pour une exploitation de plusieurs cartes
graphiques, il est nécessaire de placer un processus par nœud pour exploiter l’ensemble des
cartes du nœud. Ces différents processus, se situent nécessairement dans un environnement
à mémoire distribuée, d’où le choix de l’utilisation de MPI pour la gestion du parallélisme
des processus hôtes.
En pratique, dans notre implémentation, chaque GPU n’est géré que par un et un
seul processus hôte. En effet, des études préliminaires ont montré une dégradation des
performances lorsque plusieurs processus exploitent la même carte graphique de manière
concurrente comparativement au cas où une carte est associée à un processus. Ce phénomène
est en partie dû au fait que notre implémentation est plus efficace pour traiter de grandes
tâches comparativement au traitement de plusieurs tâches plus petites. D’autre part, il nous
semble plus avantageux de ne pas exploiter plusieurs cartes à partir du même processus
hôte car le découpage des tâches est déjà réalisé au niveau des différents processus hôtes. Il
apparaît donc inutile d’ajouter un second niveau de découpage interne au processus. Ainsi,
l’exploitation de n cartes graphiques est obtenue par le placement de n processus MPI
répartis sur l’ensemble des nœuds contenant les cartes.
1186.2. Application multi-GPU
L’inconvénient majeur de cette stratégie est qu’un nœud de calcul dispose généralement
d’un plus grand nombre de cœurs CPU que de cartes graphiques. Dans l’exemple de la
machine Froggy, le rapport est de 8. Lors d’une utilisation multi-GPU, de nombreux cœurs
CPU sont inutilisés. L’approche que nous proposons dans la section 6.3 à travers la mise
en œuvre de la méthode hybride nous permettra d’explorer une solution à ce problème
d’occupation.
La suite de ce chapitre est consacrée à la mise en œuvre de cette stratégie dans un cadre
multi-GPU puis hybride multi-CPU et multi-GPU.
6.2. Application multi-GPU
6.2.1. Mécanisme de communication
La résolution de l’équation de transport sur plusieurs cartes graphiques nécessite des
communications entre ces GPU. À chaque carte est associée une partie du domaine de
calcul. Ainsi, le domaine de calcul est séparé le long de plans orthogonaux à une direction
de découpe. Nous appelons direction de découpe une direction dont le traitement nécessite
des communications. Le principal avantage de ce découpage est de conserver une méthode de
résolution identique au cas simple GPU lors du traitement des directions de l’espace autres
que celles de découpe. Dans ces dernières, les données correspondant aux sous-problèmes 1D
sont distribuées sur plusieurs cartes ce qui implique des communications entre ces cartes.
Nous distinguons alors les données locales calculées par une carte et les données non locales
qui sont calculées par une autre carte et qui doivent être transférées.
Deux communications sont nécessaires : une pour l’étape d’advection et l’autre pour
le remaillage. Pour l’advection, les interpolations du champ de vitesse nécessaires au calcul
des positions des particules sont faites sur des données non locales pour les particules
ayant quitté le domaine. Ces données devront être transférées au préalable depuis les cartes
voisines. La quantité de ces données dépend directement du champ de vitesse lui-même.
Toutefois, une majoration de leur taille est possible à partir du nombre CFL maximal. En
effet, ce dernier correspond au nombre maximal de cellules traversées par les particules en
une itération. Une particule au bord du domaine n’aura pas besoin de plus de données distantes
qu’elle ne peut traverser de cellules. Cet algorithme est schématisé sur la figure 6.2a.
De la même manière, lors du remaillage, la taille des zones de communications dépend du
nombre CFL maximal ainsi que de la largeur du support de la formule de remaillage employée.
Lors du calcul, le domaine local est bordé par des zones mémoire qui représentent les
points de grille voisins distants et récupèrent les contributions des particules sur ces points.
Ces derniers sont parfois appelés points fantômes ou ghosts. Les données de ces zones sont
ensuite envoyées aux processus voisins puis ajoutées aux données locales. L’adaptation de
cet algorithme est schématisé sur la figure 6.2b. Les communications se font exclusivement
avec les processus voisins dans la direction de calcul. Dans les deux algorithmes, une utilisation
de la mémoire partagée comme un cache similaire au cas simple GPU est employée
pour les données du champ de vitesse non local ainsi que pour les points de grille exté-
rieurs. Les échanges de données à l’issue du remaillage se caractérisent par un ajout des
1196. Implémentation sur architectures hétérogènes
valeurs distantes du scalaire aux valeurs locales, alors que pour le champ de vitesse, il s’agit
simplement d’une copie des données qui sont utilisées en lecture uniquement.
GPUn
GP Un−1
GPUn+1
Intégration
Interpolations
Vitesse
(grille)
Mémoire
partagée
Position
(particules)
Copies de données
Utilisation des données
Communication inter-GPU
Données non locales
(a) Advection
GPUn
GPUn−1
GPUn+1
Scalaire
(particules)
Position
(particules)
Scalaire
(grille)
Mémoire
partagée
+=
+=
+=
+=
Λp,r
Copies de données
Utilisation des données
Communication inter-GPU
Données non locales
(b) Remaillage
Figure 6.2. – Adaptation des algorithmes d’advection et remaillage au cas multi-GPU
Ces communications inter-GPU consistent en des échanges de données entre les mé-
moires globales des cartes graphiques. Généralement, les implémentations MPI ne sont pas
capables de lire et écrire des données directement dans la mémoire des cartes sans faire
intervenir l’hôte. Toutefois, certaines implémentations spécifiques telles que MPI-ACC (Aji
et al., 2012) ou MVAPICH (Wang et al., 2011) permettent de réaliser des envois de messages
directement de la mémoire d’une carte à l’autre. Dans cette dernière, les transferts utilisent
les technologies telles que proposées par les versions récentes de CUDA sur les cartes Nvidia
(GPUDirect). La librairie MVAPICH est disponible au téléchargement 2 mais ne permet
qu’une exploitation des seules cartes NVIDIA et, à notre connaissance, la librairie générique
MPI-ACC n’a pas été encore distribuée. Ces travaux font état de gains en termes de per-
2. http ://mvapich.cse.ohio-state.edu/downloads/
1206.2. Application multi-GPU
formances des communications pouvant atteindre 30% par rapport à des transferts naïfs.
En l’absence de telles librairies, la méthode naïve consiste en une succession de transferts
depuis la mémoire globale de la carte vers le CPU, entre les CPU hôtes et enfin du CPU
vers la mémoire de la carte de destination. Ce mécanisme est illustré sur la figure 6.3 par
l’enchaînement des flèches vertes et bleues.
Réseau local
host - device
MPI
GPU-aware MPI
Figure 6.3. – Schémas de communications inter-GPU
Les résultats de cette thèse sont obtenus à l’aide de transferts naïfs combinant explicitement
un usage des fonctions OpenCL pour les transferts entre les cartes et les CPU
hôtes ainsi que des envois de message MPI entre CPU. Nous précisons que l’utilisation
technologies spécifiques aux cartes Nvidia n’a pas encore été intégré au standard OpenCL.
De manière générale, ces transferts peuvent être optimisés par un découpage des données
en blocs dont les envois sont traités en chaîne (Aji et al., 2013), comme illustré par la fi-
gure 6.4. Ainsi, le message original est traité par un ensemble d’envois de plus petite taille
permettant un recouvrement des opérations. La taille des blocs est un des paramètres qui
doit être ajusté en fonction du matériel utilisé (PCIe et réseau).
Transfert manuel GPU vers CPU MPI CPU vers GPU
Transfert par blocs
en chaîne temps
Figure 6.4. – Optimisation des communications inter-GPU
6.2.2. Performances
Les performances de cette implémentation dans un contexte multi-GPU sont étudiées à
travers l’exemple de transport de fonction levelset 3D présenté en section 5.3.2.
Des études de scalabilité, dont le principe a été introduit en section 1.2.2, permettent
d’observer l’évolution du temps de calcul face à l’augmentation du volume total de communication
induite par l’augmentation du nombre de ressources utilisées. La scalabilité forte
d’un code démontre sa capacité à traiter un problème plus rapidement lorsque le nombre de
1216. Implémentation sur architectures hétérogènes
ressources augmente. Idéalement, on attend que le temps de calcul soit réduit d’un facteur
n lorsque les ressources sont augmentées d’un facteur n. Cette étude n’est pas adaptée à
notre implémentation multi-GPU car elle conduit à la résolution de problèmes de tailles
de plus en plus petite à mesure que le nombre de cartes utilisées augmente. Dans ce type
d’étude, la taille du problème total est fixée et doit pouvoir être traitée par un seul GPU.
De plus, comme nous avons vu dans le chapitre précédent, les meilleures performances sont
obtenues lorsque le problème traité sur un GPU est suffisamment grand.
Une étude de scalabilité faible est préférable dans ce contexte. Elle conduit à l’étude de
l’évolution du temps de calcul lorsque le nombre de ressources augmente en conservant une
charge de travail par GPU constante. Ainsi, en partant d’une taille de problème compatible
avec les caractéristiques d’une carte graphique, l’influence des communications est directement
mesurée. Les résultats de scalabilité, présentés sur la figure 6.5, sont obtenus en en
utilisant un schéma RK2 et une formule de remaillage Λ6,4 pour résoudre des problèmes de
taille (NX, NY , nNZ) où n est le nombre de GPU employés. Ainsi, chaque GPU est chargé
d’un problème de taille (NX, NY , NZ). Nous ne considérons ici qu’une seule direction de
découpe, dans la direction Z. La figure 6.5 représente l’évolution de la scalabilité en fonction
du nombre de cartes graphiques utilisées. Deux cas sont considérés : le premier est
une résolution identique de 2563 points de grille par GPU pour la vitesse et le scalaire. Le
second est un cas multiéchelle où la vitesse est connue sur une grille de taille 1283 alors que
le scalaire est résolu sur 5123 points.
Les oscillations qui apparaissent pour les cas à 2563 par GPU sont dues à la distance
variable entre deux cartes voisines. En effet, les communications au sein d’un même nœud
sont plus rapides que d’un nœud à l’autre. En pratique, lorsqu’un GPU est ajouté à un
nombre impair, on ajoute la seconde carte du dernier nœud à l’ensemble des cartes utilisées.
Dans ce cas, les communications supplémentaires sont réalisées entre les deux cartes du
même nœud, ce qui conduit à une amélioration de la scalabilité. La perte importante de
scalabilité entre 1 et 2 GPU provient de l’absence totale de communications dans le cas 1
GPU ainsi que du manque d’optimisation des cas multi-GPU. Comme nous l’avons évoqué
précédemment, leur taille dépend du nombre CFL de la simulation. Pour les cas Na =
Nu = 2563
, le nombre CFL maximal est égal à 8 et implique des communications de taille
8×2562
éléments par voisins pour le champ de vitesse et le scalaire. Dans le cas multiéchelle
Na = 1283
et Nu = 5123
, le pas de temps est identique et les tailles de communications par
voisins sont de 4 × 1283
et 15 × 5123
respectivement pour la vitesse et le scalaire. D’autre
part, dans l’état actuel du code, nous n’avons pas encore mis en place de stratégies de
recouvrement des communications par des calculs, ce qui implique que les temps de calculs
sont augmentés de la totalité des temps de communications. Ainsi la scalabilité du cas 2
GPU par rapport au cas 1 GPU est assez faible car elle revient à comparer les temps de
communications à un cas sans aucune communication. Toutefois, la scalabilité par rapport
au cas utilisant 2 GPU est satisfaisante car supérieure à 0.85 jusqu’à 12 GPU. La version
avec un seul kernel donne des résultats similaires à celle avec deux kernels séparés avec des
temps de calcul inférieurs de 3%. D’autre part, la chute de scalabilité entre 1 et 2 GPU
peut être atténuée en diminuant le volume de communications par une réduction du pas de
temps.
La répartition du temps de calcul pour quelques cas tirés de l’étude précédente est
représentée sur la figure 6.6. Elle donne la répartition du temps de calcul global d’une
1226.2. Application multi-GPU
0.4
0.5
0.6
0.7
0.8
0.9
1
2
2(N
a
, N
u
)
4
4(N
a
, N
u
)
6
6(N
a
, Nu
)
8
8(N
a
, N
u
)
10
10(N
a
, Nu
)
12
12(N
a
, Nu
)
Scalabilité : ˜S
=
T(1)
1 /Tn
Nombre de GPU / Taille du problème
2 kernels, N
a = N
u = 2563
2 kernels, N
a = 1283
, Nu = 5123
1 kernel, N
a = N
u = 2563
1 kernel, N
a = 1283
, Nu = 5123
Figure 6.5. – Performances du transport de scalaire 3D multi-GPU
itération entre les différentes directions. Comme annoncé précédemment, les temps de calcul
issus des communications dans la direction Z apparaissent comme ajoutés au temps de
calcul obtenu sans communications et sont inclus dans la partie associée à l’hôte pour cette
direction. Ainsi, seul le temps de communication varie avec le nombre de GPU et les temps
d’exécutions des kernels restent constants.
Nous détaillons sur la figure 6.7a les éléments constituant la direction Z en distinguant
les kernels OpenCL pour l’initialisation, les kernels d’advection et de remaillage ainsi que les
étapes de transferts de données. Les communications entre CPU sont notées MPI et celles
entre les cartes et les hôtes sont notées D→H ou H→D selon le sens de transfert. Enfin,
l’étape d’ajout des contributions provenant des processus voisins est notée += et est effectuée
par l’hôte de chaque carte. Les dépendances entre toutes ces étapes sont représentées
sur la figure 6.8.
Cette représentation de l’enchaînement des différentes étapes lors du traitement d’une
direction de découpe montre que certaines peuvent être réalisées simultanément. En effet,
l’initialisation des particules est indépendante du transfert des données du champ de vitesse.
De même, la copie des données du scalaire correspondant à une partie du domaine
local est indépendante des communications des contributions pour les domaines voisins.
Le parallélisme par tâches OpenCL permet de démarrer ces opérations sans en attendre la
complétion. Les détails du profilage des temps de calculs pour la figure 6.7a sont réalisés en
forçant une synchronisation explicite des tâches permettant leur comparaison.
Comme le montre la figure 6.7a, les étapes de calculs ne suffisent pas à couvrir les
communications. La figure 6.7b illustre cette remarque en reprenant la figure 6.7a avec un
code de couleur indiquant les étapes de calcul et celles de communication. Ces résultats
suggèrent la nécessité d’une réduction des temps de communications. Une optimisation
1236. Implémentation sur architectures hétérogènes
8
4
2
1
0 0.02 0.04 0.06 0.08 0.1 0.12
Nombre de GPU
Simple échelle : N
a = N
u = 2563
Initialisation X
Calcul X
Host X
Initialisation Y
Calcul Y
Host Y
Initialisation Z
Calcul Z
Host Z
8
4
2
1
0 0.1 0.2 0.3 0.4 0.5 0.6 0.7
Nombre de GPU
Temps de calcul par itération (s)
Multiéchelle : N
a = 1283
, Nu = 5123
Figure 6.6. – Temps de calcul par itération
envisageable consiste à améliorer les temps de transfert entre GPU en utilisant, par exemple,
un traitement par blocs en chaîne. Après cette première optimisation, une stratégie de
recouvrement des communications par les calculs pourra être envisagée. En particulier,
les étapes de calculs peuvent être séparées en deux parties à l’issue d’un redécoupage du
domaine local. Une première partie entièrement locale, ne nécessitant pas l’usage de données
distantes, peut s’exécuter pendant les communications. La seconde partie consiste à traiter
le reste du domaine à l’aide des données transférées. L’optimisation des communications
ainsi que leur recouvrement constituent une des perspectives immédiates de ce travail.
Les résultats présentés ici sont réalisés uniquement dans le cas d’une seule direction de
découpe, par plans XY . L’implémentation que nous proposons ne se restreint pas à cette approche
et permet notamment de considérer une découpe dans autre direction ainsi que dans
plusieurs directions. Cette dernière est utile essentiellement dans les cas où un grand nombre
de cartes graphiques est employé afin de réduire les disparités de nombre de points des domaines
locaux. Par exemple, pour la résolution d’un problème global de taille (NX, NY , NZ)
sur n cartes graphiques la résolution des domaines locaux est égale à (NX, NY , NZ/n) dans
le cas d’une découpe dans la direction Z. Elle passe à (NX, NY /n1, NZ/n2), avec n = n1n2
pour une découpe dans les directions Y et Z. L’avantage est de conduire à des résolutions
plus grandes dans les directions de découpes que dans le premier cas. En revanche un
plus grand nombre de communication est nécessaire. Les configurations considérées dans
ce manuscrit ne nécessitent pas l’utilisation d’un découpage dans plusieurs directions car le
nombre de cartes graphiques reste relativement faible.
Cette implémentation multi-GPU pour le transport de scalaire peut être employée en
parallèle d’une résolution CPU de l’écoulement pour la simulation du problème complet.
1246.2. Application multi-GPU
8
4
2
1
Nombre de GPU
N
a = 1283
, Nu = 5123
Transposition XZ (kernel)
Advection (kernel)
Remaillage (kernel)
Advec. et Remail. (kernel)
Advection D→H
Advection MPI
Advection H→D
Remaillage D→H
Remaillage D→H local
Remaillage MPI
Remaillage += (hôte)
Remaillage H→D local
8
4
2
1
0 10 20 30 40 50 60 70 80 90 100
Nombre de GPU
Proportion de la direction Z (% du temps de calcul)
N
a = N
u = 2563
(a) Étapes de l’algorithme
8
4
2
1
Nombre de GPU
N
a = 1283
, Nu = 5123
Communications H↔D
Communications MPI
Calcul
8
4
2
1
0 10 20 30 40 50 60 70 80 90 100
Nombre de GPU
Proportion de la direction Z (% du temps de calcul)
N
a = N
u = 2563
(b) Calculs et communications
Figure 6.7. – Profilage de la direction de découpe
1256. Implémentation sur architectures hétérogènes
Initialisation
Vitesse
D→H
Vitesse
MPI
Vitesse
H→D
Advection
Remaillage
Scalaire local
D→H
Scalaire
D→H
Scalaire
MPI
Scalaire
+=
Scalaire local
H→D
Figure 6.8. – Dépendances des étapes de communication multi-GPU
6.3. Transport turbulent d’un scalaire passif
6.3.1. Application hybride
Le problème que nous considérons dans cette partie est le transport de scalaire passif
dans un jet plan turbulent tridimensionnel, tel que présenté par Magni et al. (2012). Le
domaine de calcul est une boite unitaire périodique [0; 1]3
. Le problème est modélisé par
le couplage entre les équations de Navier-Stokes, en formulation vitesse vorticité, et d’une
équation de transport du scalaire θ, rappelé ci-après :
div u = 0, ω = rotu,
Dω
Dt
=
∂ω
∂t + (u · ∇) ω
= (ω · ∇)u + ν∆u,
Dθ
Dt
=
∂θ
∂t + (u · ∇)θ = κ∆θ.
(6.1)
L’écoulement est constitué d’un jet plan, modélisé par un champ de vitesse initialement
nul dans tout le domaine excepté dans une région d’épaisseur w le long d’un plan XZ.
Le champ de vitesse initial est perturbé par un champ aléatoire P de magnitude 0,05. Le
scalaire passif est initialisé de la même manière que le champ de vitesse. Les valeurs initiales
du champ de vitesse et du scalaire sont données par les expressions :
θ(x, y, z) = (1 + 0.3 sin(8πx))
1 + tanh
0.1 − 2|y − 0.5|
4w
/2 (6.2)
u
X(x, y, z) = θ(x, y, z)P
X,
u
Y
(x, y, z) = P
Y
u
Z
(x, y, z) = P
Z
(6.3)
La condition initiale du champ de vitesse est représentée en figure 6.9 pour la composante
u
X. L’écoulement se développe dans le plan du jet, dans la direction X. Les perturbations
provoquent l’établissement d’un régime turbulent qui se traduit par l’évolution tridimensionnelle
de l’écoulement. Le scalaire est ainsi transporté dans tout le domaine.
L’écoulement est caractérisé par la largeur du jet w = 0.1, ce qui donne un nombre de
Reynolds égal à 103 pour une viscosité ν = 10−4
. Différentes valeurs de nombre de Schmidt
1266.3. Transport turbulent d’un scalaire passif
Figure 6.9. – Champ de vitesse initial, composante u
X
1276. Implémentation sur architectures hétérogènes
seront considérées en fonction du rapport d’échelle entre les grilles de résolutions du fluide
et du scalaire. En effet, comme nous l’avons décrit au chapitre 1, le rapport des échelles de
dissipation d’énergie est lié au nombre de Schmidt : ηκ
√
Sc = ην, avec Sc = ν/κ où ν est
la viscosité du fluide et κ la diffusivité du scalaire. Ces différentes échelles sont prises en
compte par la résolution des discrétisations des variables. Le champ de vitesse est résolu
sur une grille plus grossière que celle du scalaire.
Nous rappelons que la méthode numérique hybride employée pour résoudre ces problèmes
consiste en l’utilisation d’une méthode semi-Lagrangienne pour le transport du
scalaire et de différences finies pour sa diffusion. L’écoulement est résolu en employant
une méthode semi-Lagrangienne pour le transport de vorticité, des différences finies pour
le terme d’étirement et une méthode spectrale pour la diffusion de vorticité. L’équation de
Poisson pour le calcul du champ de vitesse est également résolue par une méthode spectrale.
6.3.2. Exploitation d’une machine hétérogène
Comme nous l’avons évoqué précédemment, le transport du scalaire et le fluide sont
suffisamment indépendants pour être résolus simultanément sur différents matériels. En
effet, le couplage de ces sous-problèmes consiste simplement en une communication du
champ de vitesse en début d’itération de la partie fluide vers le transport. Pour l’exemple
de l’utilisation de la machine Froggy présentée en section 6.1, nous utilisons n GPU et les
n cœurs CPU hôtes associés pour résoudre le transport du scalaire ainsi que les 7n cœurs
CPU disponibles sur les nœuds pour calculer le champ de vitesse de l’écoulement. Cette
distribution des tâches est représentée sur la figure 6.10.
Réseau local
Transport
Navier-Stokes
Figure 6.10. – Distribution des tâches pour l’application hybride
En pratique, nous introduisons une notion de parallélisme par tâche. Les différents processus
MPI sont associés à une tâche à travers un découpage du communicateur global.
Une synchronisation globale est effectuée à l’occasion de la communication du champ de
vitesse. Dans cette exemple, deux tâches sont définies : une pour l’écoulement et l’autre
pour le transport. Pour simplifier la distribution des tâches sur l’ensemble des processus,
la résolution globale du scalaire doit être un multiple de n. De même, les résolutions de
la vitesse et de la vorticité doivent être égales et multiples du nombre de cœurs CPU associés
à leur calcul. D’autre part, les opérations de FFT du solveur spectral donnent de
meilleures performances pour des résolutions multiples d’une puissance de 2. Ainsi, sauf
1286.3. Transport turbulent d’un scalaire passif
mention contraire, la résolution du fluide sera égale à un multiple de 4n et seulement 4 des
7 cœurs seront utilisés.
6.3.3. Résultats et performances
L’évolution du jet est caractérisée par une phase de diffusion suivie d’une phase de création
d’enstrophie qui correspond à l’apparition d’instabilités tridimensionnelles s’accompagnant
de la production de petites échelles. L’enstrophie E décrit l’évolution des pertes
d’énergie cinétique de l’écoulement E par la relation :
dE
dt
= −νE, (6.4)
avec
E =
1
2
Z
Ω
||u||2
dx et E =
Z
Ω
||ω||2
dx
La figure 6.11a donne la variation de l’enstrophie de l’écoulement dont l’augmentation rapide,
vers t = 2, indique l’apparition du régime turbulent. Les effets de dissipation d’énergie
par diffusion deviennent ensuite prépondérants et se traduisent par une diminution de l’enstrophie
et des valeurs extrêmes du champ de vitesse.
Ces simulations sont réalisées en employant des formules de remaillage Λ6,4 et une intégration
en temps par un schéma Runge-Kutta d’ordre deux pour les transports de la
vorticité et du scalaire. Des schémas aux différences finies sont utilisés à l’ordre 4 pour le
terme d’étirement et au premier ordre pour la diffusion du scalaire. Enfin, le pas de temps
est calculé à chaque itération de manière à être maximal, tout en vérifiant la condition de
CFL Lagrangienne :
∆t 6
M
|∇u|∞
.
Le choix de la constante M < 1 est laissé à l’utilisateur. Pour de grandes valeurs il
peut conduire, selon les problèmes traités, à l’apparition d’instabilités numériques pouvant
perturber l’écoulement de manière non physique. En pratique, une calibration de cette
constante par rapport au problème et à ses conditions initiales est nécessaire. Dans cet
exemple, nous constatons expérimentalement que des valeurs M > 0.2 ne permettent plus
de capter la physique de l’écoulement surtout lorsque le régime turbulent est établi, pour
t > 3. D’autre part, la perturbation aléatoire appliquée à la condition initiale conduit à des
valeurs du gradient du champ de vitesse peu représentatives de l’écoulement, en début de
simulation, et entraîne l’utilisation de pas de temps trop grands. Dans ce cas, il est nécessaire
d’employer une stratégie de calcul différente en début de simulation. En particulier,
une technique simple consiste à fixer le pas de temps à une valeur arbitraire. Une autre
idée est d’ajouter une contrainte supplémentaire sous la forme d’une condition de CFL par
rapport au champ de vitesse.
L’évolution du pas de temps et du nombre CFL maximal de l’écoulement sont présentés
sur la figure 6.11b pour deux modifications du calcul du pas de temps. Lorsque l’écoulement
n’a pas encore atteint un régime turbulent, nous appliquons une condition de type CFL (cas
1) tel que : ∆t 6 1.5∆x
u/|u|∞ ou bien (cas 2) une restriction à un pas de temps inférieur à
0.011. Dans tous les cas, le pas de temps utilisé vérifie la condition de CFL Lagrangienne.
1296. Implémentation sur architectures hétérogènes
Cette dernière devient la contrainte la plus restrictive à partir de l’instant t = 1.5 et
conduit à une diminution du pas de temps. Enfin, il augmente à nouveau sur la fin de la
simulation, à mesure que l’énergie est dissipée par les petites échelles. Toutefois, les pas de
temps obtenus sont assez grands et le nombre CFL varie entre 2 et 13, par rapport à la
grille fine de résolution 1 0243
. L’avantage de l’approche couplant une condition de CFL
et la condition Lagrangienne est qu’elle permet de conserver l’intérêt d’un pas de temps
adaptatif en suivant la dynamique de l’écoulement.
20
40
60
80
100
120
140
0 1 2 3 4 5
Enstrophie : E
=
R ||ω||
2d
x
Temps
Cas 1 : M = 0.15, CF L 6 1.5
Cas 2 : M = 0.15, ∆t 6 0.011
(a) Enstrophie
0.002
0.004
0.006
0.008
0.01
0.012
∆t
0
2
4
6
8
10
12
14
0 1 2 3 4 5
0
0.2
0.4
0.6
0.8
1
1.2
1.4
1.6
Nombre CFL maximal
|u|∞
∆t/
∆
x
θ
|u|∞
∆t/
∆
x
u
Temps
(b) Pas de temps et CFL max.
Figure 6.11. – Configuration du jet turbulent
Le nombre CFL obtenu pour le transport du scalaire peut paraître relativement faible
pour une méthode particulaire. En effet, dans cet exemple, nous employons le même pas de
temps à la fois pour la résolution du fluide et celle du scalaire. Théoriquement, une condition
moins restrictive que celle employée ici pour le transport du scalaire est envisageable
et permettrait d’utiliser de plus grands pas de temps. Cela est illustré par les exemples
de transports de fonctions levelset donnés dans le chapitre 5 où le nombre CFL atteint
des valeurs de plusieurs dizaines. Une solution, exploitée notamment par Lagaert et al.
(2014), consiste à réaliser des sous-itérations pour la partie fluide. Elle permet d’ajuster les
contraintes sur le pas de temps indépendemment pour chaque sous-problème. En pratique,
une condition LCFL est imposée pour la résolution du transport du scalaire, avec M grand,
et un nombre de sous-itérations est calculé afin d’obtenir un pas de temps suffisamment petit
pour la résolution du fluide. Dans cet exemple, il serait envisageable d’employer des pas
de temps 6 fois plus grands pour le transport du scalaire, en prenant M = 0.9. Toutefois,
l’intérêt de cette approche est limité ici car une itération du transport du scalaire est, dans
la majorité des cas, totalement recouverte par le calcul de l’écoulement. Par conséquent,
relativement au temps total de simulation, des sous-itérations pour la partie fluide condui-
1306.3. Transport turbulent d’un scalaire passif
raient à un renforcement du déséquilibre de charge entre les CPU et les GPU, comme nous
le verrons plus loin.
Les figures 6.12 donnent les valeurs de la norme de la vorticité et du scalaire dans un
plan XZ au centre du jet à l’instant t = 4.5. L’écoulement est complètement turbulent et on
observe de nombreuses structures de tailles variables. Une comparaison de ces deux images
permet d’illustrer les différentes échelles qui caractérisent ce problème pour un nombre de
Schmidt élevé. En effet, les plus petites structures de la figure de gauche, correspondant au
fluide, sont bien plus grandes que celles de la figure de droite, pour le scalaire. Le rapport
entre les tailles des structures est égal à √
Sc et est égal à 8 dans cet exemple.
||ω||
0 40
(a) Norme de la vorticité
θ
0 1
(b) Scalaire
Figure 6.12. – Champs instantanés dans le plan XZ, au centre du jet, à t = 4.5. Nu =
1283, Nθ = 1 0243, Sc = 64
Cette simulation a été réalisée en employant 32 cœurs CPU pour la résolution de l’écoulement
et 8 GPU pour le transport du scalaire à raison de 1,4 secondes par itérations, soit
23 minutes de calcul pour atteindre t = 5. La répartition des temps de calcul pour les
différentes parties de la résolution sont présentées en figure 6.13 pour différentes résolutions
et configurations. Par notre stratégie de programmation hybride, les résolutions des deux
parties du problème sont exécutées simultanément sur différentes ressources. Ainsi, le temps
de calcul total est donné par la plus longue des parties. Les trois premières lignes de la figure
correspondent à une étude de scalabilité forte car les résolutions restent identiques. La troisième
ligne fait apparaître une large part de communication pour l’advection multi-GPU
dans la direction Z. Le temps de calcul associé à cette étape est encore augmenté lorsque
la résolution du scalaire passe à 1 0243 points.
La nécessité d’une optimisation des communications entre GPU telle que suggérée par
les résultats de la section 6.2 est ici moins prononcée. En effet, dans la plupart des confi-
gurations employées pour cette application, la résolution du fluide est la partie limitante
du temps de calcul global. Ainsi, les communications, même non optimisées, générées par
1316. Implémentation sur architectures hétérogènes
le transport multi-GPU sont recouvertes par les calculs de l’écoulement sur CPU. Comme
nous l’avons détaillé précedemment, notre implémentation se base sur une majoration de
la quantité de données à échanger pour les communications inter-GPU. Dans ces exemples,
cela conduit à un volume de communications par GPU pour les cas Nu = 1283
et Nu = 2563
respectivement de 2 × 1282
et 4 × 2562 points pour les données du champ de vitesse. Pour
le scalaire, le nombre de points est de 10 × 5122
et 17 × 1 0242 pour les cas Nθ = 5123
et
Nθ = 1 0243
.
Cette estimation des tailles de communications est réalisée à priori par l’utilisateur
à partir d’une majoration du pas de temps et du champ de vitesse. Une limite à cette
approche est que les données échangées ne sont pas toujours entièrement utilisées. En effet,
au gré de l’évolution du pas de temps, la taille des données nécessaires peut diminuer par
rapport à l’estimation. De même, le maximum de vitesse n’est pas nécessairement atteint
au voisinage des bords du domaine local. La mise en place d’un calcul de la taille des
données à échanger à chaque itération a été envisagé mais n’a pas été retenu. En effet,
la complexité algorithmique supplémentaire ne permet pas nécessairement de conduire à
une réduction des temps de calcul liés à la diminution du volume des communications. Le
code GPU que nous développons exploite des tableaux en mémoire partagée dans laquelle
l’allocation dynamique n’est pas possible. Par conséquent, un changement dans la taille de
ces tableaux nécessite une recompilation des noyaux OpenCL au cours de l’exécution. Cette
recompilation peut être réalisée seulement dans les cas où la taille des tableaux augmente.
Cependant, les communications et les transferts seraient effectués sur des données non
contiguës, ce qui nuit aux performances.
On notera que le temps de calcul associé aux communications induites par le découpage
par tâches de l’implémentation hybride sont assez faibles car elles ne concernent que
le champ de vitesse. Enfin, les temps de calculs pour l’advection de la vorticité sont assez
longs relativement à la résolution du champ de vitesse. Une des causes de ce comportement
est que l’implémentation multi-CPU développée par Lagaert et al. (2014) que nous
utilisons est plutôt destinée à traiter de larges résolutions sur un très grand nombre de
processeurs, jusqu’à 3 0643 points sur 2 048 cœurs. De plus, traiter un problème de taille
1283
sur 32 cœurs conduit à une charge par cœur de seulement 1282 × 4 points. Le volume
de communications généré dans la direction Z devient relativement important car toutes
les particules nécessitent un envoi, le support de la formule de remaillage étant plus large
que le domaine local. Le cas 4 est le seul où le calcul du transport du scalaire est plus long
que le calcul de l’écoulement sur CPU. Ce déséquilibre sera vraisemblablement atténué par
une optimisation des communications entre GPU.
Comme pour l’étude dans le cas multi-GPU, nous réalisons une étude de scalabilité
faible, sur la figure 6.14a, dont les temps de calculs sont donnés sur la figure 6.14b. Deux cas
d’occupation des nœuds sont considérés. Le premier consiste en la résolution d’un problème
de taille Nu = 1283
et Nθ = 5123 pour un ensemble de ressources composé de 4 cœurs
CPU pour la résolution du fluide et 1 GPU pour le transport du scalaire, ce qui correspond
à une occupation de 5/8 = 62, 5%. Le second cas nous permet d’atteindre une occupation
maximale en utilisant 7 cœurs. La taille du sous-problème de la partie fluide Nu = 1123 =
(7 × 16)3
est ajustée pour être multiple de 7. Comme prévu par les résultats précédents,
la résolution du fluide est effectuée en un temps plus long que le transport du scalaire.
Dans les deux cas, l’évolution du temps de calcul du solveur multi-GPU donne lieu à une
1326.3. Transport turbulent d’un scalaire passif
Cas 5 : N
u = 2563
-32CPU
N
θ = 1 0243
-8GPU
Cas 4 : N
u = 1283
-32CPU
N
θ = 1 0243
-8GPU
Cas 3 : N
u = 1283
-32CPU
N
θ = 5123
-8GPU
Cas 2 : N
u = 1283
-8CPU
N
θ = 5123
-1GPU
Cas 1 : N
u = 1283
-4CPU
N
θ = 5123
-1GPU
0 0.5 1 1.5 2 2.5 3 3.5
Temps de calcul par itération
Temps total
Calcul de ∆t
Advection ω
Étirement
Diffusion ω
Poisson
Advection θ (dir. X)
Advection θ (dir. Y)
Advection θ (dir. Z)
Advection θ (comm. dir. Z)
Diffusion θ
Comm. hybride
Figure 6.13. – Répartition du temps de calcul pour le cas hybride
scalabilité similaire à celle obtenue pour la figure 6.5. Les communications entre GPU sont
pénalisées par la présence des communications induites par la résolution de l’écoulement
sur CPU, en plus des raisons évoquées en section 6.2. En effet, toutes les communications
internœuds passent nécessairement par le même réseau et se partagent sa bande passante,
ce qui limite les performances en comparaison au cas où seuls les GPU sont utilisés. En
revanche, la scalabilité reste supérieure à 85 et 70% respectivement dans les deux cas sur
48 et 84 cœurs pour le calcul de l’écoulement.
Conclusion
Dans ce chapitre nous avons vu comment les mécanismes habituels utilisés pour l’exploitation
des CPU multicœurs des machines à mémoire distribuée s’étendent au cas des
accélérateurs. L’approche étudiée consiste à compléter le parallélisme classique pour la gestion
de la mémoire distribuée par un niveau de parallélisme spécifique à l’utilisation des
accélérateurs. Ainsi, notre implémentation est capable d’exploiter l’ensemble des ressources
d’une machine hétérogène, composée de CPU multicœurs et de cartes graphiques. Dans le
modèle de programmation OpenCL, les cartes graphiques sont associées à un processus hôte
sur le CPU. Dans le cas d’une utilisation seule des GPU, un grand nombre de cœurs sont
donc inutilisés. Nous avons exploré une solution à ce problème d’occupation à l’occasion
de l’exemple de transport de scalaire dans un écoulement turbulent. L’idée est de placer
des processus sur l’ensemble des cœurs des nœuds et de les associer à différentes tâches.
Un ensemble de processus est identifié comme hôtes des cartes graphiques permettent de
1336. Implémentation sur architectures hétérogènes
Cas 1 : 1283
|5123
Ressources unitaires : (4CPU + 1GPU)
Temps total
Fluide
Scalaire
Cas 2 : 1123
|5123
Ressources unitaires : (7CPU + 1GPU)
Temps total
Fluide
Scalaire
0
0.1
0.2
0.3
0.4
0.5
0.6
0.7
0.8
0.9
1
2 4 6 8 10 12
Scalabilité faible : ˜S
=
T(1)
1 /Tn
Quantité de ressources
(a) Scalabilité faible
0
0.5
1
1.5
2
2.5
3
2 4 6 8 10 12
Temps de calcul par itération (s)
Quantité de ressources
(b) Temps de calcul
Figure 6.14. – Scalabilité faible pour le cas hybride
calculer le transport du scalaire alors que les autres processus sont affectés à la résolution
de l’écoulement.
Ce chapitre nous a permis d’analyser les performances de la méthode dans un cadre
multi-GPU à travers une étude de scalabilité faible. Il apparaît dans les résultats que la
part de temps de calcul induite par les communications entre cartes graphiques nécessite des
optimisations. En effet, diverses stratégies ont été évoquées telles qu’un découpage en blocs
pour un traitement en chaîne ou encore un recouvrement par les calculs ne nécessitant pas
de communications. Toutefois, lors de la résolution hybride du problème complet, le temps
de calcul est généralement limité par la résolution du fluide sur les cœurs CPU.
Le problème de transport de scalaire passif par un jet plan turbulent a été réalisé sur
diverses configurations matérielles jusqu’à l’exploitation de 6 nœuds complets de la machine
Froggy, soit 96 cœurs CPU et 8 GPU et pour des résolution de 2563 points pour le fluide
et 1 0243 pour le scalaire. Une limitation de cette approche est que l’équilibrage de la
charge entre les CPU et les GPU n’est pas possible autrement que par une modification
des résolutions ou des paramètre des méthodes. Ainsi, le meilleur équilibrage de charge
est obtenu dans le cas 4 de la figure 6.13 et pourrait être amélioré par l’optimisation des
communications inter-GPU. Pour ce qui est du cas 5, correspondant aux résolutions les plus
importantes, une solution consisterait à employer des ressources CPU supplémentaires, des
nœuds sans GPU par exemple.
134Conclusion générale
L’objectif principal de cette thèse était d’explorer les possibilités d’une exploitation de
machines de calcul hétérogènes par une méthode hybride pour la résolution de problèmes
multiéchelles de transport de scalaire passif.
La méthode de résolution employée repose sur une méthode particulaire avec remaillage.
Elle s’identifie à une classe de méthodes semi-Lagrangiennes dans laquelle les particules
suivent les trajectoires de l’écoulement mais en traitant l’interpolation particule-grille de
manière explicite par remaillage. L’intérêt majeur est de combiner les avantages des mé-
thodes Lagrangiennes et Eulériennes. En effet, cette méthode permet l’utilisation de pas
de temps plus grands que ceux obtenus sous une contrainte de CFL classique pour les
méthodes de grille. De plus, elle est parfaitement adaptée à la résolution d’équations de
conservation et permet une montée en ordre des schémas numériques lorsque des formules
de remaillages conservant un grand nombre de moments et suffisamment régulières sont
utilisées. Nous avons exposé, dans le chapitre 2, une méthode de construction de telles
formules dont les caractéristiques influent directement sur l’ordre de la méthode. Dans ce
même chapitre, nous avons exploité l’analogie avec la méthode des différences finies pour
démontrer la consistance et la stabilité des schémas numériques ainsi obtenus.
Le principe d’une méthode hybride tel que rappelé dans le chapitre 3 est de coupler différentes
méthodes de résolution adaptées aux différents aspects physiques et numériques du
problème considéré. Dans cette thèse, nous avons repris l’idée d’un couplage de la méthode
semi-Lagrangienne avec des schémas aux différences finies et des méthodes spectrales pour
la résolution de problèmes de transport de scalaire passif dans un écoulement turbulent.
Cette approche consiste à combiner les trois niveaux d’hybridation : grilles de résolutions
différentes pour l’écoulement et le transport du scalaire, méthodes numériques de diverses
natures et calcul sur architectures hétérogènes. Le calcul hybride est un aspect émergent du
calcul à hautes performances et découle directement de la volonté de s’adapter aux architectures
des machines de calcul parallèles. Le constat de leur évolution rapide nous a poussé
à développer un code multiarchitecture dans lequel l’accent a été mis sur la portabilité et
la souplesse d’utilisation (chapitre 4). Ce code est ainsi capable de s’exécuter sur divers
types d’architectures (CPU multicœur et GPU) et de machines (d’un portable jusqu’à un
serveur de calcul parallèle). Le langage Python a été choisi pour sa portabilité, sa simplicité
d’interfaçage avec d’autres langages et ses performances. Il nous permet d’orchestrer les
simulations en utilisant, entre autres, les librairies MPI et OpenCL ainsi que des routines
en Fortran.
135Conclusion générale
L’utilisation de cartes graphiques est particulièrement bien adaptée à la méthode particulaire
avec remaillage d’ordre élevé. En effet, comme nous l’avons montré dans le chapitre 5,
la régularité des structures de données ainsi que l’intensité opérationnelle des schémas numé-
riques nous permettent d’obtenir des performances de calcul intéressantes. En particulier,
dans une analyse par le modèle roofline, elles atteignent des performances généralement
supérieures à 50% de la puissance de calcul maximale atteignable. Les faibles temps de
calculs ainsi obtenus incitent à traiter des résolutions importantes. Cependant, elles sont
rapidement limitées par les tailles des différents niveaux de mémoire des cartes graphiques.
C’est pourquoi, nous avons développé une version multi-GPU de la méthode dont les performances,
en termes de scalabilité, ont été analysées dans le chapitre 6. Les résultats ont
montré un fort potentiel de réduction du temps de calcul induit par les communications
entre GPU sous réserve de leur optimisation et de leur recouvrement par des calculs. Cette
implémentation multi-GPU nous permet d’atteindre l’objectif principal de réalisation de
simulations de transport d’un scalaire passif dans un écoulement turbulent en exploitant
une méthode hybride et une architecture hétérogène multi-CPU et multi-GPU. Nous avons
proposé une approche permettant d’augmenter l’occupation des nœuds de calcul basée sur
un parallélisme par tâches. Elle conduit à la résolution simultanée du transport du scalaire
sur plusieurs cartes graphiques et de l’écoulement sur les cœurs CPU disponibles. Malgré
des temps de communications entre GPU relativement importants, le calcul du transport
du scalaire reste généralement plus rapide que celui de l’écoulement. Une limite à cette
stratégie est que la résolution de deux sous-problèmes sur des architectures différentes peut
conduire à un déséquilibre de charge qu’il est possible d’ajuster par une modification des
paramètres des méthodes et des tailles de grilles.
De nombreuses perspectives se dégagent des aspects mathématiques, numériques et applicatifs
de ce travail. Au niveau de la méthode numérique, il serait intéressant d’étendre
l’étude de montée en ordre aux schémas d’intégration des trajectoires des particules et de
splitting dimensionnel. Pour les premiers, nous avons réalisé l’analyse de consistance pour
des schémas d’advection d’ordre 1 et 2 ainsi que l’analyse de stabilité au premier ordre. Une
poursuite de ces études pour le cas de schémas d’ordres plus élevés serait nécessaire afin
de s’assurer de la validité de l’utilisation de schémas de type Runge-Kutta d’ordre 4, par
exemple. En ce qui concerne le splitting, nous avons essentiellement employé un splitting
de Strang d’ordre 2. La mise en œuvre d’un splitting d’ordre 3 ou 4 serait intéressante du
point de vue numérique et algorithmique.
D’autre part, lors de l’étude de la construction de formules de remaillage d’ordre élevés
Λp,r, nous avons tenté, de produire des formules diffusives, sans obtenir de résultats
satisfaisants. En pratique de telles formules ont été obtenues seulement à partir des noyaux
Λ2,r. L’intérêt de ces formules serait de réaliser une diffusion de la quantité transportée
par les particules directement dans l’étape de remaillage et ainsi d’éviter un second calcul
dédié. En effet, le traitement de la diffusion du scalaire passif, par différences finies dans
nos simulations, nécessite un parcours de l’ensemble des données en lecture et écriture dont
la suppression conduirait à une diminution du temps de calcul. Cette amélioration serait
vraisemblablement significative sur GPU mais devrait également être sensible sur des architectures
CPU plus classiques. La méthode de construction des formules, développée dans le
chapitre 2, consiste à résoudre un système linéaire dont les inconnues sont les coefficients
polynômiaux. Ce système traduit l’expression des différentes contraintes parmi lesquelles la
conservation des p premiers moments. Une étude plus fine que la simple modification de la
136contrainte de conservation du moment d’ordre 2 serait nécessaire pour la prise en compte
de la diffusion.
Du point de vue numérique, une perspective se dégage directement de l’analyse des
performances de la résolution du transport de scalaire dans un cas multi-GPU. Comme
nous l’avons souligné dans le chapitre 6, les communications entre cartes graphiques font
état d’un temps de traitement assez long comparativement au temps de calcul total. Une
réduction de ce temps de traitement est envisageable en deux étapes. Dans une première
étape, il serait intéressant d’optimiser les transferts de données entre GPU en utilisant une
approche similaire à celle employée dans la librairie MPI-ACC (Aji et al., 2012). L’idée est de
traiter les messages en plusieurs envois successifs. Ce traitement par blocs en chaîne devrait
permettre un recouvrement des différentes étapes et ainsi accélérer la communication. En
effet, pendant l’envoi du message correspondant à un bloc, il est possible de réaliser la
copie depuis l’hôte vers la carte de destination du bloc précédent ainsi que celle du bloc
suivant depuis la carte vers l’hôte émetteur. Dans une seconde étape, un recouvrement de
ces transferts par des calculs est possible en réalisant, par exemple, le calcul en deux passes.
Les calculs locaux, indépendants des données distantes, peuvent être réalisés pendant leurs
transferts.
En ce qui concerne l’implémentation multi-GPU, l’occupation des ressources CPU est
un problème délicat pour lequel nous avons proposé une solution dans le chapitre 6. En
effet, les nœuds de calculs présentent généralement plus de cœurs CPU que de GPU et
comme notre implémentation se base sur l’exploitation d’une carte par un seul processus,
cela conduit à une inutilisation des cœurs restants. L’approche basée sur un parallélisme
par tâches consiste, dans notre application, à réaliser le calcul de l’écoulement sur ces cœurs
CPU disponibles. Sur l’exemple d’utilisation de la machine Froggy, le fluide est calculé sur
4 des 7 cœurs disponibles, soit une occupation de 5/8 = 62.5%. Une occupation maximale
a été obtenue artificiellement en distribuant cette tâche sur l’ensemble des 7 cœurs en
ajustant la taille de la grille de résolution. De même, une tentative de placement de 8
processus pour cette même tâche sur les 8 cœurs physiques sur lesquels est ajouté un 9e
processus pour le calcul du scalaire a conduit à des performances largement dégradées. Nous
atteignons ainsi les limites de notre parallélisme par tâche qui, par choix de simplification
des communications, se restreint à la possibilité d’une seule tâche par processus. Cependant,
une autre stratégie pour l’augmentation de l’occupation est envisageable. Dans le cas des
octocœurs utilisés, les meilleurs résultats ont été obtenus en employant 1 cœur CPU associé
à 1 GPU pour le calcul du scalaire et 4 cœurs CPU pour le calcul de l’écoulement. Les trois
cœurs restants peuvent être assignés à d’autres tâches que celles de calcul telles que des
opérations de post-traitement, de sorties sur fichiers ou encore pour la gestion de reprises
des calculs en cours de simulation.
D’autre part, l’implémentation que nous avons proposé est basée exclusivement sur un
parallélisme par envoi de messages pour les tâches n’utilisant pas de GPU. Une perspective
intéressante serait d’envisager l’ajout d’un paradigme à mémoire partagée pour l’exploitation
des cœurs CPU. Ainsi, les cœurs d’un même nœuds seraient utilisés à travers un
parallélisme spécifique tel que OpenMP, ou même OpenCL. Un parallélisme à trois niveaux
serait donc obtenu en combinant l’utilisation de MPI entre les nœuds, OpenMP (ou
OpenCL) pour les cœurs CPU d’un même nœud et OpenCL pour les GPU. La conception
a été réalisée dans le but d’obtenir un code robuste dans lequel ces modifications peuvent
137Conclusion générale
être apportées sans impacter l’ensemble de la librairie et de manière transparente pour
l’utilisateur.
Enfin, une perspective à ce travail, en termes d’application, serait de réaliser des simulations
de transport de scalaire actif ayant un effet sur l’écoulement. Par exemple, lorsque
le scalaire représente une densité dans un écoulement de fluide multiphasique. Ce problème
se modélise par une équation de transport de la densité dont la vitesse est donnée par les
équations de Navier-Stokes. Dans ces dernières un terme barotrope apparaît pour permettre
la prise en compte de la densité comme force extérieure au modèle. En pratique la résolution
du transport de la densité est toujours envisagée sur GPU et celle du terme barotrope sera
mise en œuvre soit directement sur GPU soit sur CPU, selon la nature de la méthode numérique
utilisée. Dans le premier cas, cela implique une modification du champ de vitesse
sur GPU et donc son transfert vers le CPU pour la résolution de l’écoulement. Dans le
second cas, un simple transfert de la densité vers le CPU est nécessaire. L’intérêt de cette
application serait de conserver le caractère multiéchelle du problème en utilisant des grilles
de résolutions différentes pour l’écoulement et la densité. Dans ce cas, il serait nécessaire de
filtrer la densité, après son transport, à l’échelle de l’écoulement. Ce filtre serait réalisé sur
les GPU afin de ne transférer vers les CPU qu’une densité filtrée, donc de taille réduite.
138Bibliographie
Aji, A. M., J. Dinan, D. Buntinas, P. Balaji, W.-c. Feng, K. R. Bisset et R. Thakur (2012).
« MPI-ACC: An Integrated and Extensible Approach to Data Movement in Acceleratorbased
Systems ». IEEE 14th International Conference on High Performance Computing
and Communication & IEEE 9th International Conference on Embedded Software and
Systems.
Aji, A. M., L. S. Panwar, F. Ji, M. Chabbi, K. Murthy, P. Balaji, K. R. Bisset, J. Dinan,
W.-c. Feng, J. Mellor-Crummey, X. Ma et R. Thakur (2013). « On the Efficacy of GPUIntegrated
MPI for Scientific Applications ». Proceedings of the 22nd international symposium
on High-performance parallel and distributed computing.
Baqais, A., M. Assayony, A. Khan et M. Al-Mouhamed (2013). « Bank Conflict-Free Access
for CUDA-Based Matrix Transpose Algorithm on GPUs ». International Conference on
Computer Applications Technology.
Batchelor, G. K. (1958). « Small-scale variation of convected quantities like temperature in
turbulent fluid Part 1. General discussion and the case of small conductivity ». Journal
of Fluid Mechanics 5.1.
Bergdorf, M., G.-H. Cottet et P. Koumoutsakos (2005). « Multilevel Adaptive Particle Methods
for Convection-Diffusion Equations ». Multiscale Modeling & Simulation 4.1.
Bergdorf, M. et P. Koumoutsakos (2006). « A Lagrangian Particle-Wavelet Method ». Multiscale
Modeling & Simulation 5.3.
Bergman, K., S. Borkar, D. Campbell, W. Carlson, W. Dally, M. Denneau, P. Franzon,
W. Harrod, K. Hill, J. Hiller, S. Karp, S. Keckler, D. Klein, R. Lucas, M. Richards, A.
Scarpelli, S. Scott, A. Snavely, T. Sterling, R. S. Williams et K. Yelick (2008). ExaScale
Computing Study : Technology Challenges in Achieving Exascale Systems. Rapport
technique. DARPA IPTO.
Büyükkeçeci, F., O. Awile et I. F. Sbalzarini (2012). « A portable OpenCL implementation
of generic particle–mesh and mesh–particle interpolation in 2D and 3D ». Parallel
Computing 39.2.
Canuto, C., M. Y. Hussaini, A. Quarteroni et T. A. Zang (1987). Spectral Methods in Fluid
Dynamics (Scientific Computation).
Chen, S. et G. D. Doolen (1998). « Lattice boltzmann method for fluid flows ». Annual
Review of Fluid Mechanics 30.0.
Cheng, H., L. Greengard et V. Rokhlin (1999). « A Fast Adaptive Multipole Algorithm in
Three Dimensions ». Journal of Computational Physics 155.2.
Chorin, A. J. (1968). « Numerical Solution of the Navier-Stokes Equations ». Mathematics
of Computation 22.
139Bibliographie
Chorin, A. J. (1973). « Numerical study of slightly viscous flow ». Journal of Fluid Mechanics
57.4.
Cocle, R., G. Winckelmans et G. Daeninck (2008). « Combining the vortex-in-cell and
parallel fast multipole methods for efficient domain decomposition simulations ». Journal
of Computational Physics 227.21.
Coquerelle, M. et G.-H. Cottet (2008). « A vortex level set method for the two-way coupling
of an incompressible fluid with colliding rigid bodies ». Journal of Computational Physics
227.21.
Cottet, G.-H. (1991). « Particle-grid domain decomposition methods for the Navier-Stokes
equations in exterior domains ». Lectures in Applied Mathematics 28.
Cottet, G.-H. et S. Mas-Gallic (1990). « A particle method to solve the Navier-Stokes
system ». Numerische Mathematik 57.1.
Cottet, G.-H., P. Koumoutsakos et M. L. Ould Salihi (2000). « Vortex Methods with Spatially
Varying Cores ». Journal of Computational Physics 162.1.
Cottet, G.-H., B. Michaux, S. Ossia et G. VanderLinden (2002). « A Comparison of Spectral
and Vortex Methods in Three-Dimensional Incompressible Flows ». Journal of Computational
Physics 175.2.
Cottet, G.-H. et L. Weynans (2006). « Particle methods revisited: a class of high order
finite-difference methods ». Comptes Rendus Mathematique 343.1.
Cottet, G.-H., G. Balarac et M. Coquerelle (2009a). « Subgrid particle resolution for the
turbulent transport of a passive scalar ». Advances in Turbulence XII, Proceedings of the
12th EUROMECH European Turbulence Conference, September, 2009 132.1.
Cottet, G.-H. et A. Magni (2009b). « TVD remeshing formulas for particle methods ».
Comptes Rendus de l’Academie des Sciences Paris Serie I 34.23.
Cottet, G.-H., J.-M. Etancelin, F. Perignon et C. Picard (2014). « High order semi-lagrangian
particles for transport equations: numerical analysis and implementations issues. » ESAIM:
Mathematical Modelling and Numerical Analysis 48.4.
Crouseilles, N., T. Respaud et E. Sonnendrücker (2009). « A forward semi-Lagrangian method
for the numerical solution of the Vlasov equation ». Computer Physics Communications
180.10.
Degond, P. et S. Mas-Gallic (1989). « The Weighted Particle Method for ConvectionDiffusion
Equations Part 1 : The Case of an Isotropie Viscosity ». Mathematics of Computation
53.188.
Dolbeau, R., S. Bihan et F. Bodin (2007). « HMPP: A hybrid multi-core parallel programming
environment ». Workshop on General Purpose Processing on Graphics Processing
Units.
Dongarra, J., I. Foster, G. Fox, W. Gropp, K. Kennedy, L. Torczon et A. White (2003).
The Sourcebook of Parallel Computing.
Dongarra, J., P. Beckman, T. Moore, P. Aerts, G. Aloisio, J.-C. Andre, D. Barkai, J.-
Y. Berthou, T. Boku, B. Braunschweig, F. Cappello, B. Chapman, A. Choudhary, S.
Dosanjh, T. Dunning, S. Fiore, A. Geist, B. Gropp, R. Harrison, M. Hereld, M. Heroux,
A. Hoisie, K. Hotta, Y. Ishikawa, F. Johnson, S. Kale, R. Kenway, D. Keyes, B. Kramer,
J. Labarta, A. Lichnewsky, T. Lippert, B. Lucas, B. Maccabe, S. Matsuoka, P. Messina,
P. Michielse, B. Mohr, M. S. Mueller, W. E. Nagel, H. Nakashima, M. E. Papka, D. Reed,
M. Sato, E. Seidel, J. Shalf, D. Skinner, M. Snir, T. Sterling, R. Stevens, F. Streitz, B.
Sugar, S. Sumimoto, W. Tang, J. Taylor, R. Thakur, A. Trefethen, M. Valero, A. van
der Steen, J. Vetter, P. Williams, R. Wisniewski et K. Yelick (2011). « The Internatio-
140Bibliographie
nal Exascale Software Project roadmap ». International Journal of High Performance
Computing Applications 25.1.
Dongarra, J., J. Hittinger, J. Bell, L. Chac\’{o}n, R. Falgout, M. Heroux, P. Hovland, E. Ng,
C. Webster et S. Wild (2014). Applied Mathematics Research for Exascale Computing.
Rapport technique. U.S. Department of Energy, Office of Science, Advanced Scientific
Computing Research Program.
Fermi, E., J. Pasta et S. Ulam (1955). Studies of nonlinear problems. Rapport technique.
Gotoh, T., S. Hatanaka et H. Miura (2012). « Spectral compact difference hybrid computation
of passive scalar in isotropic turbulence ». Journal of Computational Physics
231.21.
Green500 (2014). http://www.green500.org/.
Gustafson, J. L. (1988). « Reevaluating Amdahl’s Law ». Communications of the ACM
31.5.
Higham, N. J. (2002). Accuracy and Stability of Numerical Algorithms. Second edi. SIAM.
Ishiyama, T., K. Nitadori et J. Makino (2012). « 4.45 Pflops astrophysical N-body simulation
on K computer - The gravitational trillion-body problem ». International Conference
for High Performance Computing, Networking, Storage and Analysis, SC.
Jansson, N., J. Hoffman et M. Nazarov (2011). « Adaptive simulation of turbulent flow past
a full car model ». State of the Practice Reports on - SC ’11 0.
Khronos (2014). The OpenCL Specification, version 2.0.
Klöckner, A., N. Pinto, Y. Lee, B. Catanzaro, P. Ivanov et A. Fasih (2012). « PyCUDA and
PyOpenCL: A Scripting-Based Approach to GPU Run-Time Code Generation ». Parallel
Computing 38.3.
Kong, X., M. C. Huang, C. Ren et V. K. Decyk (2011). « Particle-in-cell simulations with
charge-conserving current deposition on graphic processing units ». Journal of Computational
Physics 230.4.
Koumoutsakos, P. (1997). « Inviscid Axisymmetrization of an Elliptical Vortex ». Journal
of Computational Physics 138.2.
Koumoutsakos, P. et A. Leonard (1995). « High-resolution simulations of the flow around
an impulsively started cylinder using vortex methods ». Journal of Fluid Mechanics 296.
Kuczaj, A., E. Komen et M. Loginov (2010). « Large-Eddy Simulation study of turbulent
mixing in a T-junction ». Nuclear Engineering and Design 240.9.
Labbé, S., J. Laminie et V. Louvet (2004). Méthodologie et environment de développement
orientés objets : de l’analyse mathématique à la programmation.
Lagaert, J.-B., G. Balarac, G.-H. Cottet et P. Bégou (2012). « Particle method: an efficient
tool for direct numerical simulations of a high Schmidt number passive scalar in turbulent
flow ». Center for Turbulence Research Proceedings of the Summer Program 2012. 1959.
Lagaert, J.-B., G. Balarac et G.-H. Cottet (2014). « Hybrid spectral-particle method for
the turbulent transport of a passive scalar ». Journal of Computational Physics 260.0.
Leonard, A. (1980). « Vortex methods for flow simulation ». Journal of Computational
Physics 37.3.
Lesieur, M. (2008). Turbulence in fluids.
Lesieur, M., O. Métais et P. Comte (2005). Large-Eddy Simulations of Turbulence.
Liu, M. B. et G. R. Liu (2010). « Smoothed Particle Hydrodynamics (SPH): an Overview
and Recent Developments ». Archives of Computational Methods in Engineering 17.1.
Logg, A., K.-A. Mardal et G. Wells (2012). Automated Solution of Differential Equations
by the Finite Element Method.
141Bibliographie
Magni, A. et G.-H. Cottet (2012). « Accurate, non-oscillatory, remeshing schemes for particle
methods ». Journal of Computational Physics 231.1.
Mernik, M., J. Heering et A. M. Sloane (2005). « When and how to develop domain-specific
languages ». ACM Computing Surveys 37.4.
Michioka, T. et F. K. Chow (2008). « High-Resolution Large-Eddy Simulations of Scalar
Transport in Atmospheric Boundary Layer Flow over Complex Terrain ». Journal of
Applied Meteorology and Climatology 47.12.
Monaghan, J. (1985). « Extrapolating B splines for interpolation ». Journal of Computational
Physics 60.2.
Moore, G. E. (1998). « Cramming More Components onto Integrated Circuits ». Proceedings
of the IEEE. Tome 86. 1.
Moore, G. E. (2005). Excerpts from A Conversation with Gordon Moore : Moore’s Law.
Murtis, J., J. S. Elkinton et R. T. Cardé (1992). « Odor plumes and how insects use them ».
Annual review of entomology 37.1.
Nvidia (2012a). Kepler GK110. Rapport technique.
Nvidia (2012b). Tesla K20 GPU accelerator, board specification. Rapport technique.
Nvidia (2014). Cuda C programming guide.
OpenACC (2013). The OpenACC Application Programming Interface.
Ould Salihi, M. L. (1998). « Couplage de méthodes numériques en simulation directe d’écoulements
incompressibles ». Thèse de doctorat. Université Joseph Fourier.
Ould Salihi, M. L., G.-H. Cottet et M. El Hamraoui (2000). « Blending finite-difference
and vortex methods for incompressible flow computations ». SIAM Journal on Scientific
Computing 22.5.
Pérez, F., B. E. Granger et J. D. Hunter (2011). « Python: An Ecosystem for Scientific
Computing ». Computing in Science & Engineering 13.2.
Pitsch, H., O. Desjardins, G. Balarac et M. Ihme (2008). « Large-eddy simulation of turbulent
reacting flows ». Progress in Aerospace Sciences 44.6.
Rashed, G. et R. Ahsan (2012). « Python in computational science: applications and possibilities
». International Journal of Computer Applications 46.20.
Rees, W. M. van, A. Leonard, D. I. Pullin et P. Koumoutsakos (2011). « A comparison of
vortex and pseudo-spectral methods for the simulation of periodic vortical flows at high
Reynolds numbers ». Journal of Computational Physics 230.8.
Rodgers, D. P. (1985). « Improvements in Multiprocessor System Design ». SIGARCH Computer
Architecture News 13.3.
Rossi, F., P. Londrillo, A. Sgattoni, S. Sinigardi et G. Turchetti (2012). « Towards robust
algorithms for current deposition and dynamic load-balancing in a GPU particle in cell
code ». AIP Conference Proceedings. Tome 184.
Rossinelli, D. et P. Koumoutsakos (2008). « Vortex methods for incompressible flow simulations
on the GPU ». The Visual Computer 24.7-9.
Rossinelli, D., M. Bergdorf, G.-H. Cottet et P. Koumoutsakos (2010). « GPU accelerated
simulations of bluff body flows using vortex particle methods ». Journal of Computational
Physics 229.9.
Rossinelli, D., C. Conti et P. Koumoutsakos (2011). « Mesh-particle interpolations on graphics
processing units and multicore central processing units. » Philosophical transactions.
Series A, Mathematical, physical, and engineering sciences 369.1944.
Rossinelli, D., B. Hejazialhosseini, P. Hadjidoukas, C. Bekas, A. Curioni, A. Bertsch, S.
Futral, S. J. Schmidt, N. A. Adams, P. Koumoutsakos et L. Livermore (2013). « 11
142Bibliographie
PFLOP/s Simulations of Cloud Cavitation Collapse ». Proceedings of the International
Conference on High Performance Computing, Networking, Storage and Analysis (SC ’13).
Ruetsch, G. et P. Micikevicius (2009). Optimizing Matrix Transpose in CUDA. Rapport
technique January. NVIDIA.
Sagaut, P. (2006). Large Eddy Simulation for Incompressible Flows - An introduction.
Sbalzarini, I. F., J. H. Walther, M. Bergdorf, S. E. Hieber, E. M. Kotsalis et P. Koumoutsakos
(2006). « PPM – A highly efficient parallel particle–mesh library for the simulation of
continuum systems ». Journal of Computational Physics 215.2.
Schoenberg, I. J. (1946). « Contributions to the problem of approximation of equidistant
data by analytic functions ». Quarterly of Applied Mathematics 4.2.
Sethian, J. a. et P. Smereka (2003). « Level set methods for fluid interfaces ». Annual Review
of Fluid Mechanics 35.1.
Shalf, J., S. Dosanjh et J. Morrison (2010). « Exascale Computing Technology Challenges ».
High Performance Computing for Computational Science–VECPAR 2010.
Shraiman, B. I. et E. D. Siggia (2000). « Scalar turbulence ». Nature 405.6787.
Staniforth, A. et J. Côté (1991). « Semi-Lagrangian Integration Schemes for Atmospheric
Models - A Review ». Monthly weather review 119.9.
Stantchev, G., W. Dorland et N. Gumerov (2008). « Fast parallel Particle-To-Grid interpolation
for plasma PIC simulations on the GPU ». Journal of Parallel and Distributed
Computing 68.10.
Subramaniam, B., W. Saunders, T. Scogland et W.-c. Feng (2013). « Trends in energyefficient
computing: A perspective from the Green500 ». 4th International Green Computing
Conference.
Taylor, J. R. et R. Stocker (2012). « Trade-offs of chemotactic foraging in turbulent water. »
Science 338.6107.
Temam, R. (1968). « Une méthode d’approximation de la solution des équations de NavierStokes
». Bulletin de la Société Mathématique de France 96.
Top500 (2014). http://www.top500.org/.
Tryggvason, G., R. Scardovelli et S. Zaleski (2011). Direct Numerical Simulations of Gas–Liquid
Multiphase Flows. Cambridge : Cambridge University Press.
Volkov, V. (2010). « Better performance at lower occupancy ». Proceedings of the GPU
Technology Conference,
Wang, H., S. Potluri, M. Luo, A. K. Singh, S. Sur et D. K. Panda (2011). « MVAPICH2-
GPU: optimized GPU to GPU communication for InfiniBand clusters ». Computer Science
- Research and Development 26.3-4.
Weynans, L. et A. Magni (2013). « Consistency, accuracy and entropic behaviour of remeshed
particle methods ». ESAIM: Mathematical Modelling and Numerical Analysis 47.1.
Williams, S., A. Waterman et D. Patterson (2009). « Author : Roofline : An Insightful
Visual Performance Model for Floating-Point Programs and Multicore Architectures ».
Communications of the ACM 52.4.
Yokota, R., L. A. Barba, T. Narumi et K. Yasuoka (2013). « Petascale turbulence simulation
using a highly parallel fast multipole method on GPUs ». Computer Physics Communications
184.3.
143A. Formules de remaillage
de type Λp,r
Cette annexe décrit l’ensemble des formules de remaillage de type Λp,r construites par
la méthode décrite dans la section 2.2. Les caractéristiques des formules sont résumées dans
le tableau A.1. Les formules sont regroupées en fonction de la largeur de leur support et
pour chaque noyau, nous donnons leur expression. Les poids de remaillage sont également
donnés et exprimés en fonction de la distance y de la particule au point de grille le plus
proche à gauche.
A.1. Formules de type Λ2,r
y
w0 w1 w2 w3
Figure A.1. – Poids de remaillage pour les formules de type Λ2,r
Formule Λ2,1
Λ2,1(x) = M0
4
(x) =
1 −
5
2
|x|
2 +
3
2
|x|
3 0 6 |x| < 1
2 − 4|x| +
5
2
|x|
2 −
1
2
|x|
3 1 6 |x| < 2
0 2 6 |x|
(A.1)
w[0] = (y * (y * (-y + 2.) - 1.)) / 2.
w[1] = (y * y * (3. * y - 5.) + 2.) / 2.
w[2] = (y * (y * (-3. * y + 4.) + 1.)) / 2.
w[3] = (y * y * (y - 1.)) / 2.
145A. Formules de remaillage de type Λp,r
Nom Moment maximal conservé Régularité Support Degré
Λ2,1 2 C
1
[−2; 2] 3
Λ2,2 2 C
2
[−2; 2] 5
Λ2,3 2 C
3
[−2; 2] 7
Λ2,4 2 C
4
[−2; 2] 9
Λ4,2 4 C
2
[−3; 3] 5
Λ4,3 4 C
3
[−3; 3] 7
Λ4,4 4 C
4
[−3; 3] 9
Λ6,3 6 C
3
[−4; 4] 7
Λ6,4 6 C
4
[−4; 4] 9
Λ6,5 6 C
5
[−4; 4] 11
Λ6,6 6 C
6
[−4; 4] 13
Λ8,4 8 C
4
[−5; 5] 9
Tableau A.1. – Comparatif des formules de remaillage de type Λp,r.
Formule Λ2,2
Λ2,2(x) =
1 − |x|
2 −
9
2
|x|
3 +
15
2
|x|
4 − 3|x|
5 0 6 |x| < 1
−4 + 18|x| − 29|x|
2 +
43
2
|x|
3 −
15
2
|x|
4 + |x|
5 1 6 |x| < 2
0 2 6 |x|
(A.2)
w[0] = (y * (y * (y * (y * (2. * y - 5.) + 3.) + 1.) - 1.)) / 2.
w[1] = (y * y * (y * (y * (-6. * y + 15.) - 9.) - 2.) + 2.) / 2.
w[2] = (y * (y * (y * (y * (6. * y - 15.) + 9.) + 1.) + 1.)) / 2.
w[3] = (y * y * y * (y * (-2. * y + 5.) - 3.)) / 2.
146A.2. Formules de type
Λ
4,r
Formule Λ2,3
Λ2,3(x) =
1 − |x|2 − 15|x|4 + 752 |x|5 − 632 |x|6 + 9|x|7 0 6 |x| < 1 32 − 168|x| + 376|x|2 − 460|x|3 + 330|x|4 − 2772 |x|5 + 632 |x|6 − 3|x|7 1 6 |x| < 2 0 2 6 |x| (A.3)
w[0] = (y * (y * (y * y * (y * (y * (-6. * y + 21.) - 25.) + 10.) + 1.) - 1.)) / 2.
w[1] = (y * y * (y * y * (y * (y * (18. * y - 63.) + 75.) - 30.) - 2.) + 2.) / 2.
w[2] = (y * (y * (y * y * (y * (y * (-18. * y + 63.) - 75.) + 30.) + 1.) + 1.)) / 2.
w[3] = (y * y * y * y * (y * (y * (6. * y - 21.) + 25.) - 10.)) / 2.
Formule Λ2,4
Λ2,4(x) =
1 − |x|2 − 1052 |x|5 + 3572 |x|6 − 231|x|7 + 135|x|8 − 30|x|9 0 6 |x| < 1 −208 + 1432|x| − 4304|x|2 + 7420|x|3 − 8085|x|4 +11543 2 |x|5 − 5397 2 |x|6 + 797|x|7 − 135|x|8 + 10|x|9 1 6 |x| < 2 0 2 6 |x| (A.4)
w[0] = (y * (y * (y * y * y * (y * (y * (y * (20. * y - 90.) + 154.) - 119.) + 35.) + 1.) - 1.)) / 2.
w[1] = (y * y * (y * y * y * (y * (y * (y * (-60. * y + 270.) - 462.) + 357.) - 105.) - 2.) + 2.) / 2.
w[2] = (y * (y * (y * y * y * (y * (y * (y * (60. * y - 270.) + 462.) - 357.) + 105.) + 1.) + 1.)) / 2.
w[3] = (y * y * y * y * y * (y * (y * (y * (-20. * y + 90.) - 154.) + 119.) - 35.)) / 2.
147A. Formules de remaillage de type
Λp,r
y
w
0
w
1
w
2
w
3
w
4
w
5
Figure A.2. – Poids de remaillage pour les formules de type Λ4,r
A.2. Formules de type Λ4,r
Formule Λ4,2
Λ4,2(x) = M06(x) =
1 − 54 |x|2 − 3512 |x|3 + 214 |x|4 − 2512 |x|5 0 6 |x| < 1 −4 + 754 |x| − 2458 |x|2 + 545 24 |x|3 − 638 |x|4 + 2524 |x|5 1 6 |x| < 2 18 − 1534 |x| + 2558 |x|2 − 313 24 |x|3 + 218 |x|4 − 524 |x|5 2 6 |x| < 3 0 3 6 |x| (A.5)
w[0] = (y * (y * (y * (y * (-5. * y + 13.) - 9.) - 1.) + 2.)) / 24.
w[1] = (y * (y * (y * (y * (25. * y - 64.) + 39.) + 16.) - 16.)) / 24.
w[2] = (y * y * (y * (y * (-50. * y + 126.) - 70.) - 30.) + 24.) / 24.
w[3] = (y * (y * (y * (y * (50. * y - 124.) + 66.) + 16.) + 16.)) / 24.
w[4] = (y * (y * (y * (y * (-25. * y + 61.) - 33.) - 1.) - 2.)) / 24.
w[5] = (y * y * y * (y * (5. * y - 12.) + 7.)) / 24.
148A.2. Formules de type
Λ
4,r
Formule Λ4,3
Λ4,3(x) =
1 − 54 |x|2 − 283 |x|4 + 1456 |x|5 − 245 12 |x|6 + 356 |x|7 0 6 |x| < 1 31 − 1945 12 |x| + 2905 8 |x|2 − 5345 12 |x|3 + 1281 4 |x|4 − 1615 12 |x|5 + 2458 |x|6 − 3512 |x|7 1 6 |x| < 2 −297 + 3501 4 |x| − 8775 8 |x|2 + 3029 4 |x|3 − 3731 12 |x|4 + 911 12 |x|5 − 245 24 |x|6 + 712 |x|7 2 6 |x| < 3 0 3 6 |x| (A.6)
w[0] = (y * (y * (y * (y * (y * (y * (14. * y - 49.) + 58.) - 22.) - 2.) - 1.) + 2.)) / 24.
w[1] = (y * (y * (y * (y * (y * (y * (-70. * y + 245.) - 290.) + 111.) + 4.) + 16.) - 16.)) / 24.
w[2] = (y * y * (y * y * (y * (y * (140. * y - 490.) + 580.) - 224.) - 30.) + 24.) / 24.
w[3] = (y * (y * (y * (y * (y * (y * (-140. * y + 490.) - 580.) + 226.) - 4.) + 16.) + 16.)) / 24.
w[4] = (y * (y * (y * (y * (y * (y * (70. * y - 245.) + 290.) - 114.) + 2.) - 1.) - 2.)) / 24.
w[5] = (y * y * y * y * (y * (y * (-14. * y + 49.) - 58.) + 23.)) / 24.
Formule Λ4,4
Λ4,4(x) =
1 − 54 |x|2 + 14 |x|4 − 1003 |x|5 + 4554 |x|6 − 2952 |x|7 + 3454 |x|8 − 1156 |x|9 0 6 |x| < 1 −199 + 5485 4 |x| − 32975 8 |x|2 + 28425 4 |x|3 − 61953 8 |x|4 + 33175 6 |x|5 −20685 8 |x|6 + 3055 4 |x|7 − 1035 8 |x|8 + 115 12 |x|9 1 6 |x| < 2 5913 − 89235 4 |x| + 297585 8 |x|2 − 143895 4 |x|3 + 177871 8 |x|4 − 54641 6 |x|5 +19775 8 |x|6 − 1715 4 |x|7 + 3458 |x|8 − 2312 |x|9 2 6 |x| < 3 0 3 6 |x| (A.7)
w[0] = (y * (y * (y * (y * (y * (y * (y * (y * (-46. * y + 207.) - 354.) + 273.) - 80.) + 1.) - 2.)
- 1.) + 2.)) / 24.
w[1] = (y * (y * (y * (y * (y * (y * (y * (y * (230. * y - 1035.) + 1770.) - 1365.) + 400.) - 4.) + 4.)
+ 16.) - 16.)) / 24.
w[2] = (y * y * (y * y * (y * (y * (y * (y * (-460. * y + 2070.) - 3540.) + 2730.) - 800.) + 6.) - 30.)
149A. Formules de remaillage de type
Λp,r
+ 24.) / 24.
w[3] = (y * (y * (y * (y * (y * (y * (y * (y * (460. * y - 2070.) + 3540.) - 2730.) + 800.) - 4.) - 4.)
+ 16.) + 16.)) / 24.
w[4] = (y * (y * (y * (y * (y * (y * (y * (y * (-230. * y + 1035.) - 1770.) + 1365.) - 400.) + 1.) + 2.)
- 1.) - 2.)) / 24.
w[5] = (y * y * y * y * y * (y * (y * (y * (46. * y - 207.) + 354.) - 273.) + 80.)) / 24.
A.3. Formules de type Λ6,r
y
w
0
w
1
w
2
w
3
w
4
w
5
w
6
w
7
Figure A.3. – Poids de remaillage pour les formules de type Λ6,r
Formule Λ6,3
Λ6,3(x) =
1 − 4936 |x|2 − 959 144 |x|4 + 2569 144 |x|5 − 727 48 |x|6 + 623 144 |x|7 0 6 |x| < 1 1385 − 8617 60 |x| + 12873 40 |x|2 − 7912 |x|3 + 4557 16 |x|4 − 9583 80 |x|5 + 2181 80 |x|6 − 623 240 |x|7 1 6 |x| < 2 −440 + 25949 20 |x| − 117131 72 |x|2 + 2247 2 |x|3 − 66437 144 |x|4 + 81109 720 |x|5 − 727 48 |x|6 + 623 720 |x|7 2 6 |x| < 3 3632 5 − 7456 5 |x| + 58786 45 |x|2 − 633|x|3 + 26383 144 |x|4 − 22807 720 |x|5 + 727 240 |x|6 − 89 720 |x|7 3 6 |x| < 4 0 4 6 |x| (A.8)
w[0] = (y * (y * (y * (y * (y * (y * (-89. * y + 312.) - 370.) + 140.) + 15.) + 4.) - 12.)) / 720.
w[1] = (y * (y * (y * (y * (y * (y * (623. * y - 2183.) + 2581.) - 955.) - 120.) - 54.) + 108.)) / 720.
w[2] = (y * (y * (y * (y * (y * (y * (-1869. * y + 6546.) - 7722.) + 2850.) + 195.) + 540.) - 540.)) / 720.
w[3] = (y * y * (y * y * (y * (y * (3115. * y - 10905.) + 12845.) - 4795.) - 980.) + 720.) / 720.
150A.3. Formules de type Λ6,r
w[4] = (y * (y * (y * (y * (y * (y * (-3115. * y + 10900.) - 12830.) + 4880.) - 195.) + 540.) + 540.)) / 720.
w[5] = (y * (y * (y * (y * (y * (y * (1869. * y - 6537.) + 7695.) - 2985.) + 120.) - 54.) - 108.)) / 720.
w[6] = (y * (y * (y * (y * (y * (y * (-623. * y + 2178.) - 2566.) + 1010.) - 15.) + 4.) + 12.)) / 720.
w[7] = (y * y * y * y * (y * (y * (89. * y - 311.) + 367.) - 145.)) / 720.
Formule
Λ6,4
Λ6,4(x) =
1 − 4936
|x|
2 +
7
18
|x|
4 − 3521
144
|x|
5 + 12029 144
|x|
6 − 15617
144
|x|
7 + 1015 16
|x|
8 − 1015
72
|x|
9 0
6 |x| < 1
−877
5 + 72583 60
|x| − 145467 40
|x|
2 + 18809
3
|x|
3 − 54663
8
|x|
4 + 390327 80
|x|
5
−182549
80
|x|
6 + 161777 240
|x|
7 − 1827
16
|x|
8 + 203 24
|x|
9 1 6 |x| < 2
8695
− 656131
20
|x| + 3938809 72
|x|
2 − 158725
3
|x|
3 + 2354569 72
|x|
4 − 9644621
720
|x|
5
+523589 144
|x|
6 − 454097
720
|x|
7 + 1015 16
|x|
8 − 203
72
|x|
9 2 6 |x| <
3
−142528
5 + 375344
5
|x| − 3942344 45
|x|
2 + 178394
3
|x|
3 − 931315
36
|x|
4 + 5385983 720
|x|
5
−1035149
720
|x|
6 + 127511 720
|x|
7 − 203
16
|x|
8 + 2972
|x|
9 3
6 |x| <
4
0
4
6 |x|
(A.9)
w[0] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (-1006. * y + 5533.) - 12285.) + 13785.) - 7829.)
+ 1803.) - 3.) - 5.) + 15.) + 4.) - 12.)) / 720.
w[1] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (7042. * y - 38731.) + 85995.) - 96495.) + 54803.)
- 12620.) + 12.) + 60.) - 120.) - 54.) + 108.)) / 720.
w[2] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (-21126. * y + 116193.) - 257985.) + 289485.)
- 164409.) + 37857.) - 15.) - 195.) + 195.) + 540.) - 540.)) / 720.
w[3] = (y * y * (y * y * (y * y * (y * (y * (y * (y * (35210. * y - 193655.) + 429975.) - 482475.) + 274015.)
- 63090.) + 280.) - 980.) + 720.) / 720.
w[4] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (-35210. * y + 193655.) - 429975.) + 482475.)
- 274015.) + 63085.) + 15.) - 195.) - 195.) + 540.) + 540.)) / 720.
w[5] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (21126. * y - 116193.) + 257985.) - 289485.)
+ 164409.) - 37848.) - 12.) + 60.) + 120.) - 54.) - 108.)) / 720.
w[6] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (-7042. * y + 38731.) - 85995.) + 96495.) - 54803.)
151A. Formules de remaillage de type Λp,r
+ 12615.) + 3.) - 5.) - 15.) + 4.) + 12.)) / 720.
w[7] = (y * y * y * y * y * y * (y * (y * (y * (y * (1006. * y - 5533.) + 12285.) - 13785.) + 7829.)
- 1802.)) / 720.
Formule
Λ6,5
Λ6,5(x) =
1 − 4936
|x|
2 +
7
18
|x|
4 − 701
8
|x|
6 + 54803 144
|x|
7 − 32165
48
|x|
8 + 9555 16
|x|
9 − 38731
144
|x|10
+ 3521 72
|x|11
0
6 |x| < 1
1233
− 617533
60
|x| + 1544613 40
|x|
2 − 515179
6
|x|
3 + 502579
4
|x|
4 − 3809911
30
|x|
5
+3618099 40
|x|
6 − 10894163
240
|x|
7 + 251685 16
|x|
8 − 172123
48
|x|
9 + 38731 80
|x|10
− 3521
120
|x|11 1 6 |x| < 2
−181439
+ 16709441 20
|x| − 125352311 72
|x|
2 + 13002493
6
|x|
3 − 64445353
36
|x|
4 + 30912301 30
|x|
5
−3373567
8
|x|
6 + 88345523 720
|x|
7 − 1194095
48
|x|
8 + 160657 48
|x|
9 − 38731
144
|x|10
+ 3521 360
|x|11 2 6 |x| <
3
1188352
− 19108864
5
|x| + 250837216 45
|x|
2 − 14600752
3
|x|
3 + 25437902
9
|x|
4 − 17195278
15
|x|
5
+13253241 40
|x|
6 − 49136309
720
|x|
7 + 471205 48
|x|
8 − 45083
48
|x|
9 + 38731 720
|x|10
− 503
360
|x|11
3
6 |x| <
4
0
4
6 |x|
(A.10)
w[0] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (-1006. * y + 5533.) - 12285.) + 13785.) - 7829.)
+ 1803.) - 3.) - 5.) + 15.) + 4.) - 12.)) / 720.
w[1] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (7042. * y - 38731.) + 85995.) - 96495.) + 54803.)
- 12620.) + 12.) + 60.) - 120.) - 54.) + 108.)) / 720.
w[2] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (-21126. * y + 116193.) - 257985.) + 289485.)
- 164409.) + 37857.) - 15.) - 195.) + 195.) + 540.) - 540.)) / 720.
w[3] = (y * y * (y * y * (y * y * (y * (y * (y * (y * (35210. * y - 193655.) + 429975.) - 482475.) + 274015.)
- 63090.) + 280.) - 980.) + 720.) / 720.
w[4] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (-35210. * y + 193655.) - 429975.) + 482475.)
- 274015.) + 63085.) + 15.) - 195.) - 195.) + 540.) + 540.)) / 720.
w[5] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (21126. * y - 116193.) + 257985.) - 289485.)
+ 164409.) - 37848.) - 12.) + 60.) + 120.) - 54.) - 108.)) / 720.
w[6] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (-7042. * y + 38731.) - 85995.) + 96495.) - 54803.)
152A.3. Formules de type Λ6,r
+ 12615.) + 3.) - 5.) - 15.) + 4.) + 12.)) / 720.
w[7] = (y * y * y * y * y * y * (y * (y * (y * (y * (1006. * y - 5533.) + 12285.) - 13785.) + 7829.)
- 1802.)) / 720.
Formule
Λ6,6
Λ6,6(x) =
1 − 4936
|x|
2 +
7
18
|x|
4 −
1
36
|x|
6 − 46109
144
|x|
7 + 81361 48
|x|
8 − 544705
144
|x|
9 + 655039 144
|x|10
−223531
72
|x|11
+ 81991 72
|x|12
− 6307
36
|x|13
0
6 |x| < 1
−44291
5 + 1745121 20
|x| − 15711339 40
|x|
2 + 32087377 30
|x|
3 − 7860503
4
|x|
4 + 38576524 15
|x|
5
−24659323
10
|x|
6 + 84181657 48
|x|
7 − 74009313
80
|x|
8 + 17159513 48
|x|
9 − 7870247
80
|x|10
+438263 24
|x|11
− 81991
40
|x|12
+ 6307 60
|x|13 1 6 |x| < 2
3905497
− 424679647
20
|x| + 3822627865 72
|x|
2 − 2424839767
30
|x|
3 + 3009271097 36
|x|
4 − 930168127
15
|x|
5
+305535494
9
|x|
6 − 9998313437
720
|x|
7 + 203720335 48
|x|
8 − 137843153
144
|x|
9 + 22300663 144
|x|10
−6126883
360
|x|11
+ 81991 72
|x|12
− 6307
180
|x|13 2 6 |x| <
3
−255622144
5 + 971097344
5
|x| − 15295867328 45
|x|
2 + 5442932656 15
|x|
3 − 2372571796
9
|x|
4 + 2064517469 15
|x|
5
−9563054381
180
|x|
6 + 2210666335 144
|x|
7 − 796980541
240
|x|
8 + 76474979 144
|x|
9 − 43946287
720
|x|10
+343721 72
|x|11
− 81991
360
|x|12
+ 901 180
|x|13
3
6 |x| <
4
0
4
6 |x|
(A.11)
w[0] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (3604. * y - 23426.) + 63866.)
- 93577.) + 77815.) - 34869.) + 6587.) + 1.) - 3.) - 5.) + 15.) + 4.) - 12.)) / 720.
w[1] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (-25228. * y + 163982.) - 447062.)
+ 655039.) - 544705.) + 244083.) - 46109.) - 6.) + 12.) + 60.) - 120.) - 54.) + 108.)) / 720.
w[2] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (75684. * y - 491946.) + 1341186.)
- 1965117.) + 1634115.) - 732249.) + 138327.) + 15.) - 15.) - 195.) + 195.) + 540.) - 540.)) / 720.
w[3] = (y * y * (y * y * (y * y * (y * (y * (y * (y * (y * (y * (-126140. * y + 819910.) - 2235310.)
+ 3275195.) - 2723525.) + 1220415.) - 230545.) - 20.) + 280.) - 980.) + 720.) / 720.
153A. Formules de remaillage de type
Λp,r
w[4] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (126140. * y - 819910.) + 2235310.)
- 3275195.) + 2723525.) - 1220415.) + 230545.) + 15.) + 15.) - 195.) - 195.) + 540.) + 540.)) / 720.
w[5] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (-75684. * y + 491946.) - 1341186.)
+ 1965117.) - 1634115.) + 732249.) - 138327.) - 6.) - 12.) + 60.) + 120.) - 54.) - 108.)) / 720.
w[6] = (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (y * (25228. * y - 163982.) + 447062.)
- 655039.) + 544705.) - 244083.) + 46109.) + 1.) + 3.) - 5.) - 15.) + 4.) + 12.)) / 720.
w[7] = (y * y * y * y * y * y * y * (y * (y * (y * (y * (y * (-3604. * y + 23426.) - 63866.) + 93577.)
- 77815.) + 34869.) - 6587.)) / 720.
A.4. Formules de type Λ8,r
y
w
0
w
1
w
2
w
3
w
4
w
5
w
6
w
7
w
8
w
9
Figure A.4. – Poids de remaillage pour les formules de type Λ8,r
154A.4. Formules de type Λ8,r
Formule
Λ8,4
Λ8,4(x) =
1 − 205 144
|x|
2 + 91 192
|x|
4 − 6181
320
|x|
5 + 6337 96
|x|
6 − 2745
32
|x|
7 + 28909 576
|x|
8 − 3569
320
|x|
9
0
6 |x| < 1
−154
+ 12757 12
|x| − 230123 72
|x|
2 + 264481 48
|x|
3 − 576499
96
|x|
4 + 686147 160
|x|
5
−96277
48
|x|
6 + 14221 24
|x|
7 − 28909
288
|x|
8 + 3569 480
|x|
9
1 6 |x| < 2
68776
7 − 1038011 28
|x| + 31157515 504
|x|
2 − 956669
16
|x|
3 + 3548009 96
|x|
4 − 2422263
160
|x|
5
+197255 48
|x|
6 − 19959
28
|x|
7 + 144545 2016
|x|
8 − 3569
1120
|x|
9
2 6 |x| <
3
−56375
+ 8314091 56
|x| − 49901303 288
|x|
2 + 3763529 32
|x|
3 − 19648027
384
|x|
4 + 9469163 640
|x|
5
−545977
192
|x|
6 + 156927 448
|x|
7 − 28909
1152
|x|
8 + 3569 4480
|x|
9
3
6 |x| <
4
439375
7 − 64188125 504
|x| + 231125375 2016
|x|
2 − 17306975
288
|x|
3 + 7761805 384
|x|
4 − 2895587
640
|x|
5
+129391 192
|x|
6 − 259715
4032
|x|
7 + 28909 8064
|x|
8 − 3569
40320
|x|
9
4
6 |x| < 5
0 5 6 |x|
(A.12)
w0 = (y * (y * (y * (y * (y * (y * (y * (y * (-3569. * y + 16061.) - 27454.) + 21126.) - 6125.)
+ 49.) - 196.) - 36.) + 144.)) / 40320.
w1 = (y * (y * (y * (y * (y * (y * (y * (y * (32121. * y - 144548.) + 247074.) - 190092.)
+ 55125.) - 672.) + 2016.) + 512.) - 1536.)) / 40320.
w2 = (y * (y * (y * (y * (y * (y * (y * (y * (-128484. * y + 578188.) - 988256.) + 760312.)
- 221060.) + 4732.) - 9464.) - 4032.) + 8064.)) / 40320.
w3 = (y * (y * (y * (y * (y * (y * (y * (y * (299796. * y - 1349096.) + 2305856.) - 1774136.)
+ 517580.) - 13664.) + 13664.) + 32256.) - 32256.)) / 40320.
w4 = (y * y * (y * y * (y * (y * (y * (y * (-449694. * y + 2023630.) - 3458700.) + 2661540.)
- 778806.) + 19110.) - 57400.) + 40320.) / 40320.
w5 = (y * (y * (y * (y * (y * (y * (y * (y * (449694. * y - 2023616.) + 3458644.) - 2662016.)
+ 780430.) - 13664.) - 13664.) + 32256.) + 32256.)) / 40320.
w6 = (y * (y * (y * (y * (y * (y * (y * (y * (-299796. * y + 1349068.) - 2305744.) + 1775032.)
- 520660.) + 4732.) + 9464.) - 4032.) - 8064.)) / 40320.
w7 = (y * (y * (y * (y * (y * (y * (y * (y * (128484. * y - 578168.) + 988176.) - 760872.)
+ 223020.) - 672.) - 2016.) + 512.) + 1536.)) / 40320.
155A. Formules de remaillage de type Λp,r w8 = (y * (y * (y * (y * (y * (y * (y * (y * (-32121. * y + 144541.) - 247046.) + 190246.) - 55685.) + 49.) + 196.) - 36.) - 144.)) / 40320. w9 = (y * y * y * y * y * (y * (y * (y * (3569. * y - 16060.) + 27450.) - 21140.) + 6181.)) / 40320.
156B. Publications
157ESAIM: M2AN 48 (2014) 1029–1060 ESAIM: Mathematical Modelling and Numerical Analysis
DOI: 10.1051/m2an/2014009 www.esaim-m2an.org
HIGH ORDER SEMI-LAGRANGIAN PARTICLE METHODS
FOR TRANSPORT EQUATIONS:
NUMERICAL ANALYSIS AND IMPLEMENTATION ISSUES
G.-H. Cottet1, J.-M. Etancelin1, F. Perignon1 and C. Picard1
Abstract. This paper is devoted to the definition, analysis and implementation of semi-Lagrangian
methods as they result from particle methods combined with remeshing. We give a complete consistency
analysis of these methods, based on the regularity and momentum properties of the remeshing
kernels, and a stability analysis of a large class of second and fourth order methods. This analysis
is supplemented by numerical illustrations. We also describe a general approach to implement these
methods in the context of hybrid computing and investigate their performance on GPU processors as
a function of their order of accuracy.
Mathematics Subject Classification. 65M12, 65M75, 65Y05, 65Y20.
Received October 22, 2013. Revised January 28, 2014.
Published online June 30, 2014.
1. Introduction
Particle methods are Lagrangian methods that have been designed for advection dominated problems, with
applications mostly in plasma physics [10], incompressible flows [4,7,16], or gas dynamics [20]. Following [12, 13],
particle methods are often associated with remeshing, in order to maintain the regularity of the particle distribution
and, as a consequence, to control the accuracy of the method in presence of strong strain in the flow
carrying the particles. Remeshing removes the grid free nature of particle methods but maintains some of its
features like conservation, locality, and stability. It not only guarantees accuracy but also allows to combine in
a seamless fashion particle methods with grid-based techniques, like domain decomposition methods and fast
FFT-based Poisson solvers for field evaluations [5, 22], multi-resolution and adaptive mesh refinement [1, 2].
In practice particle remeshing occurs every few time steps. In that case, and as long as the remeshing frequency
does not increase when the discretization parameters tend to zero, Remeshed Particle Methods (RPM in the
sequel) can be viewed as conservative forward semi-lagrangian methods. Classical semi-lagrangian methods for
transport equations combine tracking of trajectories originating at grid points and interpolation from the grid.
Because they operate on local point values, semi-lagrangian methods in general do not conserve mass, unless
some specific treatment is done. By contrast, particle methods transport masses which makes them inherently
conservative.
Keywords and phrases. Advection equations, particle methods, semi-Lagrangian methods, GPU computing.
1 Universit´e Grenoble Alpes and CNRS, Laboratoire Jean Kuntzmann, BP 53 38041, Grenoble Cedex 9, France.
georges-henri.cottet@imag.fr
Article published by EDP Sciences c EDP Sciences, SMAI 2014
Proposition d’une architecture de surveillance ”active” `a
base d’agents intelligents pour l’aide `a la maintenance de
syst`emes mobiles - Application au domaine ferroviaire
Antoine Le Mortellec
To cite this version:
Antoine Le Mortellec. Proposition d’une architecture de surveillance ”active” `a base d’agents
intelligents pour l’aide `a la maintenance de syst`emes mobiles - Application au domaine ferroviaire.
Automatic Control Engineering. Universit´e de Valenciennes et du Hainaut-Cambresis,
2014. French. .
HAL Id: tel-00947981
https://tel.archives-ouvertes.fr/tel-00947981v2
Submitted on 4 Apr 2014
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of scientific
research documents, whether they are published
or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est
destin´ee au d´epˆot et `a la diffusion de documents
scientifiques de niveau recherche, publi´es ou non,
´emanant des ´etablissements d’enseignement et de
recherche fran¸cais ou ´etrangers, des laboratoires
publics ou priv´es.Thèse de doctorat
Pour obtenir le grade de Docteur de l’Université de
VALENCIENNES ET DU HAINAUT-CAMBRESIS
Spécialité Automatique et Génie Informatique
Présentée et soutenue par Antoine LE MORTELLEC
Le 30/01/2014 à Valenciennes
Ecole doctorale :
Sciences Pour l’Ingénieur (SPI)
Equipe de recherche, Laboratoire :
Laboratoire : Thermique Ecoulement Mécanique Matériaux Mise en Forme Production (TEMPO)
Equipe : Production, Services, Information (PSI)
Proposition d’une architecture de surveillance “active” à base d’agents
intelligents pour l’aide à la maintenance de systèmes mobiles
Application au domaine ferroviaire
JURY
Président du jury
Pierre Castagna. Professeur à l’Université de Nantes.
Rapporteurs
Zineb Simeu-Abazi. Maître de conférences HDR à l’Université Joseph Fourier de Grenoble.
Benoît Iung. Professeur à l’Université de Lorraine.
Samir Lamouri. Professeur à l’Ecole Nationale Supérieure d’Arts et Métiers Paris Tech.
Examinateur
Audine Subias. Maître de conférences HDR à l’Université de Toulouse.
Directeur de thèse
Damien Trentesaux. Professeur à l’Université de Valenciennes et du Hainaut Cambrésis.
Co-encadrants de thèse
Yves Sallez. Maître de conférences HDR à l’Université de Valenciennes et du Hainaut Cambrésis.
Thierry Berger. Maître de conférences à l’Université de Valenciennes et du Hainaut Cambrésis.
Membre invité
Frédéric Grzesiak. Directeur technique de la société PROSYST de Valenciennes.
N° Ordre : 14/06 Page 2
Page 3
Avant-propos
Cette thèse s’inscrit dans le cadre du projet SURFER (SURveillance active FERroviaire)
conduit par Bombardier-Transport, en collaboration avec la société PROSYST, le groupe
HIOLLE INDUSTRIES, l'Université de Valenciennes et du Hainaut-Cambrésis (UVHC) et
l'Institut Français des Sciences et Technologies des Transports, de l'Aménagement et des
Réseaux (IFSTTAR). Elle a été financée dans le cadre d’un contrat de collaboration de
Recherche entre le laboratoire TEMPO EA4542 et la société PROSYST. Le temps de travail a
été partagé entre ces deux entités.
Le projet SURFER est supporté financièrement par le Fonds Unique Interministériel (FUI) et
la région Nord Pas-de-Calais, et sponsorisé par les Pôles de compétitivité i-Trans et
Advancity.
Les accords de consortium établis entre les différents partenaires du projet SURFER ont
restreint la divulgation de certains développements scientifiques et technologiques réalisés
pendant mes travaux de Recherche. Ces éléments ne sont donc pas publiés dans ce manuscrit. Page 4
Remerciements
Les travaux présentés dans ce manuscrit ont été réalisés au sein de l’équipe PSI du laboratoire
TEMPO de l’Université de Valenciennes et du Hainaut Cambrésis en collaboration avec la
société PROSYST.
Je tiens à remercier en premier lieu le professeur Damien Trentesaux, responsable de l’équipe
PSI, qui a dirigé cette thèse pour la qualité de son encadrement, ses conseils pertinents et son
aide tout au long de ces trois années de doctorat. Je remercie mes co-encadrants de thèse,
M. Yves Sallez, Maître de Conférences HDR, et M. Thierry Berger, Maître de Conférences,
pour leur disponibilité, leurs critiques constructives et leurs encouragements, ainsi que pour le
temps qu’ils ont consacré à relire et à corriger ce manuscrit.
J’exprime toute ma gratitude à Mme Zineb Simeu-Abazi, Maître de Conférences HDR au
laboratoire G-SCOP de Grenoble, à M. Benoît Iung, professeur au CRAN de Nancy et à
M. Samir Lamouri, professeur à l’École Nationale Supérieure d’Arts et Métiers Paris Tech,
qui m’ont fait l’honneur de rapporter cette thèse. J’ai été particulièrement sensible à leur
lecture attentive de ce manuscrit, aux nombreuses discussions et perspectives scientifiques
qu’ils ont apportées à mes travaux. Je remercie vivement Mme Audine Subias, Maître de
Conférences HDR au LAAS de Toulouse pour avoir accepté d’examiner cette thèse et
M. Pierre Castagna, professeur à l’IRCCyN de Nantes, pour avoir accepté de présider ce jury.
Mes remerciements s’adressent également à l’ensemble du personnel de la société PROSYST
et à son dirigeant, M. Abdallah Asse, pour leur accueil et leur sympathie. Je remercie
chaleureusement M. Frédéric Grzesiak, directeur technique et M. Khaled El Sanwar,
ingénieur de Recherche et Développement, pour leur aide, la vision qu’ils m’ont transmise sur
les différents aspects du sujet de thèse et la confiance qu’ils m’ont accordée.
Je tiens à remercier M. Guillaume Branger, ingénieur de Recherche et Développement au sein
de Bombardier-Transport France et pilote du projet SURFER, pour son soutien, l’expérience
qu’il m’a apportée et l’intérêt qu’il a porté à l’égard de mes travaux.
Je remercie évidemment les membres de l’équipe TEMPO-PSI ainsi que tous les “surfeurs”
qui ont contribué à la concrétisation de cette thèse. Je pense en particulier à Joffrey Clarhaut,
Rebiha Bekrar, Jean Gandibleux, Quentin Coutadeur et Vivien Basselot.
Je remercie ma famille pour m’avoir soutenu pendant toutes ces années d’études. Merci à mes
sœurs, Cécile et Aurore, sans qui cette thèse n’existerait probablement pas.
Je n’oublie pas mes amis, notamment mes amis Rennais, qui m’ont toujours encouragé et
motivé pendant ces années passées dans le “ch’Nord”. Merci à vous. REMERCIEMENTS
Page 5
À ma maman..., Page 6
Table des matières
Introduction générale ............................................................................................................................................. 9
Ch. I Problématique de la surveillance pour l’aide à la maintenance ............................................................... 12
Introduction ...................................................................................................................................................... 12
1. Contexte général ........................................................................................................................................... 13
1.1 Approche systémique adoptée ................................................................................................................ 13
1.2 Propriétés des systèmes cibles considérés .............................................................................................. 14
1.3 Terminologie relative à la maintenance .................................................................................................. 16
1.4 Activités de la maintenance .................................................................................................................... 17
2. Fonctions d’un système de surveillance ....................................................................................................... 20
2.1 Détection ................................................................................................................................................ 22
2.2 Diagnostic ............................................................................................................................................... 22
2.3 Pronostic ................................................................................................................................................. 23
2.4 Elaboration de conseils ........................................................................................................................... 23
3. Modèle d’architecture de surveillance .......................................................................................................... 24
3.1 Standards d’architectures de surveillance ............................................................................................... 24
3.2 Problématiques de la surveillance des systèmes cibles considérés ......................................................... 30
4. Conclusion .................................................................................................................................................... 34
Ch. II Surveillance de systèmes mobiles : état de l’art et approches de surveillance active .............................. 35
Introduction ...................................................................................................................................................... 35
1. Etat de l’art des architectures de diagnostic .................................................................................................. 35
1.1 Diagnostic distant ................................................................................................................................... 36
1.2 Diagnostic embarqué .............................................................................................................................. 38
1.3 Typologie des architectures de diagnostic .............................................................................................. 43
2. Approches de surveillance active.................................................................................................................. 45
2.1 Concept de surveillance active ............................................................................................................... 46
2.2 Approche multi-agents ........................................................................................................................... 47
2.3 Approche holonique ............................................................................................................................... 49
2.4 Comparaison des approches ................................................................................................................... 52
3. Conclusion .................................................................................................................................................... 53
Ch. III Proposition d’une architecture holonique pour la surveillance active de systèmes cibles mobiles ...... 54
Introduction ...................................................................................................................................................... 54
1. Système de surveillance holonique ............................................................................................................... 54
1.1 Approche de modélisation du système cible à surveiller ........................................................................ 55
1.2 Spécification d’une architecture holonique de surveillance ................................................................... 58
1.3 Architecture de surveillance proposée .................................................................................................... 61
2. Structure interne d’un holon de surveillance ................................................................................................ 66
2.1 Données exploitées par la fonction de surveillance d’un holon ............................................................. 66
2.2 Hypothèses pour l’élaboration d’un diagnostic ...................................................................................... 67
2.3 Modules internes d’une fonction de surveillance ................................................................................... 67
2.4 Niveaux de diagnostic d’une fonction de surveillance ........................................................................... 69
3. Conclusion .................................................................................................................................................... 71
Ch. IV Mise en œuvre de l’architecture holonique de surveillance active ......................................................... 72
Introduction ...................................................................................................................................................... 72
1. Diagnostic PSC individuel non-contextualisé ............................................................................................... 73
1.1 Nature des systèmes diagnostiqués ......................................................................................................... 73
1.2 Méthode de diagnostic mise en œuvre ................................................................................................... 73
1.3 Limitations de la méthode de diagnostic mise en œuvre ........................................................................ 74
2. Contextualisation du diagnostic .................................................................................................................... 75
2.1 Contextualisation individuelle ................................................................................................................ 76
2.2 Contextualisation collective ................................................................................................................... 78
3. Description comportementale des holons de surveillance ............................................................................ 80
3.1 Comportements des holons élémentaires................................................................................................ 82TABLE DES MATIÈRES
Page 7
3.2 Comportements des holons composés .................................................................................................... 84
4. Mise en œuvre des holons de surveillance .................................................................................................... 87
4.1 Implémentation de la partie informationnelle d’un holon ...................................................................... 87
4.2 Implantation physique des holons de surveillance ................................................................................. 88
5. Conclusion .................................................................................................................................................... 89
Ch. V Application au domaine ferroviaire .......................................................................................................... 90
Introduction ...................................................................................................................................................... 90
1. Contexte industriel du projet SURFER ......................................................................................................... 90
1.1 Objectifs du projet SURFER .................................................................................................................. 90
1.2 Utilisateurs du système SURFER ........................................................................................................... 91
2. Application de notre proposition pour un système train ............................................................................... 92
2.1 Instanciation de l’architecture holonique de surveillance ....................................................................... 93
2.2 Algorithmes des holons de surveillance ................................................................................................. 95
2.3 Exemples de scénarios de diagnostic ...................................................................................................... 99
3. Plateforme expérimentale ........................................................................................................................... 102
3.1 Architecture de la plateforme PEMAS ................................................................................................. 103
3.2 Implémentation des agents dans Jade ................................................................................................... 105
4. Résultats obtenus ........................................................................................................................................ 108
4.1 Implémentation de la couche acquisition embarquée ........................................................................... 108
4.2 Mise en œuvre de la méthode de diagnostic à base de modèle ............................................................. 109
4.3 Contextualisation du diagnostic............................................................................................................ 110
5. Conclusion .................................................................................................................................................. 110
Références .......................................................................................................................................................... 117
Liste des figures .................................................................................................................................................. 129
Annexes .............................................................................................................................................................. 131
Annexe A : Complément sur l’approche systémique ...................................................................................... 132
Annexe B : Etude comparative des méthodes de diagnostic ........................................................................... 133
B.1 Méthodes à base de modèles (MBD) ................................................................................................... 134
B.2 Méthodes basées sur des données historiques...................................................................................... 139
B.3 Comparaison des méthodes de diagnostic ........................................................................................... 141
Annexe C : Méthode de diagnostic mise en œuvre ......................................................................................... 144
Annexe D : Prototype SURFER ..................................................................................................................... 146 TABLE DES MATIÈRES
Page 8 Page 9
Introduction générale
Pour se démarquer et rester compétitif, les industriels misent notamment sur le développement
et l’intégration rapide de nouvelles fonctionnalités offertes par les évolutions technologiques
de l’information et de la communication.
Ces deux dernières décennies, les systèmes embarqués ont été introduits dans de nombreux
domaines d’application (transport, industrie, habitat, médical...). Ces systèmes se sont vu
confier des tâches plus importantes pour délivrer de nouveaux services aux utilisateurs avec
des délais de mise sur le marché toujours plus courts et à moindre coût. Dans certains
domaines, ces systèmes ont également permis de répondre aux exigences accrues en matière
de sécurité et de fiabilité.
Paradoxalement, le développement de ces équipements embarqués a contribué à accroitre le
nombre de pannes des systèmes dans lesquels ils sont enfouis. Ces pannes, aux conséquences
généralement coûteuses, voir catastrophiques, sont devenues inacceptables pour les industriels
qui commercialisent ces produits ainsi que pour leurs clients. L’identification des causes de
certaines pannes représente actuellement un véritable challenge dans les activités de la
maintenance. Elles entrainent une indisponibilité excessive des équipements.
Dans le domaine des transports, ces constats ont conduit un acteur majeur de l’industrie
ferroviaire à améliorer la disponibilité de ses véhicules sur rail à travers une approche
innovante visant à optimiser la maintenance. Ainsi, le projet SURFER, qui est à l’origine des
travaux présentés dans ce manuscrit, a été proposé. Ce projet repose sur la conception et le
déploiement d’une architecture évoluée pour la surveillance de matériels roulants ferroviaires.
Cette thèse se situe à la rencontre de plusieurs communautés de Recherche, dans laquelle la
notion d’intelligence (ou activité) rattachée à un produit a pour objet l’évaluation et la gestion
de la santé des équipements. Elle regroupe notamment des concepts relatifs à la surveillance
dans un contexte de maintenance, au diagnostic et au développement de produits “actifs” tout
au long de son cycle de vie.
Notre contribution principale concerne la proposition d’une architecture générique de
surveillance “active” pour l’aide à la maintenance de systèmes mobiles, basée sur des entités
de surveillance “intelligentes”. Cette architecture a vocation à supporter des méthodologies de
diagnostic développées par différentes communautés de Recherche. L’élaboration d’une
nouvelle méthode de diagnostic n’est donc pas l’objet de notre proposition.
Le projet SURFER étant le cadre applicatif de nos travaux, le domaine des transports est une
référence pour illustrer notre approche, sans pour autant restreindre l’application de notre
contribution à ce domaine.
Nous avons choisi de structurer ce manuscrit en cinq chapitres, dont l’organisation est
illustrée par la figure 1. INTRODUCTION GÉNÉRALE
Page 10
Figure 1. Organisation des chapitres de ce manuscrit.
Le chapitre I introduit le contexte général de nos travaux en présentant tout d’abord les
caractéristiques des systèmes à maintenir. Ce chapitre positionne ensuite notre étude par
rapport à un modèle d’architecture de surveillance de la littérature. Les différents verrous liés
à la surveillance des systèmes considérés sont alors exposés et les exigences à satisfaire dans
le cadre de nos travaux sont définies.
Le chapitre II dresse un état de l’art des approches de la littérature pour la surveillance de
systèmes mobiles, en proposant une typologie des architectures de diagnostic. Une classe
d’architecture est retenue dans le contexte de notre étude. Suivant ce type d’architecture, ce
chapitre s’oriente par la suite vers une approche de surveillance “active” en adoptant une
approche de modélisation à base d’entités autonomes et communicantes.
Le chapitre III est consacré à notre proposition. Une architecture générique pour la
surveillance de systèmes mobiles est proposée. Cette architecture repose sur les choix réalisés
dans le précédent chapitre. Ce chapitre spécifie l’architecture proposée et détaille la structure
interne des entités de surveillance qui composent cette architecture de surveillance.
Le chapitre IV met en œuvre l’architecture de surveillance proposée. Dans ce chapitre, les
processus internes aux entités de surveillance et les comportements attendus de ces entités
sont définis. Par la suite, une approche est adoptée pour implémenter ces entités de
surveillance.
INTRODUCTION GÉNÉRALE
Page 11
Le chapitre V applique les propositions des deux chapitres précédents au domaine ferroviaire
dans le cadre du projet SURFER. Dans un premier temps, ce chapitre instancie l’architecture
proposée pour la surveillance d’un train de passagers. Par la suite, la plateforme
expérimentale conçue pour implémenter cette architecture et valider notre approche est
détaillée. Enfin, les résultats obtenus dans ce cadre applicatif sont présentés.
Suite à ce dernier chapitre, la conclusion de nos travaux et les perspectives de Recherche
envisagées sont exposées. Page 12
Chapitre I
Problématique de la surveillance pour l’aide à la
maintenance
Introduction
Dans un contexte économique hautement concurrentiel, les fabricants et intégrateurs de
produits à haute valeur technologique sont contraints de concevoir des systèmes à des coûts
de plus en plus faibles sur l’ensemble des phases du cycle de vie. L’objectif étant de proposer
des produits compétitifs en terme de coûts d’acquisition, d’exploitation et de maintenance
(coût global de possession ou LCC : Life Cycle Cost). Par conséquent, limiter les coûts de
maintenance et d’exploitation tout en améliorant la disponibilité des systèmes est une
préoccupation majeure des industriels.
La maintenance est l’un des éléments clef dans la réduction de l’indisponibilité. Elle
représente également un point sensible, soumise notamment à des contraintes financières,
sécuritaires et énergétiques (Rabatel et al., 2009). Ainsi, la maintenance est un levier
stratégique de compétitivité et d’innovation pour les industriels (Muller et al., 2008). Elle
permet de préserver les caractéristiques fonctionnelles des systèmes et vise à améliorer leurs
disponibilités dans des conditions économiques acceptables.
L’optimisation de la maintenance se traduit par une réduction des temps d’immobilisation du
système maintenu et repose donc sur la pertinence des actions réalisées sur le système lors des
interventions de maintenance. Un système de maintenance efficace doit permettre d’orienter
au mieux le personnel de maintenance, en délivrant des informations directement exploitables
et précises sur les opérations de maintenance à réaliser.
Dans ce contexte, un système de surveillance observant en permanence un système à
maintenir lors de son fonctionnement et assurant la tâche de diagnostic de manière autonome
offre une aide précieuse aux services de maintenance (Jardine et al., 2006). Les informations
fournies par un tel système contribuent notamment à anticiper les pannes et à accélérer la
remise en service du système maintenu après l’occurrence de la défaillance. Ces informations
de surveillance peuvent apporter des précisions sur l’origine des dysfonctionnements observés
et sur les interventions de maintenance à réaliser.
Ce premier chapitre présente les systèmes à maintenir considérés dans nos travaux et introduit
les principales notions relatives à la surveillance dans un contexte de maintenance. Par la
suite, les différentes fonctions d’un système de surveillance seront présentées et les
problématiques inhérentes à la surveillance des systèmes étudiés seront exposées. CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE
Page 13
1. Contexte général
Les avancées technologiques de l’information et de la communication ont favorisé
l’intégration massive de fonctions automatisées au sein de produits industriels (BrahimDjelloul
et al., 2012 ; Kiencke et al., 2006). Ces fonctions permettent de délivrer de nouveaux
services aux utilisateurs et d’atteindre des objectifs de plus en plus élevés en termes de
sécurité et de fiabilité. Ainsi, de nombreuses fonctionnalités sont assurées par des systèmes
embarqués. Un système embarqué est un système complexe intégrant une partie logicielle et
une partie matérielle conçues conjointement pour fournir des fonctionnalités données (Simeu,
2005). Ces équipements embarqués peuvent réaliser des fonctions plus évoluées lorsqu’ils
interagissent entre eux au sein d’un système plus vaste (système de transport, bâtiment
industriel, systèmes de production, par exemple). Ces équipements interconnectés forment
alors un système réparti (Dievart et al., 2010).
La complexité croissante des systèmes dotés de ces équipements embarqués tend à rendre
leurs opérations de maintenance bien plus délicates. Par exemple, une intervention de
maintenance sur un tel système nécessite une connaissance approfondie du fonctionnement de
l’ensemble du système et des différents équipements embarqués qui le composent. Pour faire
face à cette complexité, des approches de maintenance dites “intelligentes” ont été rendues
possibles grâce aux évolutions de l’informatique, de l’électronique et des télécommunications
(Campos, 2009). Ces approches de maintenance innovantes visent à évaluer l’état d’un
système et à déterminer les interventions de maintenance nécessaires en fonction de cet état.
Les objectifs attendus de ces nouvelles approches de maintenance sont d’accroitre la durée de
fonctionnement des équipements, de réduire les coûts de maintenance, d’exploitation et de
possession, et d’améliorer la sécurité (Vachtsevanos et Lewis, 2006).
Cette partie positionne tout d’abord les systèmes considérés dans nos travaux en adoptant une
approche systémique. Par la suite, les propriétés des systèmes à maintenir considérés sont
définies et la terminologie adoptée dans nos travaux est présentée. Enfin, cette partie décrit les
différents types de maintenance et précise le rôle de la surveillance au sein d’un système de
maintenance.
1.1 Approche systémique adoptée
Ce mémoire se focalise sur l’aide à la maintenance de systèmes constitués d’équipements
embarqués répartis, désignés ci-après sous-systèmes, et organisés suivant une structure
hiérarchisée de contrôle. Par la suite, un système constitué de ces sous-systèmes sera nommé
système cible. Un système cible est supposé être maintenu par un système de maintenance.
Un système de maintenance regroupe différentes entités en charge de planifier et de réaliser
les interventions de maintenance (centre de maintenance, personnel de maintenance, par
exemple).
La figure 1.1 ci-dessous présente un exemple de système cible supposé être situé dans son
environnement. Ce système cible se compose de différents sous-systèmes organisés suivant
une structure hiérarchisée de contrôle : un sous-système commande un ou plusieurs soussystèmes
de niveau inférieur. De plus, les sous-systèmes interagissent entre eux dans le
domaine physique et dans le domaine informationnel. Les relations maître-esclave illustrées
dans cet exemple représentent les liens “logiques” de subordination entre sous-systèmes.
Les liens “physiques” entre ces sous-systèmes peuvent être réalisés par différentes
technologies (bus ou réseaux, par exemple). CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE
Page 14
Figure 1.1. Exemples de système cible et de système de maintenance considérés.
Le système de maintenance est supposé disposer d’un centre de maintenance, dont l’objectif
est de maintenir le système cible tout au long de son usage. Lorsqu’une approche de
maintenance doit être appliquée à un système cible, des exigences sont alors à allouer au
système de maintenance comme au système cible. La section suivante définit les propriétés
des systèmes cibles considérées dans nos travaux.
1.2 Propriétés des systèmes cibles considérés
Les systèmes cibles considérés dans nos travaux sont caractérisés par les propriétés suivantes :
· Décomposition : le système cible est supposé être décomposable en un ensemble fini
de sous-systèmes.
· Hétérogénéité technologique : chaque sous-système est supposé être constitué d’une
partie contrôle et d’une partie sous-contrôle. Ces sous-systèmes sont supposés
exploiter différentes technologies (électrique, électronique, mécanique, hydraulique ou
pneumatique, par exemple).
· Variabilité : un sous-système est supposé varier d’un même système cible à un autre
(évolution de la technologie, modification de composants, modernisation, par
exemple).
· Interactions : les sous-systèmes sont supposés interagir entre eux dans le domaine
physique (échanges de flux de matière ou d’énergie, par exemple) et/ou dans le
domaine informationnel (relations de type maître-esclave ou échanges d’informations,
par exemple).
· Environnement : le système cible est supposé être situé dans un environnement. Par
conséquent, le système cible comme chaque sous-système est supposé opérer dans un
contexte opérationnel spécifique. Ce contexte peut être de nature physique
(température, vibrations, par exemple) et/ou informationnelle (mode de
fonctionnement, état du système, par exemple).
· Maintenabilité : le système cible est supposé être réparable et être maintenu au sein du
système de maintenance par un centre de maintenance. CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE
Page 15
Le tableau 1.1 ci-après présente les domaines d’applications les plus représentatifs des
systèmes cibles considérés dans nos travaux. Les principales caractéristiques associées à ces
systèmes cibles sont également mentionnées.
Tableau 1.1. Exemples de systèmes cibles considérés, inspiré de (Simeu, 2005).
Application Mobilité Sévérité de
l'environnement
Intervention
immédiate
sur le système
Haut niveau
de fiabilité
Transport
Automobile P P - P
Ferroviaire P P - P
Aérien P P - P
Maritime P P - P
Aérospatial
Fusée navette P P - P
Satellites P P - P
Industrie
Systèmes de production - P P P
Centrales nucléaires - P P P
Habitat
Bâtiments (immotique) - - P -
Habitations (domotique) - - P -
- : caractéristique absente ou négligeable P : caractéristique présente
Dans certains domaines d’applications, la mobilité du système cible entraine des contraintes
spécifiques en termes de maintenabilité. En effet, lorsque le système cible est mobile, celui-ci
doit communiquer avec un centre de maintenance distant (Jianjun et al., 2007). Par exemple,
un système de transport (automobile, ferroviaire, aérien ou maritime) est un système cible
mobile évoluant dans un environnement changeant (climat, état de l’infrastructure, profil du
conducteur, par exemple). Les interventions de maintenance ne peuvent être exécutées
immédiatement sur ce système (système en service commercial et éloigné du centre de
maintenance, par exemple) (Umiliacchi et al., 2011). Aussi, un système de transport doit
répondre à des exigences strictes en matière de fiabilité.
La disponibilité d’un système cible repose sur les objectifs de fiabilité fixés lors de sa
conception et sur l’efficacité des interventions de maintenance réalisées au cours de sa phase
LégendeCHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE
Page 16
d’utilisation. Les sections suivantes présentent la terminologie et les principaux concepts
associés à la maintenance.
1.3 Terminologie relative à la maintenance
La maintenance est définie comme l’ensemble de toutes les actions techniques,
administratives et de management durant le cycle de vie d’un bien, destinées à le maintenir ou
à le rétablir dans un état dans lequel il peut accomplir la fonction requise (NF-EN-13306,
2010). Un bien désigne un élément, composant, mécanisme, sous-système, unité
fonctionnelle, équipement ou système qui peut être décrit et considéré individuellement.
Différents événements peuvent compromettre le fonctionnement désiré d’un bien ou la
mission pour laquelle un bien a été conçu. Les entraves au bon fonctionnement d’un bien sont
les fautes, les erreurs et les défaillances (Isermann et Ballé, 1997). Une faute est une
déviation non acceptable d’au moins une propriété caractéristique exprimée par le cahier des
charges ou d’un paramètre d’un bien. Une erreur représente un changement d’état d’un bien
pouvant entraîner une défaillance. Elle est produite par une ou plusieurs fautes et peut
engendrer de nouvelles erreurs. Une défaillance est la cessation de l'aptitude d'un bien à
accomplir une fonction requise et peut être causée par une ou plusieurs erreurs. Après la
défaillance, le bien est en état de panne, c’est-à-dire qu’il est inapte à accomplir une fonction
requise. Une panne peut être complète ou partielle et résulte toujours d’une défaillance.
Dans les travaux présentés dans cette thèse, le système cible considéré est supposé être affecté
par des fautes physiques (fautes matérielles) et informationnelles (fautes logicielles) survenant
dans les différentes phases de son cycle de vie (fautes de développement et fautes
opérationnelles, par exemple). Ces fautes induisent une ou plusieurs erreurs lorsqu’elles sont
actives (états non désirés du système). Dès lors que le service délivré aux utilisateurs est
impacté par ces erreurs et ne correspond plus au service attendu, une défaillance survient. La
figure 1.2 ci-dessous illustre la relation entre les concepts de faute, erreur et défaillance
survenant au sein d’un système cible. La présence d’une faute dans un sous-système du
système cible engendre une erreur interne lors de son activation, qui conduit à la défaillance
de ce sous-système. Cette défaillance peut constituer une faute pour un autre sous-système du
système cible en provoquant à son tour une erreur interne et une défaillance de ce soussystème.
Cette seconde défaillance entraine par la suite la défaillance du système cible en
impactant le service délivré aux utilisateurs.
Figure 1.2. Relation causale entre faute, erreur et défaillance.
Il est à noter que les fautes et les défaillances peuvent se manifester de manière progressive
dans le temps (phénomènes d’usures, par exemple), de manière soudaine (rupture d’une CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE
Page 17
liaison électrique, par exemple), ou présenter un caractère non permanent (défaillances
temporellement bornées ou furtives, par exemple). Une défaillance produit des effets
perceptibles par les utilisateurs du système et éventuellement décelables par un moyen de
détection. Le terme symptôme sera utilisé par la suite pour désigner les effets observables
d’une défaillance.
La tâche de diagnostic de défaillances consiste alors à analyser ces symptômes dans le but de
rechercher les éléments défectueux du système cible responsables de la défaillance (fautes).
Elle peut être réalisée par un opérateur de maintenance ou être exécutée par un système d’aide
à la maintenance. Les différentes activités de la maintenance sont exposées ci-après.
1.4 Activités de la maintenance
La définition de la maintenance évoquée précédemment englobe différentes activités mises en
œuvre tout au long du cycle de vie d’un produit. Ces activités concernent aussi bien des
aspects opérationnels de la maintenance (expertise métier, diagnostic de défaillances, par
exemple) que des aspects organisationnels (planification des interventions, approvisionnement
des pièces de rechanges, par exemple). Dans ce mémoire, les aspects opérationnels de la
maintenance seront principalement abordés. Cette section présente les différentes approches
de maintenance et précise le rôle de la surveillance au sein des activités de la maintenance.
1.4.1 Typologie de la maintenance
L’étude des différentes approches de maintenance repose sur trois concepts : l’événement
déclencheur d’une opération de maintenance, le type de maintenance correspondante et la
nature des opérations de maintenance réalisées sur le système (Ribot, 2009). Selon la norme
(NF-EN-13306, 2010), les approches de maintenance sont classées en deux catégories : la
maintenance préventive et la maintenance corrective. La première vise à initier des opérations
de maintenance sur un système avant que des défaillances ne se produisent, tandis que la
seconde consiste à intervenir sur un système en état de panne. La figure 1.3 ci-dessous résume
les principaux types de maintenance recensés dans la littérature selon ces deux catégories et
précise les événements déclencheurs des interventions de maintenance.
Figure 1.3. Différents types de maintenance, inspirée de (Alali Alhouaij, 2010). CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE
Page 18
La maintenance préventive est exécutée à intervalles prédéterminés ou selon des critères
prescrits. Elle est destinée à réduire l’occurrence de défaillances et à éviter les pannes lors de
la sollicitation du système. La maintenance préventive se décline en trois sous-types
normalisés, détaillés ci-après : la maintenance préventive à caractère systématique,
conditionnelle et prévisionnelle (NF-EN-13306, 2010).
· Systématique (Predetermined Maintenance) : maintenance préventive exécutée
conformément à un échéancier, établi à partir d’un nombre d’unités d’usage
(durée de fonctionnement, par exemple) ou suivant des données statistiques
(recommandations constructeurs, par exemple). Elle vise principalement à rajeunir
le matériel (remplacement périodique, par exemple) ou à limiter les dégradations
(tâches d’entretiens courants), quel que soit l’état réel du bien maintenu (Zille,
2009). Seule la périodicité des interventions peut être ajustée pour optimiser ce
type de maintenance.
· Conditionnelle (Condition Based Maintenance) : maintenance préventive
subordonnée à l’analyse de l’évolution surveillée de paramètres significatifs de la
dégradation ou de la baisse de performance d’un bien (Deloux, 2008). Les
paramètres significatifs de dégradations concernent par exemple des mesures de
caractéristiques physiques d’un système et précurseurs de pannes (bruit, vibration,
vitesse anormale, épaisseur trop faible d’un matériau, par exemple). Ce type de
maintenance nécessite d’établir des seuils à priori pour les différents paramètres
mesurés (seuils prédéterminés). Le dépassement d’un seuil indique alors la
nécessité d’une opération de maintenance (par exemple, le remplacement d’un
pneumatique est nécessaire lorsque son épaisseur atteint la limite fixée par son
témoin d’usure). Bien que la maintenance conditionnelle soit plus dynamique que
la maintenance systématique puisqu’elle considère l’état d’un bien, le temps
restant avant l’occurrence de la défaillance reste indéterminée avec ce type de
maintenance.
· Prévisionnelle (Predictive Maintenance) : maintenance conditionnelle effectuée
suivant les prévisions extrapolées de l’analyse et de l’évaluation de paramètres
significatifs de la dégradation d’un bien (El koujok, 2010). Ce type de
maintenance vise à prédire l’évolution de paramètres significatifs de dégradations
d’un bien dans le futur et à estimer le temps de fonctionnement restant avant la
défaillance (pronostic). Elle peut être qualifiée de maintenance prédictive,
reposant sur les évolutions de paramètres surveillés dans le futur, et de
maintenance proactive, qui consiste à déterminer les causes à l’origine des
dégradations et des défaillances (Deloux, 2008).
La maintenance corrective a pour objectif de remettre un bien en état de panne dans un état
fonctionnel. Elle peut prendre la forme d’une maintenance palliative ou curative (Ribot,
2009) :
· Palliative : maintenance corrective assurant une remise en état provisoire d’un
bien (dépannage temporaire d’un pneumatique, par exemple). Ce type de
maintenance consiste également à intervenir sur les effets néfastes d’une
défaillance. Une action de maintenance palliative doit être suivie
systématiquement d’une action de maintenance curative. CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE
Page 19
· Curative : maintenance corrective permettant une remise en état de manière
durable et définitive d’un bien. Contrairement à la maintenance palliative, la
maintenance curative a pour objectif de supprimer les causes des défaillances.
La maintenance préventive et la maintenance corrective sont complémentaires. En pratique,
une politique de maintenance combinant ces deux approches est généralement appliquée aux
systèmes. En effet, une maintenance préventive permet de diminuer la probabilité de
défaillances, mais une part de maintenance corrective incompressible subsiste (défaillances
imprévisibles). Ainsi, différentes politiques de maintenance mixte ont été définis (Ly et al.,
2013). L’élaboration d’une politique de maintenance repose notamment sur un équilibre
économique amenant à un meilleur compromis (coût et disponibilité, par exemple). La soussection
suivante positionne la surveillance suivant ces deux types de maintenance.
1.4.2 Rôle de la surveillance
Dans une approche de maintenance innovante, la surveillance occupe une place fondamentale
(Raccoceanu, 2006). La surveillance est considérée dans nos travaux comme un dispositif
passif, informationnel, qui n’influence pas le comportement du système cible sous
surveillance. Ainsi, un système de surveillance est non-intrusif vis-à-vis d’un système cible.
Ce dispositif délivre des informations pertinentes sur l’état d’un système cible pour
déclencher des interventions de maintenance (maintenance préventive conditionnelle) et
assister au mieux un opérateur de maintenance pour rétablir un système en panne
(maintenance corrective). Par exemple, une défaillance ayant conduit à une panne d’un
système cible peut être décryptée spontanément par un système de surveillance. Le système
de surveillance transmet ainsi des informations sur l’état de ce système au centre de
maintenance (figure 1.4). Ces informations concernent, par exemple, les éléments
potentiellement responsables de la panne ainsi que des actions de maintenance à réaliser sur le
système cible pour le rétablir dans un état fonctionnel. Le centre de maintenance génère alors
une demande d’intervention aux opérateurs de maintenance chargés d’intervenir sur le
système cible (tâche de maintenance corrective, par exemple). Les interventions de
maintenance corrective sont alors mieux préparées et les durées des réparations sont
maîtrisées.
Figure 1.4. Système de surveillance pour l’aide à la maintenance.CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE
Page 20
Dans une approche de maintenance préventive conditionnelle (maintenance prédictive ou
CBM : Condition Based Maintenance), l’objectif d’un système de surveillance est d’émettre
des alertes avant la défaillance du système cible pour prévenir les pannes. Cette surveillance
prédictive (ou dynamique) se focalise ainsi sur les tendances de l’évolution de l’état du
système sous surveillance dans le temps. Les informations transmises aux personnels de
maintenance permettent alors de signaler des dégradations ou des baisses de performance des
éléments du système à un stade précoce de leur développement.
La nature des informations fournies par un système de surveillance dépend des profils des
utilisateurs finaux et diffère donc selon leur expertise (opérateurs de maintenance,
concepteurs du système, par exemple) (Alanen et al., 2006). Dans le cadre d’une surveillance
pour l’aide à la maintenance au sens intervention, un système de surveillance doit incriminer
des éléments à remplacer ou à réparer bien connus des opérateurs de maintenance. Par
exemple, certains systèmes cibles comportent des Unités Remplaçables en Ligne (URL ou
LRU : Line Replaceable Unit). Une URL peut être déposée et échangée rapidement pour
optimiser les interventions de maintenance et réduire ainsi les temps d’indisponibilité des
systèmes (Dievart et al., 2010). Par conséquent, une tâche de maintenance associée à une
URL constitue une information pertinente pour un opérateur de maintenance. Néanmoins,
suivant le niveau de complexité de la tâche de maintenance à réaliser, un opérateur de
maintenance peut être habilité ou non à intervenir sur le système cible. Les informations de
surveillance doivent donc être adaptées au niveau de qualification des utilisateurs du système
de surveillance.
La surveillance est généralement réalisée en-ligne, pendant le fonctionnement du système
cible sous surveillance, mais certaines fonctions de la surveillance peuvent être exécutées
hors-ligne. C’est le cas notamment du diagnostic, dont l’exécution a posteriori peut être
possible sur la base des symptômes détectés sur le système (Azarian et al., 2010). La partie
suivante décrit les principales fonctions d’un système de surveillance.
2. Fonctions d’un système de surveillance
Un système de surveillance regroupe deux composantes essentielles : “voir” et “comprendre”
(Basseville et Cordier, 1996). La première permet d’observer et de détecter des déviations du
comportement du système sous surveillance par rapport à un comportement de référence
(perception). La seconde détermine les composants potentiellement responsables des
phénomènes observés et recherche les causes (interprétation). Dans cette partie, les
principales fonctions d’un système de surveillance mises en œuvre pour des approches de
maintenance de type conditionnelle (maintenance prédictive ou CBM) et corrective sont
présentées.
Les fonctions assurées par un système de surveillance s’inscrivent dans différentes
communautés de Recherche, et sont notamment au centre des thématiques SHM (System
Health Management) et PHM (Pronostics and Health Management) (Medina-Oliva et al.,
2012 ; Reed et al., 2011). Dans ce cadre, un système de surveillance comprend généralement
l’acquisition de données, la détection d’anomalies de fonctionnement, le diagnostic, le
pronostic et l’élaboration de recommandations de maintenance (Guillén et al., 2013 ;
Vachtsevanos et Lewis, 2006). Ces différentes fonctions ont pour but de convertir un flux de
données brutes, difficilement exploitable pour un opérateur de maintenance, en informations
pertinentes, relatives à l’état de santé du système sous surveillance et aux opérations de
maintenance à réaliser selon cet état (Abichou, 2013). Ainsi, un système de surveillance CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE
Page 21
permet de déterminer l’état d’un système (état normal ou anormal d’un système cible, par
exemple) et lorsque ce système présente des anomalies de fonctionnement, il exécute les
tâches de diagnostic et de pronostic. Selon les symptômes du système et les conclusions du
diagnostic et du pronostic, il prescrit des recommandations de maintenance ou suggère des
changements opérationnels afin que le système puisse accomplir sa mission.
La première tâche d’un système de surveillance consiste à recueillir des données brutes sur le
système sous surveillance. Cette fonction d’acquisition de données est généralement réalisée à
l’aide de méthodes dites non-destructives, n’altérant pas le fonctionnement du système sous
surveillance (IAEA, 2007). Suivant l’état de santé du système sous surveillance, différentes
fonctions sont par la suite sollicitées. L’activité d’un système de surveillance diffère selon la
présence ou non d’une défaillance au sein du système sous surveillance. La figure 1.5 cidessous
présente les principales fonctions d’un système de surveillance avant l’occurrence
d’une défaillance (surveillance dynamique) et après la défaillance du système sous
surveillance (surveillance classique).
Figure 1.5. Fonctions de surveillance dynamique et classique, adaptée de
(Raccoceanu, 2006).
Comme évoqué précédemment, la surveillance dynamique vise à éviter la défaillance du
système sous surveillance. Elle consiste alors à détecter et à diagnostiquer des dégradations ou
des baisses de performance du système sous surveillance (Bengtsson, 2003). Par la suite,
l’objectif est de pouvoir prédire (pronostiquer) des défaillances dans le futur, en projetant
l’état de santé actuel du système sous surveillance dans le temps (Tobon-Mejia et al., 2012).
La surveillance dynamique regroupe ainsi les fonctions de détection prédictive de
dégradations, de diagnostic prédictif et de pronostic. Notons que les résultats du diagnostic et
du pronostic doivent être délivrés dans un temps opportun aux personnels de maintenance afin
que des actions de maintenance puissent être exécutées sur le système avant la panne. De plus,
cette surveillance dynamique doit être suffisamment robuste pour ne pas délivrer des alertes
intempestives aux opérateurs de maintenance. CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE
Page 22
La surveillance classique intervient après l’occurrence d’une défaillance. Dans ce cas, cette
surveillance consiste à détecter les défaillances survenues dans le système sous surveillance et
à les diagnostiquer. Lorsque le système sous surveillance est en état de panne, le diagnostic
permet de rechercher les causes et de localiser les éléments défaillants du système. Cette tâche
peut s’avérer laborieuse pour un opérateur de maintenance, notamment lorsqu’il s’agit d’un
système cible constitué de multiples éléments (Azarian et al., 2010 ; Khol et Bauer, 2010). Un
diagnostic difficile peut conduire un opérateur de maintenance à déposer des éléments non
contributeurs de la panne ou à remplacer des éléments non défaillants, engendrant des coûts
excessifs de maintenance. Différentes approches ont ainsi été proposées pour automatiser
cette tâche devenant trop complexe pour un opérateur de maintenance (Feldman, 2010).
Enfin, un système de surveillance s’appuie sur les informations de diagnostic et de pronostic
pour élaborer des recommandations de maintenance et délivrer ces informations aux
personnels de maintenance. Les différentes fonctions de surveillance illustrées sur la figure
1.5 sont détaillées dans les sections suivantes.
2.1 Détection
La détection relève de la composante “voir” d’un système de surveillance. A partir de données
recueillies sur le système sous surveillance, la fonction détection permet de déceler la
présence de dégradations (surveillance dynamique) ou de défaillances (surveillance classique)
dans ce système, et donc de qualifier le comportement observé du système de normal ou
d’anormal. La fonction détection génère des signaux porteurs de symptômes à partir des
observations, également nommés résidus ou discordances par certaines communautés
(Cordier et al., 2000 ; Roth et al., 2011). Par exemple, une approche usuelle permettant de
générer des symptômes consiste à comparer certaines grandeurs observées à des seuils
caractérisant une situation anormale. Le franchissement d’un seuil indique une anomalie de
fonctionnement et provoque le déclenchement d’une alarme (Basseville et Cordier, 1996).
Les inconvénients de ces tests de dépassement de seuils résident dans la génération de fausses
alarmes (seuil trop faible) et dans la non-détection de certains symptômes (seuil trop élevé).
Certains équipements exécutent ce type de test pendant leur fonctionnement pour générer des
alarmes et fournir une aide aux opérateurs de maintenance lors de la phase de diagnostic
(Lefebvre, 2000). Cependant, les alarmes générées par ces tests intégrés (BIT : Built-In Test)
représentent essentiellement des symptômes sans informations relatives à leurs causes. Le
diagnostic établi par un opérateur de maintenance sur la base de ces événements est parfois
erroné (Pecht et al., 2001).
2.2 Diagnostic
Le diagnostic prend en charge l’interprétation des anomalies de fonctionnement du système
sous surveillance et constitue la composante “comprendre” d’un système de surveillance. La
fonction diagnostic doit permettre de lever l’ambiguïté sur le phénomène à l’origine d’une
dégradation ou d’une défaillance particulière à partir des symptômes délivrés par la fonction
détection. Pour ce faire, la fonction diagnostic fait appel à une connaissance du système sous
surveillance. Cette connaissance intègre, par exemple, une référence du fonctionnement
normal (comportement nominal) ou du fonctionnement anormal (comportement en présence
de défaillances) du système sous surveillance (Ribot, 2009). Les principales méthodes de
diagnostic développées par différentes communautés de Recherche sont présentées en
annexes de ce manuscrit.
La fonction diagnostic évalue l’état de santé actuel d’un système en recherchant les causes
(fautes) à l’origine d’une dégradation (diagnostic prédictif) ou d’une défaillance particulière CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE
Page 23
(diagnostic de défaillances) et en localisant les éléments du système à remplacer ou à réparer.
Il s’agit d’une fonction commune à la maintenance prédictive et à la maintenance corrective
permettant d’incriminer des éléments défectueux et de déterminer les actions à entreprendre
(IAEA, 2007). Le diagnostic prédictif se focalise avant tout sur l’analyse de défaillances
progressives (dégradations) pour éviter la panne et planifier à l’avance les interventions de
maintenance (commande de pièces de rechanges et gestion du personnel de maintenance, par
exemple). Néanmoins, il existe toujours des défaillances soudaines (imprévisibles) ne pouvant
être anticipées et devant faire l’objet d’un diagnostic (Jardine et al., 2006).
Contrairement aux signaux émis par la fonction détection, la fonction diagnostic est en
mesure de fournir des informations de haut niveau à un opérateur de maintenance, en
précisant les causes probables des dysfonctionnements détectés (Basseville et Cordier, 1996).
Suivant les besoins des utilisateurs du système de surveillance, le résultat d’un diagnostic peut
permettre d’identifier par exemple un composant physique défectueux ou un mode de
défaillance (Mathur et al., 2001).
2.3 Pronostic
La fonction pronostic se concentre sur l’évolution des défaillances progressives et exploite
généralement l’état de santé actuel d’un système (résultats du diagnostic prédictif) pour
évaluer son état de santé futur. Bien qu’il n’existe aucune définition stabilisée et unanime du
concept de pronostic, différentes définitions convergent vers une fonction capable de
déterminer la durée de vie restante avant la défaillance d’un système, nommée RUL
(Remaining Useful Life), ou la probabilité d’un système à fonctionner pendant un certain
temps (El koujok, 2010). Le pronostic est spécifique à la maintenance prédictive et essentielle
dans une approche CBM (Alanen et al., 2006). Il permet d’anticiper au mieux les
interventions de maintenance suivant la prédiction de l'état futur d’un équipement (Gulledge
et al., 2010). Par nature, le pronostic vise à anticiper l’état d’un système dans le futur et amène
des incertitudes (Medina-Oliva et al., 2012). En effet, le pronostic de l’état futur d’un système
doit non seulement considérer l’état actuel du système, mais également des données relatives
à ce système dans le futur (prévisions d’utilisation du système, informations sur
l’environnement futur du système, futures opérations de maintenance exécutées sur le
système, par exemple), qui influent sur son état de dégradation. Ainsi, le pronostic doit
prévoir l’état futur d’un système et fournir une durée de vie résiduelle à partir d’une
connaissance à priori sur ce système (lois de dégradations, par exemple), d’une connaissance
d’informations passées (historique des modes de fonctionnement passés), présentes (état
courant) et futures (Cocheteux et al., 2007). Cette durée de vie résiduelle avant la défaillance
peut être exprimée, par exemple, en unités de temps (heures de fonctionnement), en distances
à parcourir (nombre de kilomètres) ou en nombre de sollicitations (nombre de cycles) (Ribot,
2009).
2.4 Elaboration de conseils
En fonction de l’état de santé actuel et de la prévision de l’état de santé du système, délivrés
respectivement par les fonctions de surveillance classique et dynamique, le système de
surveillance élabore des recommandations sur les opérations de maintenance à réaliser
(actions préventives et correctives), ou privilégie un mode de fonctionnement ou une
configuration à adopter pour que le système puisse achever sa mission en évitant la panne
(Bengtsson, 2003). L’état de santé d’un système est le support principal pour orienter les
services de maintenance sur les interventions à effectuer, et peut être défini par le diagnostic
et le pronostic du système (Dievart, 2010). La fonction d’élaboration de conseils assiste
principalement l’opérateur de maintenance dans le choix des actions de maintenance à CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE
Page 24
entreprendre (remplacement d’un élément du système en priorité selon son état de santé ou
son RUL, par exemple). Par ailleurs, le bilan de santé dressé par cette fonction peut également
alerter les services de conception, pour améliorer la qualité du système, revoir sa conception,
ou impacter la conception et la fabrication d’une future génération de produits (Gulledge et
al., 2010 ; Vichare et al., 2007). Cette fonction d’aide à la maintenance s’inscrit également
dans les activités de gestion de la santé des équipements (Equipment Health Management)
dans le cycle de vie des produits.
3. Modèle d’architecture de surveillance
Après avoir décrit précédemment les principales fonctions d’un système de surveillance, cette
partie présente deux architectures considérées comme des références dans la littérature pour le
développement de systèmes de surveillance. Une architecture sera retenue en tant que modèle
dans nos travaux pour la surveillance des systèmes cibles considérés. Un modèle
d’architecture de surveillance doit être suffisamment générique pour supporter de nombreux
algorithmes de traitement et de diagnostic (Park et al., 2006). Parmi les architectures de
surveillance recensées dans la littérature s’insérant dans les thématiques SHM-PHM (System
Health Management - Pronostics and Health Management), une architecture apparaît comme
un standard de référence (Gucik-Derigny, 2011 ; Kunche et al., 2012 ; Sreenuch et al., 2013).
Il s’agit du standard OSA-CBM (Open System Architecture - Condition-Based Maintenance)
diffusé par le consensus MIMOSA (Machinery Information Management Open Systems
Alliance) (OSA-CBM, 2006).
Le standard OSA-CBM résulte initialement des travaux de Recherche de (Lebold et Thurston,
2001) et (Lebold et al., 2003), impliquant différents industriels et visant à définir un modèle
d’architecture de surveillance. Ces travaux ont permis d’établir un modèle d’architecture pour
le développement de systèmes de surveillance dans un cadre de maintenance CBM. Le
modèle d’architecture proposé repose sur différentes couches fonctionnelles implémentées
sous forme de modules. Ce modèle générique a donné lieu à une série de normes enregistrées
sous le numéro ISO 13374 et à une implémentation de référence nommée OSA-CBM.
Dans cette partie, ces deux standards complémentaires d’architectures seront dans un premier
temps présentés. Par la suite, les différentes problématiques liées à la surveillance des
systèmes cibles seront exposées. Enfin, les principales exigences attendues d’un système de
surveillance seront définies.
3.1 Standards d’architectures de surveillance
Les sous-sections suivantes précisent les différentes couches fonctionnelles définies par la
norme ISO 13374, ainsi que les interfaces spécifiées par le standard OSA-CBM. Certains
standards additionnels et spécifiques à la mise en œuvre d’un système de surveillance ne
seront pas abordés dans nos travaux (interfaces physiques, configurations, interopérabilité,
diffusion des informations, par exemple) (Sheppard et al., 2009).
3.1.1 Norme ISO 13374
Depuis 2003, la norme ISO 13374 établit les lignes directrices générales des spécifications
pour la surveillance et le diagnostic d’état des machines. Ces spécifications logicielles portent
sur le traitement, la communication et la présentation de données de surveillance
indépendamment de la technologie utilisée (ISO13374-1, 2003). La première partie de cette
norme (partie 1 : lignes directrices générales) définit un modèle d’architecture de surveillance CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE
Page 25
en six couches successives de traitement et deux couches d’interface transversales (figure
1.6). Les couches de traitement #1 à #3 sont liées à la technologie du système sous
surveillance et les couches #4 à #6, de plus haut niveau, assurent les tâches de diagnostic, de
pronostic et d’aide à la maintenance. Cette norme définit également deux couches d’interface
(#7 et #8) permettant de présenter des informations issues des différentes couches de
traitement aux utilisateurs, et d’assurer une liaison avec des systèmes externes (transmission
et stockage des données, paramétrage des différentes couches, par exemple).
Figure 1.6. Modèle d’architecture ISO 13374, adaptée de (ISO 13374-1, 2003).
Les couches fonctionnelles définies par cette norme sont détaillées ci-après. Les termes
associés aux différentes couches sont repris de la version originale de la norme.
· Data Acquisition (#1-DA) : cette couche d’acquisition de données permet de
convertir un signal délivré par un capteur ou un transducteur en un paramètre
numérique représentant une quantité physique, auquel est associé différentes
informations (datation, données de calibration, configuration du capteur utilisé, par
exemple).
· Data Manipulation (#2-DM) : cette couche de manipulation de données analyse des
signaux, effectue un calcul de descripteurs significatifs (caractéristiques), et réalise des
traitements et transformations de signaux à partir de mesures brutes.
· State Detection (#3-SD) : cette couche de détection d’état recherche des anomalies
sur les signaux traités et doit déterminer la zone d’anomalie correspondante (si elle
existe) sur laquelle se situe ces signaux, dans le but de générer des alertes ou des
alarmes.CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE
Page 26
· Health Assessment (#4-HA) : cette couche d’évaluation de la santé réalise le
diagnostic des fautes détectées et détermine l’état de santé courant de l’équipement ou
du processus, en considérant l’ensemble des informations d’états.
· Pronostic Assessment (#5-PA) : cette couche d’évaluation pronostic détermine les
états de santé et les modes de défaillances futurs à partir de l’évaluation de l’état de
santé courant et de la projection de l’utilisation de l’équipement ou du processus, et
détermine des prédictions de durées de vie résiduelle (Remaining Useful Life).
· Advisory Generation (#6-AG) : cette couche de génération de conseils fournit des
informations claires et concrètes sur des actions de maintenance nécessaires ou
concernant des modifications opérationnelles à apporter pour optimiser la durée de vie
du processus et/ou de l’équipement.
· Information Presentation (#7) : cette couche est une interface permettant de
présenter des données pertinentes issues des différentes couches à des personnels
qualifiés, telles que des courbes de tendances et des zones d’anomalies associées. Elle
doit fournir aux analystes les données nécessaires pour identifier, confirmer ou
comprendre un état anormal. Par ailleurs, cette couche assure une transformation de
données en une forme présentant clairement les informations nécessaires pour prendre
des décisions sur les actions de maintenance à réaliser.
· External Systems (#8) : cette couche permet une liaison rapide avec des systèmes
externes, et notamment avec un système de maintenance (accès à l’historique des
interventions de maintenance, transmission des recommandations de maintenance ou
de requêtes d’intervention de maintenance, par exemple), et avec un système de
contrôle d’exploitation (accès aux prévisions de l’utilisation de l’équipement,
transmission de requêtes de changements opérationnels ou de mise hors service de
l’équipement, par exemple).
Le concept d’état de santé mentionné dans la norme ISO 13374 (health state) n’est pas
clairement défini. L’état de santé d’un équipement repose généralement sur l’expertise métier
et dépend des traitements réalisés par les couches #4 à #6 du modèle. Néanmoins, la première
partie de cette norme évoque un indice de santé associé à un équipement (health index) allant
de 0 (défaillance complète de l’équipement) à 10 (équipement comme neuf).
La seconde partie de la norme ISO 13374 (partie 2 : traitement des données) caractérise les
différents modules associés aux couches successives de traitement présentées sur la figure 1.6
(ISO 13374-2, 2007). Un module peut implémenter des fonctionnalités relatives à une ou
plusieurs couches de traitement du modèle. De plus, cette norme suggère la manière dont ces
modules peuvent être agencés pour former une architecture opérationnelle de surveillance.
Ces modules peuvent notamment être répartis sur différents supports d’exécution
interconnectés entre eux. La figure 1.7 ci-dessous illustre un exemple d’architecture
opérationnelle, dans laquelle chaque module est supporté par un dispositif matériel et
implémente les fonctionnalités d’une couche du modèle. CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE
Page 27
Figure 1.7. Exemple d’architecture opérationnelle, adaptée de (ISO 13374-2, 2007).
Le medium de communication situé au centre de la figure 1.7, représente le support des
différentes communications entre ces modules et peut être réalisé au travers de différentes
technologies. Ainsi, les modules de l’architecture ne résident pas nécessairement sur le même
support et peuvent être distants les uns des autres. Cette approche permet également d’intégrer
des modules développés par différents fournisseurs pour former un système de surveillance
modulaire. Des exemples d’échanges d’informations entre ces modules sont proposés dans la
troisième partie de la norme (partie 3 : échange), diffusée en 2012 (ISO 13374-3, 2012).
3.1.2 OSA-CBM
Le standard OSA-CBM implémente précisément les six couches de traitement définies par la
norme ISO 13374 (figure 1.5). Comme la norme ISO 13374, le standard OSA-CBM ne
spécifie pas les traitements et les algorithmes internes aux différents modules. En revanche, ce
standard définit les types et les structures de données à utiliser pour le traitement et la
communication des résultats, ainsi que la manière dont les informations doivent être
transférées entre les modules et les lieux de stockage (OSA-CBM, 2006). Il s’agit d’un
standard d’interface, imposant des interfaces entre les modules d’un système de surveillance
suivant une approche CBM, et favorisant l’interopérabilité entre ces modules. Ainsi,
différents fournisseurs peuvent proposer des algorithmes propriétaires sous forme de modules
au standard OSA-CBM. Ce standard permet de dissocier les algorithmes de traitements
encapsulés dans les modules (algorithmes propriétaires) des interfaces génériques des
modules (figure 1.8). CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE
Page 28
Figure 1.8. Exemple de module OSA-CBM, adaptée de (OSA-CBM, 2006).
Les spécifications du standard OSA-CBM sont diffusées sous forme de diagrammes de
classes UML (Unified Modeling Language) et sont indépendantes de la technologie mise en
œuvre pour le développement des modules de traitement. Le concepteur du système de
surveillance doit alors sélectionner une technologie spécifique pour la mise en œuvre des
modules de traitement et définir les communications nécessaires entre ces modules. Le
standard OSA-CBM définit une typologie des échanges possibles entre modules sur la base
des recommandations de la norme ISO 13374 (partie 3 : communication). La figure 1.9 cidessous
illustre les différents types de communications définis par le standard OSA-CBM.
Figure 1.9. Interfaces entre modules, adaptée de (OSA-CBM, 2006). CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE
Page 29
Un module OSA-CBM peut communiquer avec un ou plusieurs modules selon quatre types
d’interface :
· Synchrone (type 1) : ce mécanisme permet un échange direct entre un module
producteur d’informations (serveur) et un module consommateur (client). Un module
consommateur indique à un module producteur les informations qu’il souhaite
recevoir et attend que ces informations soient disponibles et transmises par le module
producteur avant de poursuivre ses traitements.
· Asynchrone (type 2) : ce mécanisme permet à deux modules d’entretenir et de
maintenir une communication bidirectionnelle. Dans ce mode, un module
consommateur souhaitant obtenir des données de la part d’un module producteur
n’attend pas que ces données soient disponibles avant de continuer ses traitements
(dialogue de type requêtes-réponses entre deux modules, par exemple). Par ailleurs, un
module producteur peut transmettre spontanément des informations à un ou plusieurs
modules consommateurs de manière périodique ou événementielle.
· Service (type 3) : ce mécanisme permet une communication unidirectionnelle entre un
ou plusieurs modules producteurs d’informations et un module consommateur. Cette
interface peut être mise en œuvre, par exemple, pour des besoins de stockage
d’informations (archivage des informations par un module consommateur), ou pour la
gestion des requêtes d’intervention de maintenance (transmission des ordres de
maintenance vers un système de maintenance consommateur).
· Souscription (type 4) : ce mécanisme permet à un module consommateur de souscrire
à des informations auprès d’un module producteur. Le module consommateur
souscripteur reçoit alors ces informations de manière asynchrone (régulièrement ou
sur alertes), dès que les informations élaborées par le module producteur sont
disponibles.
Les modules de traitement sont généralement successifs, afin de transformer des données
brutes collectées sur un système sous surveillance en informations pertinentes. Cependant, ces
liens logiques entre modules ne sont pas imposés par le standard OSA-CBM ou la norme ISO
1337. Ainsi, un module peut en principe accéder à n’importe quel autre module lorsque ces
modules partagent un même medium de communication. Le standard OSA-CBM a été
développé sur la base d’un autre standard MIMOSA, décrit selon un même système
d’information relationnel commun (CRIS) : le standard OSA-EAI (Open System Architecture
Enterprise Application Integration). Il s’agit d’un standard visant à faciliter l’échange
d’informations entre différentes applications métiers d’une entreprise, y compris des
informations relatives à la maintenance, au diagnostic et au pronostic (OSA-EAI, 2010).
La norme ISO 13374 étant moins restrictive sur la mise en œuvre des couches fonctionnelles
du modèle que le standard OSA-CBM, elle sera retenue dans la suite de nos travaux. La
section suivante soulève les différentes problématiques liées à la surveillance des systèmes
cibles suivant les spécifications de cette norme. CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE
Page 30
3.2 Problématiques de la surveillance des systèmes cibles considérés
La norme ISO 13374 a été initialement développée pour la surveillance de machines ou
d’équipements industriels isolés (machine tournante, processus d’usinage, par exemple). En
l’absence de standards dédiés à la surveillance des systèmes cibles considérés dans nos
travaux, ce modèle offre une décomposition fonctionnelle générique d’un système de
surveillance. De plus, cette norme constitue un modèle de référence pour la surveillance de
certains systèmes cibles, notamment dans les domaines des transports et de l’industrie
(Gorinevsky et al., 2010 ; Naedele et al., 2004).
Cependant, des difficultés se présentent lorsque ce modèle d’architecture doit être instancié
pour la surveillance d’un système cible. La figure 1.10 ci-dessous illustre les principales
difficultés à appréhender pour la surveillance d’un tel système suivant ce modèle
d’architecture. A partir des six couches fonctionnelles de ce modèle, plusieurs alternatives se
présentent aux concepteurs d’un système de surveillance. Ces couches fonctionnelles peuvent
être réparties selon deux axes :
· répartition “verticale” des couches (1) : les traitements associés aux couches
fonctionnelles ISO 13374 peuvent être réalisés au plus près du système cible
(traitements embarqués) ou être pris en charge par le centre de maintenance
(traitements distants).
· répartition “horizontale” des couches (2) : la surveillance d’un système cible passe
par la surveillance de ses sous-systèmes. Par conséquent, les traitements associés aux
couches fonctionnelles ISO 13374 doivent être déployés suivant les sous-systèmes du
système cible, dont la technologie diffère d’un sous-système à un autre.
Figure 1.10. Surveillance d’un système cible suivant les couches fonctionnelles
ISO 13374. CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE
Page 31
Les sous-sections suivantes précisent les principales contraintes à considérer pour la
surveillance de systèmes cibles. Notons que ces contraintes dépendent des domaines
d’applications des systèmes cibles introduits au début de ce chapitre. Dans ces travaux, le
domaine des transports ferroviaires a été retenu comme cadre applicatif. Par conséquent, la
suite de ce manuscrit se concentre sur la surveillance de systèmes cibles mobiles.
3.2.1 Contraintes liées à la mobilité du système cible
En considérant la répartition “verticale” des couches du modèle, une séparation des couches
doit être établie suivant les traitements à effectuer à bord du système cible et les traitements à
réaliser au centre de maintenance. La première couche du modèle (#1-Data Acquisition) doit
au minimum être implémentée à bord du système cible, pour permettre la collecte des données
et la transmission de ces données au centre de maintenance. Lorsque la quantité de données à
transmettre est importante, il est préférable d’inclure la couche #2 du modèle à bord (Alanen
et al., 2006). Ainsi, plus les couches du modèle résident à bord du système cible, plus les
traitements embarqués sont évolués et permettent de délivrer des informations pertinentes au
centre de maintenance. Cependant, il est nécessaire de tenir compte des performances requises
pour mettre en œuvre les traitements associés aux couches fonctionnelles du modèle
(puissance de calcul disponible à bord, capacités de stockage et de communication, par
exemple).
Dans le but d’optimiser les interventions de maintenance, les données relatives à la
géolocalisation du système cible peuvent également être transmises au centre de maintenance.
De ce fait, le système cible peut être acheminé vers l’atelier de maintenance le plus proche en
fonction de son état de santé (Umiliacchi et al., 2011). Aussi, certains traitements nécessitent
des données fournies par le centre de maintenance (historique des tâches de maintenance,
prévisions d’utilisation du système cible, par exemple). Lorsque ces traitements sont
embarqués, le centre de maintenance doit transmettre ces données au système cible. Une
communication bidirectionnelle entre le système cible mobile et le centre de maintenance est
alors nécessaire.
3.2.2 Contraintes liées aux sous-systèmes du système cible
Suivant les couches à implémenter à bord du système cible, la répartition “horizontale” des
couches concerne l’affectation des modules de traitement aux différents sous-systèmes.
Comme abordé précédemment, un module de traitement peut implémenter les fonctionnalités
de une ou de plusieurs couches du modèle ISO 13374. De ce fait, un module de traitement
peut être affecté à un sous-système, à un groupe de sous-systèmes, ou à l’ensemble des soussystèmes.
Les contraintes associées à la mise en œuvre de ces modules de traitement sont
précisées ci-après.
· Répartition spatiale des sous-systèmes : les sous-systèmes sont généralement
implantés dans différentes zones du système cible et peuvent interagir entre eux
(interactions physiques et/ou informationnelles). L’affectation des modules de
traitement aux sous-systèmes peut alors être orientée suivant l’implantation de ces
sous-systèmes. Aussi, les interactions entre les sous-systèmes sont à considérer lors de
la mise en œuvre des modules de traitements. Par exemple, une défaillance peut
engendrer des dysfonctionnements au niveau de plusieurs sous-systèmes d’un système
cible (Lefebvre et al., 2000). De multiples alarmes peuvent ainsi être générées CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE
Page 32
lorsqu’un module relatif à la couche détection du modèle ISO 13374 (#3-State
Detection) est affecté à chaque sous-système.
· Hétérogénéité technologique des sous-systèmes : les sous-systèmes reposent sur des
technologies différentes. Par conséquent, un sous-système basé sur une certaine
technologie doit être associé à un module de traitement compatible avec cette
technologie. De plus, le modèle ISO 13374 se concentre sur la surveillance de parties
physiques d’un équipement. Cependant, les sous-systèmes considérés sont constitués
de parties physiques et informationnelles. En effet, les défaillances logicielles non
abordées dans la norme ISO 13374 ont un impact direct sur la disponibilité du système
cible. Notons que la surveillance de parties logicielles peut être abordée de la même
manière que la surveillance de parties physiques (Pipatsrisawat et al., 2009).
Néanmoins, les défaillances logicielles se manifestent principalement de manière
soudaine et peuvent difficilement être anticipées.
· Variabilité des sous-systèmes : les sous-systèmes sont conçus par différents
fournisseurs et peuvent varier entre plusieurs systèmes cibles d’une même génération
(changement de fournisseur, obsolescence de composants, ajout de fonctionnalités, par
exemple) (Azarian et al., 2011). La répartition “horizontale” des couches du modèle
doit alors être adaptée aux évolutions des différents sous-systèmes du système cible.
Par exemple, un même sous-système peut présenter des caractéristiques différentes
entre deux systèmes cibles, ou ne pas être implanté sur un autre système cible. Dans ce
cas, une modification doit pouvoir être apportée aux modules de traitement sans
impliquer une refonte de l’architecture de surveillance. Aussi, certains modules de
traitement peuvent être réutilisés pour la surveillance de sous-systèmes ayant les
mêmes caractéristiques.
3.2.4 Contraintes liées à l’environnement du système cible
Lorsque le système cible est immergé dans un environnement, il est soumis à différents
contextes opérationnels (Monnin et al., 2011). L’environnement du système cible peut
potentiellement provoquer des défaillances lors de son fonctionnement. Ces défaillances sont
alors signalées au centre de maintenance par le système de surveillance associé au système
cible. La figure 1.11 ci-après illustre un exemple de système cible mobile situé dans son
environnement. Dans cet exemple, les couches #1 à #3 du modèle ISO 13374 sont
implémentées à bord du système cible et les couches #4 à #6 sont assurées par le centre de
maintenance (répartition “verticale” des couches). La défaillance du système cible est
supposée apparaitre sous l’effet de perturbations provenant de son environnement. Cette
défaillance déclenche alors des alarmes au niveau de la couche #3 du modèle. Ces alarmes
sont par la suite transmises au centre de maintenance et analysées par un opérateur de
maintenance ou traitées par les couches #4 à #6 du modèle lorsqu’elles sont implémentées au
sol. CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE
Page 33
Figure 1.11. Exemple de surveillance d’un système cible mobile dans son environnement.
L’analyse de ces alarmes au sol est délicate pour un opérateur de maintenance. Le contexte
opérationnel du système cible n’étant pas connu, l’opérateur n’est pas en mesure de
déterminer si ces alarmes sont liées à l’environnement du système cible ou si le système cible
nécessite réellement une intervention de maintenance. Ainsi, le diagnostic établi au sol par la
quatrième couche du modèle à partir de ces alarmes risque d’être erroné. En effet, les
informations de contextes non exploitées par la couche diagnostic (#4- Health Assesment)
sont essentielles pour interpréter les dysfonctionnements du système cible. De plus, lorsque le
système cible arrive au centre de maintenance, aucun dysfonctionnement ne peut être
constaté. Le système cible n’opérant plus dans le même contexte opérationnel, il est alors
difficile de reproduire les conditions d’exploitation ayant conduit à une anomalie de
fonctionnement. Ce phénomène nommé NFF (No Fault Found) favorise le remplacement à
tort d’éléments du système cible et engendre des coûts importants de maintenance (Lanigan et
al., 2011).
A titre d’exemple, il peut être judicieux d’associer à une défaillance la localisation précise du
système cible, qui peut être fournie aisément par un dispositif de géolocalisation (Bengston,
2003). Ceci permet d’écarter certaines défaillances liées à l’environnement du système cible.
3.2.5 Exigences d’un système de surveillance
Les principales exigences associées à un système de surveillance peuvent être établies à partir
du modèle d’architecture proposé par la norme ISO 13374. Une exigence fondamentale
concerne la surveillance d’un système cible lors de son fonctionnement (surveillance enligne).
Un système de surveillance ne doit pas altérer la performance du système cible sous
surveillance. Par conséquent, les moyens d’acquisition de données associés à la première
couche du modèle ISO 13374 doivent être non-intrusifs vis-à-vis du système cible sous
surveillance. Dans nos travaux, un système de surveillance doit également répondre aux
exigences suivantes :
· Précision : le système de surveillance doit identifier précisément des éléments
défectueux à remplacer ou à réparer du système cible parmi les différents soussystèmes
qui composent ce système cible. CHAPITRE I : PROBLÉMATIQUE DE LA SURVEILLANCE POUR L’AIDE À LA MAINTENANCE
Page 34
· Facilité d’explication : le système de surveillance doit faciliter la compréhension des
informations de surveillance fournies aux opérateurs de maintenance (présentation de
données brutes ayant conduit à un résultat de diagnostic, par exemple).
· Adaptabilité : le système de surveillance doit être suffisamment modulaire pour faire
face aux changements survenant dans le système cible (remplacement de soussystèmes,
ajout ou suppression de composants, par exemple).
· Réactivité : les informations de surveillance doivent être transmises dans un temps
opportun au centre de maintenance afin d’optimiser les interventions de maintenance
(planification d’une opération de maintenance suivant l’état de certains sous-systèmes
du système cible, par exemple).
· Confiance : le système de surveillance doit être suffisamment robuste pour ne pas
générer de fausses alarmes (diagnostic erroné transmis à un opérateur de maintenance,
par exemple).
4. Conclusion
Ce premier chapitre a permis d’introduire les propriétés des systèmes cibles considérés dans
nos travaux ainsi que les différentes notions relatives à la surveillance dans un contexte de
maintenance. Au sein d’un système de maintenance, la surveillance peut permettre
d’optimiser efficacement les interventions de maintenance préventive et corrective et accroître
ainsi la disponibilité d’un système cible. Un système de surveillance assure deux composantes
principales : percevoir les dysfonctionnements survenant dans un système sous surveillance et
interpréter ces dysfonctionnements. Le diagnostic prend en charge l’interprétation des
dysfonctionnements observés sur le système sous surveillance. Cette fonction essentielle doit
permettre de déterminer les éléments défectueux du système à remplacer ou à réparer qui
seront présentés aux opérateurs de maintenance.
Dans ce chapitre, deux standards complémentaires d’architectures de surveillance ont été
présentés : un modèle proposé par la norme ISO 13374 et une implémentation de référence de
ce modèle nommé OSA-CBM. Ces deux standards décomposent un système de surveillance
en six couches fonctionnelles successives. Le modèle prescrit par la norme ISO 13374 s’avère
plus générique que le standard OSA-CBM et a été retenu dans le cadre de nos travaux.
Cependant, la surveillance d’un système cible suivant ce modèle présente certaines difficultés
exposées à la fin de ce chapitre. En effet, un système cible est constitué de sous-systèmes
hétérogènes et soumis à différents contextes opérationnels. De plus, un système cible mobile
est rattaché à un centre de maintenance distant.
La problématique principale est de concevoir une architecture de surveillance reposant sur la
norme ISO 13374 et répondant aux exigences listées en 3.2.5. Cette architecture doit
permettre de surveiller un système cible mobile qui est lui-même composé de systèmes. Cette
problématique constitue le verrou scientifique auquel nos travaux s’adressent.
Le chapitre suivant se focalise sur la surveillance de systèmes cibles mobiles et recense les
différentes approches de la littérature pour établir le diagnostic d’un tel système suivant la
quatrième couche (Health Assesment) définie par la norme ISO 13374. Page 35
Chapitre II
Surveillance de systèmes mobiles : état de l’art et
approches de surveillance active
Introduction
Le précédent chapitre a mis en évidence un ensemble de problématiques et contraintes à
considérer pour concevoir une architecture de surveillance associée à un système cible. Ce
chapitre explore les différentes approches pour la surveillance de systèmes cibles mobiles
(système de transport aérien, maritime ou ferroviaire, par exemple). Comme évoqué dans le
précédent chapitre, ces systèmes cibles évoluent dans différents contextes opérationnels et
communiquent avec un centre de maintenance distant. La première partie de ce chapitre
présente un état de l’art des architectures de diagnostic et propose une typologie des
architectures pour diagnostiquer un système cible mobile. A partir des exigences d’un système
de surveillance établies dans le précédent chapitre, une architecture de diagnostic sera retenue
dans la suite de nos travaux. La seconde partie de ce chapitre s’appuie sur le concept de
surveillance active pour proposer des approches de modélisation de l’architecture de
diagnostic choisie. Une approche de modélisation sera adoptée et reprise dans le chapitre
suivant afin de proposer une architecture générique pour la surveillance de systèmes cibles
mobiles.
1. Etat de l’art des architectures de diagnostic
La norme ISO 13374 détaillée dans le précédent chapitre définit un modèle générique
d’architecture de surveillance en six couches fonctionnelles successives, dont la quatrième
couche (#4-Health Assesment) élabore le diagnostic à partir de données fournies par les
couches de niveaux inférieurs. Le diagnostic joue un rôle décisif dans la performance d’une
architecture de surveillance, et peut également impacter la sécurité du système cible
(Koutsoukos et al., 2010). En effet, le diagnostic incrimine des éléments potentiellement
responsables d’une défaillance ou d’une dégradation particulière et implique des actions de
maintenance bien précises. De notre point de vue, deux alternatives se dégagent pour réaliser
le diagnostic d’un système cible mobile rattaché à un centre de maintenance distant. La
première consiste à collecter des données brutes sur le système cible et à transférer ces
données vers un centre de maintenance, où le diagnostic est exécuté. Dans cette première
approche, le système cible peut être vu comme un dispositif d’acquisition de données,
générant un flux de données brutes envoyé vers le centre de maintenance. Dans la seconde
approche, le système cible est considéré comme un dispositif de calcul, capable de traiter et
d’interpréter ces données brutes. Le diagnostic réside alors à bord du système cible, et seules
des informations pertinentes de diagnostic sont délivrées au centre de maintenance (Alanen et
al., 2006 ; Bengtson, 2003). CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART
ET APPROCHES DE SURVEILLANCE ACTIVE
Page 36
Ces deux approches, nommées respectivement diagnostic distant et diagnostic embarqué sont
illustrées par la figure 2.1. Lorsque le diagnostic est distant (figure 2.1 a), les couches #1 à #3
du modèle ISO 13374 sont implémentées à bord du système cible, tandis que les couches #4 à
#6 sont prises en charge par le centre de maintenance. Dans une approche de diagnostic
embarqué (figure 2.1 b), les couches #1 à #4 du modèle sont implémentées à bord du système
cible et les couches #5 et #6 sont assurées par le centre de maintenance.
Figure 2.1. Partitionnement du diagnostic : diagnostic distant (a) et diagnostic
embarqué (b).
Suivant cette dichotomie, cette partie recense les principales architectures de diagnostic pour
la surveillance de systèmes cibles mobiles, en faisant abstraction des méthodes de diagnostic
mises en œuvre. Ainsi, une typologie des architectures de diagnostic sera établie
indépendamment des traitements internes réalisés par les couches du modèle ISO 13374.
1.1 Diagnostic distant
Cette approche consiste à réaliser le diagnostic à distance dans un centre de maintenance, à
partir de données collectées et prétraitées à bord du système cible par les couches #1 à #3 du
modèle. Les alarmes et autres signaux brutes du système cible sont alors transférés et analysés
au centre de maintenance. Le diagnostic distant est généralement réalisé de manière centralisé
et doit traiter une masse de données brutes pour rechercher les causes des symptômes détectés
à bord du système cible. Cette architecture, nommée Diagnostic Distant Centralisé (DDC),
permet d’exploiter pleinement les capacités de stockage et de traitement disponibles au centre
de maintenance. Cependant, le diagnostic peut difficilement être établi pendant le
fonctionnement du système cible en raison des contraintes de communication. En effet, des
volumes de données importants doivent être transférés du système cible mobile vers le centre
de maintenance, impliquant des délais de transmission et de traitement. Par conséquent, les
données nécessaires à l’élaboration d’un diagnostic sont généralement stockées à bord du
système cible et transmises de manière périodique ou événementielle au centre de
maintenance (Jianjun et al., 2007). Ces données sont alors enregistrées en-ligne pendant le CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART
ET APPROCHES DE SURVEILLANCE ACTIVE
Page 37
fonctionnement du système et le diagnostic est exécuté hors-ligne à posteriori (approche de
type “boîte noire”).
L’architecture DDC permet également d’assurer le diagnostic de plusieurs systèmes cibles
mobiles (flotte de trains ou de navires, par exemple) (Monnin et al., 2011). D’un point de vue
fiabilité, cette architecture présente un inconvénient majeur. Le diagnostic des différents
systèmes cibles repose sur un seul et unique centre de maintenance. L’occurrence d’une
défaillance en ce point sensible de l’architecture entraine une interruption du diagnostic pour
l’ensemble des systèmes cibles (Ferrari, 2009). Par ailleurs, en examinant les exigences d’un
système de surveillance établies dans le précédent chapitre, l’architecture DDC présente les
limitations suivantes :
· Précision : les données traitées au centre de maintenance représentent essentiellement
des symptômes émis sous forme d’alarmes. L’interprétation de ces événements par
une fonction de diagnostic au sol est parfois erronée (Azarian et al., 2011). Dans
certains domaines applicatifs des systèmes cibles, le diagnostic est couramment
achevé manuellement au sol par un expert à partir des alarmes générées à bord du
système cible (De Ambrosi et al., 2008).
· Réactivité : cette approche implique des quantités de données considérables à
transférer au centre de maintenance, par exemple, par le biais de liaisons sans fil
(technologies GPRS, GSMR ou Wifi) (Schwarzenbach et al., 2010). Ces transferts de
données introduisent des retards non négligeables dans l’élaboration d’un diagnostic,
et par conséquent, dans la planification des opérations de maintenance.
· Confiance : les symptômes détectés à bord du système cible ne sont pas contextualisés.
Ainsi, une alarme peut être déclenchée par l’environnement du système cible ou être
provoquée par des interférences entre certains sous-systèmes (défaillances fugitives,
par exemple). Notons également que certaines données peuvent être superflues
(alarmes redondantes, alarmes liées aux actions du conducteur ou émises lors des
interventions de maintenance, par exemple) (Sammouri et al., 2012). Ces données sont
néanmoins transmises et archivées au centre de maintenance, engendrant des coûts
injustifiés de transmission et de stockage. Ainsi, le contexte opérationnel du système
cible n’est pas considéré lors de l’élaboration d’un diagnostic sur la base de ces
alarmes.
Néanmoins, cette architecture est relativement simple à mettre en œuvre et permet à des
systèmes d’informations externes d’exploiter aisément les données collectées.
Plusieurs implémentations de l’architecture DDC ont été réalisées dans le domaine des
transports. Par exemple, la première génération de systèmes HUMS (Health and Usage
Monitoring System), apparue au début des années 90, était limitée à la collecte de données et à
la génération d’alarmes sur certains aéronefs (Wiig, 2006). Les principaux inconvénients de
ce système résident dans la génération de fausses alarmes et dans l’interprétation de ces
masses de données brutes au centre de maintenance. Dans le domaine ferroviaire, le projet
Européen TrainCom a contribué à standardiser les échanges de données entre un matériel
roulant ferroviaire et un centre de maintenance distant (Gatti, 2002). La communication entre
le véhicule ferroviaire et un centre de maintenance au sol (ROGS : Railway Open Ground
Station) est assurée par une interface de communication nommée ROGate (Railway Open
Gateway). Ces spécifications ont permis à différentes applications situées au centre de
maintenance de traiter les données collectées à bord des trains. Cette infrastructure de CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART
ET APPROCHES DE SURVEILLANCE ACTIVE
Page 38
communication a été expérimentée en Europe dans le cadre du projet EuRoMain (European
Railway Open Maintenance System) (Euromain, 2002). Le principal objectif de ce projet était
de définir un système d’aide à la maintenance de véhicules ferroviaires en réalisant le
diagnostic à distance des différents équipements embarqués.
Actuellement, les deux principaux constructeurs mondiaux de matériels ferroviaires ont
adopté une architecture DDC. Les systèmes Orbita (Orbita, 2006) et TrainTracer
(TrainTracer, 2006) développés respectivement par Bombardier-Transport et AlstomTransport
permettent de prélever des données en temps réel sur des véhicules ferroviaires et
de les transférer vers un système central (figure 2.2).
Figure 2.2. Architecture du système TrainTracer, adaptée de (Sammouri et al., 2012).
Les données relatives aux différents équipements implantés à bord des véhicules (accès
voyageurs, climatisations, tractions, par exemple) sont transmises et stockées
systématiquement sur un serveur de données (figure 2.2). Ces données brutes (états et alarmes
des différents équipements embarqués, par exemple) sont exploitées par le personnel de
maintenance ou traitées par différentes applications (extraction de données, analyse de
tendances, diagnostic, par exemple). Ces applications sont développées par les constructeurs
ou les exploitants de matériels ferroviaires.
1.2 Diagnostic embarqué
Lorsque la quatrième couche du modèle ISO 13374 (#4-Health Assesment) est intégrée au
sein du système cible, le diagnostic est embarqué. Cette approche vise à exécuter le diagnostic
pendant le fonctionnement du système cible et offre plus d’autonomie et de réactivité.
Contrairement à une architecture DDC, les données brutes sont converties en informations de CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART
ET APPROCHES DE SURVEILLANCE ACTIVE
Page 39
diagnostic à bord du système cible (figure 2.3). Les délais et coûts de transmission sont alors
réduits car seules des informations pertinentes émanent du système cible. De plus, le
diagnostic embarqué permet d’exploiter des informations contextuelles disponibles à bord du
système cible. Ces informations complémentaires contribuent largement à améliorer la
performance du diagnostic embarqué (Byington et al., 2003).
Figure 2.3. Exemple de diagnostic embarqué, adaptée de (Hunter et al., 2013).
Le diagnostic d’un système cible repose sur le diagnostic des différents sous-systèmes qui le
composent (Kurien et al., 2002). Une première approche permettant de réaliser le diagnostic à
bord d’un tel système consiste à déployer une couche de diagnostic sur l’ensemble des soussystèmes.
Ainsi, une entité centrale de diagnostic interprète les données relatives aux
différents sous-systèmes et délivre un diagnostic global du système cible. Une seconde
approche envisage de fractionner la couche de diagnostic en autant d’entités de diagnostic
qu’il existe de sous-systèmes. Dans cette approche, une entité de diagnostic est affectée à
chaque sous-système du système cible. Le diagnostic global du système cible est alors obtenu
à partir des résultats produits par les entités locales de diagnostic. Inspiré des approches de la
littérature pour diagnostiquer des systèmes répartis, nous proposons de distinguer trois classes
d’architectures pour réaliser le diagnostic embarqué de systèmes cibles (figure 2.4). Le
diagnostic peut être centralisé, décentralisé ou réparti (également nommé distribué :
distributed diagnosis) (Fabre, 2007 ; Ferrari, 2009 ; Roychoudhury et al., 2009 ;
Subias, 2006). Notons que le diagnostic décentralisé ou réparti est généralement associé à une
méthode de diagnostic particulière dans la littérature (Genc et Lafortune, 2003 ; Pencolé et
Cordier, 2005). CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART
ET APPROCHES DE SURVEILLANCE ACTIVE
Page 40
Figure 2.4. Diagnostic centralisé (a), décentralisé (b) et distribué (c), adaptée de
(Ferrari, 2009).
Dans la première classe d’architecture, nommée Diagnostic Embarqué Centralisé (DEC), une
seule entité de diagnostic est implémentée à bord du système cible et réalise le diagnostic des
différents sous-systèmes. Dans une architecture de Diagnostic Embarqué Décentralisé (DED),
une entité de diagnostic est implémentée pour chaque sous-système. Ces entités réalisent le
diagnostic de manière indépendante et ne peuvent communiquer entre elles. Lorsque le
diagnostic est distribué, chaque sous-système est également associé à une entité de diagnostic,
mais ces entités peuvent communiquer entre elles. Le terme distribué fait généralement
référence au medium de communication utilisé pour interconnecter ces entités de diagnostic.
Dans les travaux présentés dans ce manuscrit, cette troisième classe d’architecture est
nommée Diagnostic Embarqué Décentralisé et Coopératif (DEDC), afin de dissocier
l’organisation de ces entités de diagnostic des solutions technologiques utilisées pour mettre
en œuvre ce type d’architecture. Les sous-sections suivantes précisent ces trois catégories
d’architectures.
1.1.1 Diagnostic embarqué centralisé
Le diagnostic embarqué d’un système cible est généralement réalisé par une entité centrale de
diagnostic, en charge de traiter les données brutes des différents sous-systèmes (Dievart et al.,
2010). L’architecture DEC suppose qu’une seule entité de diagnostic puisse intégrer une
connaissance de l’ensemble des sous-systèmes et établir le diagnostic global du système cible
(Kurien et al., 2002). Aussi, cette entité doit être capable d’absorber et de traiter de grandes
quantités de données à bord du système cible. Cette architecture peut s’avérer irréaliste pour
un système cible constitué de multiples sous-systèmes. En effet, les données relatives aux
sous-systèmes doivent être centralisées en un même point à bord du système cible pour être
analysées. Le système cible doit alors disposer de ressources suffisantes pour supporter ces
flux de données et réaliser les traitements nécessaires (volume de données important à traiter
en un temps donné, par exemple). Par ailleurs, cette architecture présente des limitations en
termes de fiabilité et de modularité. Par exemple, l’ajout d’un sous-système entraine
systématiquement une modification des traitements réalisés par cette entité centrale de
diagnostic.
Un exemple d’implémentation d’une architecture DEC dans le domaine des transports aériens
est le système de maintenance centralisé (CMS : Central Maintenance System). Dans cette
architecture, une unité centrale effectue des traitements à partir de symptômes et autres
données brutes pour élaborer un diagnostic (Balin et Stankunas, 2013). Ce système permet
d’identifier les causes des anomalies de fonctionnement et élabore des recommandations pour CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART
ET APPROCHES DE SURVEILLANCE ACTIVE
Page 41
le personnel de bord. Les résultats du diagnostic sont archivés et peuvent également être
consultés par des techniciens de maintenance.
Néanmoins, ce système central doit être suffisamment performant (puissance de calcul et
taille mémoire notamment) pour fournir des informations dans des délais acceptables
(situation d’urgence, par exemple).
1.1.2 Diagnostic embarqué décentralisé
L’architecture DED favorise le traitement des données au plus près des sous-systèmes à
diagnostiquer. Dans cette architecture, chaque sous-système est diagnostiqué localement par
une entité de diagnostic. Les résultats des diagnostics délivrés par ces différentes entités sont
généralement transmis de manière disjointe au centre de maintenance. Le diagnostic global du
système cible peut être envisagé de plusieurs manières. Il peut être considéré, par exemple,
comme une juxtaposition des résultats des diagnostics locaux (Biteus, 2004). De ce fait, le
diagnostic global correspond aux diagnostics des différentes parties du système cible, ce qui
permet de présenter des informations plus compréhensibles aux opérateurs de maintenance.
Aussi, le diagnostic global peut résulter d’une fusion des résultats de diagnostic locaux. Dans
ce cas, une ou plusieurs entités supplémentaires sont chargées de collecter les résultats des
diagnostics locaux et de les fusionner. Cependant, les entités de diagnostic opèrent de manière
indépendante et exploitent uniquement les observations limitées de leurs sous-systèmes. En
d’autres termes, ces entités de diagnostic ne communiquent pas entre elles (Qiu et Kumar,
2004). Par conséquent, une entité de diagnostic n’est pas en mesure de considérer les
interactions entre les sous-systèmes lors de l’élaboration d’un diagnostic (Ferrari, 2009).
Ainsi, une entité peut émettre un diagnostic erroné lorsque le sous-système auquel elle est
associée est influencé par d’autres sous-systèmes.
Cette catégorie d’architecture a notamment été expérimentée pour réaliser le diagnostic à bord
de véhicules routiers. Par exemple, dans (Nasri et al., 2012) les auteurs proposent une
architecture DED limitée au diagnostic d’une fonction sécuritaire d’un véhicule. Cette
architecture met en œuvre différentes entités locales de diagnostic (diagnostiqueurs) qui
intègrent une méthode de diagnostic spécifique, et dont les résultats de diagnostic sont
communiqués à une entité supérieure nommée coordinateur. Ce coordinateur est implémenté
à bord du véhicule et délivre un diagnostic final en fusionnant les résultats des diagnostics
locaux à partir de règles. Les entités de diagnostic mises en œuvre sont intégrées aux
équipements embarqués existants faisant l’objet d’un diagnostic (unités de contrôle des soussystèmes
du véhicule). Les informations contextuelles relatives aux différents sous-systèmes
diagnostiqués ne sont pas considérées par ces entités de diagnostic. Les résultats évoqués par
les auteurs concernent l’influence des entités de diagnostic sur la fiabilité de l’architecture
global du système et ne précisent pas réellement la performance du diagnostic obtenu.
1.1.3 Diagnostic embarqué décentralisé et coopératif
Dans cette catégorie d’architecture, les entités de diagnostic sont agencées de la même
manière que dans une architecture DED, c’est-à-dire, une entité de diagnostic est affectée à
chaque sous-système du système cible. A la différence d’une architecture DED, ces entités
opèrent de manière proactive et peuvent dialoguer entre elles (Zhang et Zhang, 2013). Par
exemple, une entité de diagnostic peut coopérer avec d’autres entités. Elle obtient ainsi des
informations complémentaires pour enrichir ses observations locales et fournir un diagnostic
plus robuste. Ces informations concernent, par exemple, les états et contextes d’autres sous-CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART
ET APPROCHES DE SURVEILLANCE ACTIVE
Page 42
systèmes (symptômes ou modes de fonctionnement de sous-systèmes évoluant dans le même
environnement, par exemple). L’architecture DEDC permet d’établir un diagnostic global du
système cible suivant un schéma de communication défini entre les différentes entités de
diagnostic (Provan, 2002). Les échanges entre ces entités sont généralement calqués sur les
interactions existantes entre les différents sous-systèmes diagnostiqués (interactions physiques
et informationnelles, par exemple) (Fabre, 2007). Les communications entre entités limitent le
nombre de fausses alarmes transmises aux opérateurs de maintenance. Néanmoins, cette
architecture implique des flux d’informations supplémentaires à bord du système cible par
rapport aux architectures DEC et DED. Cette contrainte est compensée par un allégement des
capacités de calcul requises pour réaliser le diagnostic, et par une augmentation de la fiabilité
et de la modularité de l’architecture (Ferrari, 2009). Par ailleurs, cette approche est adaptée à
l’architecture des systèmes cibles, dans laquelle les sous-systèmes interagissent entre eux et
présentent un dispositif de calcul local (unité de contrôle disposant de processeurs et de
mémoires, par exemple) (Roychoudhury et al., 2009).
Les architectures DEDC développées pour la surveillance de systèmes mobiles sont
relativement peu nombreuses. Par exemple, une architecture de type DEDC est proposée dans
(Dievart et al., 2010) pour la surveillance d’un système de transport. Cette architecture est
basée sur des entités de diagnostic reliées à une base de données commune et pouvant
s’échanger des informations par le biais d’une mémoire partagée (tableau noir). Certaines
entités sont autorisées à communiquer directement entre elles. Cependant, une méthode de
diagnostic spécifique est exécutée par les différentes entités qui composent cette architecture.
Par ailleurs, les informations contextuelles des sous-systèmes surveillés ne sont pas
considérées pour améliorer la performance du diagnostic.
Plus récemment, certaines architectures DEDC ont été développées dans le cadre du
programme IVHM (Integrated Vehicle Health Management), introduit à l’origine dans les
secteurs aéronautique et spatial (Benedettini et al., 2009). Ce concept vise à accroitre la
sécurité et la fiabilité de certains systèmes de transports (avions de ligne, véhicules aériens,
par exemple) et à optimiser leurs coûts de maintenance, en implémentant à leur bord des
fonctions avancées de diagnostic et de pronostic (Ferreiro et al., 2012 ; Schoeller et al., 2007).
Avec la création d’un centre de Recherche en collaboration avec différents industriels
(IVHM-Center, 2008), la communauté IVHM contribue activement à l’élaboration de
nouveaux standards (SAE-HM1, 2013). Cette communauté s’appuie notamment sur la norme
ISO 13374 pour concevoir et mettre en œuvre des modules de surveillance embarqués. Par
exemple, le projet VIPR (Vehicle Integrated Prognostic Reasoner) a permis de définir un
modèle d’architecture pour la surveillance de véhicules aérospatiaux (Bharadwaj et al., 2013).
L’architecture VIPR combine différentes entités interagissant entre elles pour établir un
diagnostic global d’un véhicule. Ces entités nommées HM (Health Manager) adhérent à la
structure du véhicule à diagnostiquer et sont réparties suivant trois niveaux hiérarchiques
(niveau équipement, niveau régional et niveau véhicule) (figure 2.5). Au niveau hiérarchique
le plus bas, chaque entité élabore des informations locales de diagnostic et de pronostic (DP)
relatives à un équipement (LRU HM). Ces informations sont ensuite confiées aux entités de
niveau supérieur (Area HM), capables d’analyser ces résultats en considérant les différentes
régions du véhicule (implantation géographique des équipements, interdépendances entre
équipements, par exemple). Enfin, les conclusions établies par ces entités sont exploitées par
une entité située au niveau supérieur (Vehicle HM) chargée de délivrer un diagnostic final du
véhicule. CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART
ET APPROCHES DE SURVEILLANCE ACTIVE
Page 43
Figure 2.5. Architecture VIPR, adaptée de (Cornhill et al., 2013).
Cette architecture permet d’établir un diagnostic performant au niveau véhicule, dont le taux
de fausses alarmes est faible (Cornhill et al., 2013). Néanmoins, ces entités sont généralement
associées à des technologies spécifiques. De plus, le contexte opérationnel associé aux
équipements n’est pas exploité par les entités qui composent cette architecture (informations
relatives aux organes de contrôle des sous-systèmes, par exemple).
1.3 Typologie des architectures de diagnostic
A partir des architectures exposées précédemment, une typologie des architectures de
diagnostic peut être articulée autour de trois axes.
· Le premier axe concerne l’implantation du diagnostic vis-à-vis du système cible à
diagnostiquer. Par exemple, le diagnostic peut être exécuté à bord du système cible, à
proximité du système cible (outil de diagnostic portatif, par exemple), ou être réalisé à
distance dans un centre de maintenance (Alanen et al., 2006).
· Le deuxième axe précise la distribution de la couche diagnostic en fonction des
différents sous-systèmes à diagnostiquer. Ainsi, une entité de diagnostic peut être
affectée à l’ensemble des sous-systèmes (diagnostic centralisé), ou à chaque soussystème
du système cible (diagnostic décentralisé). Il est également possible d’affecter
plusieurs entités de diagnostic à un même sous-système. Certains auteurs mentionnent
alors une distribution spatiale ou sémantique du diagnostic (Fröhlich et al., 1999 ;
Roos et al., 2003). La distribution spatiale fait référence à une répartition
géographique des entités de diagnostic, où chaque entité est affectée à une certaine
partie du système cible et prend en charge le diagnostic de cette partie. Une partie peut
correspondre, par exemple, à un sous-système ou à un regroupement de plusieurs
sous-systèmes. Dans une distribution sémantique du diagnostic, des entités de
diagnostic hétérogènes sont affectées à une même partie du système cible et réalisent CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART
ET APPROCHES DE SURVEILLANCE ACTIVE
Page 44
conjointement le diagnostic de cette partie. Une entité de diagnostic peut être focalisée
sur certains aspects de cette partie ou être spécialisée dans la résolution de certains
types de problèmes (analyse de défaillances particulières, par exemple).
· Le troisième axe de cette typologie détermine l’organisation des entités de diagnostic
au niveau social. Suivant la structure organisationnelle des entités de diagnostic, une
entité peut être autorisée ou non à coopérer avec d’autres entités. Par exemple, une
entité peut interagir avec l’ensemble des entités ou avec un nombre restreint d’entités
(Atlas et al., 2001).
La figure 2.6 ci-dessous illustre la typologie proposée et positionne les différentes classes
d’architectures définies auparavant. Le deuxième et le troisième axe concernent uniquement
les architectures permettant de réaliser le diagnostic à bord de systèmes cibles. En effet, les
architectures implémentant le diagnostic à distance impliquent des délais significatifs dans
l’analyse des données et dans l’exécution des opérations de maintenance (temps de
transmission, de stockage et de traitement des données collectées). Par exemple, l’architecture
RCD souffre d’un manque de robustesse et de précision (taux de fausses alarmes important,
informations de diagnostic erronées, non pertinentes ou non contextualisées). Par conséquent,
les architectures pour lesquelles le diagnostic est exécuté à distance ne seront pas retenues
dans la suite de nos travaux.
Figure 2.6. Positionnement des architectures de diagnostic suivant la typologie proposée.
Parmi les architectures de diagnostic embarqué, l’architecture DEDC s’avère être une
approche pertinente pour élaborer le diagnostic de systèmes cibles mobiles. Cette architecture
permet d’établir un diagnostic global du système cible à partir des informations délivrées par
différentes entités de diagnostic implantées à bord du système cible et pouvant interagir entre CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART
ET APPROCHES DE SURVEILLANCE ACTIVE
Page 45
elles. En considérant les exigences d’un système de surveillance établies dans le précédent
chapitre, cette architecture présente les avantages suivants :
· Précision : les données brutes sont traitées au plus près des équipements surveillés, ce
qui permet de garantir la qualité des observations et par conséquent la précision du
diagnostic.
· Adaptabilité : les changements survenant dans un sous-système du système cible
(modification, ajout ou suppression de composants, par exemple) impactent
uniquement l’entité de diagnostic qui lui est associée.
· Réactivité : les délais d’interventions de maintenance sont réduits car le système cible
est capable de transmettre des informations de diagnostic directement exploitables par
les services de maintenance en ciblant des actions de maintenance précises.
· Confiance : les informations contextuelles disponibles à bord du système cible peuvent
être exploitées par les différentes entités de diagnostic. De plus, ces entités sont
capables de communiquer entre elles pour obtenir davantage d’informations sur leur
environnement et limiter ainsi le nombre de fausses alarmes.
Ces travaux se positionnent dans cette dernière catégorie d’architecture. Dans la suite de ce
manuscrit, une architecture de type DEDC est retenue pour la surveillance de systèmes cibles
mobiles. La partie suivante propose des approches permettant de modéliser les entités qui
composent cette architecture en s’appuyant sur le concept de surveillance active.
2. Approches de surveillance active
L’architecture DEDC retenue précédemment requiert la définition de différentes entités en
interaction dont l’objectif est de réaliser le diagnostic à bord d’un système cible. Ainsi, cette
approche implique une augmentation des capacités informationnelles, décisionnelles et
communicationnelles des sous-systèmes à diagnostiquer. Dans ce cadre, les travaux de
Recherche menés au sein de notre équipe sur le développement de produits “actifs” ont
permis de faire émerger la notion d’activité associée à un produit tout au long de son cycle de
vie (Sallez, 2012). Cette notion d’activité s’oppose au caractère passif d’un produit classique,
contraint de subir les interventions d’un système de soutien externe (système de distribution
ou de maintenance, par exemple) et n’ayant pas la capacité de prendre des initiatives vis-à-vis
de ce système. L’activité associée à un système cible (ou produit) est supportée par un
système d’augmentation. Ce dernier réalise un ensemble de fonctions d’augmentation au plus
près du système cible et lui confère, au minimum, la capacité de déclencher un événement.
Cette faculté permet au système cible devenu “actif” d’exprimer un besoin en émettant un
signal (demande d’une intervention ou d’un service particulier, par exemple). Bien entendu,
cette activité minimale peut être complétée par d’autres activités plus complexes
(mémorisation, apprentissage, coopération entre produits actifs, par exemple). Le concept
d’augmentation consiste à associer un système d’augmentation à un produit passif lui
permettant d’être “actif” pendant une ou plusieurs phases de son cycle de vie (phase de
fabrication, de distribution et d’usage, par exemple) (Sallez et al., 2010).
Cette partie décrit le concept de surveillance active reposant sur le concept d’augmentation et
suggère des approches permettant de modéliser l’activité associée à un système cible.CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART
ET APPROCHES DE SURVEILLANCE ACTIVE
Page 46
2.1 Concept de surveillance active
La surveillance active est une application du concept d’augmentation en phase d’usage qui
consiste à doter un système cible de capacités d’auto-surveillance (Sallez et al., 2011). Ce
concept implique une augmentation des sous-systèmes du système cible par des fonctions de
surveillance. Ces fonctions sont supportées par différents systèmes d’augmentations situés au
plus près des sous-systèmes surveillés. Le système cible constitué de sous-systèmes “actif” est
donc lui-même “actif”. Ce système cible “actif” peut alors délivrer des informations de
surveillance de manière spontanée pendant son exploitation (état de santé, résultats de
diagnostic, par exemple). Dans une perspective d’évolution du système cible (développement
de nouvelles fonctionnalités, par exemple), les fonctions de surveillance supportées par un
système d’augmentation pourront être prises en charge de façon native par le système cible.
Dans l’architecture DEDC retenue dans nos travaux, chaque sous-système réalise les couches
fonctionnelles #1 à #4 du modèle ISO 13374. Un système d’augmentation peut alors être
défini pour supporter les fonctionnalités associées à ces couches et élaborer le diagnostic d’un
sous-système (figure 2.7). Ce système d’augmentation présente des capacités décisionnelles et
interactionnelles lui permettant de dialoguer avec d’autres systèmes d’augmentation et de
transmettre des informations de diagnostic à un centre de maintenance.
Figure 2.7. Exemple de surveillance active basée sur le concept d’augmentation.
Le concept de surveillance active est particulièrement adapté pour aborder la surveillance
d’un système cible mobile suivant une architecture de type DEDC. En effet, chaque sous
système du système cible peut être associé à une entité de surveillance “active” autonome,
capable d’interagir avec d’autres entités. Inspiré des modèles d’architectures de systèmes de
pilotage manufacturiers (Trentesaux, 2009), les sections suivantes présentent les principales
approches permettant de modéliser ces entités de surveillance “actives” : l’approche multiagents
et l’approche holonique.CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART
ET APPROCHES DE SURVEILLANCE ACTIVE
Page 47
2.2 Approche multi-agents
L’intelligence artificielle distribuée (IAD), axe de l’intelligence artificielle (IA), s’intéresse
aux domaines pour lesquels une seule entité est inadaptée ou inefficace pour résoudre certains
types de problèmes. Cette communauté a introduit le concept de systèmes constitués d’entités
autonomes ayant la capacité d’agir sur leur environnement et de communiquer avec d’autres
entités pour atteindre un objectif donné. Un système constitué de ces entités ou agents est
nommé Système Multi-Agents (SMA).
2.2.1 Notion d’agent
De nombreuses définitions du terme agent sont apparues depuis l’émergence des systèmes
multi-agents. En effet, cette notion est utilisée dans de nombreux domaines (Tweedale et al.,
2007). Bien qu’aucune définition précise ne soit acceptée, nous pouvons citer les deux
définitions suivantes couramment rencontrées dans la littérature.
· Un agent est un système informatique, situé dans un environnement, et qui agit d'une
façon autonome et flexible pour atteindre les objectifs (buts) pour lesquels il a été conçu
(Wooldrige et Jennings, 1995).
· Un agent est une entité autonome, réelle ou abstraite, qui est capable d’agir sur ellemême
et sur son environnement, qui, dans un univers multi-agents, peut communiquer
avec d’autres agents, et dont le comportement est la conséquence de ses observations, de
ses connaissances et des interactions avec les autres agents (Ferber, 1995).
Les agents sont décrits dans un système et diffèrent donc d’un système à un autre. La plupart
des typologies d’agents établies dans la littérature sont axées sur le degré de raisonnement des
agents. Un agent peut être vu comme un processus permettant de lier ses perceptions à ses
actions. Une classification usuelle dissocie deux catégories d’agents définies ci-après : les
agents réactifs et les agents cognitifs (Demazeau et Briot, 2001).
· Agents réactifs : ces agents sont des entités très simples, n’ayant quasiment pas de
capacité de raisonnement et ne disposant pas de mémoire. Ils perçoivent leur
environnement mais n’ont pas la capacité de le représenter symboliquement. Leurs
capacités limitées répondent uniquement à des stimuli provenant de l’environnement.
Les actions d’un agent sont directement liées à ses perceptions par une fonction
reflexe (stimulation-exécution). Par conséquent, les agents réactifs adoptent des
mécanismes de communication restreints. L’interaction entre ces agents et
l’environnement fait émerger une organisation cohérente et intelligente au niveau d’un
système d’agents. Ces agents sont qualifiés d’intelligents au niveau d’un groupe
d’agents réactifs (Müller, 2000).
· Agents cognitifs : ces agents, au contraire, plus complexes, possèdent des capacités de
raisonnement individuelles et une base de connaissance. Ces agents ont la capacité de
percevoir et de constituer une représentation explicite de leur environnement (Ferber,
1995). Un agent cognitif peut être amené à raisonner suivant ses perceptions passées,
ses interactions avec d’autres agents, ses actions antérieurement initiées, pour planifier
au mieux ses actions futures. Ils ont potentiellement la capacité d’apprendre et de
reconnaître certaines situations. Un agent cognitif adopte un langage de CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART
ET APPROCHES DE SURVEILLANCE ACTIVE
Page 48
communication plus élaboré (mécanismes d’envois de messages et requêtes, par
exemple). Dans une organisation d’agents cognitifs, les agents accomplissent leur
propre but en cherchant à optimiser leur utilité au sein du collectif d’agents. Jusqu’à
présent, cette approche a donné lieu aux travaux les plus avancés.
Les agents réactifs et cognitifs sont généralement décrits comme deux entités antagonistes.
Cependant, certains agents hybrides peuvent posséder des propriétés réactives et cognitives. A
titre d’exemple, un agent hybride peut mener un raisonnement à l’aide de ses connaissances et
présenter certaines aptitudes à réagir aux évènements.
2.2.2 Architectures à base d’agents
Un agent a généralement pour vocation d’agir au sein d’une organisation d’agents. Un
système multi-agents (SMA) est un ensemble d’agents qui évoluent dans un même
environnement. Un SMA peut être constitué, par exemple, d’agents purement réactifs,
cognitifs ou hybrides. Dans une approche “voyelle” (Demazeau, 2001), on distingue quatre
dimensions permettant d’élaborer un système multi-agents : l’Agent, l’Environnement,
l’Interaction et l’Organisation (AEIO). L’organisation décrit les relations entre les agents du
système suivant un modèle organisationnel (modèles bio-inspirés, par exemple). Dans un
SMA, la communication est primordiale pour assurer les différentes interactions entre agents.
Elle peut être assimilée à une forme d’action locale, par exemple, d’un agent vers un autre
agent, ou d’un agent vers plusieurs agents (diffusion de messages au sein d’un groupe
d’agents, par exemple).
Figure 2.8. Exemple de SMA appliqué à la surveillance de systèmes, adaptée de
(Ferber, 1995).
CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART
ET APPROCHES DE SURVEILLANCE ACTIVE
Page 49
L’architecture interne d’un agent, c’est à dire, la décomposition modulaire utilisée pour relier
les perceptions d’un agent à ses actions permet également de différencier les systèmes multiagents.
Les types d’architectures les plus connues sont les architectures suivantes (Grondin,
2008) :
· l’architecture horizontale monocouche : l’agent est constitué d’un seul module ayant
accès à la perception et à l’action (figure 2.9a),
· l’architecture horizontale avec plusieurs couches : l’agent est constitué de plusieurs
modules où chaque module a accès simultanément à la perception et à l’action
(figure 2.9b),
· l’architecture verticale modulaire : l’agent est constitué de plusieurs modules, dont le
premier accède à la perception et le dernier module accède à l’action (figure 2.9c),
· l’architecture verticale en couches : l’agent est constitué de plusieurs modules dont
un seul module peut accéder à la perception et à l’action (figure 2.9d).
Figure 2.9. Exemples d’architectures internes d’un agent, adaptée de (Müller et al., 1995).
Les architectures horizontales sont majoritairement employées pour le développement
d’agents réactifs, comme l’architecture de subsumption (Brooks, 1986), tandis que des
architectures verticales sont plutôt associées à des agents cognitifs, telle que l’architecture
BDI (Belief Desire Intention) (Rao et Georgeff, 1995). Un agent hybride peut présenter une
architecture verticale ou horizontale. Par exemple, l’architecture InteRRaP est une
architecture verticale modulaire d’agents hybrides qui comporte plusieurs couches
fonctionnelles (Müller et al., 1995). L’approche multi-agents a notamment été exploitée pour
la surveillance de systèmes répartis dans (Albert et al., 2001 ; Mangina et al., 2001 ; Naedele
et al., 2004).
2.3 Approche holonique
Les systèmes holoniques ont été introduits par le philosophe hongrois Arthur Koestler
(Koestler, 1967). Ces systèmes sont basés sur le concept de “holon”, terme formé par le
préfixe grec Holos (le tout) et du suffixe on qui suggère une particule élémentaire ou partie
d’un tout. Une propriété importante de ces systèmes est la récursivité des entités mises en
œuvre nommées holons. L’approche holonique peut s’appliquer à de nombreux systèmes, qui
peuvent être naturels (systèmes biologiques) ou artificiels (systèmes conçus par l’homme). CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART
ET APPROCHES DE SURVEILLANCE ACTIVE
Page 50
2.3.1 Concept de holon
Un holon est décrit comme une entité autonome faisant partie d’un tout qui présente un
caractère individuel et coopératif pour atteindre un objectif donné (Koestler, 1967). Le
concept de holon repose sur la notion de récursivité (Suaréz et al., 2013). Un holon peut être
vu comme une partie constitutive d’un holon de niveau supérieur, et comme un tout, composé
lui-même de holons de niveaux inférieurs. Cette dualité associée au holon est appelée effet
Janus par Koestler, en référence au nom de la divinité romaine regardant dans deux directions
opposées. Ainsi, les deux principales propriétés d’un un holon sont l’autonomie et la
coopération. La première confère au holon une identité propre d’un ensemble autonome et
cohérent. La seconde représente l’aspect social d’un holon, contribuant partiellement au
fonctionnement global du système suivant des mécanismes de coopérations avec d’autres
holons.
2.3.2 Architectures holoniques
Un système de holons qui peuvent coopérer pour atteindre un but ou un objectif donné est
nommé holarchie. Comme l’illustre la figure 2.10, une holarchie est formée par des holons
récursifs organisés de manière hiérarchisée. Naturellement, un holon peut être composé
d’autres holons, être lui-même considéré comme une holarchie et également appartenir à une
holarchie plus vaste. Dans une holarchie, un holon peut interagir avec d’autres holons situés
au niveau inférieur ou supérieur (interactions “verticales”) et avec des holons situés au même
niveau que lui (interactions “horizontales” représentées sur la figure 2.10) dans un espace de
coopération.
Figure 2.10. Exemple de système de holons ou holarchie, adaptée de (Gaud, 2007).
L’holarchie définit les règles de base pour la coopération entre holons et de ce fait limite leur
autonomie (Tanaya et al., 1997). Les conflits résultants d’une coopération entre holons au sein
d’un même espace de coopération peuvent être résolus par un holon de niveau supérieur. Ce
holon émet alors une décision à partir des observations de ses holons subordonnés. CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART
ET APPROCHES DE SURVEILLANCE ACTIVE
Page 51
L’approche holonique a notamment été appliquée au pilotage de systèmes manufacturiers
dans le cadre du projet HMS (Holonic Manufacturing System) entrepris par la communauté
internationale IMS (Intelligent Manufacturing System) (IMS, 2013). Dans ce domaine,
l’approche holonique a permis de concevoir de nouveaux modèles d’architectures, reposant
sur une décentralisation des capacités de traitement et de décision à travers des entités
autonomes et communicantes (Blanc et al., 2008 ; Deen, 2003). Les travaux importants
proposés par cette communauté représentent une rupture avec les architectures centralisées de
pilotage de systèmes manufacturiers et se proposent de répondre aux nouveaux besoins et
contraintes des industriels (flexibilité, personnalisation de masse des produits, traçabilité des
produits, par exemple) (Pujo et al., 2009).
Un HMS est une holarchie dans laquelle les holons sont autonomes, coopératifs et
entretiennent des liens de subordinations avec des holons hiérarchiquement supérieurs
(commandes, instructions, par exemple). Suivant les modèles d’architectures holoniques
proposés (ou holarchies), différents types de holons ont été définis pour désigner des entités
d’un système manufacturier. Les architectures PROSA (Van Brussel et al., 1998) et
ADACOR (Leitão et Restivo, 2006) proposent par exemple d’associer des holons aux
machines de production (holon ressource, holon machine), aux produits manufacturés (holon
produit), aux opérations à effectuer (holon ordre, holon tâche), ou encore aux tâches de
supervision (holon staff, holon supervision). La figure 2.11 présente une architecture
générique de holon adoptée par cette communauté. Dans ce modèle, un holon comporte une
partie “traitement de l’information” et une partie “traitement physique” (optionnelle). La
partie “traitement de l’information” est subdivisée en trois modules : une interface de
communication nécessaire pour interagir avec les autres holons (interface inter-holons), une
intelligence décisionnelle pour élaborer un raisonnement interne et disposer d’une certaine
autonomie (centre de décision), et une interface pour interagir avec des opérateurs humains
(interface homme-holon).
Figure 2.11. Architecture interne d’un holon, adaptée de (Bussman, 1998).
La partie “traitement physique” se compose d’un module de commande (contrôle physique) et
d’un module opérant (traitement physique). Cette partie est décrite comme facultative, dans la
mesure où un holon peut être constitué uniquement d’une partie “traitement de l’information”.CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART
ET APPROCHES DE SURVEILLANCE ACTIVE
Page 52
2.4 Comparaison des approches
Les communautés holoniques et agents convergent vers des spécifications communes, car ces
deux approches reposent sur les mêmes principes fondamentaux d’autonomie et de
coopération en explorant la distribution et la décentralisation des entités et des fonctions
(Leitão, 2004). Un holon possède des propriétés similaires à celles d’un agent, mais se
distingue de par sa récursivité (Giret et Botti, 2004). En effet, dans la plupart des modèles
d’agents, un agent est considéré comme une entité atomique (Gaud, 2007). Néanmoins,
certaines approches considèrent que des agents peuvent se regrouper pour former un agent de
niveau supérieur. Suivant ce concept, un système multi-agents holonique (holomas) est un
SMA ayant une structure récursive. Les agents d’un certain niveau sont regroupés en
organisations qui sont considérées comme des entités individuelles à un niveau supérieur. La
communauté agent s’intéresse aux comportements des entités qui composent un SMA (agent
réactif ou cognitif, par exemple) et au comportement global émergent d’un SMA. Dans une
approche holonique, un holon est récursif et associé à une partie matérielle (tangible), qui
n’est pas abordée dans les modèles d’agents. L’approche holonique est donc complémentaire
à l’approche multi-agents. D’un point de vue conceptuel, le holon est un concept et l’agent est
à la fois un concept et une technologie associée. Un modèle à base d’agents est approprié pour
implémenter la modularité et la décentralisation des structures holoniques (Leitão, 2004 ;
Marík et al., 2002). Ainsi, la technologie agent peut fournir les outils nécessaires pour mettre
en œuvre les traitements informationnels associés aux holons tout comme les mécanismes
d’interactions entre ces entités.
Dans le cadre de nos travaux, une approche à base d’agents peut être exploitée pour modéliser
les entités de surveillance de l’architecture DEDC. Comme l’illustre l’exemple présenté sur la
figure 2.12, une entité de surveillance “active” peut être décrite par un agent. Sur ce même
exemple, en considérant une approche holonique, un holon permet de considérer à la fois la
partie physique surveillée d’un système cible et l’entité de surveillance “active” qui lui est
associée. Cette seconde approche permet également de décrire la récursivité du système cible.
Figure 2.12. Périmètres de modélisation considérés dans le cadre de notre étude.
Une approche holonique est retenue dans la suite de nos travaux pour modéliser les soussystèmes
surveillés d’un système cible mobile suivant une architecture DEDC. Cette approche
qui considère les aspects matériels et immatériels des systèmes a notamment été expérimentée
pour la surveillance de systèmes naturels (Louati et al., 2012 ; Unland, 2003) et artificiels
(Jarvis et Jarvis, 2003 ; McFarlane et al., 1995 ; Silva et al., 2012 ; Stecca et al., 2013). CHAPITRE II : SURVEILLANCE DE SYSTÈMES MOBILES : ÉTAT DE L’ART
ET APPROCHES DE SURVEILLANCE ACTIVE
Page 53
3. Conclusion
Ce chapitre a dressé tout d’abord un état de l’art des architectures de diagnostic pour la
surveillance de systèmes cibles mobiles. La surveillance d’un tel système nécessite une prise
en charge de fonctions de surveillance par le système cible mobile et par un centre de
maintenance distant. La première partie de ce chapitre a défini quatre classes d’architectures
de diagnostic et a proposé une typologie des architectures de diagnostic. Afin de répondre aux
exigences exprimées dans le précédent chapitre, une architecture de diagnostic dans laquelle
le diagnostic est embarqué et réalisé de manière décentralisée et coopérative a été retenue
pour la surveillance de systèmes cibles mobiles (architecture DEDC). Dans la littérature, les
applications relatives à ce type d’architecture sont généralement spécifiques à une méthode de
diagnostic et manquent de généricité. Par ailleurs, les informations contextuelles disponibles à
bord d’un système cible ne sont pas suffisamment valorisées et considérées pour améliorer la
performance du diagnostic embarqué. En s’appuyant sur le concept de surveillance active, la
seconde partie de ce chapitre a présenté deux approches pertinentes pour modéliser les entités
qui composent cette architecture : les systèmes multi-agents et les systèmes holoniques. Une
étude comparative de ces deux approches a favorisée l’adoption d’une approche holonique
pour la surveillance de système cibles mobiles.
Le chapitre suivant propose une architecture générique de surveillance “active” de type
DEDC reposant sur une approche holonique. Cette architecture représente la composante
surveillance d’un système de maintenance associé à un système cible. Page 54
Chapitre III
Proposition d’une architecture holonique pour la
surveillance active de systèmes cibles mobiles
Introduction
Dans le précédent chapitre, une étude comparative des architectures de diagnostic pour la
surveillance de systèmes cibles mobiles a été présentée. Cette analyse a permis de retenir une
catégorie d’architecture dans laquelle le diagnostic est implanté à bord du système cible et
élaboré de manière décentralisée et coopérative (architecture DEDC).
Ce chapitre est consacré à la proposition d’une architecture de type DEDC pour la
surveillance de systèmes cibles mobiles. L’approche proposée s’appuie sur le concept de
surveillance active décrit dans le précédent chapitre en adoptant une approche holonique.
Dans ce chapitre, une architecture de surveillance active basée sur des entités de surveillance
autonomes et coopératives est proposée. La première partie de ce chapitre présente tout
d’abord une approche de modélisation d’un système cible à surveiller. Ce modèle permettra
de caractériser les entités de surveillance qui lui sont associées et de proposer par la suite
notre architecture holonique de surveillance. La deuxième partie se concentre sur la structure
interne des entités qui composent cette architecture holonique de surveillance. Elle détaille
notamment les fonctionnalités supportées par ces entités.
1. Système de surveillance holonique
L’adoption d’une architecture de type DEDC pour la surveillance de systèmes cibles mobiles
nécessite une identification des sous-systèmes à surveiller qui composent un système cible.
Un partitionnement du système cible en sous-systèmes est alors nécessaire avant de définir les
entités de surveillance qui concourent à l’élaboration d’un diagnostic. Cette décomposition
peut être abordée par une approche analytique, qui consiste à décomposer un problème en
différents sous-problèmes indépendants. Cependant, cette approche connait certaines
limitations, notamment en raison du niveau de complexité croissant des systèmes actuels et à
la manière dont ces systèmes sont conçus (Fabre, 2007).
Une approche complémentaire, se focalisant non seulement sur une analyse séparée des soussystèmes
d’un système cible, mais considérant également un système cible dans son ensemble
s’avère nécessaire. L’approche systémique adoptée au début de ce manuscrit (cf. chapitre I,
section 1.1) peut ainsi remédier aux difficultés de compréhension d’un système cible. Elle
permet de conserver une vision globale d’un système cible, constitué de sous-systèmes en
interaction, eux-mêmes considérés comme des systèmes. CHAPITRE III : PROPOSITION D’UNE ARCHITECTURE HOLONIQUE POUR LA SURVEILLANCE ACTIVE
DE SYSTÈMES CIBLES MOBILES
Page 55
Dans cette partie, la décomposition d’un système cibles en sous-systèmes est abordée en
adoptant une approche systémique. Après un rappel des principaux concepts de la systémique,
la section 1.1 présente un modèle de système cible à surveiller basé sur cette approche. La
section 1.2 spécifie les entités de surveillance associées à ce modèle suivant une approche
holonique. La section 1.3 propose notre architecture holonique de surveillance basée sur ces
entités de surveillance.
1.1 Approche de modélisation du système cible à surveiller
La systémique a pour objet l’étude et la compréhension de systèmes dont l’analyse par une
approche analytique s’avère difficile ou impossible, et vise à établir une représentation du
système étudié par le biais de modèles qualitatifs (Donnadieu et al., 2003). Elle s’appuie
notamment sur les interactions entre les éléments constituant un système pour en comprendre
son comportement global. Ces liens portent aussi bien sur de simples relations de causes à
effets que sur des échanges d’informations, de flux de matière ou d’énergie. Ces interactions
s’opèrent à des niveaux hiérarchiques différents, formant plusieurs niveaux organisationnels
structurés de manière hiérarchisée. La systémique met en œuvre trois points de vue
nécessaires à l’analyse et à la représentation d’un système (c.f. annexe A). Cette triangulation
systémique regroupe les visions fonctionnelle, organique et historique du système étudié dans
le but d’approfondir sa compréhension (Le Moigne, 1994). Outre ces différents axes
d’analyse d’un système, la démarche systémique préconise une identification des soussystèmes
(sous-ensembles ou composants) d’un système, afin de mettre en évidence les
relations que ces entités entretiennent entre elles et leurs rôles au sein d’un système.
Contrairement à une approche analytique, ces entités ne coïncident pas nécessairement avec
des composants élémentaires d’un système tangible à analyser. Aussi, cette décomposition
soulève la question du partitionnement d’un système en sous-systèmes défini par le
modélisateur. Bien que subjectif, l’établissement de frontières (ou périmètres) des soussystèmes
peut être dicté par certains critères, notamment à partir des différents points de vue
d’un système abordés précédemment. La dimension fonctionnelle, s’intéressant aux fonctions
assurées par le système, et la dimension organique, basée sur la structure des éléments
constituant le système et leurs répétitivités, sont deux exemples de critères permettant de
décomposer un système cible.
La systémique proposant un cadre méthodologique d’analyse et de conception de systèmes
cibles, conformément à un fonctionnement désiré ou à une finalité du système, elle peut
également être exploitée pour comprendre les dysfonctionnements survenant dans de tels
systèmes (Belhadaoui, 2011). Cette section propose une modélisation d’un système cible
basée sur une approche systémique. Ce modèle de système cible à surveiller servira par la
suite de socle à l’élaboration d’une architecture de surveillance.
Le modèle proposé repose sur les hypothèses établies dans le premier chapitre et plus
précisément :
· décomposition : le système cible à surveiller est supposé être organisé suivant une
structure hiérarchisée de contrôle et décomposable structurellement en un ensemble
fini de sous-systèmes. Le partitionnement du système cible en sous-systèmes est
supposé être établi sans chevauchements entre les frontières des sous-systèmes.
Chaque sous-système est supposé être contrôlé par un système de niveau supérieur,
· hétérogénéité technologique : le système cible et ses sous-systèmes sont supposés être
conçus avec des technologies hétérogènes. Néanmoins, le système cible comme
chaque sous-système présente une structure interne identique. Il se compose d’une
partie contrôle (partie décisionnelle) et d’une partie sous-contrôle (partie opérante), CHAPITRE III : PROPOSITION D’UNE ARCHITECTURE HOLONIQUE POUR LA SURVEILLANCE ACTIVE
DE SYSTÈMES CIBLES MOBILES
Page 56
· environnement : les parties contrôle et sous-contrôle sont supposées interagir dans un
environnement spécifique. Un contexte opérationnel de nature physique (température,
champ électrique, par exemple) ou informationnelle (mode de fonctionnement,
identifiant de l’utilisateur du système, par exemple) est supposé être une propriété
intrinsèque du système cible comme de chaque sous-système constituant ce système.
La figure 3.1 présente un modèle organique du système cible considéré. Ce modèle est inspiré
de l’architecture de systèmes constitués d’une partie contrôle et d’une partie sous-contrôle
(Isermann, 2008). En accord avec nos hypothèses, ce modèle présente les propriétés
suivantes :
· une partie contrôle : entité de traitement de l’information et de commande, en charge
d’assurer un comportement cohérent de la partie sous-contrôle, conformément aux
spécifications fonctionnelles imposées par le concepteur,
· une partie sous-contrôle : ensemble d’éléments soumis aux commandes de la partie
contrôle, comprenant notamment des éléments matériels (capteurs, transducteurs, par
exemple) ou informationnels (estimateurs, observateurs logiciels, par exemple)
rendant compte de l’état de cette partie,
· des signaux de commandes (U) : ensemble d’ordres délivrés par la partie contrôle dans
le but de commander la partie sous-contrôle,
· des signaux de mesures (Y) : ensemble de signaux fournis par des dispositifs de la
partie sous-contrôle et exploités par la partie contrôle pour l’élaboration des signaux
de commandes,
· un contexte opérationnel (C) : ensemble d’informations relatif à l’environnement du
système et/ou au système lui-même caractérisant une situation de fonctionnement.
Figure 3.1. Modèle organique du système cible considéré.
Le système cible à surveiller, représenté suivant une vision systémique et noté Σ sur la figure
3.1, comporte deux parties en interaction opérant dans un contexte opérationnel. Ce modèle
organique correspond à une vue globale du système cible considéré, au plus haut niveau de sa
structure hiérarchique. De par ses propriétés récursives, ce système englobe un ensemble fini
de sous-systèmes de niveaux inférieurs ayant une structure interne identique. Les soussystèmes
sont organisés en niveaux et contrôlés par un système de niveau supérieur. Dans le
modèle proposé, chaque système est caractérisé par la position qu’il occupe dans la
composition d’un système plus vaste. Par la suite, le sous-système ݆ du système Σ
sera noté
ΣȀ, et le ݇
ème sous-système du sous-système ΣȀ sera noté ΣȀȀ. La figure 3.2 ci-dessous
propose un modèle organique arborescent du système cible représenté sur la figure 3.1.
Suivant ce modèle, le système global, noté Σ
sur la figure 3.2, est décomposé en une
succession de sous-systèmes situés à différents niveaux. Chaque sous-système est décomposé
en sous-systèmes de niveau inférieur, eux-mêmes décomposés en sous-systèmes. CHAPITRE III : PROPOSITION D’UNE ARCHITECTURE HOLONIQUE POUR LA SURVEILLANCE ACTIVE
DE SYSTÈMES CIBLES MOBILES
Page 57
Par exemple sur la figure 3.2, le système Σ
de niveau n est décomposé en trois sous-systèmes
(ΣȀ, ΣȀឬ et ΣȀ̶) de niveau n-1, et le sous-système ΣȀ est lui-même décomposé en deux
sous-systèmes de niveau n-2 (ΣȀȀ et ΣȀȀឬ). Le sous-système ΣȀȀឬ est décomposé de
nouveau en sous-systèmes élémentaires de niveau inférieur (ΣȀȀឬȀ et ΣȀȀឬȀឬ).
Figure 3.2. Modèle organique arborescent du système cible considéré.
Comme évoqué précédemment chaque système est immergé dans un contexte opérationnel.
Le contexte du système Σ
et de son sous-système ΣȀ seront par la suite notés
respectivement
et Ȁ . Une propriété importante de l’approche systémique proposée est
l’agrégation des informations de contexte entre les différents sous-systèmes constituant un
système cible. En effet, le contexte opérationnel d’un sous-système caractérise la situation de
fonctionnement de ce sous-système et également de ses sous-systèmes de niveaux inférieurs.
Par ailleurs, les sous-systèmes sont soumis à un même contexte relatif au niveau hiérarchique
le plus élevé. Par exemple, sur le modèle de la figure 3.2, les sous-systèmes ΣȀȀឬȀ et
ΣȀȀឬȀឬ opèrent tous deux dans le contexte ȀȀឬ , relatif au sous-système ΣȀȀឬ , et
également dans Ȁ , contexte commun aux sous-systèmes ΣȀȀ et ΣȀȀឬ . Les différents
sous-systèmes du système Σsont soumis au même contexte
.
La structure hiérarchisée de contrôle du système cible considéré implique nécessairement des
interactions “verticales” de nature informationnelle entre les différents niveaux de
décomposition du système cible (relations d’autorités entre un sous-système et son soussystème
de niveau inférieur, par exemple). De plus, des interactions “horizontales” de nature
informationnelle et physique sont envisageables au sein d’un même niveau (échanges
d’informations ou influences physiques entre sous-systèmes, par exemple).
Simulations num´eriques m´eso- et micro-´echelles des
circulations locales g´en´er´ees par des ˆıles tropicales : cas
de l’archipel de la Guadeloupe avec une application `a la
dispersion de polluants (WRF-LES-FLEXPART)
Rapha¨el C´ec´e
To cite this version:
Rapha¨el C´ec´e. Simulations num´eriques m´eso- et micro-´echelles des circulations locales g´en´er´ees
par des ˆıles tropicales : cas de l’archipel de la Guadeloupe avec une application `a la dispersion
de polluants (WRF-LES-FLEXPART). Meteorology. Universit´e des Antilles et de la Guyane,
2014. French.
HAL Id: tel-01074600
https://hal.archives-ouvertes.fr/tel-01074600
Submitted on 14 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.Universite des Antilles et de la Guyane ´
THESE `
En vue de l’obtention du grade de
DOCTEUR DE L’UNIVERSITE DES ANTILLES ´
ET DE LA GUYANE
Ecole doctorale pluridisciplinaire ´
Sp´ecialit´e : Physique de l’atmosph`ere
Pr´esent´ee et soutenue par
Rapha¨el C´ec´e
le 10 juillet 2014
Simulations num´eriques m´eso- et
micro-´echelles des circulations locales
g´en´er´ees par des ˆıles tropicales : cas de
l’archipel de la Guadeloupe avec une
application `a la dispersion de polluants
(WRF-LES-FLEXPART)
Composition du jury :
Herv´e Delbarre (Pr, LPCA, Universit´e du Littoral) Pr´esident
Evelyne Richard (Directeur de recherche, LA, CNRS Toulouse) Rapporteur ´
Blaise Nsom (Pr, LBMS, Universit´e de Bretagne Occidentale) Rapporteur
Narcisse Zahibo (Pr, LaRGE, Universit´e des Antilles et de la Guyane) Directeur
Didier Bernard (MCF, LaRGE, Universit´e des Antilles et de la Guyane) Co-encadrant
Jean-Fran¸cois Dorville (Dr, Lecturer, Universit´e des West Indies, Jama¨ıque) Co-encadrant
Philippe Palany (Ing´enieur, Direction Interr´egionale de M´et´eo-France) Invit´e”Les philosophes n’ont fait qu’interpr´eter le monde de diff´erentes mani`eres, ce qui importe
c’est de le transformer.“
Karl Marx, Th`eses sur Feuerbach (1845)UNIVERSITE DES ANTILLES ET DE LA GUYANE ´
R´esum´e
Facult´e des Sciences Exactes et Naturelles
D´epartement de Physique
Docteur de l’Universit´e des Antilles et de la Guyane
Simulations num´eriques m´eso- et micro-´echelles des circulations locales
g´en´er´ees par des ˆıles tropicales : cas de l’archipel de la Guadeloupe avec une
application `a la dispersion de polluants (WRF-LES-FLEXPART)
par Rapha¨el C´ec´e
Ce travail est l’expression d’une volont´e de chercheurs, de la Cara¨ıbe d’am´eliorer les
connaissances scientifiques m´eso- et micro-m´et´eorologiques appliqu´ees aux milieux insulaires
sous influence des aliz´es et de d´evelopper la recherche dans ces domaines.
On sait que le ph´enom`ene m´et´eorologique le plus remarquable impactant les ˆıles de la
Cara¨ıbe reste le cyclone tropical. Mais d’autres ph´enom`enes, `a des ´echelles inf´erieures,
telles que les pluies intenses, les houles, la d´egradation de la qualit´e de l’air ont une importance
aig¨ue en termes de risques naturels ou de risques sur la sant´e. Ces exemples
attestent la n´ecessit´e d’utiliser des m´ethodes de descente d’´echelle pour exploiter l’information
m´et´eorologique et/ou climatique de grande ´echelle et d´eriver des sc´enarios locaux
et r´egionaux appliqu´es aux territoires insulaires. Ce d´efi est important car l’attente d’analyses
scientifiques pertinentes dans ces domaines est grande.
Les travaux pr´esent´es dans ce m´emoire ont pour principaux objectifs la simulation num´erique
puis l’analyse des m´ecanismes m´eso- et micro-´echelles qui induisent des circulations
locales diurnes et nocturnes sur l’archipel de la Guadeloupe `a l’aide de codes
num´eriques m´et´eorologiques ´eprouv´es car largement utilis´es en recherche et en pr´evision
op´erationnelle.
Ils constituent donc la premi`ere ´etude de mod´elisation num´erique `a haute r´esolution en
basse atmosph`ere, par descente d’´echelle dynamique, pour des intervalles d’espace compris
entre 1 km et 111 m sur cet archipel.
Le mod`ele atmosph´erique Weather Research and Forecasting ARW V3.4 (WRF ARW),
non-hydrostatique, a ´et´e utilis´e pour l’ensemble des simulations pour mod´eliser la troposph`ere
depuis l’´echelle globale `a l’´echelle de la turbulence.Trois situations m´et´eorologiques classiques r´eelles d’une dur´ee de 48 heures, correspondant
`a 80 % des situations m´et´eorologiques observ´ees dans la zone, aliz´es soutenus (AS), aliz´es
moyens (AM), aliz´es faibles (AF) ont ´et´e examin´ees. Ces situations sont caract´eris´ees par
les valeurs du nombre de Froude local suivantes : 0,82 (AS), 0,41 (AM) et 0,21 (AF). Six
domaines de mod´elisation ont ´et´e s´electionn´es pour effectuer les descentes d’´echelle dynamiques
: D01 (maille de 27 km), D02 (maille de 9 km), D03 (maille de 3 km), D04 (maille
de 1 km), D05 (maille de 333 m) et D06 (maille de 111 m) avec soixante-dix niveaux
verticaux. Les quatre premiers domaines (D01 `a D04) couvrent l’archipel de la Guadeloupe
et sont utilis´es en mode m´eso-´echelle `a l’aide d’un sch´ema d’ensemble de couche
limite plan´etaire YSU. Les domaines D05 (couvrant l’ˆıle de la Basse-Terre et le centre de
l’archipel) et D06 (couvrant la zone littorale et rurale du Petit Cul-de-Sac Marin et la
zone urbaine de l’agglom´eration pointoise) sont utilis´es en mode Large Eddy Simulation
avec une fermeture de la turbulence 1,5 TKE 3D. Le mod`ele WRF a ´et´e forc´e toutes
les six heures par l’assimilation des champs d’analyses globales du mod`ele NCEP FNL
(1➦ de r´esolution). Les simulations effectu´ees ont permis d’obtenir des champs de variables
m´et´eorologiques 10-minutes `a tr`es hautes r´esolutions spatiales.
Les r´esultats des simulations m´eso- et micro-´echelles ont ´et´e confront´es aux valeurs exp´erimentales
obtenues `a l’aide de capteurs plac´es sur des mˆats m´et´eorologiques (campagne
Atmo-Mangrov et r´eseau de mesure M´et´eo-France). Il s’agissait d’optimiser l’utilisation
des couplages de codes num´eriques tout en conservant la possibilit´e de les confronter aux
observations exp´erimentales.
Les r´esultats des simulations num´eriques micro-´echelles, des diff´erents cas (AS, AM, AF)
sont utilis´ees pour forcer (c’est-`a-dire d´efinir les conditions limites) un mod`ele lagrangien
de dispersion de particules : FLEXPART. Le syst`eme coupl´e FLEXPART-WRF a ´et´e employ´e
dans le domaine D06 pour ´etudier la dispersion du panache d’oxydes d’azote ´emis
par la principale usine de production d’´electricit´e de l’ˆıle.
La concordance entre les s´eries spatio-temporelles simulation/exp´erimental a ´et´e qualifi´ee `a
l’aide d’outils statistiques de comparaison (MAE, MBE, IOA). Ces estimateurs montrent
que pour les champs m´et´eorologiques classiques, il y a une bonne ad´equation entre les
mesures exp´erimentales et les simulations obtenues aux fines ´echelles. Les simulations
retrouvent le comportement du vent et les principales circulations observ´ees exp´erimentalement.
L’´etude des effets des conditions aux limites, particuli`erement le changement de
carte d’occupation des sols, am´eliore sensiblement les r´esultats.
En aliz´es faibles, les coupes verticales pointant l’´energie cin´etique turbulente, la temp´erature
virtuelle et la masse volumique t´emoignent de l’existence d’un ´ecoulement catabatique.
Il se caract´erise par un front bien d´efini amenant des vents maximums situ´es dansles premiers niveaux en arri`ere de la surface frontale et des tourbillons verticaux en aval de
l’´ecoulement. Cette circulation d’ouest prend naissance, en fin d’apr`es-midi, sur les reliefs
de la Soufri`ere, descend les pentes au vent de l’ˆıle de la Basse-Terre et passe sur la zone
littorale d’Arnouville 2 `a 3 h apr`es son initiation.
Pendant la nuit, ce front oscille horizontalement sur la surface maritime du Petit Cul-deSac
Marin en s’accroissant verticalement. En effet, le front s’´etant r´echauff´e en passant
au-dessus de la surface maritime, sa propagation est frein´ee sur l’ˆıle de la Grande-Terre,
au sol fortement refroidi par le rayonnement infra-rouge.
Les simulations micro-´echelles ont ´et´e utiles pour caract´eriser l’aptitude de cet ´ecoulement
catabatique nocturne `a se propager en aval, d’Arnouville vers la r´egion pointoise, et
pr´eciser sa capacit´e `a d´egrader la qualit´e de l’air dans la zone urbaine. Les pics de concentration
de NOx simul´ees surviennent aux mˆemes p´eriodes que les observations exp´erimentales
mais sont surestim´ees et d´ecal´es temporellement d’une heure.
Des surestimations des vitesses de vent ont ´et´e observ´ees en condition nocturne. Ces
impr´ecisions sont dues au manque de r´ealisme des conditions limites (occupation des sols,
topographie, temp´erature de surface de la mer) et pourront ˆetre am´elior´ees dans le futur.
Les estimateurs statistiques ont montr´e une bonne ad´equation entre les mesures exp´erimentales,
les comparaisons graphiques (en s´eries temporelles et profils de concentration)
ont quant `a elles permis de mieux caract´eriser la dynamique des concentrations de polluants
et leurs possibles interactions avec les circulations locales.
Ces r´esultats num´eriques laissent envisager de nombreuses applications dans les domaines
de la pr´evention de risques environnementaux, dans l’aide `a la caract´erisation des ressources
d’´energie renouvelables solaire, ´eolienne voire houlo-motrice. Ils peuvent ˆetre
ais´ement transposables aux autres ˆıles des petites Antilles.Abstract
Meso-scale and micro-scale numerical simulations of local circulations
induced by tropical islands : Case of the Guadeloupe archipelago with a
pollutant dispersion case (WRF-LES-FLEXPART)
by Rapha¨el C´ec´e
The present work expresses the will of Caribbean researchers to improve the meso- and
micro-meteorological scientific knowledge of the trade winds influenced island areas, and
to develop research in these domains.
It is well known that tropical hurricanes remain the most remarkable meteorological phenomena
that affect the Caribbean islands. But some other phenomena, of smaller scale,
such as intense rainfall events, swells, or air quality degradation, are of extreme importance
for natural or health hazards. These examples show the need to use downscaling
methods to exploit large scale meteorological or climatic information, and to obtain local
and regional scenarios for the island areas. This is an important challenge, as sound scientific
studies in these matters are eagerly expected. The aim of the research works exposed
in the present dissertation is numerical simulation and analysis of the meso- and microscale
mechanisms that induce diurnal and nocturnal local circulations in the Guadeloupe
archipelago, using numerical meteorological models that are widely used in research and
in operational forecasting.
These works represent the first high-resolution (1 km to 111 m) numerical study of the
lower atmosphere over the Guadeloupe archipelago.
The Weather Research and Forecasting ARW 3.4 (WRF-ARW) model is used to simulate
the troposphere from global scale to turbulence scale. Real cases of three typical weather
types (80% of cases during a year) are examined during 48 hours : strong trade winds
(STW), medium trade winds (MTW) and weak trade winds (WTW). These weather types
are characterized by values of the local Froude number : 0.82 (STW), 0.41 (MTW) and
0.21 (WTW). Six domains have been selected for the dynamical downscaling : D01 (grid
spacing of 27 km), D02 (grid spacing of 9 km), D03 (grid spacing of 3 km), D04 (grid spacing
of 1 km), D05 (grid spacing of 333 m) and D06 (grid spacing of 111 m), including 70
vertical levels. The first four domains (D01 to D04) cover the Guadeloupe archipelago and
are used in the meso-scale simulations with the planetary boundary layer scheme YSU
(ensemble mean). Domain D05 (covering the Basse-Terre island and the middle of the
archipelago) and domain D06 (covering the coastal and rural area of Le Petit Cul-de-Sac
Marin and the urban area of Pointe-`a-Pitre), are employed in the micro-scale simulation(LES) with the 3D TKE 1.5 order closure scheme. WRF has been 6 hourly reinitialized
with the NCEP FNL global analyses (resolution of 1➦). These simulations permitted to
obtain 10-minutes meteorological variable fields with a very high resolution (111 m).
Meso-scale and micro-scale model results have been evaluated with observational data
from meteorological stations (field campaign Atmo-Mangrov, French Met Office).
Once validated, the micro-scale model outputs have been used for the assimilation of the
lagrangian particle dispersion model : FLEXPART. The coupling FLEXPART-WRF has
been employed in domain D06, in order to analyze the dispersion of the nitrogen oxide
plume emitted by the main power plant of the archipelago.
Agreements between model/observations time series have been evaluated with error statistical
tools (MAE, MBE, IOA).
The error statistical tools show that simulated typical meteorological variables have a
good agreement with observational data. The model simulates well wind patterns and local
circulations observed at the stations. The use of accurate land cover data significantly
improves the results.
During the weak trade winds, vertical cross sections of the turbulent kinetic energy, virtual
temperature and density indicate the occurrence of a katabatic flow with a well defined
front. This westerly circulation starts at the end of the afternoon in the area of the volcano
of La Soufri`ere. The katabatic flow extends to the windward coast of the Basse-Terre
island and reaches the coastal area of Arnouville 2 to 3 hours after its onset time. During
the night, the katabatic front oscillates over the marine area of Le Petit Cul-de-Sac Marin.
Due to its warming over the marine area, the front cannot extend on the Grande-Terre
colder land surface.
The micro-scale simulations permitted to study the ability of this gravity flow to extend
to the urban area of Pointe-`a-Pitre, and its ability to induce pollution events in this area.
The simulated and the observed NOx concentration peaks occur nearly at the same time,
but the model overestimates them, with a one hour lag.
Overestimations of the wind speeds have been observed at nighttime. These inaccuracies
are linked with the lack of realism of the boundary conditions (land cover, topography,
sea surface temperature). These biases will be corrected in the future.
The error statistical tools showed a good agreement with observational data. The graphical
evaluations (time series, concentration vertical profiles) allowed a better understanding
of the pollution dispersions under local circulations.
These numerical results can be useful in many fields : to prevent environmental risks, to
help characterizing renewable energy sources such as solar, wind or wave energy. They
can be easily transferred to other islands of the Lesser Antilles.Remerciements
Je remercie le professeur Narcisse Zahibo, directeur du laboratoire LaRGE (Laboratoire
de Recherche en G´eosciences et Energies), mon directeur de th`ese, de m’avoir fait con- ´
fiance pour ce projet.
Je remercie chaleureusement Didier Bernard, maˆıtre de conf´erences `a l’Universit´e des
Antilles de la Guyane, mon encadrant, qui a suivi mon travail et qui m’a soutenu avec un
grand d´evouement et beaucoup d’efficacit´e, y compris lorsqu’il a dˆu traverser des moments
difficiles.
Je remercie particuli`erement Jean-Fran¸cois Dorville, lecturer `a l’Universit´e des West Indies,
qui m’a fait d´ecouvrir le monde de la recherche lorsque j’´etais en master, et qui
malgr´e l’´eloignement s’est toujours rendu disponible pour m’aider dans ces pr´esents travaux.
J’exprime mes remerciements `a Jacques Laminie, Rapha¨el Pasquier et Patrick Siarras,
du Centre Commun de Calcul Intensif (C3I) de l’Universit´e des Antilles et de la Guyane,
qui m’ont aid´e `a installer le mod`ele num´erique WRF sur les calculateurs Orca et Wahoo
de l’Universit´e.
De mˆeme, je remercie Richard Emilion, professeur `a l’Universit´e d’Orl´eans, qui m’a permis ´
d’avoir acc`es au calculateur Phoebus du Centre de Calcul Scientifique en r´egion Centre
(CCSC) de l’Universit´e d’Orl´eans, ainsi que Laurent Catherine qui m’a aid´e `a utiliser
efficacement ce calculateur.
Philippe Palany, de M´et´eo-France, m’a donn´e acc`es aux donn´ees m´et´eorologiques d’observation
qui m’ont permis d’´evaluer mes r´esultats. Qu’il en soit remerci´e.
Je tiens aussi `a remercier les jeunes chercheurs de mon laboratoire, Ma¨ına Andr´e, St´ephanie
Monjoly, Christophe D’Alexis, Vanessa Clotaire, Christelle Dixit, Fr´ed´eric Dondin, Sandrine
Samot et sp´ecialement Thomas Plocoste, grˆace `a qui j’ai b´en´efici´e d’une ambiance
de travail stimulante et sympathique.
Mes remerciements s’adressent aussi `a mes coll`egues de l’Universit´e - et particuli`erement
Andr´e Roussas - qui m’ont aid´e `a affronter des conditions de travail parfois difficiles, ainsiqu’`a Dani`ele Frison pour son aide `a la r´edaction en anglais.
Je dois finalement remercier de nombreuses personnes qui ont contribu´e, mˆeme directement,
`a ce travail.
Tout d’abord mes parents, Pierre-Robert et Marie-Claude C´ec´e, qui m’ont aid´e et encourag´e
`a poursuivre mes ´etudes universitaires jusqu’au doctorat, ainsi que ma soeur,
Mellissa C´ec´e qui m’a soutenu malgr´e la distance.
Ensuite mes camarades de Combat Ouvrier et du journal Rebelle ! avec lesquels je milite
pour construire un monde meilleur, et sp´ecialement Ren´e Cuillierier qui m’a transmis son
enthousiasme r´evolutionnaire.
Et enfin ma compagne, Delphine Prudhomme, pour son ind´efectible soutien et son importante
contribution `a ces travaux.Table des Mati`eres
Citation i
R´esum´e ii
Abstract v
Remerciements vii
Table des Mati`eres ix
Liste des Figures xiv
Liste des Tableaux xx
Liste des Abr´eviations xxi
Introduction 1
1 Circulations atmosph´eriques dans les basses couches et leurs effets :
´etude bibliographique 6
1.1 Echelles des circulations atmosph´eriques ´ . . . . . . . . . . . . . . . . . . . 6
1.2 M´eso-´echelle et micro-´echelle : circulations locales de couche limite atmosph´erique
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.1 Couche limite atmosph´erique (CLA) . . . . . . . . . . . . . . . . . 8
1.2.1.1 D´efinition . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.2.1.2 Structure de la CLA associ´ee au cycle diurne . . . . . . . 8
Couche de m´elange . . . . . . . . . . . . . . . . . . . . . . . 9
Couche r´esiduelle . . . . . . . . . . . . . . . . . . . . . . . . 9
Couche limite stable . . . . . . . . . . . . . . . . . . . . . . 10
1.2.1.3 Vent moyen, ondes et turbulence . . . . . . . . . . . . . . 10
1.2.2 Circulations locales g´en´er´ees par les conditions de terrain . . . . . . 11
1.2.2.1 R´egions cˆoti`eres : brises de mer–terre . . . . . . . . . . . . 11
Brises de mer . . . . . . . . . . . . . . . . . . . . . . . . . . 11
Brises de terre . . . . . . . . . . . . . . . . . . . . . . . . . . 11
ixTable des Mati`eres x
1.2.2.2 R´egions orographiques : vents anabatiques–catabatiques . 12
Vents anabatiques . . . . . . . . . . . . . . . . . . . . . . . . 12
Vents catabatiques . . . . . . . . . . . . . . . . . . . . . . . 12
1.3 Simulations num´eriques de la descente dynamique de la m´eso-´echelle `a la
micro-´echelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.3.1 Descente d’´echelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
1.3.2 Spectre de la turbulence : ” terra incognita ” (Wyngaard, 2004) . . 13
1.3.3 M´eso-´echelle : principaux sch´emas de moyenne d’ensemble 1D (Shin
and Hong, 2011) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3.3.1 Sch´ema YSU : fermeture au premier ordre avec un m´elange
non-local . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
1.3.3.2 Sch´ema MYJ : fermeture TKE `a l’ordre 1,5 avec un m´elange
local . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.3.4 Micro-´echelle : sch´emas Large Eddy Simulation (LES) 3D (Mirocha
et al., 2010) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.3.4.1 Fermeture SFS Smagorinsky . . . . . . . . . . . . . . . . . 17
1.3.4.2 Fermeture SFS TKE d’ordre 1.5 . . . . . . . . . . . . . . . 17
1.3.5 Descente d’´echelle : couplage d’un sch´ema d’ensemble et d’un sch´ema
LES . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
1.4 Simulation num´erique de la dispersion de polluants : applications du mod`ele
FLEXPART-WRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
1.4.1 G´en´eralit´es sur les mod`eles lagrangiens de dispersion de particules
(Hegarty et al., 2013a,b) . . . . . . . . . . . . . . . . . . . . . . . . 20
1.4.2 Quelques applications du mod`ele FLEXPART-WRF . . . . . . . . . 20
1.5 Etat de l’art sur les circulations locales g´en´er´ees par des ˆıles tropicales ´ . . . 21
1.5.1 Circulations g´en´er´ees par les ˆıles tropicales larges (Fr ≥ 1 et une
largeur > 50 km) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
1.5.2 Circulations g´en´er´ees par les ˆıles tropicales montagneuses (Fr < 1) . 22
1.5.3 Circulations g´en´er´ees par les petites ˆıles (Fr ≥ 1 et une largeur ≤
50 km) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
1.6 Etat de l’art sur l’archipel de la Guadeloupe ´ . . . . . . . . . . . . . . . . . 23
1.6.1 Contexte m´et´eorologique synoptique . . . . . . . . . . . . . . . . . 23
1.6.2 Contexte m´et´eorologique local . . . . . . . . . . . . . . . . . . . . . 24
1.6.2.1 Quelques aspects des vents locaux d’apr`es Br´evignon (2003) 25
1.6.2.2 Campagne exp´erimentale dans la zone cˆoti`ere d’Arnouville
(ARN, D’Alexis et al. (2011)) . . . . . . . . . . . . . . . . 26
1.6.2.3 Campagne exp´erimentale dans la zone urbaine de Pointe-
`a-Pitre (DCH, Plocoste (2013); Plocoste et al. (2014)) . . 27
1.6.2.4 Variabilit´e diurne et spatiale des champs de surface . . . . 28
1.6.3 Impacts des circulations locales nocturnes sur la dispersion de polluants
industriels . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.6.3.1 Centrale EDF diesel Jarry nord . . . . . . . . . . . . . . . 29
1.6.3.2 Observations du panache de la centrale durant des retournements
nocturnes du vent . . . . . . . . . . . . . . . . . 30Table des Mati`eres xi
2 M´ethodologie et outils de simulation 32
2.1 M´ethodologie g´en´erale . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
2.2 S´election des trois situations m´et´eorologiques ´etudi´ees . . . . . . . . . . . . 36
2.2.1 Classification des types de temps . . . . . . . . . . . . . . . . . . . 36
2.2.2 Circulations synoptiques de basses couches pour les dates simul´ees . 37
2.3 Mod`ele num´erique m´eso-´echelle de pr´evision m´et´eorologique : WRF ARW
V3.4.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.3.1 Description du mod`ele d’apr`es les ´etudes de Skamarock et al. (2008)
et Wang et al. (2010) . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.3.1.1 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 41
2.3.1.2 Principales ´equations r´esolues . . . . . . . . . . . . . . . . 42
Coordonn´ee verticale η et variables associ´ees . . . . . . . . . 42
Equations d’Euler incluant l’humidit´e ´ . . . . . . . . . . . . . 43
Maillage ARW d´ecal´e : Arakawa-C . . . . . . . . . . . . . . . 44
2.3.1.3 Sch´emas de param´etrisation physique . . . . . . . . . . . . 45
2.3.2 Configurations utilis´ees . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.3.2.1 Preprocessing WPS . . . . . . . . . . . . . . . . . . . . . . 47
Domaines de simulation . . . . . . . . . . . . . . . . . . . . . 47
Topographie . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Occupation des sols . . . . . . . . . . . . . . . . . . . . . . . 49
Donn´ees m´et´eorologiques globales pour l’assimilation du mod`ele
WRF ARW . . . . . . . . . . . . . . . . . . . . . 52
2.3.2.2 Param´etrisations WRF ARW . . . . . . . . . . . . . . . . 52
Caract´erisation des niveaux verticaux . . . . . . . . . . . . . 52
P´eriodes simul´ees et intervalles de temps des sorties mod`eles 53
Param´etrisations physiques m´eso- et micro-´echelles . . . . . . 54
Pas de temps de calcul . . . . . . . . . . . . . . . . . . . . . 55
Conditions initiales . . . . . . . . . . . . . . . . . . . . . . . 55
Conditions aux limites . . . . . . . . . . . . . . . . . . . . . 56
2.4 Mod`ele lagrangien de dispersion de particules : FLEXPART-WRF . . . . . 57
2.4.1 Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
2.4.1.1 Int´egration des donn´ees m´et´eorologiques WRF . . . . . . . 57
2.4.1.2 Param´etrisation de la couche limite atmosph´erique et de
la turbulence . . . . . . . . . . . . . . . . . . . . . . . . . 58
2.4.1.3 Calcul de la trajectoire des particules . . . . . . . . . . . . 59
2.4.2 Configurations de nos simulations . . . . . . . . . . . . . . . . . . . 60
2.4.2.1 P´eriodes de simulation et intervalles de temps des sorties
mod`eles . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
2.4.2.2 Caract´erisation des niveaux verticaux . . . . . . . . . . . . 61
2.4.2.3 Param´etrisation du panache de NOx de la centrale EDF . 61
2.4.2.4 Param´etrisations physiques . . . . . . . . . . . . . . . . . 62
2.5 Donn´ees m´et´eorologiques d’observation pour l’´evaluation du mod`ele WRF
ARW3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
2.5.1 Radiosondages journaliers (Universit´e du Wyoming) . . . . . . . . . 62Table des Mati`eres xii
2.5.2 Bou´ees m´et´eorologiques du National Data Buoy Center . . . . . . . 63
2.5.3 Stations m´et´eorologiques de l’archipel de la Guadeloupe (M´et´eo
France et LaRGE) . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
2.6 Donn´ees d’observation de la qualit´e de l’air pour l’´evaluation du mod`ele
FLEXPART-WRF . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
2.7 Estimateurs d’erreur utilis´es pour l’´evaluation statistique des simulations . 67
3 R´esultats des simulations et discussion 69
3.1 Simulations num´eriques m´eso-´echelles des circulations g´en´er´ees par l’archipel
de la Guadeloupe (WRF) . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.1.1 Simulation M´eso-A : r´esum´e et article publi´e . . . . . . . . . . . . . 69
3.1.2 Simulation M´eso-A’ : effets du changement de carte d’occupation
des sols dans le domaine D04 . . . . . . . . . . . . . . . . . . . . . 89
3.1.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 89
3.1.2.2 Nouvelles cat´egories d’occupation des sols `a ARN, RZT,
DES, MOU et GBD . . . . . . . . . . . . . . . . . . . . . 89
3.1.2.3 Evaluation statistique des variables de surface simul´ees : ´
comparaison M´eso-A et M´eso-A’ . . . . . . . . . . . . . . 90
3.1.2.4 Evaluation graphique des cycles diurnes dans les simula- ´
tions M´eso-A et Meso-A’ . . . . . . . . . . . . . . . . . . . 93
Station d’Arnouville (ARN) : effets du biais spatial . . . . . 93
Station du Moule (MOU) : am´eliorations de la simulation
M´eso-A’ par rapport `a M´eso-A . . . . . . . . . . 94
3.1.2.5 Comparaison des cartes de circulations locales entre M´esoA’
et M´eso-A . . . . . . . . . . . . . . . . . . . . . . . . . 95
3.1.2.6 Comparaison des cartes de flux de chaleur sensible HFX
et de temp´erature du sol Ts entre M´eso-A’ et M´eso-A . . . 97
3.1.2.7 Conclusion sur les effets de la carte CLC24 dans le domaine
D04 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
3.1.3 Conclusion sur les simulations num´eriques m´eso-´echelles des circulations
locales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
3.2 Simulations num´eriques micro-´echelles des circulations g´en´er´ees par l’archipel
de la Guadeloupe (WRF-LES) . . . . . . . . . . . . . . . . . . . . . . . 103
3.2.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
3.2.2 Evaluation du mod`ele ´ . . . . . . . . . . . . . . . . . . . . . . . . . 104
3.2.2.1 Evaluation statistique avec les observations 10 min du mˆat ´
instrument´e ARN . . . . . . . . . . . . . . . . . . . . . . . 104
3.2.2.2 Evaluation graphique avec les observations du mˆat instru- ´
ment´e ARN : cas des AF (Fr = 0, 21) . . . . . . . . . . . . 105
3.2.3 Ecoulement catabatique nocturne sur la cˆote au vent de la Basse- ´
Terre durant AF (Fr = 0, 21) . . . . . . . . . . . . . . . . . . . . . . 107
3.2.3.1 Evolution temporelle des variables de surface `a VER, ARN, ´
EDF et PAP . . . . . . . . . . . . . . . . . . . . . . . . . 109
3.2.3.2 Structure horizontale du front de l’´ecoulement simul´e (domaine
D06) . . . . . . . . . . . . . . . . . . . . . . . . . . 111Table des Mati`eres xiii
3.2.3.3 Structure verticale du front de l’´ecoulement simul´e (domaine
D06) . . . . . . . . . . . . . . . . . . . . . . . . . . 112
3.2.4 Conclusion sur les simulations num´eriques micro-´echelles des circulations
locales . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
3.3 Application de la mod´elisation micro-´echelle WRF-LES `a la dispersion d’un
panache de polluants industriels : couplage WRF-LES-FLEXPART . . . . 116
3.3.1 Introduction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
3.3.2 Cas des aliz´es soutenus (AS, Fr = 0, 82) . . . . . . . . . . . . . . . . 117
3.3.3 Cas des aliz´es moyens (AM, Fr = 0, 41) . . . . . . . . . . . . . . . . 118
3.3.4 Cas des aliz´es faibles (AF, Fr = 0, 21) . . . . . . . . . . . . . . . . . 120
3.3.4.1 Comparaisons des s´eries temporelles simul´ees et observ´ees
`a la station PAP . . . . . . . . . . . . . . . . . . . . . . . 121
3.3.4.2 Etude des coupes verticales de concentration simul´ee aux ´
points PAP et EDF . . . . . . . . . . . . . . . . . . . . . 122
Conclusion et perspectives 123
3.3.5 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
3.3.6 Perspectives . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
A Article publi´e 129
B Communications internationales 130
C Communication nationale 135
Bibliographie 137Liste des Figures
1.1 Classification des ph´enom`enes atmosph´eriques en fonction de leur ´echelle
spatio-temporelle (Orlanski, 1975; Stull, 1988). . . . . . . . . . . . . . . . . 7
1.2 Evolution temporelle de la structure verticale de la couche limite atmosph´erique ´
terrestre dans des r´egions anticycloniques (Stull, 1988). . . . . . . . . . . . 9
1.3 Sch´ema du spectre de l’´energie en fonction de la taille des structures turbulentes.
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
1.4 Carte topographique GeBCO 08 (General Bathymetric Chart of the Oceans
IOC et al. (2003), 30 secondes d’arc de r´esolution) en m : (a) zone de la
Cara¨ıbe ; (b) l’Arc des Petites Antilles. . . . . . . . . . . . . . . . . . . . . 24
1.5 Carte topographique (IGN, 50 m de r´esolution), avec la zone la plus peupl´ee
de l’archipel (rectangle noir), la d´echarge DCH (carr´e marron), la centrale
EDF (croix rouge), le campus de Fouillole (carr´e jaune), le mˆat instrument´e
du laboratoire LaRGE (ARN, triangle vert) et les 4 stations M´et´eo-France,
Raizet (RZT, disque rouge), Moule (MOU, ´etoile magenta), D´esirade (DES,
carr´e bleu), Grand-Bourg de Marie-Galante (GBD, losange noir). . . . . . 25
1.6 Cartes de circulations cˆoti`eres autour de la Guadeloupe durant des vents
synoptiques d’est (d’apr`es Br´evignon (2003)). . . . . . . . . . . . . . . . . 26
1.7 Photo des chemin´ees de la centrale ´electrique EDF Jarry nord, [cr´edit
photo : R. C´ec´e 2014]. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
1.8 Photo satellite Google earth (8/04/2013) : localisation de la centrale EDF
et du campus UAG, les fl`eches rouges correspondant aux directions (a) et
(b) du panache durant une circulation nocturne d’ouest (Fig. 1.9). . . . . . 30
1.9 Photos du panache de la centrale EDF de Jarry (prise de vue depuis le
campus de Fouillole UAG, Fig. 1.8) : (a) direction du vent nord-ouest,
photo prise le 14/09/2010 `a 7 h 21 LT ; (b) direction du vent sud-ouest,
photo prise le 4/11/2009 `a 7 h 11 LT [cr´edits photos : D. Bernard 2009-2010]. 31
2.1 Sch´ema r´ecapitulatif de la m´ethodologie adopt´ee. . . . . . . . . . . . . . . 35
2.2 Donn´ees d’observation du radar de M´et´eo-France (250 m de r´esolution) `a
16 h LT : (a) le 15 d´ecembre 2007 (AS), (b) le 24 d´ecembre 2007 (AM) et
(c) le 3 d´ecembre 2007 (AF). . . . . . . . . . . . . . . . . . . . . . . . . . . 37
2.3 Champs de surface FNL (NCEP (ment), 1➦ de r´esolution) durant AF le
3/12/2007 `a 12h UTC : (a) Pmer en hPa ; (b) vitesse UU du vent horizontal
`a 10 m en m.s-1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
2.4 Champs de surface FNL (NCEP (ment), 1➦ de r´esolution) durant AS le
14/12/2007 `a 12h UTC : (a) Pmer en hPa ; (b) vitesse UU du vent horizontal
`a 10 m en m.s-1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
xivListe des Figures xv
2.5 Champs de surface FNL (NCEP (ment), 1➦ de r´esolution) durant AM le
24/12/2007 `a 12h UTC : (a) Pmer en hPa ; (b) vitesse UU du vent horizontal
`a 10 m en m.s-1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
2.6 Architecture du mod`ele WRF ARW (d’apr`es Wang et al. (2010)). . . . . . 42
2.7 Niveaux verticaux η dans WRF ARW avec pht et phs, respectivement, les
pressions hydrostatiques au sommet et `a la surface (d’apr`es Skamarock
et al. (2008)). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
2.8 Maille individuelle de la grille Arakawa-C avec les grandeurs vectorielles
(U, V , W, Ω et φ) et les scalaires (µ, θ, qv et ql) (Skamarock and Dudhia,
2014). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.9 Interactions entre les sch´emas de param´etrisation physique du mod`ele WRF
ARW (Dudhia, 2014). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
2.10 Cartes des domaines imbriqu´es : en blanc D01 (27 km de r´esolution), en
cyan D02 (9 km de r´esolution), en gris D03 (3 km de r´esolution), en jaune
D04 (1 km de r´esolution), en vert D05 (333 m de r´esolution) et en rouge
D06 (111 m de r´esolution). . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
2.11 Cartes topographiques (m AMSL) interpol´ees `a partir des donn´ees IGN
(50 m de r´esolution) : (a) D04 (1 km de r´esolution), (b) D05 (333 m de
r´esolution), (c) D06 (111 m de r´esolution) ; avec la station num´erique VER
(triangle jaune), le mˆat instrument´e ARN (triangle vert) et la centrale
´electrique EDF (croix rouge). . . . . . . . . . . . . . . . . . . . . . . . . . 48
2.12 Carte d’occupation des sols de l’archipel de la Guadeloupe CLC24 (23 m
de r´esolution) : Corine Land Cover 2006 dont les 50 cat´egories ont ´et´e
converties en 24 cat´egories USGS, avec le rectangle noir repr´esentant l’agglom´eration
pointoise. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.13 Comparaison des cartes d’occupation des sols de l’archipel de la Guadeloupe
`a 1 km de r´esolution (D04) avec la ligne de cˆote World Vector Shoreline
(NOAA, 2014), (1) les zones urbaines, (2) les terres cultiv´ees non irrigu´ees,
(6) les m´elanges de terres cultiv´ees et de forˆets, (7) les pelouses, (8) les
arbustes, (9) les m´elanges d’arbustes et de pelouses, (10) les savanes, (11)
les forˆets de feuillus, (13) les forˆets denses, (14) les forˆets de conif`eres,
(15) les forˆets m´elang´ees mangroves incluses, (16) les surfaces d’eau, (17)
les v´eg´etations basses en zones inond´ees, (18) les surfaces bois´ees en zones
inond´ees, (21) la toundra bois´ee : (a) USGS ULC24 (M´eso-A), (b) Corine
CLC24 (M´eso-A’). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
2.14 Niveaux verticaux m´edians (WRF) pour les exp´eriences M´eso-A (croix
bleues) et M´eso-A’ (cercles rouges) : (a) profils lin´eaires en fonction du
niveau de pression (hPa) et (b) profils logarithmiques en fonction de l’altitude
(km). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
2.15 Profil vertical des 38 niveaux verticaux FLEXPART-WRF. . . . . . . . . . 61
2.16 G´eolocalisation des radiosondages (TRI, BAR, RZT, SXM, PTR, et SDM :
carr´es rouges), des bou´ees du r´eseau NDBC-NOAA (ATL, CAR, POR, et
BAH : cercles bleus) au sein des quatre premiers domaines (D01, D02,
D03, D04) employ´es dans les simulations WRF m´eso-´echelles, de r´esolutions
respectives de 27, 9, 3 et 1 km. . . . . . . . . . . . . . . . . . . . . . 63Liste des Figures xvi
2.17 Carte topographique (IGN, 50 m de r´esolution), avec le mˆat instrument´e
du laboratoire LaRGE (ARN, triangle vert) et les 4 stations M´et´eo-France,
Raizet (RZT, disque rouge), Moule (MOU, ´etoile magenta), D´esirade (DES,
carr´e bleu), Grand-Bourg de Marie-Galante (GBD, losange noir). . . . . . 64
2.18 Description du mˆat instrument´e du laboratoire LaRGE `a ARN (sch´ema
extrait de D’Alexis (2011)), avec, (a) le capteur barom´etrique PTB101B,
(b) la centrale d’acquisition Campbell CR3000, (c) le capteur HR capacitif
(HMP45C) pour l’humidit´e et la temp´erature (2 m AGL), (d) l’an´emom`etre
`a coupelles (2 m AGL), (e) la girouette (2 m AGL), (f) l’an´emom`etre sonique
3D (CSAT3) pour le calcul des flux turbulents (5 m AGL) et (g)
l’an´emom`etre sonique 2D (WindSonic) pour le vent horizontal (10 m AGL). 66
2.19 Carte de localisation de la station Gwad’air PAP (losange violet) et de la
centrale ´electrique EDF (croix rouge) : (a) Topographie (en m AMSL) du
domaine D05 (maille de 333 m) avec l’agglom´eration pointoise (contour
violet), (b) image satellite Google earth de la zone d’´etude (4/8/2013). . . 67
3.1 Carte d’occupation des sols de l’archipel de la Guadeloupe utilis´ee dans la
simulation M´eso-A’, `a 1 km de r´esolution avec les 5 stations (ARN, RZT,
DES, MOU et GBD) : (1) zones urbaines, (2) terres cultiv´ees non irrigu´ees,
(6) terres cultiv´ees–forˆets, (9) arbustes–pelouses, (11) forˆets de feuillus, (15)
forˆets m´elang´ees mangroves incluses, (16) surfaces d’eau et (17) v´eg´etations
basses en zones inond´ees. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
3.2 Comparaison des s´eries temporelles (48 h) `a ARN, avec les observations
(triangles verts), M´eso-A (carr´es bleus)et M´eso-A’ (cercles rouges) : (a1)–
(a3) la temp´erature T2 (en ➦C), (b1)–(b3) la vitesse UU `a 10 m AGL (en
m.s-1), (c1)–(c3) la direction DD `a 10 m AGL (en ➦N) ; (a1)–(c1) pour AS,
(a2)–(c2) pour AM et (a3)–(c3) pour AF. . . . . . . . . . . . . . . . . . . . 93
3.3 Comparaison des s´eries temporelles (48 h) `a MOU, avec les observations
(triangles verts), M´eso-A (carr´es bleus) et M´eso-A’ (cercles rouges) : (a1)–
(a3) la temp´erature T2 (en ➦C), (b1)–(b3) la vitesse UU `a 10 m AGL (en
m.s-1), (c1)–(c3) la direction DD `a 10 m AGL (en ➦N) ; (a1)–(c1) pour AS,
(a2)–(c2) pour AM et (a3)–(c3) pour AF. . . . . . . . . . . . . . . . . . . . 95
3.4 Comparaison du vent `a 10 m AGL (M´eso-A’–M´eso-A), avec la direction
du vent pour M´eso-A’ (fl`eches rouges), la direction du vent pour M´esoA
(fl`eches noires), la diff´erence de vitesse du vent, UUA0 − UUA en m.s-1
(contours de couleur), la ligne de cˆote pour M´eso-A’ (ligne noire), la ligne
de cˆote pour M´eso-A (ligne magenta) : (a) le 14/12/2007 `a 14 h LT,(b) le
15/12/2007 `a 04 h LT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
3.5 Comparaison du vent `a 10 m AGL (M´eso-A’–M´eso-A), avec la direction
du vent pour M´eso-A’ (fl`eches rouges), la direction du vent pour M´esoA
(fl`eches noires), la diff´erence de vitesse du vent, UUA0 − UUA en m.s-1
(contours de couleur), la ligne de cˆote pour M´eso-A’ (ligne noire), la ligne
de cˆote pour M´eso-A (ligne magenta) : (a) le 24/12/2007 `a 14 h LT, (b) le
25/12/2007 `a 04 h LT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96Liste des Figures xvii
3.6 Comparaison du vent `a 10 m AGL (M´eso-A’–M´eso-A), avec la direction
du vent pour M´eso-A’ (fl`eches rouges), la direction du vent pour M´esoA
(fl`eches noires), la diff´erence de vitesse du vent, UUA0 − UUA en m.s-1
(contours de couleur), la ligne de cˆote pour M´eso-A’ (ligne noire), la ligne
de cˆote pour M´eso-A (ligne magenta) : (a) le 3/12/2007 `a 14 h LT, (b) le
4/12/2007 `a 04 h LT. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
3.7 Comparaison M´eso-A’–M´eso-A pour le cas des AS, le 14/12/2007 `a 14 h LT
(a) et le 15/12/2007 `a 04 h LT (b) : la diff´erence de flux de chaleur sensible
HF XA0 − HF XA en W.m-2 (a1, b1) et la diff´erence de temp´erature de
surface T sA0 − T sA en ➦C (a2, b2). . . . . . . . . . . . . . . . . . . . . . . 98
3.8 Comparaison M´eso-A’–M´eso-A pour le cas des AF, le 24/12/2007 `a 14 h LT
(a) et le 25/12/2007 `a 04 h LT (b) : la diff´erence de flux de chaleur sensible
HF XA0 − HF XA en W.m-2 (a1, b1) et la diff´erence de temp´erature de
surface T sA0 − T sA en ➦C (a2, b2). . . . . . . . . . . . . . . . . . . . . . . 99
3.9 Comparaison M´eso-A’–M´eso-A pour le cas des AF, le 3/12/2007 `a 14 h LT
(a) et le 4/12/2007 `a 04 h LT (b) : la diff´erence de flux de chaleur sensible
HF XA0 − HF XA en W.m-2 (a1, b1) et la diff´erence de temp´erature de
surface T sA0 − T sA en ➦C (a2, b2). . . . . . . . . . . . . . . . . . . . . . . 100
3.10 S´eries temporelles 10 min `a ARN durant les 48 h de la simulation des AF
(3/12/2007–5/12/2007), avec les sorties du domaine D05 (333 m de r´esolution)
en bleu, les sorties du domaines D06 (111 m de r´esolution) en
rouge et les donn´ees observ´ees en noir ; (a), (b), (c), (d) et (e) repr´esentant
respectivement les variables, temp´erature de l’air `a 2 m AGL T2 (➦C),
vitesse du vent horizontal UU `a 10 m AGL (m.s-1), direction du vent DD `a
10 m AGL (➦N), flux de chaleur sensible HFX (W.m-2) et ´energie cin´etique
turbulente de surface TKE (en noir, l’´energie cin´etique turbulente totale
observ´ee, et
, en rouge et en bleu, l’´energie cin´etique turbulente sous-maille
simul´ee, es
, m2
.s-2). . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
3.11 Cartes des champs de vent (10 m AGL) du domaine D05, durant la nuit
du 3 au 4 d´ecembre 2007 : (a) 19 h LT, (b) 22 h LT, (c) 04 h LT et (d)
09 h LT ; avec la vitesse du vent horizontal en m.s-1, VER (cercle magenta),
ARN (triangle vert), EDF (carr´e blanc) et PAP (losange violet). . . . . . . 108
3.12 S´eries temporelles WRF-LES (10 min) durant la p´eriode du 3/12/2007
12 h LT au 4/12/2007 12 h LT, avec VER (D05) en noir, ARN (D06) en vert,
EDF (D06) en rouge et PAP (D06) en bleu ; (a), (b), (c) et (d) repr´esentent
respectivement les variables, flux de chaleur sensible HFX (W.m-2), temp´erature
de l’air `a 2 m AGL T2 (➦C), vitesse du vent horizontal UU `a
10 m AGL (m.s-1) et direction du vent DD `a 10 m AGL (➦N). . . . . . . . 110
3.13 Cartes des variables de surface simul´ees le 3/12/2007 `a 22 h LT : (a) vitesse
du vent horizontal UU `a 60 m AGL (m.s-1), (b) vitesse du vent vertical
`a 60 m AGL (m.s-1), (c) ´energie cin´etique turbulente sous-maille es
`a 60 m AGL (m2
.s-2) et (d) flux de chaleur sensible HFX (W.m-2) ; avec
ARN, EDF et PAP, respectivement repr´esent´es par le triangle vert, le carr´e
blanc et le losange violet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111Liste des Figures xviii
3.14 Cartes des variables de surface simul´ees le 4/12/2007 `a 04 h LT : (a) vitesse
du vent horizontal UU `a 60 m AGL (m.s-1), (b) vitesse du vent vertical
`a 60 m AGL (m.s-1), (c) ´energie cin´etique turbulente sous-maille es
`a 60 m AGL (m2
.s-2) et (d) flux de chaleur sensible HFX (W.m-2) ; avec
ARN, EDF et PAP, respectivement repr´esent´es par le triangle vert, le carr´e
blanc et le losange violet. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
3.15 Coupe verticale suivant la latitude de la station ARN (16.223➦N) le 3
d´ecembre 2007 `a 19 h LT : (a) la masse volumique ρ (kg.m-3), (b) la temp´erature
virtuelle Tv (K). . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
3.16 Coupe verticale suivant la latitude de la station ARN (16.223➦N) le 3
d´ecembre 2007 `a 22 h LT : (a) la vitesse du vent suivant les composantes
x et z (m.s-1), (b) l’´energie cin´etique turbulente sous-maille es (m2
.s-2). . . 113
3.17 Coupe verticale suivant la latitude de la station ARN (16.223➦N) le 4
d´ecembre 2007 `a 04 h LT : (a) la vitesse du vent suivant les composantes
x et z (m.s-1), (b) l’´energie cin´etique turbulente sous-maille es (m2
.s-2). . . 114
3.18 Profil vertical spatio-temporel logarithmique de l’´energie cin´etique turbulente
sous-maille es (m2
.s-2) simul´ee `a ARN : la valeur des contours d’es est
limit´ee `a 0.2 m2
.s-2
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
3.19 Cartes du vent (m.s-1) et des concentrations de NOx (µg.m-3) simul´es `a
10 m AGL durant les AS le 14 d´ecembre `a 16 h LT (a1),(a2) et le 15
d´ecembre `a 07 h LT (b1),(b2) `a l’aide de FLEXPART ; les points ARN,
EDF et PAP sont respectivement repr´esent´es par un triangle blanc, un
carr´e blanc et un losange blanc. . . . . . . . . . . . . . . . . . . . . . . . . 117
3.20 Comparaison du vent (m.s-1) et des concentrations de NOx (µg.m-3) observ´ees
et simul´ees sur le site de la station PAP durant les AS entre le 14
et le 15 d´ecembre 2007 : NO Obs. (ligne noire), NO2 Obs. (ligne bleue),
NO+NO2 Obs. (ligne verte) et NOx Flexpart `a 10 m AGL (ligne rouge). . 118
3.21 Cartes du vent (m.s-1) et des concentrations de NOx (µg.m-3) simul´es `a
10 m AGL durant les AM le 24 d´ecembre `a 16 h LT (a1),(a2) et le 25
d´ecembre `a 07 h LT (b1),(b2) `a l’aide de FLEXPART ; les points ARN,
EDF et PAP sont respectivement repr´esent´es par un triangle blanc, un
carr´e blanc et un losange blanc. . . . . . . . . . . . . . . . . . . . . . . . . 119
3.22 Comparaison des concentrations de NOx (µg.m-3) observ´ees et simul´ees sur
le site de la station PAP durant les AM entre le 24 et le 25 d´ecembre 2007 :
NO Obs. (ligne noire), NO2 Obs. (ligne bleue), NO+NO2 Obs. (ligne verte)
et NOx Flexpart `a 10 m AGL (ligne rouge). . . . . . . . . . . . . . . . . . 119
3.23 Cartes du vent (m.s-1) et des concentrations de NOx (µg.m-3) simul´es `a
10 m AGL durant les AF le 3 d´ecembre `a 16 h LT (a1),(a2) et le 4 d´ecembre
`a 07 h LT (b1),(b2) `a l’aide de FLEXPART ; les points ARN, EDF et PAP
sont respectivement repr´esent´es par un triangle blanc, un carr´e blanc et un
losange blanc. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
3.24 Comparaison des concentrations de NOx (µg.m-3) observ´ees et simul´ees sur
le site de la station PAP durant les AF entre le 3 et le 4 d´ecembre 2007 :
NO Obs. (ligne noire), NO2 Obs. (ligne bleue), NO+NO2 Obs. (ligne verte)
et NOx Flexpart `a 10 m AGL (ligne rouge). . . . . . . . . . . . . . . . . . 121Liste des Figures xix
3.25 Profils spatio-temporels logarithmiques de la concentration de NOx (µg.m-3)
simul´ee durant les AF entre le 3 et le 4 d´ecembre 2007 : (a) site de la centrale
EDF, (b) site de la station de la qualit´e de l’air PAP. . . . . . . . . . . . . 123Liste des Tableaux
2.1 Equivalences entre les 50 classes de la Corine Land Cover 2006 DOM et les ´
24 classes de l’USGS AVHRR 1992 (Pineda et al., 2004). . . . . . . . . . . 50
2.2 Configuration des six domaines de simulation. . . . . . . . . . . . . . . . . 52
2.3 Pas de temps de calcul pour les six domaines de simulation. . . . . . . . . 55
2.4 Conditions aux limites des simulations WRF pour les six domaines ´etudi´es. 56
2.5 Variables des sorties WRF requises et optionnelles pour le for¸cage du mod`ele
FLEXPART-WRF (Brioude et al., 2013). . . . . . . . . . . . . . . . . . . . 58
3.1 Comparaison des occupations des sols utilis´ees dans les simulations M´eso-A
et M´eso-A’ pour les 5 stations (1 km de r´esolution). . . . . . . . . . . . . . 90
3.2 Evaluation statistique des variables de surface simul´ees : comparaison M´eso- ´
A et M´eso-A’. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 91
3.3 Evaluation statistique des variables de surface simul´ees (10 min) par rap- ´
port aux observations ARN. . . . . . . . . . . . . . . . . . . . . . . . . . . 105
xxListe des abr´eviations
Nombres sans dimension
Fr Nombre de Froude local, d´efini par U/Nhm, avec U la vitesse du vent [m.s-1], N la
flottabilit´e [s-2] et hm la hauteur de l’obstacle [m]
Pr Nombre de Prandtl, d´efini par µCp/λ, avec µ la viscosit´e dynamique [kg.m-1.s-1],
Cp la capacit´e thermique massique [J.kg-1.K-1] et λ la conductivit´e thermique
[W.m-1.K-1]
Re Nombre de Reynolds, d´efini par V L/ν, avec V la vitesse caract´eristique du fluide
[m.s-1], L la dimension caract´eristique [m] et ν la viscosit´e cin´ematique du fluide
[m2
.s-1]
Variables
DD Direction du vent horizontal [➦N]
er Energie cin´etique turbulente r´esolue [m ´ 2
.s-2]
es Energie cin´etique turbulente sous-maille [m ´ 2
.s-2]
et Energie cin´etique turbulente totale, e ´
t = er + es
[m2
.s-2]
GFX Flux de chaleur du sol, de l’anglais : Ground Heat Flux [W.m-2]
HCLA Hauteur de la couche limite atmosph´erique [m]
HFX Flux de chaleur sensible, de l’anglais : Heat Flux [W.m-2]
LH Flux de chaleur latente, de l’anglais : Latent Heat [W.m-2]
LW Rayonnement des ondes longues re¸cu au sol, de l’anglais : Long Wave [W.m-2]
PMER Pression au niveau de la mer [hPa]
QVAP Rapport de m´elange de vapeur d’eau [g.kg-1]
SW Rayonnement des ondes courtes re¸cu au sol, de l’anglais : Short Wave [W.m-2]
xxiListe des Abr´eviations xxii
T2 Temp´erature de l’air `a 2 m AGL [➦C]
TKE Energie cin´etique turbulente, de l’anglais : Turbulent Kinetic Energy [m ´ 2
.s-2]
Ts Temp´erature de la surface du sol ou de la mer [➦C]
UU Vitesse du vent horizontal [m.s-1]
Stations d’observation
ARN Mˆat m´et´eorologique LaRGE de la zone d’Arnouville, Petit-Bourg, Guadeloupe
ATL Bou´ee m´et´eorologique du National Data Buoy Center (ID 41040, 14,516➦N, 53,024➦W)
BAH Bou´ee m´et´eorologique du National Data Buoy Center (ID 41046, 23,838➦N, 68,333➦W)
BAR Station m´et´eorologique de la Barbade (ID 78954)
CAR Bou´ee m´et´eorologique du National Data Buoy Center (ID 42059, 14,058➦N, 67,528➦W)
DES Station m´et´eorologique M´et´eo France de la D´esirade, Guadeloupe
GBD Station m´et´eorologique M´et´eo France de Grand-Bourg, Marie-Galante, Guadeloupe
MOU Station m´et´eorologique M´et´eo France du Moule, Guadeloupe
PAP Station de qualit´e de l’air Gwad’air du centre-ville de Pointe-`a-Pitre, Guadeloupe
POR Bou´ee m´et´eorologique du National Data Buoy Center (ID 41043, 21,061➦N, 64,966➦W)
PTR Station m´et´eorologique de Porto Rico (ID 78526)
RZT Station m´et´eorologique M´et´eo France du Raizet, Guadeloupe (ID 78897)
SDM Station m´et´eorologique de la R´epublique Dominicaine (ID 78486)
SXM Station m´et´eorologique de Saint Martin (ID 78866)
TRI Station m´et´eorologique de Trinidad (ID 78970)
Stations num´eriques WRF
EDF Station num´erique WRF `a la position de la centrale ´electrique EDF de Jarry,
Guadeloupe
PCM Station num´erique WRF de la zone du Petit Cul-de-Sac Marin, Guadeloupe
VER Station num´erique WRF de la zone de Vernou, Petit-Bourg, Guadeloupe
Domaines de simulation
D01 Domaine 1 de la descente d’´echelle avec une r´esolution de 27 km (m´eso-´echelle)Liste des Abr´eviations xxiii
D02 Domaine 2 de la descente d’´echelle avec une r´esolution de 9 km (m´eso-´echelle)
D03 Domaine 3 de la descente d’´echelle avec une r´esolution de 3 km (m´eso-´echelle)
D04 Domaine 4 de la descente d’´echelle avec une r´esolution d’1 km (m´eso-´echelle)
D05 Domaine 5 de la descente d’´echelle avec une r´esolution de 333 m (micro-´echelle)
D06 Domaine 6 de la descente d’´echelle avec une r´esolution de 111 m (micro-´echelle)
Divers
2D Etude en deux dimensions ´
3D Etude en trois dimensions ´
AF Aliz´es Faibles (avec une vitesse de 3 m.s-1 et un nombre de Froude, Frm = 0, 21)
AGL Au-dessus du sol, de l’anglais : Above Ground Level
AM Aliz´es Moyens (avec une vitesse de 6 m.s-1 et un nombre de Froude, Frm = 0, 41)
AMSL Au-dessus du niveau moyen de la mer, de l’anglais : Above Mean Sea Level
ARW Coeur dynamique Advanced Research du mod`ele WRF
AS Aliz´es Soutenus (avec une vitesse de 12 m.s-1 et un nombre de Froude, Frm = 0, 82)
CLA Couche Limite Atmosph´erique compos´ee de la CLS et de la CLP (du bas vers le
haut)
CLC24 Carte d’occupation des sols Corine Land Cover (2006) convertie aux 24 cat´egories
d´efinies par l’USGS
CLP Couche Limite Plan´etaire, partie haute de la CLA (≈ entre le sommet de la CLS
et la HCLA)
CLS Couche Limite de Surface, partie basse de la CLA (≈ entre 0 et 150 m AGL)
e.g. Par exemple, du latin : exempli gratia
Eq. Equation ´
Fig. Figure
FNL Mod`ele d’analyse m´et´eorologique globale, NCEP FNL (Final) Operational Global
Analysis
GFS Global Forecast System, mod`ele de pr´evision num´erique du temps `a l’´echelle globale
GRIB GRIdded Binary, format binaire utilis´e pour le stockage des donn´ees m´et´eorologiques,
format d´efini par la World Meteorological OrganizationListe des Abr´eviations xxiv
i.e. C’est-`a-dire, du latin : id est
IGN Institut National de l’Information G´eographique et Foresti`ere
IOA Indice d’ad´equation du mod`ele qui varie avec l’erreur quadratique moyenne, de
l’anglais : Index Of Agreement
IOA2 Indice d’ad´equation du mod`ele qui varie avec l’erreur moyenne absolue, de l’anglais :
Index Of Agreement 2
LaRGE Laboratoire de Recherche en G´eosciences et Energies, Universit´e des Antilles et ´
de la Guyane
LES Simulation aux grandes ´echelles, de l’anglais : Large Eddy Simulation
LT Temps local, de l’anglais : Local Time ; en Guadeloupe l’heure LT correspond `a
l’heure UTC−4
MAE Erreur moyenne absolue, de l’anglais : Mean Absolute Error
MBE Erreur du biais moyen, de l’anglais : Mean Bias Error
MSL Mean Sea Level (niveau moyen de la mer)
MYJ Sch´ema de turbulence 1D Mellor-Yamada-Janji´c
M´eso-A Simulation m´eso-´echelle utilisant la carte d’occupation des sols ULC24 dans le
domaine D04
M´eso-A’ Simulation m´eso-´echelle utilisant la carte d’occupation des sols CLC24 dans le
domaine D04
NCAR National Center for Atmospheric Research (institut am´ericain de recherche sur
l’atmosph`ere)
Obs. Donn´ees observ´ees
RMSE Erreur quadratique moyenne, de l’anglais : Root-Mean-Square Error
Tab. Tableau
ULC24 Carte d’occupation des sols USGS global land cover avec 24 cat´egories (1992)
USGS Institut d’´etudes g´eologiques des Etats-Unis, de l’anglais : United States Geological ´
Survey
UTC Temps universel coordonn´e, de l’anglais : Universal Time Coordinated ; en Guadeloupe
l’heure UTC correspond `a l’heure LT+4Liste des Abr´eviations xxv
WRF Mod`ele m´et´eorologique Weather Research and Forecasting
YSU Sch´ema de turbulence 1D Yonsei University
ZCIT Zone de Convergence IntertropicaleA la r´evolution mondiale du prol´etariat `
xxviIntroduction
Motivations et objectifs de la th`ese
La litt´erature a montr´e qu’en fonction de leur taille et de leur relief, les ˆıles tropicales sont
capables de g´en´erer leurs propres circulations dans les basses couches atmosph´eriques
(Br´evignon, 2003; Carlis et al., 2010; C´ec´e et al., 2014; D’Alexis, 2011; D’Alexis et al.,
2011; Feng and Chen, 1998; Jury et al., 2009; Lef`evre et al., 2010; Lesou¨ef et al., 2011;
Mahrer and Pielke, 1976; Malkus, 1955; Matthews et al., 2007; Minder et al., 2013;
Nguyen et al., 2010; Oliphant et al., 2001; Plocoste, 2013; Plocoste et al., 2014; Reisner
and Smolarkiewicz, 1994; Savij¨arvi and Matthews, 2004; Smith et al., 1997; Smith
and Grubiac, 1993; Smith et al., 2012; Souza, 1972; Whitehall et al., 2013; Yang and
Chen, 2005). Le contexte tropical insulaire, avec une forte irradiation solaire et des ˆıles
montagneuses, est propice `a de nombreux ph´enom`enes m´et´eorologiques locaux tels que les
vents catabatiques–anabatiques en zone montagneuse, les brises de mer-terre sur la cˆote,
la convection thermique-orographique ´evoluant en orages, les effets du relief sur des vents
cycloniques...
Ces ph´enom`enes se produisent aux ´echelles sub-kilom´etriques, infra-journali`eres, voir infrahoraires.
Ils engendrent des changements brusques qui peuvent g´en´erer des rafales de vent
localis´ees, des pr´ecipitations extrˆemes, des ´episodes de pollution atmosph´erique dans les
basses couches, ou des perturbations de l’´etat de la mer.
Il est donc essentiel d’am´eliorer les connaissances `a ces ´echelles fines, pour r´eduire les
risques sur la sant´e, les biens et les personnes. L’application de la mod´elisation de l’atmosph`ere
`a la micro-´echelle (inf´erieure au km, infra-horaire) b´en´eficierait aussi `a la recherche
sur la pr´ediction des ´energies renouvelables fluctuantes, comme l’´eolien ou le
solaire.
La bibliographie traitant des circulations locales g´en´er´ees par l’archipel de la Guadeloupe
est tr`es peu document´ee. Br´evignon (2003) a d´ecrit une cartographie grossi`ere des
r´egimes de vents locaux. D’apr`es Br´evignon (2003), il n’y aurait pas de retournement du
1Introduction 2
vent jour–nuit mais une simple variation dans la direction du vent. Il a estim´e que les
brises thermiques seraient principalement observ´ees le long de la cˆote sous le vent de la
Basse-Terre.
Pourtant, durant des aliz´es faibles `a mod´er´es, ces retournements nocturnes du vent des
basses couches ont ´et´e observ´es : sur la cˆote au vent de la Grande-Terre (Br´evignon,
2003), sur la cˆote au vent de la Basse-Terre (D’Alexis, 2011; D’Alexis et al., 2011) et sur
la cˆote sous le vent de la Grande-Terre (Plocoste, 2013; Plocoste et al., 2014). Dans le
premier cas, il s’agirait d’une brise de terre (Br´evignon, 2003). L’environnement cˆotier
et orographique du deuxi`eme cas sugg´ererait un ´ecoulement catabatique et/ou une brise
de terre (D’Alexis, 2011; D’Alexis et al., 2011). Enfin Plocoste et al. (2014) ont d´efini
la circulation nocturne d’ouest comme une brise urbaine induite par un ˆılot de chaleur
urbain dans l’agglom´eration pointoise. D’apr`es nous, l’origine purement urbaine de cet
´ecoulement serait discutable. Les mesures exp´erimentales de D’Alexis et al. (2011) effectu´ees
dans les mˆemes conditions m´et´eorologiques sur la cˆote au vent de la Basse-Terre
( station ARN), sugg´ereraient que l’´ecoulement d’ouest observ´e dans les travaux de Plocoste
et al. (2014) soit g´en´er´e, en amont, sur la cˆote au vent de la Basse-Terre avec une
extension vers la Grande-Terre. Les observations du panache de la centrale EDF de Jarry
(Fig. 1.7, 1.8, 1.9) confirmeraient cette extension de l’´ecoulement vers la cˆote ouest de la
Grande-Terre.
Cet ´ecoulement local nocturne d’ouest, soufflant en direction de la partie la plus peupl´ee
de l’archipel en passant par la zone industrielle de Jarry (o`u l’on trouve de nombreuses
sources d’´emissions de polluants), n´ecessite une analyse 3D de sa structure et de ses
m´ecanismes de formation.
Quels sont les effets pr´edominants `a prendre en compte, selon les conditions m´et´eorologiques,
pour comprendre ce cycle particulier du vent ? Quels sont les ordres de grandeur
(extensions verticale et horizontale, direction et intensit´e) pour les variations observ´ees ?
Quelles sont les influences de l’occupation des sols et de la zone maritime ? Quel est le
rˆole du flux de chaleur sensible dans les cycles diurnes observ´es ?
Actuellement, le mod`ele num´erique de pr´evision du temps, employ´e par M´et´eo-France en
Guadeloupe et en Martinique, a une r´esolution limit´ee `a 8 km (mod`ele Aladin). Cette
´echelle ne correspond pas aux ph´enom`enes m´et´eorologiques locaux qui apparaissent sur
ces petites ˆıles de l’Arc antillais.
Depuis une d´ecennie, le d´eveloppement des moyens de calcul a permis la mise en place de
mod`eles num´eriques de pr´evision du temps `a l’´echelle r´egionale. D’autres mod`eles m´et´eorologiques,
comme le mod`ele Weather Research and Forecasting WRF (Skamarock et al.,
2008), ont montr´e leur efficacit´e `a pr´edire les conditions atmosph´eriques m´eso-´echelles `aIntroduction 3
partir des donn´ees synoptiques des mod`eles globaux (Carlis et al., 2010; C´ec´e et al., 2014;
Jury et al., 2009; Lef`evre et al., 2010; Nguyen et al., 2010; Seaman et al., 2012; Yang and
Chen, 2005). Ce mod`ele est capable d’effectuer la descente d’´echelle depuis la m´eso-´echelle
(sch´ema d’ensemble de couche limite plan´etaire 1D) vers la micro-´echelle (Large Eddy Simulation,
LES 3D). C’est un axe de recherche r´ecent qu’on se propose d’appliquer `a notre
sujet d’´etude. Cette ´etude viendra compl´eter les validations de ce type de couplage entre
ces deux sch´emas de mod´elisation de la turbulence.
Ce m´emoire de th`ese constitue donc la premi`ere ´etude de mod´elisation num´erique `a haute
r´esolution de l’atmosph`ere dans les petites ˆıles montagneuses de l’archipel de la Guadeloupe
(avec des mailles m´eso-´echelles de 3 km et 1 km et des mailles micro-´echelles de
333 m et 111 m). Le mod`ele m´et´eorologique WRF ARW V3.4.1 (Skamarock et al., 2008)
ainsi que son module WRF-LES (micro-´echelle) ont ´et´e utilis´es pour simuler trois situations
m´et´eorologiques r´eelles de 48 heures, associ´ees `a des aliz´es faibles (AF), des aliz´es
moyens (AM), et des aliz´es forts (AS). Ces situations correspondent respectivement aux
valeurs du nombre de Froude local ´egales `a 0,21, 0,41 et 0,82 (Fr est d´efini par U/Nhm
avec des vitesses de vent horizontal U = 3, 6, 12 m.s-1, une flottabilit´e N de 0,01 s-1 et la
hauteur de la Soufri`ere hm = 1460 m).
Les travaux pr´esent´es ont pour principal objectif la simulation num´erique et l’analyse des
m´ecanismes m´eso- et micro-´echelles qui induisent des circulations locales diurnes et nocturnes
sur les ˆıles de la Guadeloupe et plus principalement dans la zone la plus peupl´ee
de l’archipel (l’agglom´eration pointoise situ´ee au centre de l’archipel autour du Petit Culde-Sac
Marin). A l’heure actuelle, o`u la mod´elisation de la descente d’´echelle depuis les `
sch´emas de moyenne d’ensemble (m´eso-´echelle) vers les sch´emas LES (micro-´echelle) reste
peu document´ee, notre ´etude permettra d’am´eliorer les connaissances sur cette imbrication.
Les observations de circulations nocturnes, apparaissant dans l’agglom´eration pointoise
et la zone industrielle de l’archipel, peuvent g´en´erer des pics de pollution, li´es aux sources
industrielles comme la production d’´electricit´e. Pour tenter d’´evaluer et de pr´evenir les
risques de pollution associ´es au passage de cette circulation, une analyse plus fine en temps
et en espace, est n´ecessaire. Cette analyse a pu ˆetre r´ealis´ee grˆace au couplage du mod`ele
lagrangien de dispersion de particules FLEXPART(Brioude et al., 2013) avec les sorties
WRF-LES. Les simulations micro-´echelles de la dispersion d’un panache de NOx seront
analys´ees.
Le for¸cage du mod`ele FLEXPART avec des sorties micro-´echelles WRF-LES (avec des
r´esolutions spatiales de 333 m et 111 m) toutes les 10 minutes permettra d’´evaluer laIntroduction 4
capacit´e de ce dernier `a repr´esenter la dispersion de polluants dans des ´ecoulements turbulents.
Ces premiers r´esultats de dispersion du panache de polluants issus de la zone
industrielle de Jarry pourraient aider `a l’´elaboration de plans de pr´evention de la pollution
atmosph´erique. L’ensemble des champs simul´es WRF, WRF-LES et WRF-LESFLEXPART
contribueront aussi `a combler le manque de donn´ees d’observation et de
mod´elisation (mod`ele Aladin de M´et´eo-France avec une maille de 8 km) locales sur l’archipel
de la Guadeloupe dans le domaine de la m´et´eorologie et de la pollution. Cette
´etude pourra ˆetre g´en´eralis´ee et appliqu´ee `a des environnements proches car l’Arc des Petites
Antilles est compos´e d’un ensemble d’ˆıles dont les tailles, les reliefs et les situations
m´et´eorologiques synoptiques sont similaires `a ceux retrouv´es en Guadeloupe.
Organisation du rapport
Nous pr´esenterons dans le chapitre 1, une synth`ese bibliographique des connaissances dans
le domaine de la mod´elisation des circulations atmosph´eriques, ainsi que l’´etat de l’art sur
des ´etudes exp´erimentales traitant des circulations particuli`eres d´ej`a observ´ees sur l’archipel
de la Guadeloupe.
La section 2.1 est consacr´e `a la description de la m´ethodologie et des principaux outils
employ´es. Les configurations du mod`ele m´et´eorologique r´egional WRF ARW et du mod`ele
lagrangien de dispersion de particules FLEXPART-WRF sont pr´esent´ees respectivement
dans les sections 2.3 et 2.4. Nous d´ecrivons les donn´ees d’observation disponibles pour
l’´evaluation des champs m´et´eorologiques simul´es et des sorties de concentration de polluants
dans les sections respectives, 2.5 et 2.6. La section 2.7 pr´esente les formulations des
estimateurs d’erreur statistiques.
Les r´esultats des simulations num´eriques m´eso-´echelles WRF (avec 4 domaines de r´esolutions
respectives 27, 9, 3 et 1 km), micro-´echelles WRF-LES (avec 2 domaines de r´esolutions
respectives 333 et 111 m) et de la dispersion de polluants WRF-LES-FLEXPART
(mˆemes domaines que WRF-LES) sont d´ecrits et discut´es dans le chapitre 3. La publication
traitant des sorties num´eriques de l’exp´erience M´eso-A (avec la carte d’occupation
des sols de la Guadeloupe USGS AVHRR 1992), est incluse dans la section 3.1.1. La section
3.1.2 pr´esente les effets de la carte d’occupation des sols Corine Land Cover 2006 sur
les circulations locales g´en´er´ees par l’archipel (exp´erience M´eso-A’). Dans la section 3.2,
nous analysons les circulations micro-´echelles WRF-LES, simul´ees `a partir du for¸cage des
sorties M´eso-A’ (1 km de r´esolution). Les simulations micro-´echelles de la dispersion duIntroduction 5
panache de la centrale EDF de Jarry (WRF-LES-FLEXPART) sont examin´ees `a la section
3.3.
Enfin dans la partie Conclusion et perspectives, nous r´esumons les principaux r´esultats et
enseignements de ces travaux, et nous pr´esentons leurs perspectives futures.Chapitre 1
Circulations atmosph´eriques dans les
basses couches et leurs effets : ´etude
bibliographique
1.1 Echelles des circulations atmosph´eriques ´
Comme d´ecrit par Malardel (2009) dans son livre de r´ef´erence Fondamentaux de M´et´eorologie,
l’atmosph`ere subit plusieurs types d’excitations ext´erieures comme les variations
cycliques du rayonnement solaire durant l’ann´ee, ou des excitations plus irr´eguli`eres et
complexes comme les interactions avec la surface terrestre ou oc´eanique. Il en r´esulte une
forte variabilit´e spatio-temporelle de l’´etat du fluide atmosph´erique. Dans l’atmosph`ere
excit´ee, des circulations se mettent en place et permettent un retour `a l’´equilibre. Ces
circulations pr´esentent un large champ d’´echelles spatiales et temporelles : du millim`etre
`a la taille de la plan`ete, et de la seconde `a plusieurs ann´ees (Malardel, 2009). D’apr`es Stull
(2000), les ´echelles de temps de la plupart des ph´enom`enes sont approximativement proportionnelles
aux ´echelles horizontales avec un coefficient proche d’1 s.m-1. Par exemple,
dans la couche limite atmosph´erique, les vents thermiques d’1 km de diam`etre ont une
dur´ee de circulation de 15 min. Les cellules orageuses qui ont une taille de 10 km peuvent
durer une demi-journ´ee tandis que les perturbations cycloniques de l’ordre de 1000 km
ont des dur´ees de vie allant de quelques jours `a quelques semaines (Stull, 2000).
Stull (1988) a propos´e une classification des ph´enom`enes atmosph´eriques en fonction de
leur ´echelle spatio-temporelle (Fig. 1.1). Les ´echelles (larges) plan´etaires et synoptiques ne
sont pas d´ecrites dans ce sch´ema. L’´echelle plan´etaire est caract´eris´ee par une dimension
6Chapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude
bibliographique 7
Figure 1.1: Classification des ph´enom`enes atmosph´eriques en fonction de leur ´echelle
spatio-temporelle (Orlanski, 1975; Stull, 1988).
spatiale de l’ordre de grandeur de 10.000 km (la circonf´erence de la Terre repr´esentant
4 fois cette valeur) et une dimension temporelle allant de plusieurs semaines `a plusieurs
ann´ees. Les ph´enom`enes d’´echelle plan´etaire sont associ´es aux climats et incluent les circulations
li´ees aux ondes de Rossby, `a l’ENSO (” El Ni˜no-Southern Oscillation ”), ou les
circulations d’Hadley.
L’´echelle synoptique a une dimension spatiale d’un millier de kilom`etres et une dimension
temporelle de plusieurs jours. Elle correspond aux circulations g´en´er´ees par l’intensit´e et
la position des centres anticycloniques et d´epressionnaires (comme les aliz´es).
La m´eso-´echelle s’´etend sur un espace horizontal allant de 200 km `a plusieurs centaines de
m`etres et un espace temporel allant de quelques jours `a la demi-heure (Fig. 1.1). Plusieurs
sous-´echelles sont d´efinies dans la m´eso-´echelle : la m´eso-α (les cyclones et les fronts), la
m´eso-γ (les jets de basses couches, les amas de nuages), la m´eso-δ (les orages, les effets
urbains) et la micro-α (les couches limites atmosph´eriques, les nuages cumuliformes).
Les ph´enom`enes comme la turbulence, avec des ´echelles spatiales inf´erieures `a 3 km et des
´echelles de temps inf´erieures `a l’heure, sont class´es dans la micro-´echelle. La m´eso-´echelle et
la micro-´echelle semblent confondues dans les sous-´echelles : m´eso-δ et micro-α (Fig. 1.1).
Cette zone d’imbrication inclut les ´ecoulements locaux de la couche limite atmosph´erique
(comme les brises de terre–mer et les ´ecoulements catabatiques–anabatiques). Les ´etudes
de pollution atmosph´erique comme la dispersion de panaches de polluants s’appliquent
aussi dans le domaine de la micro-´echelle.
L’ensemble des ph´enom`enes m´et´eorologiques sont bien class´es dans des ´echelles d’espace
et de temps, leur mod´elisation est donc simplifi´ee.Chapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude
bibliographique 8
1.2 M´eso-´echelle et micro-´echelle : circulations locales
de couche limite atmosph´erique
Dans cette partie, la description des ph´enom`enes de couche limite atmosph´erique, se
produisant `a la m´eso- et `a la micro-´echelle, est bas´ee sur les d´efinitions de Stull (1988).
1.2.1 Couche limite atmosph´erique (CLA)
1.2.1.1 D´efinition
La troposph`ere est la r´egion dense et habitable de l’atmosph`ere (elle regroupe 80% de
sa masse totale). La troposph`ere s’´etend du sol jusqu’`a une altitude moyenne de 11 km,
cependant seuls les premiers kilom`etres sont en g´en´eral modifi´es par les ph´enom`enes se
produisant `a la surface de la Terre. Stull (1988) a d´efini la couche limite atmosph´erique
(CLA) comme la partie de la troposph`ere qui est directement influenc´ee par la pr´esence
de la surface de la Terre avec un temps de r´eponse inf´erieur ou ´egal `a l’heure. Les for¸cages
incluent la friction, l’´evapo-transpiration, le bilan radiatif, la topographie. La hauteur de
la CLA varie en fonction des variables spatio-temporelles, avec des valeurs comprises entre
quelques centaines de m`etres `a quelques kilom`etres. Les variations diurnes de la temp´erature
de la CLA sont dues aux processus de transports, induits par le r´echauffement et le
refroidissement du sol (rayonnement solaire). La turbulence est un processus de transport
majeur.
1.2.1.2 Structure de la CLA associ´ee au cycle diurne
Stull (1988) a ´etudi´e l’´evolution diurne de la structure de la CLA terrestre dans des r´egions
anticycloniques (Fig. 1.2). La CLA passe par trois ´etats principaux : la couche m´elang´ee,
la couche r´esiduelle et la couche limite stable. La couche m´elang´ee peut ˆetre divis´ee en
couche nuageuse et une couche sous-nuageuse. La partie basse de la CLA, la couche de
surface, est d´efinie comme une couche de flux 1
constants donc avec des flux turbulents
relativement uniformes sur l’axe vertical. Une zone d’entrainement fortement stable, de
turbulence intermittente, s´epare la couche m´elang´ee de l’atmosph`ere libre. Durant la nuit,
cette zone d’entrainement laisse place `a une couche d’inversion non turbulente (aussi
appel´ee “capping”, Fig. 1.2).
1. Transport de mati`ere ou d’´energie `a travers une surfaceChapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude
bibliographique 9
Figure 1.2: Evolution temporelle de la structure verticale de la couche limite ´
atmosph´erique terrestre dans des r´egions anticycloniques (Stull, 1988).
Couche de m´elange
La couche de m´elange se d´eveloppe durant la journ´ee avec une hauteur maximale atteinte
avant midi (Fig. 1.2). Dans cette couche, la turbulence est g´en´eralement induite par la
convection. Les sources de convection sont : le transfert de chaleur provenant du sol irradi´e
par les rayons du soleil et le refroidissement radiatif (dans les fr´equences de l’infra-rouge)
au sommet des nuages.
Couche r´esiduelle
Environ une heure avant le coucher du soleil, en absence d’advection d’air froid, les thermiques
de la couche de m´elange ne se d´eveloppent plus. A cet instant, la couche de `
m´elange commence `a se d´ecomposer en une couche r´esiduelle et une couche dite nocturne
(Fig. 1.2). La couche r´esultante est appel´ee couche r´esiduelle parce que ses conditions
thermodynamiques initiales sont les mˆemes que celles de la couche de m´elange en train
de disparaˆıtre.Chapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude
bibliographique 10
Couche limite stable
Au cours de la nuit, la partie basse de la couche r´esiduelle se transforme en une couche
limite stable (Fig. 1.2). Cette couche est caract´eris´ee par une turbulence quasi-nulle et
un vent calme au niveau du sol. En cons´equence, les polluants ´emis dans la couche limite
stable se dispersent peu sur l’axe vertical. Pour ces conditions de stabilit´e, des ´ecoulements
particuliers peuvent se produire comme des vents catabatiques dans des r´egions orographiques
ou des brises de terre dans des r´egions cˆoti`eres. Ces deux ´ecoulements particuliers
seront d´ecrits dans la sous-section 1.2.2.
1.2.1.3 Vent moyen, ondes et turbulence
Les ´ecoulements locaux (se produisant sur un site d´efini) peuvent ˆetre divis´es en trois
cat´egories : le vent moyen, les ondes et la turbulence. Chacune de ces cat´egories existe
dans la CLA, o`u le transport des quantit´es comme la vapeur d’eau (humidit´e), la chaleur,
les mouvements (tourbillons) et les polluants, est domin´e par le vent moyen sur l’axe horizontal
et par la turbulence sur l’axe vertical. Le vent moyen est responsable de l’advection
assurant le transport horizontal rapide. Les ordres de grandeur classiques de vitesse du
vent sont compris entre 2 et 10 m.s-1. La friction induite pr`es du sol, g´en`ere un profil de
vitesse particulier (r´eduction continue de la vitesse en se rapprochant du sol), et donc une
vitesse du vent moyen plus faible. Les vitesses verticales du vent moyen sont de l’ordre du
millim`etre au centim`etre par seconde.
Les ondes transportent principalement la quantit´e de mouvement et l’´energie. Ces ondes
peuvent ˆetre localement g´en´er´ees par le cisaillement du vent moyen et du vent orographique.
La CLA se distingue du reste de l’atmosph`ere par la forte fr´equence de la turbulence au
voisinage du sol. La turbulence modifie les conditions de la CLA en fonction des for¸cages
de surface. Elle est superpos´ee au vent moyen, et se manifeste par des mouvements tourbillonnaires
(dits “eddies“ en anglais) de diff´erente taille imbriqu´es les uns dans les autres.
Les tourbillons les plus grands ont une taille proche de la hauteur de la CLA et sont entretenus
directement par les transferts de chaleur g´en´er´es par le sol irradi´e (pour les vents
thermiques de la CLA), par la friction du sol ou par le franchissement d’obstacle (pour les
sillages turbulents). Ces grands tourbillons peuvent ˆetre observ´es avec les boucles form´ees
par un panache de fum´ee. Les plus petits tourbillons, de l’ordre du millim`etre, sont tr`es
faibles `a cause des effets dissipatifs de la viscosit´e (friction inter-mol´eculaire qui transforme
les mouvements en chaleur).Chapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude
bibliographique 11
Dans la litt´erature, les ´etudes de la turbulence et des ondes de CLA s´eparent les variables
(comme la temp´erature ou le vent) en une composante moyenne et une composante de perturbation
en respectant les r`egles dites de Reynolds (Boussinesq, 1887; Reynolds, 1947).
La partie moyenne repr´esente les effets de la temp´erature moyenne ou du vent moyen,
tandis que la partie de perturbation repr´esente l’effet des ondes ou celui de la turbulence.
1.2.2 Circulations locales g´en´er´ees par les conditions de terrain
Stull (1988) a d´ecrit les circulations locales dans des conditions de vents faibles et calmes.
1.2.2.1 R´egions cˆoti`eres : brises de mer–terre
L’importante capacit´e calorifique des oc´eans inhibe les variations diurnes de la temp´erature
de surface de l’eau tandis que la surface de la terre, caract´eris´ee par une faible
capacit´e calorifique et une faible conductivit´e mol´eculaire, se r´echauffe et se refroidit
consid´erablement durant le cycle diurne. Donc, durant la journ´ee, la terre est plus chaude
que la mer et durant la nuit, la terre est plus froide.
Brises de mer
Pendant la matin´ee, apr`es la disparition de la couche limite stable, l’air commence `a
s’´elever au-dessus du sol chaud et l’air provenant de la mer, plus froid, commence `a le
remplacer. La brise de mer se met en place. L’extension de la brise de mer `a l’int´erieur
des terres est d´elimit´ee par un front. Ce front est marqu´e par une zone de convergence,
une chute de la temp´erature de quelques degr´es Celsius, une augmentation de l’humidit´e
et des mouvements ascendants de l’ordre de 0,5 `a 2,5 m.s-1. Un ´ecoulement de retour vers
la mer peut apparaˆıtre au-dessus pour fermer la circulation de brise de mer. En absence
de vent synoptique, le front de brise peut progresser `a l’int´erieur des terres (entre 20 km
et 50 km de distance `a la cˆote), avec une vitesse comprise entre 1 m.s-1 et 5 m.s-1
.
Brises de terre
La nuit, la surface de la terre se refroidissant plus rapidement que celle de l’eau de la mer,
le gradient horizontal de temp´erature est invers´e. Une brise de terre se met en place :
l’air froid terrestre souffle en direction de la mer plus chaude. Une circulation de retourChapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude
bibliographique 12
peut apparaˆıtre au-dessus : l’air chaud marin s’´el`eve et souffle en direction de la terre. La
circulation de brise de terre est moins intense que celle de la brise de mer.
1.2.2.2 R´egions orographiques : vents anabatiques–catabatiques
Ces ´ecoulements orographiques sont associ´es `a une diff´erence de temp´erature horizontale
entre l’air `a la surface des pentes de la montagne et l’air environnant `a la mˆeme altitude.
Vents anabatiques
Pendant la journ´ee, la surface des pentes de la montagne chauff´ees par le rayonnement
solaire r´echauffe `a son tour l’air proche du sol, qui devient plus chaud que l’air environnant
pour une mˆeme altitude. La flottabilit´e positive induit qu’un ´ecoulement anabatique se
d´eveloppe : l’air chaud va longer les pentes jusqu’au sommet de la montagne. L’air chaud
peut ensuite s’´elever au-dessus de la crˆete de la montagne et former des cumulus dans
certaines conditions d’humidit´e.
Vents catabatiques
La nuit, le refroidissement radiatif des pentes de la montagne refroidit l’air proche de
la surface. Une masse d’air plus froide que l’air environnant s’accumule sur le relief. La
flottabilit´e n´egative g´en`ere un ´ecoulement de gravit´e descendant les pentes : le vent catabatique.
Cet ´ecoulement a, en g´en´eral, une faible ´epaisseur de quelques dizaines de m`etres
et des vitesses de l’ordre de 1 `a 5 m.s-1 (Simpson, 1999).
1.3 Simulations num´eriques de la descente dynamique
de la m´eso-´echelle `a la micro-´echelle
Dans la section 1.1, nous avons montr´e que l’ensemble des ph´enom`enes m´et´eorologiques
sont class´es dans des ´echelles d’espace et de temps. Par cons´equent, leur mod´elisation
num´erique est simplifi´ee : chaque ph´enom`ene est simul´e aux ´echelles d’espace et de temps
lui correspondant. Pour des raisons de coˆut des calculs num´eriques, il est plus simple de
simuler des ph´enom`enes de large ´echelle, car ils sont associ´es `a des espaces importants
qui peuvent ˆetre repr´esent´es par un nombre plus faible de grandes mailles. A ces grandes `Chapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude
bibliographique 13
´echelles, les fluctuations sur les circulations sont tr`es faibles. Il en r´esulte des pas de temps
de calcul plus importants.
Les ph´enom`enes m´et´eorologiques associ´es `a des ´echelles spatio-temporelles diff´erentes,
interagissent entre eux (e.g. les circulations m´eso-´echelles dans un cyclone et les tourbillons
turbulents qui l’animent `a la micro-´echelle). Pour ´etudier ces interactions d’´echelles, il est
n´ecessaire d’effectuer une mod´elisation avec une imbrication d’´echelles. La notion de descente
d’´echelle est un terme g´en´erique pour d´efinir le passage d’une simulation `a l’´echelle
donn´ee `a une autre simulation `a l’´echelle plus fine (Fig. 2.10).
1.3.1 Descente d’´echelle
En simulation m´et´eorologique, il existe deux types de descentes d’´echelle dynamique entre
un domaine parent et son domaine imbriqu´e de r´esolution plus ´elev´ee. La descente d’´echelle
sans retour d’information du domaine imbriqu´e vers le domaine parent est appel´ee ” oneway
”. La descente d’´echelle avec un retour d’information du domaine imbriqu´e vers le
domaine parent est appel´ee ” two-way ”. Le transfert des conditions atmosph´eriques du
domaine imbriqu´e vers le domaine parent permettrait d’am´eliorer les simulations m´et´eorologiques.
Dans les mod`eles m´et´eorologiques m´eso-´echelles comme le Weather Research
and Forecasting WRF, le rapport de r´esolution entre le domaine imbriqu´e et le domaine
parent, est pr´econis´e `a [3 :1] (Skamarock et al., 2008).
1.3.2 Spectre de la turbulence : ” terra incognita ” (Wyngaard,
2004)
Dans la mod´elisation m´eso-´echelle, l’´echelle l de la turbulence contenant l’´energie et les
flux, est tr`es petite devant l’´echelle ∆ du filtre spatial de r´esolution des ´equations du
mouvement, donc la turbulence ne peut pas ˆetre r´esolue (Wyngaard, 2004). Dans ce
cas la turbulence est enti`erement mod´elis´ee par la fermeture des sch´emas de moyenne
d’ensemble. Dans la mod´elisation micro-´echelle Large Eddy Simulation (LES), c’est le cas
contraire, l est grand devant ∆, la turbulence de grande ´echelle est r´esolue et celle de petite
´echelle (dissipation) est mod´elis´ee. Les mod`eles de fermeture de la turbulence ne sont pas
con¸cus pour ˆetre utilis´es quand l et ∆ sont du mˆeme ordre de grandeur, Wyngaard (2004)
a appel´e cet intervalle num´erique : la ” terra incognita ”.Chapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude
bibliographique 14
1.3.3 M´eso-´echelle : principaux sch´emas de moyenne d’ensemble
1D (Shin and Hong, 2011)
La couche limite atmosph´erique se compose de la couche limite de surface (CLS, comprise
entre 0 et 150 m AGL 2
) et de la couche limite plan´etaire (CLP, comprise entre le sommet
de la CLS et le sommet de la CLA). Dans les mod`eles m´et´eorologiques, les ph´enom`enes de
couche limite atmosph´erique sont param´etr´es par un sch´ema de couche limite de surface
et un sch´ema de couche limite plan´etaire. Comme d´ecrit par Shin and Hong (2011),
dans les sch´emas de couche limite plan´etaire, les flux turbulents sous-mailles sont calcul´es
en utilisant les variables moyennes pronostiqu´ees (comme la temp´erature, le rapport de
m´elange, les vitesses horizontales), suivant les ´equations de diffusion verticale du type :
∂C
∂t = −
∂
∂zw0c
0 =
∂
∂z
Kc
∂C
∂z (1.1)
o`u Kc est la diffusivit´e turbulente pour la variable moyenne C, t le temps, z la coordonn´ee
verticale, et w
0
la fluctuation de la vitesse verticale.
1.3.3.1 Sch´ema YSU : fermeture au premier ordre avec un m´elange non-local
Le sch´ema YSU (Hong et al., 2006) ne n´ecessite pas l’addition de nouvelles ´equations pronostiques
pour exprimer les effets de la turbulence sur les variables moyennes (Shin and
Hong, 2011). En couche limite convective, ce sch´ema est bas´e sur le profil K en d´eterminant
la diffusivit´e turbulente Kc (fonction du cisaillement du vent local et du nombre de Richardson
local dans l’atmosph`ere libre). En addition de la diffusion locale (Eq. 1.1), le
sch´ema YSU consid`ere le m´elange non-local par des grands tourbillons convectifs (Shin
and Hong, 2011). Pour exprimer ce m´elange non-local, un terme d’ajustement de gradient
non-local (γc) est ajout´e :
∂C
∂t =
∂
∂z
Kc
∂C
∂z − γc
− (w0c
0
)h
z
h
3
(1.2)
avec h la hauteur de la couche limite convective. Le sch´ema YSU traite explicitement
les processus d’entrainement au sommet de la couche limite plan´etaire. En couche limite
stable, la version du sch´ema YSU am´elior´ee par Hong (2010) est bas´ee sur le nombre de
Richardson global entre la couche de surface et le sommet de la couche limite (Shin and
Hong, 2011).
2. Au-dessus du sol, de l’anglais : Above Ground LevelChapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude
bibliographique 15
1.3.3.2 Sch´ema MYJ : fermeture TKE `a l’ordre 1,5 avec un m´elange local
Le sch´ema MYJ (Janji´c, 1990) n´ecessite l’addition d’une ´equation pronostique de l’´energie
cin´etique turbulente, exprim´ee par l’accronyme anglais TKE (Turbulent Kinetic Energy) :
Kc = l
√
eSc (1.3)
avec e la TKE, l la longueur de m´elange (d´efinie par Prandtl comme la distance sur
laquelle une perturbation transporte des propri´et´es d’une parcelle d’air) et Sc le coefficient
de proportionnalit´e (Shin and Hong, 2011). Le sch´ema MYJ applique le m´elange local en
tenant compte de la diffusivit´e turbulente locale existant entre le plus bas et le plus haut
niveau vertical, en couche limite convective et stable. L’entrainement est param´etr´e par
le calcul de Kc pr`es du sommet de la couche limite plan´etaire.
1.3.4 Micro-´echelle : sch´emas Large Eddy Simulation (LES) 3D
(Mirocha et al., 2010)
Figure 1.3: Sch´ema du spectre de l’´energie en fonction de la taille des structures
turbulentes.
Les simulations aux grandes ´echelles (LES, de l’anglais : Large Eddy Simulation) ont pour
principe de calculer par r´esolution num´erique directe les structures turbulentes de grande
taille et de mod´eliser celles de petite taille (Fig. 1.3). Dans la CLA, les grands tourbillons
sont de l’ordre d’une centaine de m`etres, mais leur structure varie selon l’´ecoulement,Chapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude
bibliographique 16
tandis que les petits tourbillons ont un caract`ere universel.
Les m´ethodes LES ont pour avantages : la simulation des ´ecoulements complexes de la
micro-´echelle et la r´eduction de la puissance de calcul requise par rapport `a la simulation
num´erique directe (DNS, de l’anglais : Direct Numerical Simulation).
La mod´elisation LES repose sur la r´esolution explicite en 3D des ´echelles de production
et de transport de l’´energie turbulente atmosph´erique, tandis que la partie petite ´echelle
du spectre de la turbulence, correspondant `a la dissipation de l’´energie turbulente, est
´elimin´ee par l’interm´ediaire d’un filtre spatial (Mirocha et al., 2010). Les effets du filtrage
des structures de ces ´echelles, sur le composant r´esolu de l’´ecoulement, sont mod´elis´es par
un mod`ele de fermeture dit ” sub-filter scale ” (SFS).
Mirocha et al. (2010) ont d´ecrit les ´equations LES de la mani`ere suivante, les variables
r´esolues des structures grandes ´echelles ´etant not´ees avec un tilde, nous avons :
∂u˜i
∂t +
∂(˜uiu˜j )
∂xj
= −
1
ρ˜
∂p˜
∂xi
−
∂τij
∂xj
, (1.4)
avec τij = (ugiuj ) − (˜uju˜i). (1.5)
u˜i,j sont les vitesses r´esolues (i, j = 1, 2, 3, correspondant aux 3 composantes de la vitesse,
respectivement, u, v et w) ; ˜p est la pression r´esolue ; ˜ρ est la densit´e r´esolue ; xi
, xj
font
r´ef´erence aux coordonn´ees spatiales avec i, j = 1, 2, 3 indiquant respectivement les composants,
x, y et z. τij d´efinit la contrainte de cisaillement `a la sous-´echelle du filtre (SFS)
induit par les petites structures (petits tourbillons). Cette force de surface est param´etr´ee
par un mod`ele de contrainte SFS.
Les deux mod`eles de contrainte SFS principalement utilis´es dans la bibliographie sont :
le mod`ele de Smagorinsky (Lilly, 1967; Smagorinsky, 1963) et le mod`ele bas´e sur la fermeture
SFS TKE d’ordre 1,5 (Lilly, 1967). Chacun de ces mod`eles est de la forme de
viscosit´e turbulente (les effets de la turbulence sont d´ecrits par une analogie avec la viscosit´e
mol´eculaire) :
τij = −2νT S˜
ij , (1.6)
avec νT le coefficient de viscosit´e turbulente et S˜
ij = 1/2[(∂u˜i/∂x˜j )+ (∂u˜j/∂x˜i)] le tenseur
de d´eformation des grandes structures (Mirocha et al., 2010).Chapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude
bibliographique 17
1.3.4.1 Fermeture SFS Smagorinsky
Le coefficient de viscosit´e d’eddy de Smagorinsky est calcul´e d’apr`es la formule :
νT = (CSl)
2max[0,(S˜
ijS˜
ij − Pr−1N
2
)
1/2
]. (1.7)
CS est le coefficient de Smagorinsky. L’´echelle de longueur est donn´ee par l = (∆x∆y∆z)
1/3
.
Le nombre de Prandtl turbulent Pr est d´efini par µCp/λ, avec µ la viscosit´e dynamique
(kg.m-1.s-1), Cp la capacit´e thermique massique (J.kg-1.K-1) et λ la conductivit´e thermique
(W.m-1.K-1). Le nombre de Prandtl repr´esente le rapport entre la diffusivit´e de la quantit´e
de mouvement et la diffusivit´e thermique. N2
est la fr´equence de Brunt-V¨ais¨al¨a. Elle
repr´esente la stabilit´e de la couche d’air : si la parcelle d’air d´eplac´ee verticalement oscille
autour de sa position d’´equilible N2
est positive, dans le cas contraire N2
est inf´erieure ou
´egale `a 0. L’´equation 1.7 induit une r´eduction de la contrainte quand la stabilit´e augmente
jusqu’`a une limite de la disparition du m´elange, quand N2
est tr`es important par rapport
aux d´eformations. Ceci limiterait l’utilisation du mod`ele Smagorinsky dans des conditions
de forte stabilit´e (Mirocha and Kirkil, 2010).
1.3.4.2 Fermeture SFS TKE d’ordre 1.5
Dans ce mod`ele le coefficient de viscosit´e d’eddy est d´efini par :
νT = Cl√
es
, (1.8)
o`u es est l’´energie cin´etique turbulente sous-maille, et C = 0, 15. Quand cette fermeture
est s´electionn´ee, le mod`ele WRF int`egre l’´equation pronostique suivante, de la TKE du
SFS (Mirocha et al., 2010) :
∂t(µdes)+Transport = µd(Production cisaillement+Production thermique+Dissipation)
(1.9)
avec µd, la masse de la colonne d’air sec et le terme de dissipation mod´elis´e par l’expression
−Ce
3/2
s /l.Chapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude
bibliographique 18
1.3.5 Descente d’´echelle : couplage d’un sch´ema d’ensemble et
d’un sch´ema LES
Les simulations num´eriques des circulations locales incluant une descente d’´echelle (” oneway
” et ” two-way ”) depuis les dimensions synoptiques jusqu’`a celles de la m´eso-echelle
sont largement r´epandues dans la litt´erature et ont montr´e leur efficacit´e (Carlis et al.,
2010; C´ec´e et al., 2014; Jury et al., 2009; Lef`evre et al., 2010; Nguyen et al., 2010; Seaman
et al., 2012; Yang and Chen, 2005). En revanche la descente d’´echelle (” one-way
” et ” two-way ”) depuis la m´eso-´echelle (sch´ema de moyenne d’ensemble 1D) vers la
micro-´echelle (Large Eddy Simulation 3D) est tr`es r´ecente et peu document´ee (Mirocha
and Kirkil, 2010). Cette imbrication d’´echelle n´ecessite d’importants moyens de calcul en
comparaison avec les simulations m´eso-´echelles. Ces besoins ´elev´es de calcul sont principalement
li´es au maillage. La r´esolution minimale requise en LES est de l’ordre de la
centaine de m`etres, alors que les sch´emas de moyenne d’ensemble sont limit´es `a la r´esolution
du kilom`etre. En g´en´eral, le rapport de r´esolution d’imbrication entre deux domaines
est de 3 :1. Dans le cas de l’imbrication m´eso-LES, il sera donc n´ecessaire d’utiliser des
domaines interm´ediaires situ´ees dans la ” terra incognita ” (Wyngaard, 2004) du spectre
de la turbulence. Enfin, la finesse du maillage LES induit des dur´ees de calcul plus longues,
associ´ees `a la diminution du pas de temps et `a l’augmentation de la fr´equence d’appel des
sch´emas de mod´elisation de la physique.
La plupart des ´etudes traitant le sujet ont ´et´e r´ealis´ees `a partir de l’utilisation du syst`eme
coupl´e WRF-LES.
Dans le cas d’imbrication id´ealis´ee (sans couplage avec la m´eso-´echelle) de deux domaines
LES en ” two-way ”, Moeng et al. (2007) ont montr´e un bon transfert des conditions
turbulentes du domaine imbriqu´e vers le domaine parent. Moeng et al. (2007) ont ´enonc´e
les probl`emes qui seraient rencontr´es dans le cas du transfert de ces conditions turbulentes
d’un domaine LES 3D vers un domaine de moyenne d’ensemble 1D m´eso-´echelle :
la diff´erence de pr´ediction du transport turbulent entre les deux domaines (induisant des
biais sur les champs de vent et de temp´erature) et le temps de latence aux conditions
limites (passage des mouvements turbulents LES dans les ´ecoulements laminaires m´eso-
´echelles).
Zhu (2008b) a analys´e un cas r´eel de transport turbulent dans l’ouragan Ivan. Il a utilis´e
simultan´ement 6 domaines avec une r´esolution horizontale comprise entre 8100 m et
100 m. Dans les 3 premiers domaines (m´eso-´echelle), les circulations de la couche limite
cyclonique ont ´et´e r´esolues par le sch´ema YSU. Dans les 3 autres domaines (micro-´echelle),
le mod`ele LES de Smagorinsky a ´et´e s´electionn´e pour r´esoudre les grands tourbillons deChapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude
bibliographique 19
la turbulence. Les r´esultats WRF-LES du vent de surface (moyenn´e toutes les 10 min)
ont montr´e une bonne ad´equation avec les donn´ees d’observation. Par une ´etude similaire
WRF-LES, Zhu (2008a) a montr´e que les vents d´evastateurs de l’ouragan Katrina, lors de
son arriv´ee sur les cˆotes am´ericaines, avaient pour principale origine les grands tourbillons
de la turbulence.
L’´evaluation de la ressource ´eolienne, la pr´evision de la puissance ´electrique g´en´er´ee,
la conception d’une ferme ´eolienne, n´ecessitent l’analyse, en conditions m´et´eorologiques
r´eelles, des ´ecoulements moyens et turbulents. L’imbrication m´eso-´echelle – ´echelle large
eddy (” one-way ” et ” two-way ”) commence aussi `a ˆetre appliqu´ee dans le domaine
de l’´energie ´eolienne (Liu et al., 2010; Lundquist et al., 2010; Marjanovic et al., 2010).
Liu et al. (2010) ont montr´e la capacit´e du syst`eme WRF-LES, incluant l’assimilation
de donn´ees d’observation non-maill´ees, `a pr´edire les effets locaux du vent dans une ferme
´eolienne.
Talbot et al. (2012) ont men´e les travaux les plus r´ecents sur l’imbrication de domaines
LES (dont la plus haute r´esolution est de 50 m) dans les domaines WRF m´eso-´echelles. Ils
ont analys´e les performance du syst`eme WRF-LES pour des situations m´et´eorologiques
r´eelles. Talbot et al. (2012) ont r´ealis´e la descente d’´echelle en deux ´etapes, `a l’aide de trois
domaines m´eso-´echelles (de r´esolutions respectives, 12150 m, 4050 m et 1350 m) et de trois
domaines micro-´echelles (de r´esolutions respectives, 450 m, 150 m et 50 m). Le mod`ele
de moyenne d’ensemble YSU a ´et´e utilis´e pour la m´eso-´echelle. Les sorties du domaine
m´eso-´echelle de plus haute r´esolution (1350 m) ont ensuite ´et´e interpol´ees lin´eairement en
temps et en espace pour le for¸cage du domaine LES de plus faible r´esolution (450 m). Les
mod`eles sous-mailles TKE ordre 1,5 et Smagorinsky ont ´et´e test´es en LES. Dans le domaine
de plus haute r´esolution (50 m), Talbot et al. (2012) ont constat´e que les variations
de temp´erature ´etaient bien simul´ees contrairement `a celles de l’humidit´e sp´ecifique. Les
vitesses et les directions du vent simul´e pr´esentaient d’importantes erreurs particuli`erement
durant la nuit. Talbot et al. (2012) n’ont pas remarqu´e de diff´erences significatives
entre les simulations micro-´echelles Smagorinsky et TKE ordre 1,5.
1.4 Simulation num´erique de la dispersion de polluants
: applications du mod`ele FLEXPART-WRF
L’analyse du transport de polluants dans l’air est essentiel dans la pr´evention des risques
sur la sant´e, le suivi de la qualit´e de l’air (pic de pollution r´ecent `a Paris, poussi`eres
du Sahara dans l’arc des Petites Antilles), et la s´ecurit´e a´erienne (´eruptions en 2010 duChapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude
bibliographique 20
volcan Eyjafj¨oll en Islande et du volcan de la Soufri`ere de Montserrat). La connaissance
des champs de vent aux diff´erentes ´echelles, macroscopiques et microscopiques, permet de
pr´edire les trajectoires des particules. Les deux m´ethodes principalement connues sont : la
m´ethode eul´erienne et la m´ethode lagrangienne. La m´ethode eul´erienne consiste `a suivre
l’ensemble des concentrations de particule en chaque point du domaine. Cette approche
est tr`es gourmande en m´emoire et en temps de calcul. La m´ethode lagrangienne consiste `a
suivre une particule ou un groupe de particule. Dans cette section, nous nous focaliserons
sur les m´ethodes lagrangiennes et leurs couplages avec le mod`ele m´et´eorologique m´eso-
´echelle WRF.
1.4.1 G´en´eralit´es sur les mod`eles lagrangiens de dispersion de
particules (Hegarty et al., 2013a,b)
Les mod`eles lagrangiens de dispersion de particules suivent un ensemble de particules en
sens direct (” forward ”) depuis une r´egion source et en sens indirect (” backward ”)
depuis un r´ecepteur (lieu de mesures) (Hegarty et al., 2013a). Le transport de chacune
des particules est bas´e sur les champs de vents moyens (provenant d’un mod`ele num´erique
de pr´evision m´et´eorologique) et la composante turbulente du vent obtenue par un mod`ele
sous-maille (Hegarty et al., 2013a). L’´evaluation des mod`eles lagrangiens les plus utilis´es,
HYSPLIT (Hybrid Single Particle Lagrangian Integrated Trajectory), STILT (Stochastic
Time-Inverted Lagrangian Transport) et FLEXPART (FLEXible PARTicle), a montr´e
que ces mod`eles ont les mˆemes performances et que la pr´ecision des simulations d´epend
principalement des donn´ees m´et´eorologiques utilis´ees comme condition initiale et limite
(Hegarty et al., 2013a,b).
1.4.2 Quelques applications du mod`ele FLEXPART-WRF
Le syst`eme FLEXPART-WRF (Brioude et al., 2013) repr´esente le mod`ele lagrangien de
dispersion de particules FLEXPART (Stohl et al., 2005) qui int`egre les champs m´et´eorologiques
m´eso-´echelles du mod`ele WRF (Skamarock et al., 2008) avec le pas de temps
souhait´e. Nous d´ecrirons le mod`ele FLEXPART-WRF dans la section 2.4 du rapport.
Landgren (2011) a utilis´e le mod`ele FLEXPART-WRF (incluant 3 domaines imbriqu´es
de r´esolutions respectives, 9, 3 et 1 km) pour examiner les ´emissions de gaz de trois
volcans : Popocat´epetl (Mexique), Tungurahua (Equateur) et Nyiragongo (R´epublique ´
d´emocratique du Congo). Landgren (2011) a constat´e que le mod`ele FLEXPART-WRFChapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude
bibliographique 21
simulait bien les ´emissions de gaz volcaniques mˆeme pour des petites ´echelles (1 km).
Globalement, les mesures de concentration de SO2 ont montr´e une bonne performance du
mod`ele dans deux tiers des cas. Cependant les hauteurs et largeurs du panache ´etaient
biais´ees, le mod`ele pr´esentait une importante propagation du panache. D’apr`es Landgren
(2011), l’am´elioration des donn´ees m´et´eorologiques d’entr´ee pourrait r´eduire ces biais.
Dans une ´etude exp´erimentale et num´erique, de Foy et al. (2011) ont examin´e les panaches
de polluants affectant le bassin du centre-ville de Mexico. Les mesures lidar ont
´et´e compar´ees aux sorties mod`eles FLEXPART-WRF pour plusieurs groupes d’´emissions :
les ´emissions urbaines, les feux de forˆet et les poussi`eres soulev´ees par le vent. Le mod`ele
´etait suffisamment performant pour caract´eriser correctement les types d’a´erosols et leur
ˆage (de Foy et al., 2011).
A l’aide de FLEXPART-WRF, ` Angevine et al. (2013) ont aussi men´e une ´etude du transport
de polluants multi-sources. Ces travaux concernent plusieurs r´egions de la Californie
et deux types de traceurs : les ´emissions automobiles (CO) et l’´emission agricole d’ammoniac.
Sur plusieurs sites de comparaison, les sorties mod`eles ´etaient qualitativement
fid`eles aux observations.
Sandeepan et al. (2013) ont montr´e la capacit´e du mod`ele FLEXPART-WRF `a reproduire
l’effet de serpentement d’un panache bi-modal (p´eriodicit´e de 30 min) durant un
´ecoulement catabatique.
1.5 Etat de l’art sur les circulations locales g´en´er´ees ´
par des ˆıles tropicales
Les effets m´ecaniques des ˆıles sur le flux d’aliz´es continu sont caract´eris´es par un nombre
de Froude local Fr qui est d´efini par (U/Nhm), o`u U est la vitesse du vent, hm est la
hauteur de l’obstacle, et N est la fr´equence de flottabilit´e.
De mani`ere g´en´erale, la litt´erature et en particulier Beucher (2010) analyse les circulations
locales pour chacun des trois types d’ˆıles tropicales suivants : les ˆıles larges (avec Fr ≥ 1
et une largeur > 50 km), les ˆıles montagneuses (avec Fr < 1), ou les ˆıles petites (avec
Fr ≥ 1 et une largeur ≤ 50 km).Chapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude
bibliographique 22
1.5.1 Circulations g´en´er´ees par les ˆıles tropicales larges (Fr ≥ 1
et une largeur > 50 km)
Les effets des ˆıles larges sur les vents synoptiques ont ´et´e examin´es pour les ˆıles Tiwi
(Oliphant et al., 2001) et Porto Rico (Jury et al., 2009; Malkus, 1955). Oliphant et al.
(2001) ont montr´e qu’avec une topographie plate de 8000 km2
, les ˆıles Tiwi g´en`erent leur
propre r´egime de circulations locales d’origine thermique, associ´e avec des brises de mer
le jour, et des brises de terre la nuit. Les simulations de la m´et´eorologie m´eso-´echelle
de Porto Rico, `a l’aide du mod`ele Weather Research and Forecast (WRF), ont indiqu´e
comment le r´echauffement diurne et l’orographie agissent sur la structure de la couche
limite convective et le flux d’aliz´es (Jury et al., 2009).
1.5.2 Circulations g´en´er´ees par les ˆıles tropicales montagneuses
(Fr < 1)
En g´en´eral, les ˆıles montagneuses comme l’archipel d’Hawaii (Carlis et al., 2010; Feng
and Chen, 1998; Nguyen et al., 2010; Reisner and Smolarkiewicz, 1994; Smith and Grubiac,
1993; Yang and Chen, 2005), la Nouvelle-Cal´edonie (Lef`evre et al., 2010), l’ˆıle de
la R´eunion (Lesou¨ef et al., 2011), ou les ˆıles des Petites Antilles comme Saint-Vincent
(Smith et al., 1997) et la Dominique (Minder et al., 2013; Smith et al., 2012) auraient
principalement des effets m´ecaniques sur le flux incident (blocage sur la cˆote au vent
et contournements, effets d’acc´el´eration de Venturi, panne de vent et tourbillons dans le
sillage) avec dans certains cas des circulations thermiques apparaissant sur leurs cˆotes
sous le vent.
Les r´esultats de l’´etude num´erique id´ealis´ee de Lesou¨ef et al. (2011) ont montr´e que le
r´egime des ´ecoulements locaux au-dessus de l’ˆıle de la R´eunion variait avec l’intensit´e des
aliz´es. Dans le cas de vitesse de vent synoptique nulle, des circulations thermiques sont
g´en´er´ees par les contrastes de temp´erature entre la terre et la mer, et entre l’air et les
pentes des montagnes. Pour une vitesse de vent synoptique de 5 m.s-1, le r´egime de vent
local est caract´eris´e par une convergence diurne et une divergence nocturne. Des brises
thermiques peuvent se produire sur la cˆote sous le vent. Pour une vitesse de vent synoptique
de 10 m.s-1, la convergence et la divergence de la circulation sont moins marqu´ees.
Les effets thermiques sont inhib´es par les forts aliz´es, cependant il y a des occurrences de
brises sur la cˆote sous le vent.
Durant la campagne de terrain Dominica Experiment (DOMEX), Minder et al. (2013);Chapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude
bibliographique 23
Smith et al. (2012) ont observ´e que deux types de r´egimes de vent local apparaissaient
sur la cˆote sous le vent de l’ˆıle montagneuse de la Dominique en fonction de l’intensit´e
des aliz´es. Des vitesses de vent synoptique inf´erieures `a 5 m.s-1 ´etaient associ´ees `a des
´ecoulements anabatiques sur les pentes au vent et sous le vent tandis que celles sup´erieures
`a 8 m.s-1 ´etaient associ´ees `a des fort courants descendant les pentes sous le vent du relief.
1.5.3 Circulations g´en´er´ees par les petites ˆıles (Fr ≥ 1 et une
largeur ≤ 50 km)
Les impacts thermiques des petites ˆıles sur la couche limite atmosph´erique marine ont
´et´e analys´es par des observations et des simulations num´eriques au-dessus de l’ˆıle de la
Barbade, dont le diam`etre est de 40 km (Mahrer and Pielke, 1976; Souza, 1972; Whitehall
et al., 2013) et au-dessus de l’ˆıle de Nauru, dans le Pacifique, dont le diam`etre est de 5 km
(Matthews et al., 2007; Savij¨arvi and Matthews, 2004). Ces ´etudes ont montr´e qu’avec un
important r´echauffement de la surface du sol, les petites ˆıles tropicales peuvent g´en´erer
leurs propres circulations d’origine convective.
Whitehall et al. (2013) ont men´e des simulations WRF d’un ph´enom`ene d’inondations
extrˆemes sur l’ˆıle de la Barbade, durant les aliz´es faibles (vitesse de vent inf´erieure `a
5 m.s-1). Les r´esultats de la mod´elisation ont indiqu´e que le d´eveloppement de nuages
de convection profonde ´etait conditionn´e par deux m´ecanismes de circulation locale.
Premi`erement, un syst`eme de brise de mer induisait une convergence de l’humidit´e dans
les basses couches. Deuxi`emement, la topographie de l’ˆıle (sommet `a 366 m AMSL), entraˆınait
une ´el´evation m´ecanique de cette masse d’air humide.
1.6 Etat de l’art sur l’archipel de la Guadeloupe ´
1.6.1 Contexte m´et´eorologique synoptique
L’archipel de la Guadeloupe est un ensemble d’ˆıles localis´e `a 61,5➦W et 16,3➦N dans la
partie centrale de l’Arc des Petites Antilles (Fig. 1.4). Ces ˆıles travers´ees par les aliz´es ont
un climat tropical insulaire caract´eris´e par deux saisons pr´edominantes (Br´evignon, 2003).
La premi`ere est une saison relativement s`eche avec des pr´ecipitations tr`es peu intenses, appel´ee
le carˆeme. Elle s’´etend de mi-janvier `a mars. La seconde, appel´ee l’hivernage, s’´etend
de juillet `a novembre. Elle se caract´erise par des cumuls de pluie plus ´elev´es. L’intensit´e desChapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude
bibliographique 24
Figure 1.4: Carte topographique GeBCO 08 (General Bathymetric Chart of the
Oceans IOC et al. (2003), 30 secondes d’arc de r´esolution) en m : (a) zone de la
Cara¨ıbe ; (b) l’Arc des Petites Antilles.
pr´ecipitations est le facteur marquant principalement la diff´erence entre ces deux saisons.
Les donn´ees d’observation de la station m´et´eorologique du Raizet (RZT, disque rouge,
Fig. 1.5), localis´ee en zone convective, indiquent qu’en f´evrier le cumul moyen mensuel est
de l’ordre de 60,6 mm tandis qu’en octobre il atteint 214,5 mm. Le cycle saisonnier est
une cons´equence de la variation annuelle de la latitude de la zone de convergence intertropicale
(ZCIT). Le cycle annuel des pr´ecipitations observ´ees `a la station m´et´eorologique
du Raizet indique que le carˆeme correspond `a la position la plus australe de la ZCIT,
soit 5➦S, et l’hivernage, `a la position la plus nord soit 10➦N. Br´evignon (2003) a d´ecrit
le r´egime des aliz´es arrivant sur l’Arc antillais. Les aliz´es sont g´en´er´es par l’anticyclone
des A¸cores dans l’Atlantique nord et soufflent vers les basses pressions ´equatoriales en
subissant une d´eviation vers la droite de leur mouvement, li´ee `a la force de Coriolis. La
direction et la force des aliz´es d´epend principalement de la position et de l’intensit´e des
centres anticycloniques et d´epressionnaires sur l’Atlantique. Durant l’ann´ee, les aliz´es sont
en g´en´eral mod´er´es (vitesse de l’ordre de 6 m.s-1). Le passage de perturbations tropicales,
subtropicales ou de fronts peut induire dans leur queue une panne d’aliz´es caract´eris´ee par
des vents tr`es faibles (vitesse inf´erieure `a 5 m.s-1). Le passage des cyclones tropicaux peut
g´en´erer de puissants vents tournants qui ont des vitesses comprises entre 20 et 70 m.s-1
.
1.6.2 Contexte m´et´eorologique local
L’archipel de la Guadeloupe comprend deux ˆıles principales (Fig. 1.5) : la Basse-Terre, une
ˆıle volcanique montagneuse avec une topographie complexe qui s’´el`eve jusqu’`a 1467 m (le
sommet du volcan de la Soufri`ere) et la Grande-Terre, un plateau calcaire avec une faibleChapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude
bibliographique 25
topographie qui s’´el`eve jusqu’`a 135 m. Ces deux ˆıles sont s´epar´ees par un canal ´etroit,
la Rivi`ere sal´ee. Ce dernier est bord´e par deux zones d’eaux peu profondes : Le Petit
Cul-de-sac Marin au sud et le Grand Cul-de-sac Marin au nord. D´esirade, Marie-Galante
et Les Saintes sont des petites ˆıles de l’archipel. La particularit´e de la Guadeloupe est la
combinaison de deux types de topographie (Fig. 1.5) : l’ˆıle montagneuse de la Basse-Terre
(Fr < 1 et une largeur ≤ 50 km) et la petite ˆıle, relativement plate, de la Grande-Terre
(Fr > 1 et une largeur ≤ 50 km).
Il y a tr`es peu d’´etudes traitant des circulations locales au-dessus de la Guadeloupe. Dans
la bibliographie, les donn´ees m´et´eorologiques d’observation proviennent principalement
de quatre stations M´et´eo-France (Raizet, D´esirade, Moule, et Grand-Bourg) et d’une
station cˆoti`ere du Laboratoire de Recherche en G´eosciences et Energie (LaRGE), situ´ee `a ´
Arnouville. Ces stations sont respectivement nomm´ees RZT, DES, MOU, GBD, et ARN
(Fig. 1.5).
Figure 1.5: Carte topographique (IGN, 50 m de r´esolution), avec la zone la plus
peupl´ee de l’archipel (rectangle noir), la d´echarge DCH (carr´e marron), la centrale
EDF (croix rouge), le campus de Fouillole (carr´e jaune), le mˆat instrument´e du
laboratoire LaRGE (ARN, triangle vert) et les 4 stations M´et´eo-France, Raizet (RZT,
disque rouge), Moule (MOU, ´etoile magenta), D´esirade (DES, carr´e bleu),
Grand-Bourg de Marie-Galante (GBD, losange noir).
1.6.2.1 Quelques aspects des vents locaux d’apr`es Br´evignon (2003)
En se basant sur des observations en mer et des donn´ees de stations terrestres, Br´evignon
(2003) a pr´esent´e quelques aspects du vent sur l’archipel. Ils ont d´efini trois r´egimes de
circulation locale. Le r´egime au vent : les vents synoptiques continus soufflent sans panneChapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude
bibliographique 26
de vent nocturne (cas de DES et MOU, Fig. 1.5). Le r´egime continental insulaire au milieu
de l’archipel, dans les zones terrestres autour du Grand Cul-de-Sac Marin et du Petit Culde-Sac
Marin (cas de ARN, RZT, GBD, Fig. 1.5), avec la nuit, le refroidissement radiatif
du sol qui induit une panne de vent dans les basses couches. Le r´egime sous le vent (incluant
le r´egime orographique), qui est gouvern´e par des effets thermiques et dynamiques
locaux. Le vent est en g´en´eral faible et perturb´e dans la zone sous le vent. Sous des vents
synoptiques faibles, la nuit, des apparitions de faibles brises de terre sur la cˆote au vent de
la Grande-Terre (MOU, Fig. 1.5) ont ´et´e observ´ees. Br´evignon (2003) a publi´e des cartes
de circulations cˆoti`eres (Fig. 1.6) en se basant sur les observations marines empiriques.
Pour un vent d’est, les circulations diurnes et les circulations nocturnes semblent similaires
(Fig. 1.6). On peut observer, de jour comme de nuit, des effets dynamiques de contourneFigure
1.6: Cartes de circulations cˆoti`eres autour de la Guadeloupe durant des vents
synoptiques d’est (d’apr`es Br´evignon (2003)).
ment et d’acc´el´eration du vent, ainsi que des retournements du vent qui apparaissent sur
la cˆote sous le vent de la Basse-Terre. D’apr`es Br´evignon (2003), le ph´enom`ene de brise
de mer–terre serait tr`es discret en Guadeloupe `a cause de la petitesse du territoire. Il a
indiqu´e qu’il n’y aurait pas de retournement du vent jour–nuit mais une simple variation
dans la direction du vent. Les brises thermiques seraient principalement observ´ees le long
de la cˆote sous le vent de la Basse-Terre (Br´evignon, 2003).
1.6.2.2 Campagne exp´erimentale dans la zone cˆoti`ere d’Arnouville (ARN,
D’Alexis et al. (2011))
D’Alexis (2011) a men´e une campagne exp´erimentale de terrain pour analyser les ph´enom`enes
de micro-´echelle dans la couche de surface de mangrove 3
. Entre avril 2007 et avril
3. Milieu naturel cˆotier avec une v´eg´etation semi-immerg´ee domin´ee par les pal´etuviers.Chapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude
bibliographique 27
2008, la station m´et´eorologique du Laboratoire de Recherche en G´eosciences et Energie ´
(LaRGE) a enregistr´e des mesures `a 1 Hz et `a 20 Hz. Cette station ´etait localis´ee dans la
zone cˆoti`ere d’Arnouville sur la cˆote au vent de la Basse-Terre (ARN, Fig. 1.5). Les donn´ees
recueillies sur une ann´ee ont montr´e qu’en g´en´eral, sous des aliz´es faibles `a mod´er´es, il
y a des apparitions d’un renversement nocturne du vent dans les bas niveaux verticaux.
Cet ´ecoulement nocturne d’ouest est associ´e `a une chute soudaine de la temp´erature de
l’air `a 2 m AGL. La localisation (une zone cˆoti`ere en bas des pentes au vent de la chaˆıne
de montagnes), pourrait sugg´erer un vent catabatique et–ou une brise de terre. Durant
261 jours de mesure (entre avril 2007 et avril 2008), D’Alexis et al. (2011) ont observ´e
121 jours d’occurrence de cet ´ecoulement nocturne (i.e. une fr´equence d’apparition d’un
jour sur deux). Cette observation indiquerait que durant la campagne exp´erimentale, pr`es
de la moiti´e des nuits ont ´et´e marqu´ees par cet ´ecoulement. Sur l’ann´ee, d´ecembre est le
mois de fr´equence maximale du ph´enom`ene, alors que juin est celui de fr´equence minimale.
D’Alexis et al. (2011) ont constat´e que cet ´ecoulement inverse du vent pouvait s’´etablir
pendant toute la nuit, ou ˆetre intermittent avec le retour des ´ecoulements classiques des
aliz´es. Les circulations nocturnes particuli`eres observ´ees par Br´evignon (2003); D’Alexis
et al. (2011), ont une direction ouest, une vitesse de vent inf´erieure `a 2 m.s-1, et semblent
repousser au large les aliz´es des basses couches.
1.6.2.3 Campagne exp´erimentale dans la zone urbaine de Pointe-`a-Pitre (DCH,
Plocoste (2013); Plocoste et al. (2014))
Plocoste (2013) a men´e une campagne exp´erimentale sur la dispersion des compos´es organiques
volatils de la d´echarge de la Gabarre (DCH, Fig. 1.5) situ´ee dans l’agglom´eration
pointoise, sur la cˆote ouest de la Grande-Terre `a 7 km de ARN. Durant des aliz´es faibles,
Plocoste et al. (2014) ont observ´e la pr´esence d’un renversement nocturne du vent qui
adopte une direction ouest et une vitesse inf´erieure `a 2 m.s-1. Ce flux ´etait associ´e `a
une baisse locale de la temp´erature de l’air. Les mesures de la station RZT (entre 2000 et
2012) ont montr´e que ce ph´enom`ene ´etait plus fr´equent durant le mois de d´ecembre et bien
moins fr´equent au cours du mois de juin (Plocoste, 2013). Cette mˆeme variation annuelle
avait ´et´e constat´ee par D’Alexis et al. (2011) `a la station ARN. Plocoste et al. (2014)
ont attribu´e l’origine de cet ´ecoulement `a la pr´esence d’un ˆılot de chaleur urbain dans la
zone et l’ont d´efini comme une brise urbaine. D’apr`es nous, l’origine purement urbaine de
cet ´ecoulement serait discutable pour les raisons suivantes. Les mesures exp´erimentales de
D’Alexis et al. (2011) effectu´ees dans les mˆemes conditions m´et´eorologiques, sugg´ereraient
que l’´ecoulement d’ouest observ´e par Plocoste (2013) est g´en´er´e, en amont, sur la cˆoteChapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude
bibliographique 28
au vent de la Basse-Terre avec une extension vers la Grande-Terre. Les observations du
panache de la centrale EDF de Jarry (Fig. 1.7, 1.8, 1.9) confirmeraient cette extension de
l’´ecoulement vers la cˆote ouest de la Grande-Terre (sous-section 1.6.3).
1.6.2.4 Variabilit´e diurne et spatiale des champs de surface
Au-dessus des ˆıles de l’archipel de la Guadeloupe, la temp´erature de l’air `a 2 m augmente
en g´en´eral de 5➦C entre 6 h et 10 h LT 4
et atteint sa valeur maximale `a 13 h LT (Br´evignon,
2003). Le refroidissement radiatif commence `a la fin de l’apr`es-midi (17 h LT) et la temp´erature
minimale est atteinte le lendemain matin `a 5 h LT.
Durant ses travaux de th`ese, D’Alexis (2011) a examin´e la relation entre le cycle diurne
(moyenn´e sur les six mois de la saison s`eche de l’ann´ee 2008) de la temp´erature de l’air
`a 2 m et celui de la vitesse du vent `a 10 m. La station m´et´eorologique de la D´esirade,
DES, est caract´eris´ee par des vents soutenus (7–8 m.s-1) avec une absence de variations
diurnes de la vitesse du vent `a 10 m. Les donn´ees de vent de cette station peuvent ˆetre
utilis´ees pour d´ecrire de mani`ere grossi`ere le vent synoptique incident. Pour les stations du
Raizet et d’Arnouville, respectivement, RZT et ARN, qui sont sous l’influence du r´egime
continental insulaire, les temp´eratures et les vitesses de vent semblent avoir une ´evolution
horaire quasiment synchronis´ee.
Les cycles diurnes de temp´erature et la moyenne annuelle de la temp´erature de l’air audessus
de la mer (27➦± 0,5➦C) indiquent que le contraste thermique le plus important entre
la terre et la mer apparaˆıt durant la nuit (le contraste mer–RZT atteint 4,7➦C `a 5 h LT). De
plus, les cycles diurnes de la vitesse du vent `a 10 m montrent que les diff´erences majeures
entre le vent synoptique (station DES) et le vent local (stations continentales insulaires)
se produisent `a partir de l’heure du d´ebut de refroidissement radiatif. Ceci peut sugg´erer
que durant la nuit, les circulations locales sont mieux marqu´ees que durant le jour. Dans
le cas de RZT, `a partir de minuit, le plus souvent, il y a une absence totale de vent. A`
cause du refroidissement nocturne, une couche froide de surface se d´eveloppe au-dessus de
la Grande-Terre, et les aliz´es plus chauds sont oblig´es de passer au-dessus de cette couche
(Br´evignon, 2003).
4. Temps local, de l’anglais : Local Time ; en Guadeloupe l’heure LT correspond `a l’heure UTC−4Chapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude
bibliographique 29
1.6.3 Impacts des circulations locales nocturnes sur la dispersion
de polluants industriels
1.6.3.1 Centrale EDF diesel Jarry nord
Malgr´e le d´eveloppement des ´etudes sur la caract´erisation de ressources ´energ´etiques renouvelables
dans l’Arc des Petites Antilles (comme l’´energie marine, l’´eolien ou le solaire),
l’´electricit´e est presque exclusivement produite `a partir de sources fossiles. En Guadeloupe,
la principale usine de production d’´electricit´e est la centrale EDF diesel Jarry nord
(Fig. 1.7), situ´ee dans la zone industrielle de Jarry (Petit Cul-de-Sac Marin, Fig. 1.5 et
Fig. 1.8). Cette centrale constitue la premi`ere source industrielle d’´emissions de polluants.
Figure 1.7: Photo des chemin´ees de la centrale ´electrique EDF Jarry nord, [cr´edit
photo : R. C´ec´e 2014].
D’apr`es le Registre fran¸cais des Emissions polluantes ´ , la centrale EDF Jarry nord ´emet
en moyenne chaque ann´ee, 0,5 M´egatonnes de dioxyde de carbone (CO2), 10 kilotonnes
d’oxydes d’azote (NOx) et 3 kilotonnes d’oxydes de soufre (SOx). La dispersion de ces
rejets importants doit ˆetre examin´ee pour pr´evenir les risques sanitaires.Chapitre 1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude
bibliographique 30
Figure 1.8: Photo satellite Google earth (8/04/2013) : localisation de la centrale
EDF et du campus UAG, les fl`eches rouges correspondant aux directions (a) et (b) du
panache durant une circulation nocturne d’ouest (Fig. 1.9).
1.6.3.2 Observations du panache de la centrale durant des retournements
nocturnes du vent
Des observations du panache de la centrale EDF Jarry nord nous ont permis de d´etecter, en
d´ebut de matin´ee, le renversement nocturne du vent dans la couche limite stable (Fig. 1.9).
Dans le cas du 14 septembre 2010 `a 7 h 21 LT, le vent dans les basses couches a
une direction nord-ouest, le panache se dirige vers le campus universitaire de Fouillole
(Fig. 1.9a, 1.8). Le radiosondage du jour (lanc´e `a 7 h LT depuis la station RZT) indique
une faible vitesse du vent dans les basse couches (< 0,5 m.s-1, `a 125 m AGL) et une
´epaisseur de la couche limite stable de 400 m.
Dans le cas du 4 novembre 2009 `a 7 h 11 LT, le vent de basses couches a une direction
sud-ouest, le panache se dirige vers le pont de la Gabarre (Pointe-`a-Pitre, Fig. 1.9b, 1.8).
Comme pour la pr´ec´edente situation, l’analyse du radiosondage correspondant montre de
faibles vitesses du vent dans les basses couches (≈ 3 m.s-1 `a 325 m AGL) et une couche
limite stable plus d´evelopp´ee (550 m).
Ces observations confirment la pr´esence d’une circulation d’ouest dans le Petit Cul-de-Sac
Marin, en amont de la zone urbaine de Pointe-`a-Pitre.
Cet ´ecoulement local nocturne d’ouest, soufflant en direction de la partie la plus peupl´ee
de l’archipel en passant par la zone industrielle de Jarry, dans laquelle plusieurs sources
d’´emissions de polluants sont pr´esentes, n´ecessite une analyse 3D de sa structure et des
m´ecanismes de sa formation dans les basses couches de l’atmosph`ere surplombant l’archipel.Chapitre
1. Circulations atmosph´eriques dans les basses couches et leurs effets : ´etude
bibliographique 31
Figure 1.9: Photos du panache de la centrale EDF de Jarry (prise de vue depuis le
campus de Fouillole UAG, Fig. 1.8) : (a) direction du vent nord-ouest, photo prise le
14/09/2010 `a 7 h 21 LT ; (b) direction du vent sud-ouest, photo prise le 4/11/2009 `a
7 h 11 LT [cr´edits photos : D. Bernard 2009-2010].Chapitre 2
M´ethodologie et outils de simulation
2.1 M´ethodologie g´en´erale
Les travaux de mod´elisations num´eriques pr´esent´es ont deux objectifs principaux. Premi`erement,
l’analyse des m´ecanismes m´eso- et micro-´echelles qui induisent des circulations
locales diurnes et nocturnes sur les ˆıles de la Guadeloupe. Deuxi`emement, l’´etude des
effets de ces circulations sur la dispersion du panache de la source industrielle la plus polluante
de l’archipel. Pour atteindre ces objectifs, la m´ethodologie suivante a ´et´e adopt´ee
(Fig. 2.1).
Nous avons choisi trois situations m´et´eorologiques r´eelles d´ependant de la vitesse du flux
incident des aliz´es et excluant les perturbations synoptiques pluvieuses : les aliz´es faibles
(AF), les aliz´es soutenus (AS), et les aliz´es moyens (AM), correspondant aux p´eriodes
respectives, 3/12/2007 6 h UTC–5/12/2007 6 h UTC 1
, 14/12/2007 6 h UTC–16/12/2007
6 h UTC, et 24/12/2007 6 h UTC–26/12/2007 6 h UTC.
Pour ces trois types de temps nous avons simul´e, `a l’aide du mod`ele WRF ARW V3.4.1,
une descente d’´echelle ” two-way ” jusqu’`a 1 km de r´esolution (m´eso-´echelle), avec l’assimilation
des donn´ees d’analyse mondiale FNL NCEP (NCEP (ment), 110 km de r´esolution)
aux conditions limites du domaine de plus basse r´esolution. Quatre domaines imbriqu´es,
D01, D02, D03 et D04 (de r´esolutions respectives 27, 9, 3 et 1 km) ont ´et´e employ´es, le domaine
D04 couvrant la totalit´e de l’archipel de la Guadeloupe (Fig. 2.10). L’intervalle de
temps des sorties mod`eles est horaire. La turbulence de la CLP est mod´elis´ee par le sch´ema
1. Temps universel coordonn´e, de l’anglais : Universal Time Coordinated ; en Guadeloupe l’heure UTC
correspond `a l’heure LT+4
32Chapitre 2. M´ethodologie et principaux outils de simulation 33
d’ensemble 1D YSU (Hong et al., 2006). Les ´echanges sol–atmosph`ere gouvernent le bilan
´energ´etique de surface et sont succeptibles d’induire des circulations locales d’origine
thermique et dynamique. Afin d’obtenir des simulations pertinentes, il est n´ecessaire de
disposer de cartes d’occupation des sols r´ealistes, d´ecrivant avec pr´ecision les diff´erentes
cat´egories succeptibles d’exister dans le territoire `a ´etudier. Pour la descente d’´echelle
m´eso-´echelle, deux exp´eriences num´eriques ont ´et´e r´ealis´ees. La premi`ere, ” M´eso-A ”,
inclut dans le domaine D04 la carte d’occupation des sols USGS Advanced Very High
Resolution Radiometer (AVHRR) d’1 km de r´esolution qui r´esulte d’analyses d’images
satellites datant de 1992 (Anderson et al., 1976; Eidenshink and Faundeen, 1994). La
seconde, ” M´eso-A’ ”, inclut dans le domaine D04 la carte d’occupation des sols Coordination
of Information on the Environment (Corine Land Cover, CLC2006), de 23 m
de r´esolution qui a ´et´e produite `a partir d’images satellites plus r´ecentes, de 2006 (EEA,
2007). Les r´esultats de l’exp´erience M´eso-A ont ´et´e publi´es par C´ec´e et al. (2014). L’article
est pr´esent´e dans la section 3.1.1 du rapport. Les r´esultats de l’exp´erience M´eso-A’ nous
permettent d’´evaluer l’impact de la carte d’occupation des sols Corine 2006 sur les circulations
locales g´en´er´ees par la Guadeloupe. Les champs de surface simul´es dans le domaine
D04 sont ´evalu´es `a l’aide des donn´ees d’observation de 5 stations m´et´eorologiques.
Les simulations micro-´echelles WRF-LES sont r´ealis´ees `a l’aide de deux nouveaux domaines
(Fig. 2.10) : D05 (333 m de r´esolution) et D06 (111 m de r´esolution). Le domaine
D05 inclut l’ˆıle de la Basse-Terre et la cˆote ouest de la Grande-Terre. Le domaine D06
couvre la zone du Petit Cul-de-Sac Marin incluant la zone d’Arnouville (ARN), la zone
industrielle de Jarry et Pointe-`a-Pitre. Les domaines D05 et D06 ont une imbrication ”
one-way ”. Les conditions limites du domaine D05 sont d´efinies par les sorties horaires du
domaine m´eso-´echelle D04 via une fonction d’interpolation WRF ” NDOWN ” (avec une
m´ethode spline cubique). WRF-LES r´esoud explicitement en 3D les ´echelles de production
et de transport de l’´energie cin´etique turbulente tandis que sa dissipation est mod´elis´ee
par le mod`ele de fermeture TKE d’ordre 1,5. L’intervalle de temps des sorties WRF-LES
pour les deux domaines est de 10 minutes. Le choix de cet intervalle de temps repose sur
deux contraintes, le volume des donn´ees de sortie (150 Mo par sortie) et la possibilit´e de
comparer les donn´ees num´eriques avec des donn´ees d’observations de station. Ces champs
simul´es infra-horaires sont ´evalu´es `a l’aide des donn´ees d’observation du mˆat instrument´e
ARN (la direction DD et la vitesse UU du vent horizontal `a 10 m AGL, la temp´erature de
l’air `a 2 m AGL T2, le flux de chaleur sensible HFX, l’´energie cin´etique turbulente TKE,
etc.).
Enfin, nous avons utilis´e un couplage WRF-LES-FLEXPART pour ´etudier la pollution
de la centrale diesel EDF de Jarry. La dispersion du panache de NOx de la centrale estChapitre 2. M´ethodologie et principaux outils de simulation 34
simul´ee pour des p´eriodes de 24 h pour chaque type de temps. Le mod`ele lagrangien
FLEXPART-WRF est forc´e toutes les 10 minutes avec les sorties WRF-LES. Les simulations
WRF-LES-FLEXPART sont r´ealis´ees dans le domaine LES D06. Les concentrations
de NOx simul´ees par le syst`eme WRF-LES-FLEXPART sont moyenn´ees et sauv´ees toutes
les 10 minutes. Ces sorties sont compar´ees, graphiquement, avec les donn´ees d’observation
de l’unique station de mesure de la qualit´e de l’air dans la zone (station de Pointe-`a-Pitre
de l’association agr´e´ee de surveillance de la qualit´e de l’air en Guadeloupe, Gwad’air).Chapitre 2. M´ethodologie et principaux outils de simulation 35
Figure 2.1: Sch´ema r´ecapitulatif de la m´ethodologie adopt´ee.Chapitre 2. M´ethodologie et principaux outils de simulation 36
2.2 S´election des trois situations m´et´eorologiques ´etudi´ees
2.2.1 Classification des types de temps
Nous utiliserons la classification climatologique des types de temps dans les Petites Antilles
et la Guyane, d´ecrite dans le rapport de stage de K. Morvan (R´ealisation d’une
climatologie et dune classification en type de temps sur les Petites Antilles et la Guyane,
Universit´e des Antilles et de la Guyane, M´et´eo-France, 2011). Cette classification obtenue
par des k-moyennes est fond´ee sur 20 ans d’observations des stations m´et´eorologiques locales
et sur les champs de r´e-analyses Era-Interim du Centre europ´een pour les pr´evisions
m´et´eorologiques `a moyen terme (CEPMMT, en anglais : European Center for Medium
range Weather Forecasting, ECMWF). Elle utilise les variables r´e-analys´ees suivantes : la
vitesse du vent horizontal `a 850 hPa, la vitesse du vent vertical `a 600 hPa, la divergence
du vent horizontal `a 200 hPa, la pression au niveau de la mer (Pmer), la temp´erature de
l’air `a 2 m, la temp´erature de l’air `a 925 hPa et la temp´erature potentielle du thermom`etre
mouill´e `a 850 hPa.
Pour simuler et examiner les circulations du vent local g´en´er´ees par l’archipel de la Guadeloupe,
trois types de temps issus de cette classification ont ´et´e choisis. Le for¸cage principal
est la vitesse du flux incident des aliz´es, en conformit´e avec la m´ethode pr´esent´ee par Lesou¨ef
et al. (2011) et Smith et al. (2012).
Les aliz´es faibles (AF), les aliz´es moyens (AM), et les aliz´es soutenus (AS) sont associ´es
`a des vitesses de vent respectives de 3, 6, et 12 m.s-1. D’apr`es Br´evignon (2003) les AM
repr´esentent le type de temps le plus fr´equent durant l’ann´ee (60% des cas). Les AS et AF
constituent chacun 10% des cas durant l’ann´ee, les 20% des cas restants correspondent aux
fortes perturbations pluvieuses (les fronts d´epressionnaires, les ondes d’est, les cyclones,
etc.).
Dans le but d’´etudier les m´ecanismes qui induisent les retournements nocturnes du vent
des basses couches `a ARN, les jours simul´es ont ´et´e s´electionn´es durant la p´eriode de la
campagne exp´erimentale de D’Alexis (2011), soit d’avril 2007 `a juin 2008.
Le mois de d´ecembre a ´et´e choisi car ce mois, correspondant `a l’initiation de la saison
s`eche, inclut aussi bien l’apparition des trois types de temps (AS, AM et AF), l’absence
de fortes perturbations synoptiques que des fr´equences ´elev´ees des retournements nocturnes
du vent.
A partir de ces crit`eres, nous avons s´electionn´e trois p´eriodes de 48 heures, correspondant `Chapitre 2. M´ethodologie et principaux outils de simulation 37
respectivement aux situations m´et´eorologiques, AF, AS, et AM : 3/12/2007 6 h UTC–
5/12/2007 6 h UTC, 14/12/2007 6 h UTC–16/12/2007 6 h UTC, et 24/12/2007 6 h UTC–
26/12/2007 6 h UTC (avec le temps UTC correspondant `a LT+4). Les observations effectu´ees
`a partir des images radar M´et´eo-France montrent une couverture nuageuse tr`es
faibles durant ces trois p´eriodes (Fig. 2.2). La couverture nuageuse pr´esente sur la chaˆıne
de montagne de la Basse-Terre, durant les AS (Fig. 2.2a) est caract´eristique d’un r´egime
orographique.
Figure 2.2: Donn´ees d’observation du radar de M´et´eo-France (250 m de r´esolution)
`a 16 h LT : (a) le 15 d´ecembre 2007 (AS), (b) le 24 d´ecembre 2007 (AM) et (c) le 3
d´ecembre 2007 (AF).
2.2.2 Circulations synoptiques de basses couches pour les dates
simul´ees
Pour d´ecrire les circulations synoptiques de basses couches correspondant `a chaque type
de temps (AF, AS, et AM), les champs de surface FNL (NCEP (ment), 1➦ de r´esolution)
sont examin´es dans la zone centrale de l’oc´ean Atlantique (latitudes comprises entre 5➦N
et 35➦N et longitudes comprises entre 70➦W et 10➦W). Le flux d’aliz´es arrivant sur les Antilles
est principalement conditionn´e par la position et la force des cellules anticycloniques
des A¸cores et des Bermudes.
Durant les AF, le 3 d´ecembre 2007 `a 12 h UTC, la faible cellule anticyclonique des Bermudes
est s´epar´ee de celle des A¸cores par un creux barom´etrique (avec une Pmer minimale
de 1005 hPa). Nous observons un front d´epressionnaire de 1012 hPa (22➦N, 54➦W,
Fig. 2.3a) qui induit, dans sa queue, une zone de vents faibles affectant la Martinique,
la Dominique et la Guadeloupe (Fig. 2.3b). Sur l’Arc des Petites Antilles, le gradient
de pression horizontale a une faible valeur de 0,2 hPa sur 100 km (Fig. 2.3a). Les aliz´es
arrivant sur la Guadeloupe ont une direction nord-est et une vitesse inf´erieure `a 5 m.s-1
(Fig. 2.3b).Chapitre 2. M´ethodologie et principaux outils de simulation 38
Figure 2.3: Champs de surface FNL (NCEP (ment), 1➦ de r´esolution) durant AF le
3/12/2007 `a 12h UTC : (a) Pmer en hPa ; (b) vitesse UU du vent horizontal `a 10 m
en m.s-1
.
Durant les AS, le 14 d´ecembre 2007, le fort anticyclone des Bermudes est en position
basse, l’isobare 1024 hPa est positionn´ee `a 25➦N (Fig. 2.4a). Il y a un resserrement des
isobares, le gradient de pression horizontale atteint sur l’Arc des Petites Antilles, la valeur
de 0,6 hPa sur 100 km. Les aliz´es incidents ont des vitesses ´elev´ees de 12 m.s-1 et une
direction est-nord-est quasi-uniforme (Fig. 2.4b). La l´eg`ere d´ec´el´eration du vent autour
de la Martinique, de la Dominique et de la Guadeloupe pourrait sugg´erer un freinage du
flux par l’orographie de ces ˆıles montagneuses.
Durant les AM, le 24 d´ecembre 2007, les deux cellules anticycloniques sont en position
haute (Fig. 2.5a). Elles sont s´epar´ees par un faible creux barom´etrique (avec une Pmer
minimale de 1018 hPa). Les AM sont caract´eris´es par des vents d’est mod´er´es arrivant
sur les Petites Antilles (7 m.s-1, Fig. 2.5b). Sur l’Arc, le gradient de pression horizontale a
une valeur moyenne de 0,4 hPa sur 100 km. Au passage de l’Arc antillais, le flux d’aliz´es
subit une d´ec´el´eration de 2 m.s-1 (Fig. 2.5b).Chapitre 2. M´ethodologie et principaux outils de simulation 39
Figure 2.4: Champs de surface FNL (NCEP (ment), 1➦ de r´esolution) durant AS le
14/12/2007 `a 12h UTC : (a) Pmer en hPa ; (b) vitesse UU du vent horizontal `a 10 m
en m.s-1
.Chapitre 2. M´ethodologie et principaux outils de simulation 40
Figure 2.5: Champs de surface FNL (NCEP (ment), 1➦ de r´esolution) durant AM le
24/12/2007 `a 12h UTC : (a) Pmer en hPa ; (b) vitesse UU du vent horizontal `a 10 m
en m.s-1
.Chapitre 2. M´ethodologie et principaux outils de simulation 41
2.3 Mod`ele num´erique m´eso-´echelle de pr´evision m´et´eorologique
: WRF ARW V3.4.1
2.3.1 Description du mod`ele d’apr`es les ´etudes de Skamarock
et al. (2008) et Wang et al. (2010)
Le mod`ele Weather Research and Forecasting ARW (WRF ARW, Skamarock et al. (2008))
est un mod`ele atmosph´erique non-hydrostatique et compressible con¸cu par le National
Center for Atmospheric Research (NCAR). WRF ARW est largement utilis´e en recherche
scientifique et en pr´evision op´erationnelle. C’est un code num´erique dit open-source (libre
de t´el´echargement, d’utilisation et de d´eveloppement). WRF est principalement support´e
et d´evelopp´e par la Mesoscale and Microscale Meteorology Division du NCAR. Ce mod`ele
m´et´eorologique permet une grande vari´et´e de mod´elisations de l’atmosph`ere : des applications
depuis l’´echelle globale jusqu’`a l’´echelle LES, des descentes d’´echelle dynamiques ”
one-way ” ou ” two-way ”, des simulations id´ealis´ees ou r´eelles incluant le for¸cage par des
champs de mod`eles globaux (type GFS, FNL, ou des r´e-analyses Era-Interim), des assimilations
de donn´ees d’observation en temps r´eel pour la pr´ediction... Il contient plusieurs
conditions de limites lat´erales avec un ensemble d’options de param´etrisation physique.
2.3.1.1 Architecture
Wang et al. (2010) ont d´ecrit l’architecture du mod`ele WRF (Fig. 2.6). Pour des simulations
de cas r´eels, le programme WRF Preprocessing System (WPS) est utilis´e. Ses
fonctions permettent : de d´efinir les domaines de simulation ; d’interpoler les donn´ees
terrestres statiques (comme la topographie et l’occupation des sols) sur les domaines de
simulation ; et d’interpoler les donn´ees m´et´eorologiques maill´ees d’un autre mod`ele (GFS,
FNL NCEP, Era-Interim, ...). Les donn´ees d’observation non maill´ees (stations m´et´eorologiques,
radar, ...) peuvent ˆetre ´egalement int´egr´ees, filtr´ees et valid´ees par le syst`eme
d’assimilation WRF-Var ou le syst`eme d’analyse OBSGRID. Le coeur dynamique ARW
utilise les sch´emas de second et troisi`eme ordre de Runge-Kutta pour g´en´erer les pr´evisions.
Les sorties WRF peuvent ˆetres lues et trait´ees par plusieurs outils de visualisation (VAPOR,
NCAR Command Language (NCL), ou RIP4). Le programme MET permet de les
formater pour leur assimilation dans WPS.Chapitre 2. M´ethodologie et principaux outils de simulation 42
Figure 2.6: Architecture du mod`ele WRF ARW (d’apr`es Wang et al. (2010)).
2.3.1.2 Principales ´equations r´esolues
Le coeur dynamique ARW r´esout les ´equations d’Euler non-hydrostatiques et compressibles
(Skamarock et al., 2008). Le mod`ele suit la philosophie de Ooyama (1990), ces
´equations sont exprim´ees sous forme de flux de variables conservatrices (i.e., la chaleur, la
quantit´e de mouvement, etc.). Les ´equations sont formul´ees en utilisant une coordonn´ee
verticale hydrostatique, η, qui d´epend des variations topographiques (Kasahara, 1974;
Laprise, 1992).
Coordonn´ee verticale η et variables associ´ees
La coordonn´ee verticale d´ependant de la pression hydrostatique (ph = ρgH) et donc de
la topographie, est appel´ee η et d´efinie par :
η = (ph − pht)/µd o`u µd = phs − pht. (2.1)
ph est la pression hydrostatique, pht et phs, repr´esentent respectivement, les pressions
hydrostatiques au sommet et `a la surface. Les valeurs de η sont normalis´ees et varient
entre 1 `a la surface et 0 au sommet du mod`ele (Fig. 2.7). Avec µd(x,y) repr´esentant laChapitre 2. M´ethodologie et principaux outils de simulation 43
masse de la colonne d’air sec par unit´e de surface au point (x,y), les variables s’´ecrivent :
V = µdv = (U, V, W), Ω = µdη,˙ Θ = µdθ. (2.2)
v = (u, v, w) sont les vitesses covariantes en 3D (base vectorielle), ω = ˙η est la vitesse
verticale contravariante (vitesse associ´ee au changement de coordonn´ee verticale), θ est
la temp´erature potentielle. Dans les ´equations gouvernantes de ARW, les variables nonconserv´ees
suivantes apparaissent : le g´eopotentiel φ = gz (avec g l’acc´el´eration de la
pesanteur), la pression p, et le volume massique α = 1/ρ.
Figure 2.7: Niveaux verticaux η dans WRF ARW avec pht et phs, respectivement, les
pressions hydrostatiques au sommet et `a la surface (d’apr`es Skamarock et al. (2008)).
Equations d’Euler incluant l’humidit´e ´
En utilisant la coordonn´ee verticale adimensionnelle η et les variables associ´ees d´ecrites
ci-dessus, Skamarock et al. (2008) ont ´ecrit les ´equations d’un fluide parfait compressible,
le long de la colonne d’air (axe-η). Ces ´equations sont dites d’Euler et ont ´et´e pr´esent´eesChapitre 2. M´ethodologie et principaux outils de simulation 44
par Laprise (1992), pour les avantages qu’elles offrent en simulation atmosph´erique nonhydrostatique
:
∂tU + (∇.Vu) + µdα∂xp + (α/αd)∂ηp∂xφ = FU (2.3)
∂tV + (∇.Vv) + µdα∂yp + (α/αd)∂ηp∂yφ = FV (2.4)
∂tW + (∇.Vw) − g[(α/αd)∂ηp − µd] = FW (2.5)
∂tΘ + (∇.Vθ) = FΘ (2.6)
∂tµd + (∇.V) = 0 (2.7)
∂tφ + µ
−1
d
[(V.∇φ) − gW] = 0 (2.8)
∂tQm + (∇.Vqm) = FQm (2.9)
en incluant la relation diagnostique pour le volume massique d’air sec,
∂ηφ = −αdµd, (2.10)
et l’´equation d’´etat des gaz atmosph´eriques
p = p0(Rdθm/p0αd)
γ
. (2.11)
γ = cp/cv = 1.4 est le rapport de capacit´e thermique pour l’air sec, Rd est la constante
des gaz parfaits pour l’air sec, et p0 est la pression de r´ef´erence (1000 hPa). Les termes
FU , FV , FW , FΘ et FQm repr´esentent les for¸cages provenant de la physique du mod`ele, du
m´elange turbulent, de la vapeur d’eau, des projections sph´eriques et de la rotation de la
Terre. Les ´equations 2.3 et 2.4 repr´esentent les ´equations de la quantit´e de mouvement
horizontale. Les ´equations 2.5, 2.6, 2.7, 2.8 et 2.9 d´ecrivent respectivement, la quantit´e de
mouvement verticale, l’´equation thermodynamique, l’´equation de continuit´e, l’´equation
de la hauteur du g´eopotentiel et l’´equation de l’humidit´e. Skamarock et al. (2008) ont
exprim´e ces ´equations eul´eriennes humides sous forme de perturbations par rapport `a un
´etat de r´ef´erence (avec les variables d´efinies suivant la d´ecomposition de Reynolds (1947)
p = ¯p(¯z)+p
0
, φ = φ¯(¯z)+φ
0
, α = ¯α(¯z)+α
0
, µd = ¯µd(x, y)+µ
0
d
) et en utilisant des facteurs
d’´echelle et des termes rotationnels.
Maillage ARW d´ecal´e : Arakawa-C
La r´esolution num´erique des ´equations d´efinies dans la section pr´ec´edente (Eq. 2.3-2.8) se
fait `a l’aide d’un maillage d´ecal´e. Les grandeurs vectorielles (U, V , W, Ω et φ) sontChapitre 2. M´ethodologie et principaux outils de simulation 45
moyenn´ees sur les arˆetes de la maille et les grandeurs scalaires (µ, θ, qv et ql) sont
moyenn´ees au centre de la maille (Fig. 2.8). Ce sch´ema est d´enomm´e Arakawa de type C
du nom d’un de ses cr´eateurs (Arakawa and Lamb, 1977), il est particuli`erement utilis´e
dans les r´esolutions d’´ecoulements g´eophysiques (oc´ean et atmosph`ere).
Figure 2.8: Maille individuelle de la grille Arakawa-C avec les grandeurs vectorielles
(U, V , W, Ω et φ) et les scalaires (µ, θ, qv et ql) (Skamarock and Dudhia, 2014).
2.3.1.3 Sch´emas de param´etrisation physique
Les cat´egories de param´etrisation physique disponibles dans WRF sont : la microphysique,
la convection, la couche de surface, la surface du sol (canop´ee), le rayonnement
et la couche limite plan´etaire (CLP) (Skamarock et al., 2008). Les interactions entre les
sch´emas de param´etrisation ont ´et´e r´esum´ees par Dudhia (2014) dans la Fig. 2.9.
La microphysique r´esout explicitement 2
les processus suivants : les changements d’´etats
de la vapeur d’eau, la formation nuageuse et les pr´ecipitations.
Les sch´emas de convection sont responsables de la prise en compte des ph´enom`enes se
produisant `a l’´echelle de la sous-maille, provenant de nuages de convection profonde et
peu profonde : repr´esentation des flux verticaux associ´es aux mouvements ascendants et
descendants. Ces sch´emas sont importants car ils permettent de r´eduire le coˆut de calcul
qui serait n´ecessaire `a la r´esolution de ces ph´enom`enes avec un maillage plus fin.
2. L’´etat actuel est calcul´e uniquement `a l’aide des ´etats pr´ec´edents.Chapitre 2. M´ethodologie et principaux outils de simulation 46
Figure 2.9: Interactions entre les sch´emas de param´etrisation physique du mod`ele
WRF ARW (Dudhia, 2014).
Les sch´emas de couche de surface calculent les vitesses de friction et les coefficients
d’´echange. Ces variables permettent le calcul des flux de chaleur et d’humidit´e dans les
mod`eles de surface et le calcul du tenseur des contraintes de surface dans les sch´emas de
couche limite plan´etaire (CLP).
Les mod`eles de surface utilisent l’information atmosph´erique fournie par la couche de surface,
le rayonnement et la microphysique (pr´ecipitations) pour produire les flux de chaleur
et d’humidit´e associ´es aux variables d’´etat du sol et aux propri´et´es de surface (rugosit´e,
alb´edo, ...).
Les sch´emas de CLP d´eterminent les profils de flux dans la couche limite de m´elange et
la couche stable. Ces sch´emas fournissent des ´evolutions spatio-temporelles de la temp´erature,
de l’humidit´e et de la quantit´e de mouvement horizontal dans la colonne atmosph´erique.
Enfin, les sch´emas de rayonnement mod´elisent la divergence du flux radiatif (r´eflexion,
diffusion, effets des nuages) et les flux des grandes et courtes longueurs d’onde arrivant `a
la surface.Chapitre 2. M´ethodologie et principaux outils de simulation 47
2.3.2 Configurations utilis´ees
2.3.2.1 Preprocessing WPS
Domaines de simulation
Les simulations WRF incluent 6 domaines imbriqu´es dont les zones de couverture et
les r´esolutions ont ´et´e s´electionn´ees en fonction des objectifs de la mod´elisation et des
recommandations de Skamarock et al. (2008) (comme le rapport de r´esolution entre un
domaine parent et un domaine imbriqu´e de [3 :1]).
Dans le but de simuler les circulations locales m´eso-´echelles induites par les interactions
entre les vents synoptiques et des petites ˆıles comme la Guadeloupe, nous avons utilis´e
une descente d’´echelle ” two way ” avec quatre domaines (D01, D02, D03, D04, de r´esolutions
respectives en km : 27, 9, 3, 1)(Fig. 2.10). Le domaine de plus basse r´esolution,
D01, couvre une grille de 80 x 80 mailles [longitude x latitude] dans la zone centrale de
l’Atlantique (de l’Am´erique du Sud `a la R´epublique Dominicaine). Le domaine D02 couvre
une grille de 121 x 109 mailles dans l’Arc des Petites Antilles. Le domaine D03 couvre
une grille de 112 x 91 mailles dans la zone d´elimit´ee par la Dominique et les ˆıles de Saint
Kitts et N´evis. Le dernier domaine imbriqu´e, D04, couvre une grille de 130 x 112 mailles
sur l’archipel de la Guadeloupe.
Figure 2.10: Cartes des domaines imbriqu´es : en blanc D01 (27 km de r´esolution),
en cyan D02 (9 km de r´esolution), en gris D03 (3 km de r´esolution), en jaune D04
(1 km de r´esolution), en vert D05 (333 m de r´esolution) et en rouge D06 (111 m de
r´esolution).
Dans le but d’´etudier, `a la micro-´echelle, les circulations nocturnes particuli`eres observ´ees
`a ARN et leurs effets dans la zone la plus peupl´ee de l’archipel, deux autres domaines
ont ´et´e associ´es `a notre ´etude (Fig. 2.10) : le D05 et le D06 (de r´esolutions respectives,Chapitre 2. M´ethodologie et principaux outils de simulation 48
333 m et 111 m). Le domaine D05 couvre une grille de 120 x 129 mailles sur l’ˆıle de la
Basse-Terre et la cˆote ouest de la Grande-Terre. Enfin le dernier domaine imbriqu´e D06
est compos´e de 165 x 69 mailles sur la zone du Petit Cul-de-Sac Marin, incluant la zone
d’Arnouville, la zone industrielle de Jarry et Pointe-`a-Pitre.
Topographie
La topographie des trois domaines de plus faibles r´esolutions (D01, D02 et D03) a ´et´e
interpol´ee `a partir des donn´ees fournies par l’US Geological Survey 3
(USGS, 30 secondes
d’arc de r´esolution). La topographie des trois autres domaines (D04, D05 et D06) a ´et´e
interpol´ee depuis la carte topographique de l’Institut G´eographique National 4
(IGN) dont
la r´esolution est de 50 m. L’impact de la r´esolution sur la repr´esentation du relief de la
Guadeloupe est illustr´e par la comparaison de la topographie des domaines D04, D05 et
D06 (Fig. 2.11).
Figure 2.11: Cartes topographiques (m AMSL) interpol´ees `a partir des donn´ees IGN
(50 m de r´esolution) : (a) D04 (1 km de r´esolution), (b) D05 (333 m de r´esolution),
(c) D06 (111 m de r´esolution) ; avec la station num´erique VER (triangle jaune), le
mˆat instrument´e ARN (triangle vert) et la centrale ´electrique EDF (croix rouge).
3. Institut d’´etudes g´eologiques des Etats-Unis, de l’anglais : United States Geological Survey ´
4. Institut National de l’Information G´eographique et Foresti`ereChapitre 2. M´ethodologie et principaux outils de simulation 49
Occupation des sols
Les circulations locales sont g´en´eralement g´en´er´ees par des contrastes thermiques de surface.
Donc leur mod´elisation num´erique implique une bonne repr´esentation de la carte
d’occupation des sols. Pour notre application au cas de l’archipel de la Guadeloupe, nous
avons pr´ealablement utilis´e une carte d’occupation des sols tr`es bien r´ef´erenc´ee dans la
bibliographie : les donn´ees globales USGS 5
(ULC24) avec 1 km de r´esolution (Anderson
et al., 1976; Eidenshink and Faundeen, 1994). Cette carte d’occupation des sols, r´ealis´ee
`a partir des donn´ees satellites du Radiom`etre Avanc´e `a Tr`es Haute R´esolution AVHRR
(1992–1993, Eidenshink and Faundeen (1994)), a ´et´e employ´ee dans l’exp´erience M´eso-A.
Dans le cadre des simulations micro-´echelles, il ´etait pr´ef´erable de disposer de donn´ees
dont la r´esolution est sup´erieure ou ´egale `a la taille d’une maille du domaine D06 (111 m).
De plus, dans un souci de r´ealisme, la date de la carte d’occupation des sols devait correspondre
avec notre p´eriode de simulation (2007).
Les donn´ees de la carte d’occupation des sols Corine Land Cover 2006 (EEA, 2007) pour
les d´epartements d’outremer, bas´ee sur l’interpr´etation des images des satellites SPOT et
Landsat, ont ´et´e r´ecemment mises en ligne. Ces donn´ees, qui incluent une classification
en 50 classes d’occupation des sols, ont une r´esolution 1 : 100000 (un pixel de 23 m pour
la Guadeloupe).
Le sch´ema de canop´ee Noah-LSM (Chen and Dudhia, 2001), utilis´e dans la configuration
de nos simulations WRF, est param´etr´e `a partir des 24 cat´egories USGS d’occupation
du sol. Pour int´egrer la nouvelle carte d’occupation des sols, la conversion des 50 classes
Corine en 24 classes USGS est n´ecessaire. Pineda et al. (2004) ont propos´e un tableau
d’´equivalences entre les cat´egories Corine et les cat´egories USGS (Tab. 2.1).
En nous basant sur l’analyse de Pineda et al. (2004), nous avons donc converti les 50 classes
de la carte d’occupation des sols de la Guadeloupe Corine 2006 en 24 classes USGS pour
obtenir la carte CLC24 6
(Fig. 2.12). Cette repr´esentation de tr`es haute r´esolution est tr`es
r´ealiste (Fig. 2.12) : on y observe l’agglom´eration pointoise (au centre de l’archipel), la
domination des forˆets de feuillus sur l’ˆıle de la Basse-Terre et celle des terres cultiv´ees sur
la Grande-Terre. La pr´ecision de la carte nous permet aussi d’observer la zone aride du
crat`ere de la Soufri`ere (Fig. 2.12).
La comparaison, `a 1 km de r´esolution (domaine D04), des cartes USGS AVHRR (ULC24)
(Fig. 2.13a) et Corine CLC24 (Fig. 2.13b) montre d’importants biais dans l’occupation
des sols ULC24. Tout d’abord, contrairement `a la repr´esentation CLC24, la ligne de cˆote
ULC24 semble avoir un d´ecalage sud-est avec la ligne de cˆote World Vector Shoreline
5. Carte d’occupation des sols USGS global land cover avec 24 cat´egories (1992)
6. Carte d’occupation des sols Corine Land Cover (2006) convertie aux 24 cat´egories d´efinies par USGSChapitre 2. M´ethodologie et principaux outils de simulation 50
Tableau 2.1: Equivalences entre les 50 classes de la Corine Land Cover 2006 DOM ´
et les 24 classes de l’USGS AVHRR 1992 (Pineda et al., 2004).
Corine Description Corine USGS Description USGS Albedo Rugosit´e
1–11 Zones urbaines, industrielles 1 Zones urbaines, industrielles 0,15 1,00
12 Terres cultiv´ees non irrigu´ees 2 Terres cultiv´ees non irrigu´ees 0,19 0,07
13-14 Terres irrigu´ees en permanence, 3 Terres cultiv´ees irrigu´ees 0,15 0,07
rizi`eres
15–21 Vignobles, vergers et petits fruits, 6 Terres cultiv´ees/forˆets 0,15 0,07
oliveraies, canne `a sucre,
bananeraies, palmeraies, caf´eiers
22 Prairies 2 Terres cultiv´ees non irrigu´ees 0,19 0,07
23–26 Cultures annuelles et permanentes, 6 Terres cultiv´ees/forˆets 0,15 0,07
syst`emes complexes de culture,
zones agricoles et espaces naturels,
territoires agro-forestiers
27 Forˆets de feuillus 11 Forˆets de feuillus 0,12 0,80
28 Forˆets de conif`eres 14 Forˆets de conif´eres 0,10 1,09
29–30 Forˆets m´elang´ees, mangroves 15 Forˆets m´elang´ees 0.12 0.80
31 Pelouses et pˆaturages naturels 7 Pelouses 0,19 0,08
32–34 Landes et broussailles, v´eg´etation 9 Arbustes et pelouses 0,23 0,05
V´eg´etation scl´erophylle,
forˆet et v´eg´etation arbustive
35–38 Plages, dunes et sable, roches nues 19 Zones arides et 0,12 0,01
V´eg´etation clairsem´ee, v´eg´etation clairsem´ee
zones incendi´ees
39 Glaciers et neiges ´eternelles 24 Neige et glacier 0,70 0,001
40–44 Marais int´erieurs, salines, tourbi`eres 17 v´eg´etation basse 0,12 0,04
Marais maritimes, marais salants, en zones innond´ees
zones intertidales
45–50 Eaux continentales, eaux maritimes 16 Surfaces d’eau 0,19 0,001
(NOAA, 2014). De plus, la domination de l’occupation des sols de l’archipel par les savanes
et les terres cultiv´ees non irrigu´ees semble irr´ealiste (Fig. 2.13a). Cette carte ne
montre pas les diff´erences entre la v´eg´etation de l’ˆıle plate de la Grande-Terre et celle du
relief de la Basse-Terre qui est soumis `a un r´egime pluvieux plus intense. Enfin les zones
urbaines de la carte ULC24 semblent tr`es mal repr´esent´ees.
Suite `a cette comparaison graphique, le choix a ´et´e fait d’effectuer de nouvelles simulations
m´eso-´echelles (M´eso-A’) en int´egrant l’occupation des sols CLC24 dans le domaine D04.
Les effets de la CLC24 sur les circulations locales de l’archipel (1 km de r´esolution) sont
examin´es `a la section 3.1.2. La CLC24 est aussi utilis´ee dans les domaines micro-´echelles :
D05 et D06.
La configuration des donn´ees g´eographiques pour les six domaines de simulation estChapitre 2. M´ethodologie et principaux outils de simulation 51
Figure 2.12: Carte d’occupation des sols de l’archipel de la Guadeloupe CLC24 (23 m
de r´esolution) : Corine Land Cover 2006 dont les 50 cat´egories ont ´et´e converties en
24 cat´egories USGS, avec le rectangle noir repr´esentant l’agglom´eration pointoise.
Figure 2.13: Comparaison des cartes d’occupation des sols de l’archipel de la
Guadeloupe `a 1 km de r´esolution (D04) avec la ligne de cˆote World Vector Shoreline
(NOAA, 2014), (1) les zones urbaines, (2) les terres cultiv´ees non irrigu´ees, (6) les
m´elanges de terres cultiv´ees et de forˆets, (7) les pelouses, (8) les arbustes, (9) les
m´elanges d’arbustes et de pelouses, (10) les savanes, (11) les forˆets de feuillus, (13)
les forˆets denses, (14) les forˆets de conif`eres, (15) les forˆets m´elang´ees mangroves
incluses, (16) les surfaces d’eau, (17) les v´eg´etations basses en zones inond´ees, (18) les
surfaces bois´ees en zones inond´ees, (21) la toundra bois´ee : (a) USGS ULC24
(M´eso-A), (b) Corine CLC24 (M´eso-A’).
r´esum´ee dans le tableau 2.2.Chapitre 2. M´ethodologie et principaux outils de simulation 52
Tableau 2.2: Configuration des six domaines de simulation.
D01 D02 D03 D04 D05 D06
R´esolution [m] 27000 9000 3000 1000 333 111
Nombre de mailles [lon. x lat.] 80 x 80 121 x 109 112 x 91 130 x 112 120 x 129 165 x 69
Superficie [km2
] 4665600 1068309 91728 14560 1584 140
Topographie USGS 30 s IGN 50 m
Occupation des sols M´eso-A ULC24 30 s ULC24 30 s CLC24 23 m
Occupation des sols M´eso-A’ ULC24 30 s CLC24 23 m CLC24 23 m
Sch´ema de turbulence Sch´ema de moyenne d’ensemble 1D Sch´ema LES 3D
Donn´ees m´et´eorologiques globales pour l’assimilation du mod`ele WRF ARW
Les donn´ees globales du syst`eme NCEP FNL (Final) Operational Global Analysis (NCEP,
ment) ont ´et´e int´egr´ees toutes les 6 heures, dans le mod`ele WRF. Ces champs de donn´ees,
dont la maille est de 1➦(≈ 110 km) et le pas de temps de six heures, sont en t´el´echargement
libre. Les analyses NCEP FNL sont disponibles pour des dates post´erieures au 30/07/1999
18 h UTC. Les donn´ees proviennent du syst`eme d’assimilation de donn´ees mondiales
(GDAS), qui recueille, en continu, les donn´ees d’observation depuis le syst`eme de t´el´ecommunications
globales (GTS). Les sorties d’analyses FNL incluent des champs `a la
surface et sur 26 niveaux verticaux levels entre 1000 mb et 10 mb. Les param`etres disponibles
comprennent la pression de surface, la pression au niveau de la mer, la hauteur
du g´eopotentiel, la temp´erature, la temp´erature de surface du sol et de la mer, l’humidit´e
relative, les composantes horizontales du vent, les mouvements verticaux, la vorticit´e et
la teneur en ozone.
2.3.2.2 Param´etrisations WRF ARW
Caract´erisation des niveaux verticaux
Les exp´eriences M´eso-A et M´eso-A’ comportent respectivement 71 et 70 niveaux verticaux
m´edians (centres des mailles verticales) avec un premier niveau vertical `a une altitude de
13 m AGL (Fig. 2.14b). Le sommet du mod`ele est limit´e au niveau de pression 50 hPa dans
l’exp´erience M´eso-A et `a la tropopause 100 hPa dans l’exp´erience M´eso-A’ (Fig. 2.14a).
Le mod`ele fournit les variables de surface classiques avec la temp´erature `a 2 m AGL (T2)
qui est calcul´ee `a partir de la temp´erature du premier niveau vertical et de celle de la
surface du sol, tandis que pour le vent `a 10 m AGL, le calcul est bas´e sur la th´eorie des
similitudes de Monin-Obukhov.
Suivant les recommandations de Skamarock et al. (2008), la distance entre les niveauxChapitre 2. M´ethodologie et principaux outils de simulation 53
Figure 2.14: Niveaux verticaux m´edians (WRF) pour les exp´eriences M´eso-A (croix
bleues) et M´eso-A’ (cercles rouges) : (a) profils lin´eaires en fonction du niveau de
pression (hPa) et (b) profils logarithmiques en fonction de l’altitude (km).
verticaux est inf´erieure `a 900 m (Fig. 2.14b). Dans le but d’´etudier les circulations locales
induites dans la CLA par l’orographie et les contrastes thermiques de surface, nous
avons d´efini dans les deux exp´eriences 43 niveaux verticaux dans les couches inf´erieures `a
3000 m AGL, en incluant 23 niveaux dans les 1000 premiers m`etres (Fig. 2.14b).
Les simulations WRF-LES micro-´echelles (D05 et D06) comportent les mˆemes niveaux
verticaux que ceux de l’exp´erience M´eso-A’.
P´eriodes simul´ees et intervalles de temps des sorties mod`eles
A m´eso- et micro-´echelle, la dur´ee des p´eriodes simul´ees est de 60 heures pour les trois `
cas, AF (du 2 d´ecembre 2007 18 h UTC au 5 d´ecembre 2007 6 h UTC), AS (du 13
d´ecembre 2007 18 h UTC au 16 d´ecembre 2007 6 h UTC) et AM (du 23 d´ecembre 2007
18 h UTC au 26 d´ecembre 2007 6 h UTC). Aussi bien en m´eso-´echelle qu’en micro-´echelle,
les r´esultats des 12 premi`eres heures ne sont pas pris en compte dans notre analyse, car
ils correspondent `a la p´eriode classique du temps de latence du mod`ele, appel´ee ” spin-up
” (Hu et al., 2010).
Les sorties mod`eles m´eso-´echelles (D01, D02, D03 et D04) sont sauvegard´ees toutes les
heures. Suivant la m´ethode de Talbot et al. (2012), les champs simul´es horaires du domaine
D04 sont utilis´es par la suite comme conditions limites du domaine LES D05 via une
fonction d’interpolation spline cubique, appel´ee ” NDOWN ”. Les sorties WRF-LES des
domaines D05 et D06 sont sauvegard´ees toutes les 10 minutes.Chapitre 2. M´ethodologie et principaux outils de simulation 54
Param´etrisations physiques m´eso- et micro-´echelles
Les sch´emas de physique utilis´es dans nos travaux `a la m´eso-´echelle et `a la micro-´echelle
correspondent aux param´etrisations les plus fr´equemment employ´ees dans les ´etudes num´eriques
utilisant le mod`ele WRF.
Dans les domaines m´eso-´echelles (D01, D02, D03 et D04), la couche limite plan´etaire
(CLP) est mod´elis´ee par le sch´ema de moyenne d’ensemble non-local-K YSU (Hong et al.,
2006) associ´e `a la diffusion horizontale Smagorinsky du premier ordre. Les ´etudes comparatives
des sch´emas de CLP du mod`ele WRF ont montr´e que le sch´ema YSU ´etait
le plus performant en couche limite convective (Hu et al., 2010; Shin and Hong, 2011).
Cependant, en condition de stabilit´e nocturne, le sch´ema YSU (versions WRF ant´erieures
`a la 3.4.1 utilis´ee ici) avait tendance `a inhiber le gradient de vent vertical, ceci ´etant en
parti dˆu `a un m´elange vertical excessif (Hu et al., 2013). La r´eduction du m´elange vertical
nocturne dans la version 3.4.1 du code WRF ARW a permis d’am´eliorer la pr´ediction des
vitesses du vent des basses couches durant la nuit (Hu et al., 2013). Le sch´ema YSU a
aussi montr´e de bonnes performances dans les ´etudes de couplage micro-´echelle WRF-LES
(Talbot et al., 2012; Zhu, 2008a,b).
Dans les domaines micro-´echelles (D05 et D06), la couche limite plan´etaire (CLP) est
r´esolue explicitement par le sch´ema LES 3D avec la fermeture 3D TKE d’ordre 1.5 (d´ecrit
`a la sous-section 1.3.4).
Dans les six domaines de simulation, la param´etrisation de la couche de surface est bas´ee
sur la th´eorie des similitudes de Monin-Obukhov.
La microphysique est mod´elis´ee par le sch´ema WRF Single-Moment 6-class WSM6 (Hong
and Lim, 2006) qui est pr´ef´erable pour les simulations de haute r´esolution au sch´ema
WRF Single-Moment 3-class WSM3 utilis´e par Lef`evre et al. (2010).
Pour la param´etrisation du rayonnement `a ondes longues et du rayonnement `a ondes
courtes, les sch´emas RRTM (Mlawer et al., 1997) et Dudhia (Dudhia, 1989) sont respectivement
s´electionn´es. Les ˆıles volcaniques des Petites Antilles, comme la Martinique, la
Dominique et la Guadeloupe ont une topographie complexe. Dans le but de mieux simuler
les for¸cages radiatifs, les effets de pente et d’ombre ont ´et´e ajout´es pour les domaines D03,
D04, D05 et D06.
Le mod`ele de surface Noah Land Surface Model (Chen and Dudhia, 2001) est s´electionn´e.
Il inclut le calcul de l’humidit´e et de la temp´erature dans quatre couches du sol.
Dans le domaine D01, le sch´ema Kain-Fritsch (Kain, 2004) est ajout´e pour mod´eliser
la convection. Dans les 5 autres domaines, le mod`ele r´esout explicitement la convection.
D’apr`es Skamarock et al. (2008), les sch´emas de convection doivent ˆetre appliqu´es sur des
mailles de taille sup´erieure `a 10 km.Chapitre 2. M´ethodologie et principaux outils de simulation 55
L’option de variation de la temp´erature de surface de la mer en fonction du rayonnement
est activ´ee. Cette option permet de simuler le cycle diurne de la temp´erature de surface
de la mer.
Pas de temps de calcul
Pour maximiser les pas de temps de calcul tout en maintenant le mod`ele num´eriquement
stable, nous avons utilis´e une m´ethode de pas de temps adaptatif bas´ee sur les conditions
de stabilit´e Courant-Friedrichs-Lewy (CFL). Trois param`etres doivent ˆetre pr´ealablement
d´efinis en fonction de la r´esolution du domaine (∆x, en km). Skamarock et al. (2008)
recommandent un pas de temps de d´epart de 6∆x, un pas de temps minimal de 4∆x et
un pas de temps maximal de 8∆x.
Le pas de temps adaptatif a ´et´e employ´e pour les simulations m´eso-´echelles (Tab. 2.3). Son
utilisation pour les simulations LES entraˆınait des erreurs et des interruptions de calcul.
Nous avons donc fix´e les pas de temps de calcul des domaines D05 et D06 (Tab. 2.3).
Tableau 2.3: Pas de temps de calcul pour les six domaines de simulation.
D01 D02 D03 D04 D05 D06
∆x = 27 km ∆x = 9 km ∆x = 3 km ∆x = 1 km ∆x = 0.3 km ∆x = 0.1 km
Pas de temps de d´epart (s) 162 54 18 6 ∅ ∅
∆t = 6∆x
Pas de temps minimal (s) 108 36 12 4 ∅ ∅
∆t = 4∆x
Pas de temps maximal (s) 216 72 24 8 ∅ ∅
∆t = 8∆x
Pas de temps constant (s) ∅ ∅ ∅ ∅ 1,2 0,4
∆t = 4∆x
Conditions initiales
Les conditions initiales incluent aussi bien les conditions au sol (topographie, occupation
des sols, ...) que les champs m´et´eorologiques interpol´es provenant des analyses globales
du mod`ele NCEP FNL (NCEP, ment), dont la maille est de 110 km. Ces champs maill´es
comportent des variables 2D au sol et des variables 3D qui seront interpol´ees sur les
niveaux verticaux de la simulation.Chapitre 2. M´ethodologie et principaux outils de simulation 56
Conditions aux limites
Les conditions aux limites lat´erales des six domaines de simulation sont configur´ees par une
zone de sp´ecification (zone entourant le domaine d’´epaisseur ´egale `a une maille) et par la
zone de relaxation (zone suivant entourant le domaine d’´epaisseur ´egale `a quatre mailles).
Les valeurs des conditions sont impos´ees dans la zone de sp´ecification, puis propag´ees
dans la zone de relaxation (Davies and Turner, 1977) permettant d’´eviter les instabilit´es
induits par d’´eventuels gradients ´elev´es.
Tableau 2.4: Conditions aux limites des simulations WRF pour les six domaines
´etudi´es.
D01 D02 D03 D04 D05 D06
Sommet Vitesse verticale w nulle
Surface Conditions du sol (topographie, rugosit´e, alb´edo, ...)
Bords lat´eraux NCEP-FNL Sorties D01 Sorties D02 Sorties D03 Sorties D04 Sorties D05
Intervalle de temps 6 h ∆tD01 ∆tD02 ∆tD03 1 h ∆tD05
Imbrication Two-way One-way
Dans le cas des simulations `a la m´eso-´echelle, les conditions aux limites lat´erales du premier
domaine (D01, 27 km de maille) proviennent des champs m´et´eorologiques NCEP-FNL
(NCEP, ment) interpol´es, 2D et 3D, toutes les six heures (Tab. 2.4). Pour les trois autres
domaines (D02, D03 et D04), les conditions aux limites sont ´etablies par imbrication :
c’est le domaine parent qui fixe les conditions lat´erales du domaine fils `a chaque pas de
temps.
Dans le cas des simulations `a la micro-´echelle, les conditions aux limites lat´erales du
premier domaine (D05, 333 m de maille) sont ´etablies par les sorties interpol´ees, 2D et
3D, du domaine D04 (1 km de r´esolution), toutes les heures. Les conditions limites du
domaine D06 sont d´efinies par les r´esultats du domaine D05.
Le sommet de l’atmosph`ere, d´efini respectivement dans les simulations M´eso-A et M´esoA’,
`a 50 hPa et 100 hpa, est param´etr´e par une condition de vitesse verticale nulle.Chapitre 2. M´ethodologie et principaux outils de simulation 57
2.4 Mod`ele lagrangien de dispersion de particules :
FLEXPART-WRF
2.4.1 Description
Le mod`ele lagrangien de dispersion de particules FLEXPART (Stohl et al., 2005) a ´et´e
con¸cu initialement pour simuler, aux larges et moyennes ´echelles, la dispersion de polluants
provenant de sources industrielles, tels les accidents au sein d’une centrale nucl´eaire,
les incendies de plateforme industrielle, etc. FLEXPART simule le transport, la diffusion,
les d´epˆots secs et humides, et la d´esint´egration radioactive des traceurs lib´er´es
depuis des sources (point, ligne, surface ou volume). La dynamique de ce code permet
des simulations directes (la dispersion des traceurs depuis leur source), ou indirectes
(d´etermination des sources potentielles pour des r´ecepteurs connus). Ce mod`ele utilise
les donn´ees m´et´eorologiques mondiales comme les pr´edictions du mod`ele Global Forecast
System (GFS, Han and Pan (2011); Yang et al. (2006)) fournies avec une r´esolution
sup´erieure ou ´egale `a 0,5➦. Dans le cas des moyennes et petites ´echelles, c’est le mod`ele
coupl´e FLEXPART-WRF qui a ´et´e d´evelopp´e pour mod´eliser la dispersion de particules
(Brioude et al., 2013). Tout comme FLEXPART, le code FLEXPART-WRF ´ecrit en Fortran
95 est en libre t´el´echargement sous la licence GNU General Public Licence (GPL).
2.4.1.1 Int´egration des donn´ees m´et´eorologiques WRF
Le transport des polluants dans le code num´erique FLEXPART-WRF est forc´e par des
champs de variables m´et´eorologiques WRF (Tab. 2.5).
Les sorties du mod`ele WRF sont maill´ees sur une grille Arakawa C-grid avec des niveaux
verticaux η suivant la topographie. Les composantes du vent horizontal et vertical sont
d´efinies sur grille d´ecal´ee. Dans le mod`ele FLEXPART-WRF, les vents sont interpol´es
sur le centre des mailles, de telle sorte que toutes les donn´ees m´et´eorologiques soient sur
la mˆeme grille. Les donn´ees WRF 3-D sont interpol´ees dans FLEXPART-WRF, sur des
niveaux cart´esiens suivant la topographie.Chapitre 2. M´ethodologie et principaux outils de simulation 58
Tableau 2.5: Variables des sorties WRF requises et optionnelles pour le for¸cage du
mod`ele FLEXPART-WRF (Brioude et al., 2013).
Variable WRF Dimension Description
ZNW 1D Valeur Eta des niveaux verticaux Eta
ZNU 1D Valeur Eta `a la moiti´e des niveaux verticaux
PB 3D Valeur de la pression `a l’´etat de r´ef´erence en Pa
P 3D Perturbation sur la pression en Pa
PHB 3D Valeur du g´eopotentiel `a l’´etat de r´ef´erence en m2
.s-2
PH 3D Perturbation sur le g´eopotentiel en m2
.s-2
T 3D Perturbation de temp´erature potentielle en K
QVAP 3D Rapport de m´elange de vapeur d’eau en kg.kg-1
TKE 3D Energie cin´etique turbulente en m ´ 2
.s-2 (optionnel)
XLAT 2D Latitude en degr´e nord
XLONG 2D Longitude en degr´e est
MAPPAC M 2D Facteur d’´echelle de la carte
PSFC 2D Pression `a la surface en Pa
U10 2D Vitesse du vent horizontal `a 10 m suivant l’axe x
V10 2D Vitesse du vent horizontal `a 10 m suivant l’axe y
T2 2D Temp´erature `a 2 m en K
Q2 2D Humidit´e sp´ecifique `a 2 m en kg.kg-1
SW 2D Rayonnement solaire incident en W.m-2 (optionnel)
RAINNC 2D Pr´ecipitation r´esolue explicitement en mm (optionnel)
RAINC 2D Pr´ecipitation convective en mm (optionnel)
HFX 2D Flux de chaleur sensible `a la surface en W.m-2 (optionnel)
UST 2D Vitesse de friction en m.s-1 (optionnel)
HCLA 2D Hauteur de la couche limite atmosph´erique en m (optionnel)
Type 1 des variables de vent int´egr´ees
U 3D Vitesse du vent horizontal suivant l’axe x en m.s-1
V 3D Vitesse du vent horizontal suivant l’axe y en m.s-1
W 3D Vitesse du vent suivant l’axe z en m.s-1
Type 2 des variables de vent int´egr´ees
AVGFLX RUM 3D Vitesse du vent horizontal suivant l’axe x, pond´er´ee sur la masse
et moyenn´ee sur l’intervalle de temps, en Pa.m.s-1
AVGFLX RVM 3D Vitesse du vent horizontal suivant l’axe y, pond´er´ee sur la masse
et moyenn´ee sur l’intervalle de temps, en Pa.m.s-1
AVGFLX WWM 3D Mouvement vertical, pond´er´e sur la masse
et moyenn´e sur l’intervalle de temps, en Pa.m.s-1
MU 2D Perturbation de la masse d’air dans la colonne en Pa
MUB 2D Masse d’air de r´ef´erence dans la colonne en Pa
Type 3 des variables de vent int´egr´ees
U 3D Vitesse du vent horizontal suivant l’axe x en m.s-1
V 3D Vitesse du vent horizontal suivant l’axe y en m.s-1
WW 3D Mouvement vertical de la masse d’air en Pa.s-1
2.4.1.2 Param´etrisation de la couche limite atmosph´erique et de la turbulence
Par d´efaut, deux param`etres de couche limite WRF sont utilis´es : la vitesse de friction et
le flux de chaleur sensible. Stohl et al. (2005) ont indiqu´e que ces param`etres peuvent ˆetre
calcul´es dans FLEXPART en appliquant la m´ethode du profil (Berkowicz and Prahm,
1982) au vent (10 m et second niveau vertical) et `a la temp´erature (2 m et second niveau
vertical). Une option (SFC OPTION) permet d’int´egrer la hauteur de la couche limite
simul´ee par WRF ou d’effectuer son calcul dans FLEXPART par la m´ethode de la valeur
critique du nombre de Richardson (Stohl et al., 2005; Vogelezang and Holtslag, 1996).
Dans ce cas, la HCLA est atteinte pour le premier niveau vertical pour lequel le nombre
de Richardson d´epasse la valeur critique de 0,25.Chapitre 2. M´ethodologie et principaux outils de simulation 59
Quatre options sont disponibles pour la param´etrisation du vent turbulent dans la couche
limite (Brioude et al., 2013) :
1. Le traitement de la turbulence est d´esactiv´e.
2. Le m´elange turbulent de la couche limite est trait´e par le sch´ema de turbulence
Hanna (Hanna, 1982). Ce sch´ema est bas´e sur les param`etres suivants : la hauteur
de couche limite (HCLA), la longueur de Monin-Obukhov, l’´echelle de la vitesse de
convection, la longueur de rugosit´e et la vitesse de friction. En fonction du r´egime
de la couche limite, instable, stable ou neutre, diff´erents profils turbulents sont
utilis´es. Le sch´ema de turbulence Hanna peut ˆetre associ´e `a une param´etrisation
de couche limite convective. Dans ce cas la turbulence gaussienne est remplac´ee
par la formulation de Luhar et al. (1996).
3. Les composantes du vent turbulent sont calcul´ees `a partir de l’´energie cin´etique
turbulente (TKE) fournie par WRF. La TKE est r´epartie entre les composantes horizontales
et verticales suivant la couche de surface et la stabilit´e locale param´etr´ee
par le sch´ema de turbulence Hanna.
4. La TKE des sorties WRF est utilis´ee. La TKE est r´epartie d’apr`es l’´equilibre entre
l’´energie turbulente de production et celle de dissipation.
Au-dessus de la CLP, la turbulence est bas´ee sur une diffusivit´e verticale constante de
0,1 m2
.s-1 dans la stratosph`ere et une diffusivit´e horizontale de 50 m2
.s-1 dans la troposph`ere
libre (Stohl et al., 2005). La stratosph`ere et la troposph`ere sont diff´erenci´ees par
une valeur seuil de 2 pvu (potential vorticity units).
2.4.1.3 Calcul de la trajectoire des particules
Comme d´ecrit par Stohl et al. (2005), FLEXPART utilise un sch´ema du type ” acc´el´eration
nulle ”. L’´equation de la trajectoire (Stohl et al., 1998) est une ´equation diff´erentielle du
premier ordre,
dX
dt = v[X(t)] (2.12)
qui est int´egr´ee `a l’aide d’un sch´ema d’int´egration num´erique du premier ordre de type
Euler :
X(t + ∆t) = X(t) + v(X, t)∆t, (2.13)
o`u t est le temps, ∆t l’incr´ement de temps, X le vecteur position et v = ¯v + vt + vm, le
vecteur du vent incluant le vent de la maille ¯v, les fluctuations du vent turbulent vt et les
fluctuations du vent `a la m´eso-´echelle vm.Chapitre 2. M´ethodologie et principaux outils de simulation 60
Le transport des particules est calcul´e `a partir des donn´ees m´et´eorologiques (principalement
les vents) interpol´ees `a la position de la particule (Stohl et al., 2005) tandis que la
dispersion turbulente est bas´ee sur la r´esolution des ´equations de Langevin.
2.4.2 Configurations de nos simulations
L’objectif principal des simulations WRF-LES-FLEXPART est d’analyser les effets des
circulations locales sur la dispersion d’un panache de polluants industriels dans la zone
la plus peupl´ee de l’archipel pour trois cas r´eels de situation m´et´eorologique (AS, AM et
AF).
Nous nous sommes int´eress´es `a la source industrielle la plus polluante de l’ˆıle : la centrale
diesel EDF de Jarry nord, situ´ee dans le Petit Cul-de-Sac Marin (Fig. 1.5, 1.7, 1.8, 1.9).
D’apr`es le Registre fran¸cais des Emissions polluantes ´ , la centrale EDF Jarry nord ´emet
chaque ann´ee, 10 kilotonnes d’oxydes d’azote en ´equivalent NO2 (NOx = NO + NO2).
Seules les ´emissions de NOx sont r´epertori´ees dans ce registre, le rapport du m´elange NO–
NO2 n’est pas disponible. Nous avons donc analys´e les concentrations d’oxyde d’azote
NOx produites par la combustion du diesel dans la centrale, durant les trois types de
temps (AS, AM et AF). La couleur brune, caract´eristique du NO2, nous permet d’´evaluer
visuellement la structure du panache depuis des photos d’observation (Fig. 1.7, 1.9).
Les simulations de la dispersion du NOx ´emis depuis les chemin´ees de la centrale sont
effectu´ees dans le domaine LES D06 (Fig. 2.10, 2.11) `a l’aide de FLEXPART.
2.4.2.1 P´eriodes de simulation et intervalles de temps des sorties mod`eles
Les dur´ees des p´eriodes simul´ees sont de 24 heures pour les trois cas : AF (du 3 d´ecembre
2007 16 h UTC au 4 d´ecembre 2007 16 h UTC), AS (du 14 d´ecembre 2007 16 h UTC au
15 d´ecembre 2007 16 h UTC) et AM (du 24 d´ecembre 2007 16 h UTC au 25 d´ecembre
2007 16 h UTC).
Les sorties WRF-LES du domaine D06 sont utilis´ees pour forcer toutes les 10 minutes
le mod`ele FLEXPART. Les sorties de concentration de NOx sont moyenn´ees sur 10 minutes
et sauvegard´ees toutes les 10 minutes. Nous avons choisi d’employer le mˆeme intervalle
de temps pour l’int´egration dans FLEXPART des sorties WRF-LES et pour les
sauvegardes des concentrations WRF-LES-FLEXPART, pour limiter toute mod´elisation
suppl´ementaire des champs m´et´eorologiques par FLEXPART et les ´eventuels biais associ´es.Chapitre
2. M´ethodologie et principaux outils de simulation 61
2.4.2.2 Caract´erisation des niveaux verticaux
Pour simuler les effets des circulations locales sur la dispersion du panache de NOx, 38
niveaux verticaux, allant de 10 `a 3000 m AGL ont ´et´e employ´es (Fig. 2.15). Tout comme
dans le mod`ele WRF, les niveaux verticaux FLEXPART suivent les variations de la topographie.
Figure 2.15: Profil vertical des 38 niveaux verticaux FLEXPART-WRF.
2.4.2.3 Param´etrisation du panache de NOx de la centrale EDF
D’apr`es le site internet du Registre fran¸cais des Emissions polluantes ´ , la centrale EDF
Jarry nord a ´emis en 2007 9,790 kilotonnes d’oxydes d’azote en ´equivalent NO2. En partant
de ce chiffre, la masse totale de NOx ´emise par la centrale durant les simulations
de 24 heures est de 26,820 tonnes. Le nombre total de particules simul´ees durant les 24
heures, est ´etabli `a 100000 avec un taux d’´emission constant (toutes les 10 minutes).
Les dimensions de la colonne d’´ejection des particules, sont d´etermin´ees en fonction des
coordonn´ees g´eographiques des chemin´ees de la centrale, de leur hauteur et des observations
de l’extension verticale du panache en couche limite atmosph´erique neutre. La
distance entre les deux chemin´ees est inf´erieure `a la taille de la maille du domaine D06
(111 m). Nous consid´erons donc, une unique colonne d’´ejection pour les deux chemin´ees
sur la grille du domaine. La colonne d’´ejection s’´etend horizontalement sur un rectangle
d´elimit´e par le coin inf´erieur gauche (16.23518➦N, 61.5543➦W) et le coin sup´erieur droit
(16.23559➦N, 61.5537➦W). La colonne d’´ejection s’´etend verticalement depuis la hauteur
des chemin´ees (≈ 60 m AGL) jusqu’`a la hauteur du panache observ´ee en couche limite
neutre (≈ 600 m AGL).Chapitre 2. M´ethodologie et principaux outils de simulation 62
2.4.2.4 Param´etrisations physiques
Brioude et al. (2012) ont montr´e que l’utilisation des champs de vitesse verticale instantan´ee
WRF, entrainait des biais dans les zones de topographie complexe. Pour pr´evenir
ces incertitudes, les simulations ont ´et´e effectu´ees en int´egrant les champs de vitesses
moyenn´ees WRF : les composantes horizontales et verticales de la vitesse sont pond´er´ees
sur la masse et moyenn´ees sur l’intervalle de temps. Dans notre cas, ces champs de vitesses
sont moyenn´ees sur 10 minutes. D’apr`es Brioude et al. (2013), les champs de vitesses
moyenn´ees WRF permettent de r´eduire les incertitudes sur la mod´elisation de la trajectoire
des particules dans FLEXPART.
Les sorties num´eriques WRF-LES n’incluent pas la hauteur de la couche limite atmosph´erique
(HCLA), FLEXPART d´etermine ce param`etre en se basant sur la valeur critique du
nombre de Richardson.
Nous avons utilis´e les deux param´etrisations de turbulence qui permettent l’int´egration
des champs de TKE produits par WRF-LES (description dans la partie 2.4.1.2). Durant
nos simulations, l’activation de la param´etrisation de la turbulence bas´ee sur l’´equilibre
entre la production et la dissipation de la TKE, a entrain´e des instabilit´es num´eriques
g´en´erant des valeurs invalides. Donc nous avons finalement opt´e pour l’utilisation d’une
seule param´etrisation : la r´epartition de la TKE WRF-LES suivant des coefficients de
stabilit´e du sch´ema Hanna (Hanna, 1982).
2.5 Donn´ees m´et´eorologiques d’observation pour l’´evaluation
du mod`ele WRF ARW3
2.5.1 Radiosondages journaliers (Universit´e du Wyoming)
Pour ´evaluer nos premi`eres simulations nous avons jug´e utile d’effectuer des comparaisons
des param`etres sur toute la troposph`ere `a l’aide des donn´ees fournies par les radiosondages.
Cependant un seul radiosondage est disponible une fois par jour pour la zone de la Guadeloupe
(station RZT de l’a´eroport du Raizet), soit pour les trois simulations de 48 heures,
seulement six profils observ´es. Pour avoir des points de comparaison suppl´ementaires,
d’autres stations de radiosondage (12 h UTC) ont ´et´e utilis´ees : BAR (ID 78954, Barbade)
et SXM (ID 78866, Saint-Martin) qui sont localis´ees dans le domaine D02, TRI
(ID 78970, Trinidad), PTR (ID 78526, Porto-Rico), et SDM (ID 78486, R´epublique Dominicaine)
qui sont localis´ees dans le domaine D01 (Fig. 2.16).Chapitre 2. M´ethodologie et principaux outils de simulation 63
Il faut noter que les radiosondages ont approximativement la moiti´e du nombre des niveaux
verticaux simul´es par WRF. Pour calculer les estimateurs d’erreur pr´esent´es dans
la section 2.7, les radiosondages observ´es et les profils verticaux mod´elis´es sont interpol´es
(avec une m´ethode spline cubique) aux mˆemes niveaux de pression (1000, 950, 925, 900,
850, 800, 700, 650, 600, 500, 400, 300, 250, 200, 150, et 100 hPa).
Le mod`ele int`egre les profils d’observation via les analyses NCEP FNL `a 12 h UTC. Pour
estimer la capacit´e du mod`ele WRF `a pr´edire la stratification, les profils verticaux WRF
`a 11 h UTC sont ´evalu´es.
Les r´esultats des 35 comparaisons (TRI a un radiosondage manquant) `a chaque niveau,
entre les profils interpol´es observ´es et simul´es sont pr´esent´es dans la section 3.1.1 du
rapport.
Figure 2.16: G´eolocalisation des radiosondages (TRI, BAR, RZT, SXM, PTR, et
SDM : carr´es rouges), des bou´ees du r´eseau NDBC-NOAA (ATL, CAR, POR, et
BAH : cercles bleus) au sein des quatre premiers domaines (D01, D02, D03, D04)
employ´es dans les simulations WRF m´eso-´echelles, de r´esolutions respectives de 27, 9,
3 et 1 km.
2.5.2 Bou´ees m´et´eorologiques du National Data Buoy Center
Les donn´ees d’observation de la surface de la mer sont extraites de quatre bou´ees du
National Data Buoy Center (http://www.ndbc.noaa.gov/) : la bou´ee POR (ID 41043,
21,061➦N, 64,966➦W, au nord de Porto-Rico) localis´ee dans le domaine 2, la bou´ee BAH
(ID 41046, 23,838➦N, 68,333➦W, au large des Bahamas), la bou´ee CAR (ID 42059, 15,058➦N,
67,528➦W, en mer des Cara¨ıbes) et la bou´ee ATL (ID 41040, 14,516➦N, 53,024➦W, dansChapitre 2. M´ethodologie et principaux outils de simulation 64
l’oc´ean Atlantique), qui sont localis´ees dans le domaine 1 (Fig. 2.16).
Les donn´ees d’observation horaires ´etudi´ees sont les moyennes 10 min des variables suivantes
: la temp´erature de la surface de la mer, la temp´erature de l’air `a 4 m au-dessus
du niveau de la mer (AMSL), la vitesse et la direction du vent `a 5 m AMSL. Les quatre
bou´ees ont une pr´ecision de 1➦C pour la temp´erature de surface de la mer, 1➦C pour la
temp´erature de l’air, 1 m.s-1 pour la vitesse du vent et 10➦ pour la direction du vent.
Les variables des sorties WRF sont extraites au point de maille le plus proche de chaque
bou´ee. Les observations, temp´erature de surface de la mer, temp´erature de l’air `a 4 m AMSL,
et vitesse et direction du vent `a 5 m AMSL, sont respectivement compar´ees avec les variables
WRF, ”skin temperature”, temp´erature de l’air `a 2 m AMSL et vitesse et direction
du vent `a 10 m AMSL.
L’´evaluation des champs de surface marins WRF est pr´esent´ee `a la section 3.1.1 du rapport.
2.5.3 Stations m´et´eorologiques de l’archipel de la Guadeloupe
(M´et´eo France et LaRGE)
Les donn´ees d’observation `a la surface terrestre sont extraites des cinq stations m´et´eorologiques
de l’archipel de la Guadeloupe (domaine 4), en fonctionnement durant la p´eriode
´etudi´ee (d´ecembre 2007). RZT, DES, MOU, et GBD sont des stations du r´eseau M´et´eoFigure
2.17: Carte topographique (IGN, 50 m de r´esolution), avec le mˆat
instrument´e du laboratoire LaRGE (ARN, triangle vert) et les 4 stations
M´et´eo-France, Raizet (RZT, disque rouge), Moule (MOU, ´etoile magenta), D´esirade
(DES, carr´e bleu), Grand-Bourg de Marie-Galante (GBD, losange noir).Chapitre 2. M´ethodologie et principaux outils de simulation 65
France, localis´ees respectivement, au Raizet, `a la D´esirade, au Moule et `a Grand-Bourg
(Fig. 2.17). Les donn´ees horaires utilis´ees sont les moyennes 10 min des variables suivantes
: la temp´erature de l’air `a 2 m AGL, la vitesse et la direction du vent `a 10 m AGL.
Ces quatre stations M´et´eo-France ont une pr´ecision de 0,1➦C pour la temp´erature, 1 m.s-1
pour la vitesse du vent, et 10➦ pour la direction du vent.
D’Alexis (2011) a men´e une campagne exp´erimentale de terrain pour analyser les ph´enom`enes
de micro-´echelle dans la couche de surface de mangrove. Entre avril 2007 et juin
2008, la station m´et´eorologique du Laboratoire de Recherche en Energie et G´eosciences ´
(LaRGE) a enregistr´e des mesures `a 1 Hz et `a 20 Hz. Ce mˆat instrument´e ARN, localis´e
dans la zone cˆoti`ere d’Arnouville de Petit-Bourg (Fig. 2.17) est muni d’un capteur
barom´etrique PTB101B (Fig. 2.18a), d’une centrale d’acquisition Campbell CR3000
(Fig. 2.18b), d’un capteur HR capacitif (HMP45C) pour l’humidit´e et la temp´erature `a
2 m AGL (Fig. 2.18c), d’un an´emom`etre `a coupelles `a 2 m AGL (Fig. 2.18d), d’une girouette
`a 2 m AGL (Fig. 2.18e), d’un an´emom`etre sonique 3D (CSAT3) pour le calcul
des flux turbulents `a 5 m AGL (Fig. 2.18f) et d’un an´emom`etre sonique 2D (WindSonic)
pour le vent horizontal `a 10 m AGL (Fig. 2.18g). La station ARN a une pr´ecision de 0,2➦C
pour la temp´erature, 2% (avec une r´esolution de 0,01 m.s-1) pour la vitesse du vent, et
3➦ pour la direction du vent. En plus de ces variables classiques, la station ARN, avec
ses mesures `a 20 Hz nous permettra d’´evaluer les simulations de flux turbulents comme
le flux de chaleur sensible (HFX) et l’´energie cin´etique turbulente (TKE). Les champs de
surface WRF-LES (10 minutes) seront ´evalu´es avec les donn´ees mesur´ees par ARN.Chapitre 2. M´ethodologie et principaux outils de simulation 66
Figure 2.18: Description du mˆat instrument´e du laboratoire LaRGE `a ARN (sch´ema
extrait de D’Alexis (2011)), avec, (a) le capteur barom´etrique PTB101B, (b) la
centrale d’acquisition Campbell CR3000, (c) le capteur HR capacitif (HMP45C) pour
l’humidit´e et la temp´erature (2 m AGL), (d) l’an´emom`etre `a coupelles (2 m AGL), (e)
la girouette (2 m AGL), (f ) l’an´emom`etre sonique 3D (CSAT3) pour le calcul des flux
turbulents (5 m AGL) et (g) l’an´emom`etre sonique 2D (WindSonic) pour le vent
horizontal (10 m AGL).
2.6 Donn´ees d’observation de la qualit´e de l’air pour
l’´evaluation du mod`ele FLEXPART-WRF
Nous avons utilis´e les donn´ees d’observation de concentration en NOx enregistr´ees par
la station du r´eseau Gwad’air (association agr´e´ee de surveillance de la qualit´e de l’air,
AASQA) situ´ee `a Pointe-`a-Pitre (PAP) donc dans l’agglom´eration pointoise (Fig. 2.19).
Cette agglom´eration compos´ee de quatre communes (Pointe-`a-Pitre, Baie-Mahault, Les
Abymes et Le Gosier) inclut la zone industrielle la plus importante de l’archipel (zone deChapitre 2. M´ethodologie et principaux outils de simulation 67
Jarry, not´ee EDF sur la Fig. 2.19). L’agglom´eration pointoise est la zone la plus peupl´ee
de l’archipel : 133000 habitants pour une superficie de 175 km2
(Plocoste, 2013).
Figure 2.19: Carte de localisation de la station Gwad’air PAP (losange violet) et de
la centrale ´electrique EDF (croix rouge) : (a) Topographie (en m AMSL) du domaine
D05 (maille de 333 m) avec l’agglom´eration pointoise (contour violet), (b) image
satellite Google earth de la zone d’´etude (4/8/2013).
Plocoste (2013) a d´ecrit les ´equipements de mesure de cette station : un analyseur d’oxyde
d’azote NOX 2000 G, un analyseur de poussi`eres TEOM 1400A, un analyseur d’ozone OZ
2000 G et un calibrateur SONIMIX 3022-2000TM et un analyseur de dioxyde de soufre
SF 2000 G.
2.7 Estimateurs d’erreur utilis´es pour l’´evaluation statistique
des simulations
C´ec´e et al. (2014) ont d´ecrit les estimateurs d’erreur (MBE, RMSE, MAE, IOA and IOA2)
qui ont ´et´e employ´es pour l’´evaluation statistique des simulations.
Les outils d’´evaluation statistique les plus utilis´es dans les ´etudes de mod´elisation m´et´eorologiques,
ont ´et´e d´evelopp´es par Willmott (1981); Willmott and Matsuura (2005). Les
erreurs individuelles de pr´ediction du mod`ele sont d´efinies comme ei = Pi − Oi (i =
1, 2, ..., n), o`u Pi et Oi sont respectivement les pr´edictions mod`eles et les observations in
situ. L’erreur du biais moyen est d´efinie comme MBE = n
−1 Pn
i=1
ei = P¯ − O¯. L’erreur
moyenne absolue est d´efinie par MAE = n
−1 Pn
i=1
|ei
|. L’erreur quadratique moyenne est
bas´ee sur la somme du carr´e des erreurs : RMSE =
n
−1 Pn
i=1
|ei
|
2
1/2
. Willmott (1981) aChapitre 2. M´ethodologie et principaux outils de simulation 68
d´efini un indice de performance des mod`eles (IOA) comme
IOA = 1 −
Pn
i=1
|ei
|
2
Pn
i=1
[|Pi − O¯| + |Oi − O¯|]
2
(2.14)
avec une valeur comprise entre 0 et 1. Les valeurs sup´erieures `a 0,5 sont consid´er´ees comme
bonnes. Willmott et al. (2011) ont reformul´e un indice de performance dont la valeur suit
les variations de croissance ou d´ecroissance de la MAE. L’intervalle de valeur est [-1,1].
Ils ont exprim´e ce nouvel indice comme
IOA2 =
1 −
Pn
i=1
|ei|
2
Pn
i=1
|Oi−O¯|
, quand Pn
i=1
|ei
| ≤ 2
Pn
i=1
|Oi − O¯|
2
Pn
i=1
|Oi−O¯|
Pn
i=1
|ei|
− 1, quand Pn
i=1
|ei
| > 2
Pn
i=1
|Oi − O¯|
(2.15)
. D’apr`es l’´equation (2.15), une valeur de IOA2 ´egale `a 0,5 indique que la somme des erreurs
repr´esente la moiti´e de la somme des variations du mod`ele parfait plus celles ajout´ees
des observations. A l’oppos´e, une valeur de IOA2 ´egale `a -0,5 signifie que la somme des `
erreurs repr´esente le double de la somme des variations du mod`ele parfait plus celles des
observations. La RMSE et l’IOA sont les outils les plus utilis´es dans la lit´erature pour
exprimer les diff´erences entre les pr´evisions et les donn´ees observ´ees. Cependant, comme
´ecrit par Willmott and Matsuura (2005), du fait qu’ils sont caract´eris´es par la somme
du carr´e des erreurs, les erreurs importantes ont relativement plus d’influence sur l’erreur
totale, que les plus faibles (contrairement `a la MAE).
Nos simulations num´eriques de courte dur´ee, avec peu de points spatiaux de comparaison
(nombre faible de stations m´et´eorologiques dans la zone d’´etude) seraient d’autant plus
affect´ees par ce probl`eme. Pour le r´esoudre, suivant la recommandation de Willmott and
Matsuura (2005); Willmott et al. (2011), la MAE and l’IOA2 sont choisis `a la place de
la RMSE et du IOA. Les valeurs suivantes de IOA2 : n´egative, comprise entre 0 et 0,5,
et sup´erieure `a 0,5, sont respectivement consid´er´ees comme mauvaises, bonnes et tr`es
bonnes.Chapitre 3
R´esultats des simulations et
discussion
3.1 Simulations num´eriques m´eso-´echelles des circulations
g´en´er´ees par l’archipel de la Guadeloupe
(WRF)
Dans cette partie, nous pr´esentons les r´esultats des simulations num´eriques m´eso-´echelles
incluant les quatre domaines : D01, D02, D03 et D04 (Fig. 2.10).
Deux configurations du domaine D04 sont analys´ees : la configuration M´eso-A (carte
d’occupation des sols USGS 1992, ULC) et la configuration M´eso-A’ (carte d’occupation
des sols Corine 2006, CLC24).
3.1.1 Simulation M´eso-A : r´esum´e et article publi´e
Les r´esultats des simulations num´eriques m´eso-´echelles (M´eso-A) ont ´et´e publi´es dans la
revue scientifique ” Monthly Weather Review ”.
Le mod`ele Weather Research and Forecast (WRF) est utilis´e pour simuler une descente
d’´echelle dynamique `a l’aide des quatre domaines imbriqu´es (D01, D02, D03, D04), de
r´esolutions respectives : 27, 9, 3, 1 km.
Les trois situations m´et´eoroloqiques, correspondant aux aliz´es faibles, moyens et soutenus,
sont simul´ees : AF, AM et AS (respectivement li´es aux valeurs du nombre de Froude local
69Chapitre 3. R´esultats des simulations et discussion 70
de 0,21, 0,41 et 0,82).
Pour les trois types de temps, les variables m´et´eorologiques classiques pr´esentent une
bonne ad´equation avec les donn´ees d’observations, sur plusieurs sites. C’est aussi le cas
des champs simul´es `a 1 km sur l’archipel de la Guadeloupe, malgr´e l’utilisation dans le
mod`ele WRF de la carte d’occupation des sols ULC24 dont les biais ont ´et´e d´ecrits dans
le chapitre 2 du rapport.
Les r´esultats de la simulation M´eso-A ont permis de compl´eter la cartographie des r´egimes
m´et´eorologiques locaux observ´es par Br´evignon (2003). Ces descriptions peu pr´ecises n’incluaient
pas des donn´ees maill´ees de vent, de temp´erature de surface, de couverture nuageuse
et de flux de chaleur sensible sur l’ensemble de l’archipel.
Les r´egimes attendus du vent local (au vent, continental insulaire, sous le vent) et la
pr´edominance des effets thermiques et orographiques (respectivement au-dessus de la
Grande-Terre et de la Basse-Terre) sont retrouv´es dans les sorties simul´ees.
Dans le cas des AS, la convection est inhib´ee et les circulations locales sont g´en´er´ees par
l’orographie.
Durant les AM, dans les zones de faibles topographies, les circulations locales sont gouvern´es
par le contraste thermique de surface qui induit, durant la journ´ee, une convergence
des vents marins vers la terre et, durant la nuit, une divergence des vents de la terre vers
la mer.
Dans le cas des AF, le mod`ele simule correctement un vent catabatique nocturne induisant
un ´ecoulement d’ouest observ´e exp´erimentalement par D’Alexis (2011); D’Alexis
et al. (2011) sur la cˆote au vent de la Basse-Terre. Durant la nuit, cette circulation s’opposant
aux aliz´es semble s’´etendre en mer (dans le Petit Cul-de-Sac Marin), puis sur la
zone industrielle de Jarry et enfin sur la cˆote ouest de la Grande-Terre. Cet ´ecoulement a
une vitesse de vent maximale de 4.7 m s-1
.
Les r´esultats de l’exp´erience M´eso-A sugg`erent que cet ´ecoulement particulier, apparaissant
dans l’agglom´eration pointoise et la zone industrielle de Jarry, pourrait g´en´erer une
d´egradation de la qualit´e de l’air, li´ee aux sources industrielles de polluants (comme la
centrale diesel de production d’´electricit´e).Numerical Simulations of Island-Induced Circulations and Windward Katabatic Flow
over the Guadeloupe Archipelago
RAPHAE¨ L CE´ CE´ , DIDIER BERNARD, AND CHRISTOPHE D’ALEXIS
Department of Physics, University of the French West Indies and French Guiana, Pointe-a-Pitre, Guadeloupe
JEAN-FRANC¸ OIS DORVILLE
Department of Physics, University of West Indies, Kingston, Jamaica
(Manuscript received 8 April 2013, in final form 18 September 2013)
ABSTRACT
This article deals with the first high-resolution numerical modeling of the weather over the small and high
islands of the Guadeloupe archipelago. Its main goal is to analyze the mechanisms that drive local-scale
airflow circulations over this archipelago, using the 1-km Weather Research and Forecasting Model (WRF).
Three meteorological situations corresponding to weak trade winds (WTW), medium trade winds (MTW),
and strong trade winds (STW) have been selected and are linked with local Froude number values of 0.21,
0.41, and 0.82, respectively. For these three weather types, simulated typical meteorological variables present
a good agreement with observational data at several locations. The 48-h simulations allow the completion of
the previous coarse observational descriptions that did not include a map of the wind, skin temperature, cloud
cover, and sensible heat flux for the whole archipelago. The expected local wind regime areas (windward,
inland, and leeward) are retrieved in the model outputs, including the predominance of thermal and orographic
effects over Grande-Terre Island and Basse-Terre Island, respectively. Under STW, the convection is
inhibited and the local circulations are driven by the orography. In the case of WTW, the model simulates well
a katabatic wind, inducing cold nocturnal reversed flow on the windward coast of Basse-Terre. This circulation,
opposing the trade winds, extends to the sea and Grande-Terre Island. This flow has a maximum wind
speed of 4.7 m s21
. This particular flow occurring in the most densely populated area produces an important
nocturnal pollution period due to industrial sources (the diesel power plants of the archipelago).
1. Introduction
Many authors have shown that strong radiative and
high topography forcings may induce local circulations
over tropical islands. Mechanical effects of islands on
the steady trade winds is characterized by the local
Froude number Frm which is defined by (U/Nhm), where
U is the wind speed, hm is the height of the mountain,
and N is the buoyancy frequency. The literature dealing
with this subject is generally concerned with one of three
types of island: large (i.e., Frm $ 1, width .50 km), high
(i.e., Frm , 1), or small (i.e., Frm $ 1, width #50 km).
Effects of large islands on synoptic winds have been
examined for the Tiwi Islands (Oliphant et al. 2001) and
Puerto Rico (Malkus 1955; Jury et al. 2009). Oliphant
et al. (2001) showed that with a flat area of 8000 km2
, the
Tiwi Islands generate their own thermal airflow regime
associated with sea/land-breeze systems. The Weather
Research and Forecasting Model (WRF) simulation
over Puerto Rico (Jury et al. 2009), indicated how diurnal
heating and orography act on the convective
boundary layer structure and trade wind airstream. In
general, high islands like the Hawaiian Islands (Smith
and Grubiac 1993; Reisner and Smolarkiewicz 1994;
Feng and Chen 1998; Yang and Chen 2005; Carlis et al.
2010; Nguyen et al. 2010), New Caledonia (Lefevre et al.
2010), Reunion Island (Lesoue¨f et al. 2011), or Lesser
Antilles islands like St. Vincent (Smith et al. 1997) and
Dominica (Smith et al. 2012) would have mainly mechanical
effects on the impinging airflow with in some
cases thermal circulations occurring on the lee side.
During the Dominica Experiment field campaign
(DOMEX), Smith et al. (2012) observed that two types
Corresponding author address: Raphae¨l Cece, Faculty of Sciences,
Department of Physics, University of the French West Indies and
French Guiana, Fouillole campus, Pointe-a-Pitre 97110, Guadeloupe.
E-mail: raphael.cece@univ-ag.fr
850 MONTHLY WEATHER REVIEW VOLUME 142
DOI: 10.1175/MWR-D-13-00119.1
2014 American Meteorological Society
71
Influence du mapping sur la reconnaissance d’un
syst`eme de communication
Marion Bellard
To cite this version:
Marion Bellard. Influence du mapping sur la reconnaissance d’un syst`eme de communication.
Information Theory. Universit´e Pierre et Marie Curie, 2014. French. .
HAL Id: tel-00959782
https://tel.archives-ouvertes.fr/tel-00959782v2
Submitted on 17 Mar 2014
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of scientific
research documents, whether they are published
or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est
destin´ee au d´epˆot et `a la diffusion de documents
scientifiques de niveau recherche, publi´es ou non,
´emanant des ´etablissements d’enseignement et de
recherche fran¸cais ou ´etrangers, des laboratoires
publics ou priv´es.THÈSE DE DOCTORAT DE
l’UNIVERSITÉ PIERRE ET MARIE CURIE
Spécialité
Informatique
École doctorale Informatique, Télécommunications et Électronique (Paris)
Présentée par
Marion Bellard
Pour obtenir le grade de
DOCTEUR de l’UNIVERSITÉ PIERRE ET MARIE CURIE
Sujet de la thèse :
Influence du mapping sur la reconnaissance d’un système de
communication
soutenue le 30 janvier 2014
devant le jury composé de :
Thierry Berger Université de Limoges Rapporteur
Pierre Loidreau DGA-MI Rapporteur
Gilles Burel Université de Bretagne Occidentale Examinateur
Jean-Pierre Tillich INRIA Paris-Rocquencourt Examinateur
Annick Valibouze Université Pierre et Marie Curie Examinateur
Nicolas Sendrier INRIA Paris-Rocquencourt Directeur de thèseMarion Bellard
Influence du mapping sur la reconnaissance d’un système de
communication
INRIA-équipe-projet SECRET
Domaine de Voluceau
78153 Le ChesnayRemerciements
Je tiens à remercier ici toutes les personnes qui m’ont permis d’effectuer cette thèse dans d’excellentes
conditions, aussi bien pour leurs qualités techniques que humaines.
Je tiens d’abord à remercier Nicolas Sendrier mon directeur de thèse pour ses conseils et ses idées
qui ont été précieuses et nécessaires au bon déroulement de ces trois années de thèse.
Je tiens également à remercier Jean-Pierre Tillich, avec qui j’ai eu la chance de travailler, pour son
exigence et sa patience.
Merci ensuite à mes deux rapporteurs Pierre Loidreau et Thierry Berger qui ont donné de leur
temps pour la relecture de ce manuscrit. Je devrais d’ailleurs remercier doublement Thierry Berger,
je lui dois en effet ma découverte des codes correcteurs au cours de mes deux années de Master. Merci
également à Gilles Burel et Annick Valibouze d’avoir accepté de faire partie de mon jury.
Je ne saurais remercier les gens qui m’ont aidée et soutenue durant cette thèse sans remercier
Audrey, avec qui j’ai partagé de multiples interrogations et rebondissements, pour sa disponibilité. Je
lui souhaite bonne chance pour la suite.
Mes pensées vont ensuite vers Maxime et Jérôme sans qui cette thèse n’aurait pas eu lieu et bien
sûr Florine, Denis, Marc, Pierre, Angélique et François pour leur accueil et leur sympathie. Je ne doute
pas que j’aurai le plaisir de les revoir.
Un grand merci à tous les membres et anciens du projet SECRET que j’ai eu l’occasion de côtoyer
Anne, Pascale, María, Christelle, André, Anthony, Ayoub, Baudoin, Céline, Christina, Denise, Gaë-
tan, Grégory, Joëlle, Mamdouh, Matthieu, Rafael, Stéphane, Valentin, Vincent, Virginie et Yann. Je
garderai d’excellents souvenirs des trois années que j’ai passées au projet.
Je dois une dédicace particulière à Christelle qui est d’un grand secours et qui nous aide toujours
avec le sourire, à Ayoub, Baudoin, Céline, Christina et Valentin avec qui j’ai partagé mes séances de
footing et à Christina de nouveau en tant que pâtissière en chef du projet et ancienne collègue de
bureau, merci à elle pour ses excellents gâteaux et sa bonne humeur. Merci également à tous ceux
avec qui j’ai appris l’art des mots croisés.
Mes prochains remerciements vont à mes collègues Grégory, Valentin et Virginie qui font du bureau
1 un endroit où il fait bon travailler. Mille mercis à Grégory pour tous ses conseils et son aide précieuse,
à Valentin pour sa disponibilité sans faille et à Virginie pour sa gentillesse et sa présence.
Merci ensuite à mes proches pour leur soutien et leur patience, mes amies Amanda et Adeline, ma
famille Fanny, Michael, Fredo, Ingrid, Christine, mes parents bien sûr et enfin Nicolas.iiNotations
Notations mathématiques
H⊤ la transposée de la matrice H
dH( . , . ) la distance de Hamming
de( . , . ) la distance euclidienne
WH( . ) le poids de Hamming
Fq le corps à q éléments, q puissance d’un
nombre premier
GL(a, F2) l’ensemble des matrices inversibles de
taille a × a à coefficients dans F2
pgcd le plus grand diviseur commun
ppcm le plus petit multiple commun
degg(x) le degré du polynôme g(x)
Notations relatives aux mappings
a le nombre de bits par symboles binaires de
la modulation
C une constellation
CL(f) la classe linéaire de f
CA(f) la classe affine de f
f un mapping
Gp la pénalité de Gray moyenne
Gpk la pénalité de Gray maximum
Notations relatives aux codes correcteurs
C un code
n la longueur du code
k la dimension du code
G une matrice génératrice
H une matrice duale
iiiChapitre 1
A0 l’amplitude de l’onde porteuse
A et B des alphabets de modulation
b(t) un bruit blanc gaussien
f0 la fréquence de l’onde porteuse
g(t) une impulsion élémentaire
M le nombre de points de la constellation
M − ASK,M − P SK, M − QAM une modulation à M points
p(t) une onde porteuse
r(t) le signal reçu
sI (t) la porteuse en phase
sQ(t) la porteuse en quadrature
s(t) le signal émis
ϕ0 la phase de l’onde porteuse
Chapitre 4
C\I code poinçonné aux positions indéxées par I
HI matrice duale restreinte aux positions indixées par I
p la probabilité d’erreur du canal binaire symétrique
PC la probabilité de collisions pour des données codées
Paléa la probabilité de collisions pour des données aléatoires
R = PC
Paléa
le rapport des probabilités de collisions
t la taille des blocs de lecture d’une séquence binaire
Xobs le nombre de collisions observées sur une séquence binaire
xobs la probabilité de collisions observée sur une séquence biniareRésumé
Ce document présente les travaux effectués durant ma thèse au sein de l’Equipe-projet SECRET
à INRIA Paris-Rocquencourt.
Nous nous intéressons à la reconstruction d’un système de communication dans un contexte non
coopératif. Nous cherchons d’une part à reconstruire l’association réalisée entre symboles binaires et
symboles physiques lors de la conversion de données binaires en un signal modulé (éventuellement
bruité). On appelle cette opération le mapping. Dans un canal hertzien, une modulation M-aire peut
transmettre M symboles distincts formant une constellation dans un espace euclidien multidimensionnel
(par exemple bidimensionnel, représentant la phase et l’amplitude des symboles transmis). Nous
regardons essentiellement les modulations de 4 à 256 − QAM (Quadrature Amplitude Modulation).
En l’absence de redondance il est impossible de décider quel mapping a été utilisé, aussi nous supposons
ici que les données binaires sont codées. Nous nous intéressons particulièrement aux mappings
respectant le critère de Gray (deux symboles de la constellation, voisins pour la distance euclidienne,
correspondront à des symboles binaires à distance de Hamming de 1). Ce type de mapping est en effet
couramment utilisé car il permet de limiter l’impact des erreurs d’interprétations lors de la démodulation.
La recherche exhaustive du mapping pour ce type de constellations devient impossible lorsque
le nombre de points de celles-ci augmente, alors que les grandes constellations possèdent l’avantage
d’augmenter les débits de transmission. Nous définissons alors deux types de classes d’équivalences de
mappings : linéaires et affines. Nous définissons de plus un test basé sur la reconnaissance de codes
convolutifs et le taux d’erreur du canal. Nous construisons un algorithme de reconstruction, en appliquant
ce test, de manière appropriée, à un ensemble de représentants des classes d’équivalences
définies. Nous verrons que le résultat d’un tel parcours n’est pas unique mais qu’il permet de réduire
significativement le nombre de mappings possibles tout en réduisant le coût de la recherche.
D’autre part nous définissons une méthode de détection des paramètres d’un code convolutif ainsi
qu’une méthode de reconstruction du dual d’un tel code. Nous regardons une séquence binaire codée
et bruitée par blocs de taille t. Deux blocs identiques définissent ce que l’on appelle une collision. La
cardinalité de l’ensemble des blocs observés pour des données codées est inférieure à celle observée
pour des données aléatoires. Donc la donnée de la probabilité de collisions pour différentes tailles de
blocs permet de distinguer des données codées de données aléatoires. Des blocs glissants sont utilisés
pour caractériser la présence d’un code convolutif. Cela permet d’obtenir la longueur, la dimension
du code et le degré maximum des polynômes générateurs du dual ainsi que la taille de chacune des
équations de parité. De plus en poinçonnant des bits dans chacun des blocs observés nous déduisons
de la probabilité de collisions des équations de parité du code et une matrice génératrice du dual. La
probabilité de collision est de plus invariante pour le changement de mapping lorsque la taille de bloc
est un multiple de la taille des symboles du mapping. Nous sommes alors en mesure de détecter la
longueur du code sans connaître le mapping qui a été utilisé lors de la modulation.
vTable des matières
Notations iii
Résumé v
Introduction 1
1 Introduction à la Transmission du signal Numérique 3
1.1 Modulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.1 Transmission du signal . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1.2 Constellations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
1.2 Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
1.3 Canal de transmission . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.4 Démodulation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2 Mappings 13
2.1 Codages Gray réfléchis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.2 Codages Gray non réfléchis . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.3 Codages Gray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.4 Mappings Gray P SK . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.5 Mappings Gray QAM . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
2.6 Mappings quasi-Gray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3 Codes Convolutifs et Codes de Reed-Solomon 23
3.1 Introduction aux codes correcteurs d’erreurs . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2 Codes cycliques . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3 Codes convolutifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.1 Représentation binaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.3.2 Équations de parité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.3 Représentation en série . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.3.4 Codeurs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4 Reconstruction de codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.1 Codes Convolutifs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.2 Codes Reed-Solomon . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
vii4 Signature de codes convolutifs et recherche du dual par tests statistiques 39
4.1 État de l’art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1.1 Test de profondeur . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.1.2 Test de Burrows-Wheeler et Runs . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2 Test de collisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.3 Espérance du nombre de collisions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3.1 Code de parité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3.2 Équation de parité de poids u . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.4 Distingueur de code convolutif . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
4.5 Détection des paramètres d’un code convolutif par un teststatistique . . . . . . . . . . 52
4.5.1 Détection de la longueur de code . . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.5.2 Détection de la dimension de code . . . . . . . . . . . . . . . . . . . . . . . . . 52
4.5.3 Détection de la longueur des équations de parité . . . . . . . . . . . . . . . . . 58
4.5.4 Résultats de tests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
4.6 Application à la reconstruction du dual . . . . . . . . . . . . . . . . . . . . . . . . . . 59
4.6.1 Reconstruction du dual d’une matrice binaire . . . . . . . . . . . . . . . . . . . 60
4.6.2 Reconstruction du dual d’un code convolutif . . . . . . . . . . . . . . . . . . . . 62
4.7 Signature de codes convolutifs à mapping inconnu . . . . . . . . . . . . . . . . . . . . 64
5 Classes de Mappings 65
5.1 Relations d’équivalences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
5.2 Partitionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
5.3 Représentants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
5.4 Classification des mappings Gray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.4.1 Partitionnement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
5.4.2 Représentants . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
5.5 Classification des mappings quasi-Gray . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
6 Reconstruction de mappings en présence de données codées et bruitées 79
6.1 Classes d’équivalences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.1.1 Équivalence linéaire . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
6.1.2 Équivalence affine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
6.1.3 Nombre de solutions par classe affine . . . . . . . . . . . . . . . . . . . . . . . . 85
6.1.4 Unicité de la classe affine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
6.2 Algorithme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
6.3 Applications aux mappings Gray . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
6.4 Résultats obtenus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
6.5 Application au cas des codes Reed-Solomon . . . . . . . . . . . . . . . . . . . . . . . . 91
A Rapport de probabilités de collisions avec une équation de parité 93Introduction
La transmission d’une information numérique nécessite notamment un codage, à l’aide de codes
correcteurs d’erreurs, puis une adaptation au canal de transmission que l’on appelle modulation. La
modulation est composée de deux parties. La première appelée le mapping permet d’associer des symboles
binaires à des paramètres physiques comme une amplitude et une phase. La seconde partie de la
modulation permet elle d’utiliser ces valeurs pour modifier ponctuellement un signal porteur. Lors de
la réception d’un signal il faut effectuer les opérations inverses de celles appliquées en émission afin de
retrouver l’information émise. Un signal reçu doit donc avant toute chose être démodulé. On parle de
contexte non coopératif lorsqu’un observateur doit recouvrer la séquence binaire émise à partir du seul
signal transmis. Dans ce contexte il faut donc démoduler le signal observé pour associer aux symboles
physiques une information binaire et enfin reconstruire le codage canal utilisé. Nous nous intéressons
ici à ce problème de reconstruction d’un système de communication. Retrouver la modulation correspond
au problème de la démodulation aveugle pour lequel il existe de nombreux travaux académiques,
cependant cette démodulation n’inclut pas la reconstruction du mapping. Nous étudions alors le problème
de la reconstruction du mapping. Retrouver le codage utilisé correspond au problème de la
reconstruction de codes correcteurs d’erreurs pour lequel il existe également de nombreux travaux de
recherche. On pourra citer notammant le travail de A. Valembois sur la reconstruction du dual d’un
code correcteur d’erreur. Son algorithme se base sur la méthode de Canteaut-Chabaud de recherche de
mots de petits poids dans un code. Des travaux spécifiques sur la reconstruction des codes convolutifs
existent comme les thèses de E. Filiol, J. Barbier et M. Côte. Nous sommes intéressés à résoudre le
problème de la reconnaissance de mapping lorsque les données sont codées par un codeur convolutif et
nous utilisons le travail de M. Côte pour notre étude. Cela nous permet d’obtenir une matrice géné-
ratrice du code correcteur utilisé à partir d’une séquence codée bruitée. Cependant, si l’on ne connaît
pas l’association réalisée entre symboles binaires et symboles physiques, le mapping, on ne connaît pas
le comportement de l’algorithme de reconnaissance de code convolutif. Nous nous intéressons à ce problème
et étudions l’interaction entre la reconnaissance de codes convolutifs et la recherche de mapping.
Dès lors que la transmission d’un signal s’effectue grâce à un protocole de communication, la sé-
quence composée des mots de code transmis est encapsulée. De ce fait, il est possible de s’appuyer sur
des balises pour connaître la synchronisation des mots de codes, c’est-à-dire que l’on connait le début
des mots. Nous considérons alors dans ces travaux que la synchronisation est connue et qu’on n’avons
pas à la rechercher.
Nous avons abordé nos travaux selon deux axes. Le premier objectif est de décrire une méthode de
reconstruction du mapping à partir de données démodulées avec un mapping par défaut. Le second
axe consiste à obtenir des informations sur le code de manière invariante pour le mapping.
1Le second axe nous conduit à l’utilisation d’un test statistique basé sur le comptage de collisions
dans une séquence binaire observée par blocs. Ce test permet d’estimer le cardinal de l’ensemble observé
et donne une information à la fois quantitative et qualitative sur l’espace des blocs observés.
Nous définissons alors une méthode de détection de la longueur d’un code convolutif invariante pour
le changement de mapping. C’est-à-dire que nous sommes en mesure de dire si un code convolutif
à été utilisé pour coder les données observées et le cas écheant d’en donner la longueur et ce sans
connaître le mapping utilisé. Nous définissons de plus une méthode de détection des paramètres d’un
code convolutif et de reconstruction du dual connaissant le mapping. C’est l’objet du Chapitre 4. Ce
travail a été soumis à publication.
Le premier axe concerne la reconstruction du mapping lorsque les données observées sont codées.
Nous nous sommes principalement intéressés au cas des codes convolutifs. Lorsque l’on parcourt les
divers mappings possibles on peut observer une multitude de séquences codées correspondant à divers
codes correcteurs. Nous explicitons alors les liens qui relient les différents codes observés. Des classes
d’équivalences de mapping peuvent être définies. Elles seront présentées dans le Chapitre 5. Ceci
nous conduit à l’élaboration d’une méthode de reconstruction de mappings permettant de diminuer
le nombre de mappings à parcourir pour les petites tailles de constellations. Pour des constellations à
16 points et plus, nous considérons uniquement les mappings de type Gray et quasi-Gray. La méthode
s’étend naturellement à ces mappings. Celle-ci est applicable dans le cas où le signal transmis est
un signal bruité. Nous regardons également le comportement des codes de Reed-Solomon vis-à-vis
du changement de mapping. Ceci est vu au Chapitre 6. Cette partie du travail à fait l’objet d’une
publication à ISITA’2012 [7].
2Chapitre 1
Introduction à la Transmission du signal
Numérique
On peut représenter un système de communication (Figure 1.1) par la suite des traitements
appliqués aux données binaires, en émission et en réception, afin d’assurer leur transmission.
Codage source Codage canal Modulation
Décodage source Décodage Canal Démodulation
Canal de transmission
Bruit
Figure 1.1 – Synoptique d’une transmission numérique
Codage source : Le codage de source consiste à éliminer la redondance de manière à réduire la
quantité de données à transmettre.
Codage canal : Quel que soit le type de canal de transmission utilisé, le signal transmis est
soumis à des perturbations, que l’on appelle bruit, pouvant entraîner une altération des données. Afin
d’y remédier, il est d’usage d’ajouter de la redondance à l’information dans le but de détecter puis
corriger les erreurs de transmission. Nous utilisons pour cela des codes correcteurs d’erreurs.
Modulation : La modulation consiste à transformer un message en un signal adapté à la transmission
sur un support physique.
Une introduction aux codes correcteurs d’erreurs est donnée au Chapitre 3. Nous nous intéressons
à présent à différents types de modulations. Nous définissons ici ce qu’est une constellation et introduisons
la notion de mapping, avant d’aborder les modèles de canaux de transmission. Ce chapitre est
basé sur les ouvrages [19], [39] et [22].
3Chapitre 1. Introduction à la Transmission du signal Numérique
1.1 Modulation
Nous nous intéressons ici à la transmission de données numériques. L’information à véhiculer est
donc une séquence binaire, tandis qu’un support physique permet de transmettre une information
sous forme d’un signal continu. La modulation consiste alors à transformer l’information binaire en
un signal continu adapté au support de transmission.
Nous verrons qu’il existe deux possibilités pour transmettre un signal numérique : la transmission
en bande de base ou la modulation d’une onde porteuse. La transmission en bande de base consiste à
associer à la séquence binaire d’entrée un signal physique qui est transmis dans une plage de fréquence
contenant la fréquence nulle. Elle s’utilise dans le cas d’une transmission filaire. La modulation par
onde porteuse consiste à modifier un ou plusieurs paramètres d’une onde porteuse, en fonction du
symbole binaire à transmettre (un bloc de bits de longueur donnée), et à l’émettre dans une plage de
fréquence donnée qui peut être différente pour différents utilisateurs.
Une démarche commune aux deux méthodes de transmission est l’association d’une information
physique et d’un symbole binaire. C’est ce que nous appelons le mapping.
1.1.1 Transmission du signal
Transmission en bande de base
La notion de transmission en bande de base ne sera pas utile en tant que telle mais sera utile pour
la compréhension du mécanisme de modulation présenté dans le paragraphe suivant.
L’information à transmettre étant une séquence binaire, la première approche est d’associer au bit
0 un état significatif (par exemple une tension positive) et d’associer au bit 1 un autre état significatif
(par exemple une tension négative). On appelle cette opération le codage, même si ce terme peut
porter à confusion.
Un exemple de codage : le codage NRZ (No Return to Zero) Le codage NRZ associe au bit
0 une valeur α et associe au bit 1 la valeur −α. La transmission de la séquence 0110101 se traduira
alors par la transmission du signal suivant :
+α
−α
0
1 1 1 1
0 0
Figure 1.2 – Exemple de transmission suivant un codage NRZ
Cet exemple ne constitue pas une règle générale, le bit 0 pouvant être codé par une valeur α positive
ou négative et inversement pour le bit 1.
41.1 Modulation
On dit alors que l’ensemble A = {α, −α} est un alphabet pour le codage NRZ.
De manière générale, la suite de bits constituant le message est mise sous forme de symboles binaires,
en créant des paquets de a bits. Il existe donc 2a
symboles binaires distincts auquels sont
associés des valeurs αi appartenant à un alphabet A de cardinal 2a
. Le signal émis est de la forme
s(t) = P
j αjg(t − jT) où αj est la j
ème valeur à transmettre et appartient à l’alphabet A choisi et
g(t) est une impulsion élémentaire de durée T.
Dans l’exemple du codage NRZ, l’impulsion utilisée est telle que g(t) = (
1 si 0 ≤ t < T
0 sinon . On
détaille le calcul de s(t) pour la transmission de la séquence binaire 0110101 dans le tableau ci-dessous :
j bit à transmettre αj s(t)
0 0 −α −αg(t) = −α, ∀ 0 ≤ t < T
1 1 α αg(t − T) = α, ∀ T ≤ t < 2T
2 1 α αg(t − 2T) = α, ∀ 2T ≤ t < 3T
3 0 −α −αg(t − 3T) = −α, ∀ 3T ≤ t < 4T
4 1 α αg(t − 4T) = α, ∀ 4T ≤ t < 5T
5 0 −α −αg(t − 5T) = −α, ∀ 5T ≤ t < 6T
6 1 −α −αg(t − 6T) = −α, ∀ 6T ≤ t < 7T
Modulation par onde porteuse
On définit une onde porteuse par l’expression p(t) = A0cos(2πf0t + ϕ0) où A0 est l’amplitude du
signal, f0 sa fréquence et ϕ0 sa phase.
La modulation par onde porteuse consiste à transmettre de l’information en modifiant un ou
plusieurs paramètres de cette onde porteuse. Le signal en bande de base est alors transposé en fréquence
afin d’assurer la transmission dans une bande de fréquence adaptée. C’est-à-dire que le signal en bande
de base devient le signal modulant. De plus le signal est transmis à une fréquence donnée qui peut être
différente pour différents utilisateurs. Il existe différents types de modulation utilisant des paramètres
distincts de la porteuse comme :
– la modulation ASK (Amplitude Shift Keying), une modulation d’amplitude
– la modulation PSK (Phase Shift Keying), une modulation de phase
– la modulation FSK (Frequency Shift Keying), une modulation de fréquence
– la modulation QAM (Quadrature Amplitude Modulation), une modulation de phase et d’amplitude
Nous ne nous intéressons ici qu’aux modulations d’amplitude et/ou de phase. On note a le nombre
de bits par symbole binaire. On a donc M = 2a
symboles possibles. Nous supposons ici, pour simplifier
5Chapitre 1. Introduction à la Transmission du signal Numérique
l’écriture des signaux modulés, que l’amplitude A0 des porteuses est égale à 1.
Modulation ASK Le signal modulé s’écrit
s(t) = X
j
αjg(t − jT)cos(2πf0t)
En notant
sI (t) = X
j
αjg(t − jT)
on a
s(t) = cos(2πf0t)sI (t)
Le signal sI (t) modifie alors l’amplitude de la porteuse p(t) = cos(2πf0t).
On prendra a priori comme alphabet {±α, ±3α, . . . , ±(M − 1)α}.
Modulation PSK Le signal modulé s’écrit
s(t) = X
j
cos(2πf0t + αj )g(t − jT)
En notant
sI (t) = X
j
cos(αj )g(t − jT)
et
sQ(t) = X
j
sin(αj )g(t − jT)
on a
s(t) = cos(2πf0t)sI (t) − sin(2πf0t)sQ(t)
Le signal sI (t) modifie l’amplitude de la porteuse p(t) = cos(2πf0t) tandis que le signal sQ(t)
modifie l’amplitude de la porteuse sin(2πf0t) = cos(2πf0t +
π
2
). On appelle la première porteuse la
porteuse en phase, la seconde la porteuse en quadrature.
On pourra prendre, pour M = 4, l’un des deux alphabets suivants {
iπ
4
|i = 1, 3, 5, 7} ou {
iπ
2
|k =
0, 1, 2, 3}. On prendra pour M = 8 l’alphabet {
iπ
4
|i = 0, 1, 2, . . . , 7}.
Modulation QAM La modulation d’amplitude et de phase simultanée nécessite l’utilisation de
deux alphabets A et B de cardinal respectif 2b
et 2b
′
. À un symbole binaire de b + b
′ bits on associe
un couple (αi
, βi
′) ∈ A × B. Et le signal modulé s’écrit
s(t) = X
j
αjcos(2πf0t + βj )g(t − jT)
(αj , βj ) ∈ A × B étant la j
ème valeur à transmettre.
En écrivant
sI (t) = X
j
αjcos(βj )g(t − jT)
61.1 Modulation
sI (t)
sQ(t)
−(M − 1)α −3α −α α 3α (M − 1)α
b b b b b b
Figure 1.3 – Constellation d’une modulation M-ASK ayant pour alphabet {±α, ±3α, . . . , ±(M −1)α}
et
sQ(t) = X
j
αjsin(βj )g(t − jT)
on a
s(t) = cos(2πf0t)sI (t) − sin(2πf0t)sQ(t)
Comme pour la modulation de phase, sI (t) et sQ(t) modifient respectivement l’amplitude de la
porteuse en phase et de la porteuse en quadrature.
Les trois modulations présentées ici s’écrivent sous la forme s(t) = cos(2πf0t)sI (t)−sin(2πf0t)sQ(t)
avec des expressions différentes pour sI (t) et sQ(t) (avec sQ(t) = 0 pour une modulation ASK). À ce
titre on peut classer chacune de ces modulations comme des cas, particuliers ou non, de modulation
de type QAM.
Nous étudierons pour ces modulations les divers mappings possibles. Nous allons voir à présent la
notion de constellation et leur forme pour ces modulations.
On note M − ASK, M − P SK et M − QAM des modulations à M = 2a points, c’est-à-dire
admettant log2M bits par symbole binaire.
1.1.2 Constellations
Pour un temps tj fixé, il existe (αj , βj ) tel que :
(
sI (tj ) = αj
sQ(tj ) = 0 pour une modulation ASK
(
sI (tj ) = cos(αj )
sQ(tj ) = sin(αj )
pour une modulation PSK
(
sI (tj ) = αj cos(βj )
sQ(tj ) = αj sin(βj )
pour une modulation QAM
On représente alors l’ensemble des sI (tj ) et sQ(tj ) dans le plan, formant ainsi une constellation,
représentée par la Figure 1.3 dans le cas d’une modulation M-ASK.
Définition 1.1.1 (Constellation) Une constellation est la représentation des différents états de la
modulation
On peut faire de même pour les modulations de type PSK et QAM. On obtient pour une modulation
PSK un ensemble de points répartis sur un cercle. (Le rayon du cercle étant déterminé par l’amplitude
A0 de la porteuse, que nous avons supposé normalisée à 1 afin de simplifier l’écriture des signaux
modulés). Un exemple de constellation PSK pour un nombre de bits par symbole égal à 3 est donné
par la Figure 1.5.
7Chapitre 1. Introduction à la Transmission du signal Numérique
t t
t t
Figure 1.4 – Constellation d’une modulation 4-PSK
b
b
b
b
b
b
b
b
αk
sI (t)
sQ(t)
Figure 1.5 – Constellation 8-PSK
r r r r
r r r r
r r r r
r r r r
r r r r
r r r r r r
r r r r r r
r r r r r r
r r r r r r
r r r r
r r r r r r r r
r r r r r r r r
r r r r r r r r
r r r r r r r r
r r r r r r r r
r r r r r r r r
r r r r r r r r
r r r r r r r r
r r r r r r r r
r r r r r r r r
r r r r r r r r r r r r
r r r r r r r r r r r r
r r r r r r r r r r r r
r r r r r r r r r r r r
r r r r r r r r r r r r
r r r r r r r r r r r r
r r r r r r r r r r r r
r r r r r r r r r r r r
r r r r r r r r
r r r r r r r r
r r r r r r r r r r r r r r r r
r r r r r r r r r r r r r r r r
r r r r r r r r r r r r r r r r
r r r r r r r r r r r r r r r r
r r r r r r r r r r r r r r r r
r r r r r r r r r r r r r r r r
r r r r r r r r r r r r r r r r
r r r r r r r r r r r r r r r r
r r r r r r r r r r r r r r r r
r r r r r r r r r r r r r r r r
r r r r r r r r r r r r r r r r
r r r r r r r r r r r r r r r r
r r r r r r r r r r r r r r r r
r r r r r r r r r r r r r r r r
r r r r r r r r r r r r r r r r
r r r r r r r r r r r r r r r r
Figure 1.6 – Constellations correspondant à des modulations (de gauche à droite) : 16-QAM, 32-
QAM, 64-QAM, 128-QAM et 256-QAM
Le choix de l’alphabet (ou des alphabets) détermine la forme de la constellation. Les modulations
32 et 128−QAM sont d’ailleurs ici cruciformes contrairement aux modulations à 2a points avec a pair.
Nous étudions ici les mappings des constellations données par la Figure 1.6 pour les modulations
QAM de 16 à 256 points, par la Figure 1.5 pour une constellation à 8 points et enfin par la Figure 1.4
pour une constellation à 4 points, soit de 2 à 8 bits par symbole binaire. La représentation sous forme
de constellation sera à présent l’unique représentation pour une modulation donnée.
1.2 Mapping
La modulation est l’opération qui permet de convertir une séquence d’information binaire en un
signal adapté au support de transmission. Le nombre de bits que l’on souhaite transmettre à chaque
intervalle de temps détermine la taille de l’alphabet à utiliser et donc le nombre de points de la constellation
pour une modulation donnée.
81.3 Canal de transmission
Définition 1.2.1 (Mapping 1) On appelle mapping l’association réalisée entre un symbole binaire
et un élément de l’alphabet correspondant à la modulation choisie.
Un exemple de mapping
Prenons une modulation 2−ASK d’alphabet A = {−α, α}, on peut définir un mapping en associant
au bit 0 la valeur −α, et au bit 1 la valeur α. On peut représenter cette association directement sur
la constellation. Mais un second mapping est possible en faisant l’association inverse, c’est-à-dire en
associant au bit 0 la valeur α et au bit 1 la valeur −α.
On peut alors considérer l’opération de mapping comme l’association d’un point de la constellation
et d’un symbole binaire.
Définition 1.2.2 (Mapping 2) Soit C une constellation à M = 2a points. On appelle mapping toute
bijection, f, de C dans {0, 1}
a
, qui à un point P de C associe un symbole binaire de longueur a.
Naturellement d’après la définition 1.2.2, le nombre de mappings possible pour une constellation
donnée est de (2a
)!. Ce nombre est décrit pour différentes tailles de constellations par la Table 1.1.
Table 1.1 – Nombre de mappings pour a = 2, 3, 4
a Nombre de mappings
2 24
3 40 320
4 > 2 ∗ 1013
Nous utiliserons à présent cette définition du mapping. Notons qu’il existe cependant certains
mappings ayant des propriétés permettant de limiter les erreurs de transmission, comme les mappings
de type Gray [30] que nous utiliserons par la suite.
1.3 Canal de transmission
Lors de la transmission d’un signal, celui-ci est soumis à des atténuations et déformations propres
au canal (par exemple dû à la distance entre deux antennes pour une communication sans-fil). Il est
également soumis à des perturbations externes que l’on appelle couramment du bruit.
Différents supports de transmission permettent de véhiculer une information (câble électrique,
fibre optique, liaison sans-fil . . .). Chaque type de transmission possède un modèle de propagation qui
lui est propre. Une liaison sans-fil est en particulier sensible aux obstacles entraînant des réflexions,
diffractions du signal. À ce titre, ces liaisons sont les plus difficiles à modéliser et il existe différents
modèles de canaux de transmission.
Les deux modèles les plus couramment utilisés sont le canal à bruit blanc additif gaussien et
le canal binaire symétrique. Ils sont tous deux des canaux dits sans mémoire. Il existe cependant
d’autres modèles simulant notamment les canaux multi-trajets tels que les canaux de Rayleigh et de
Rice, utilisés pour modéliser les radiocommunications, auxquels nous ne nous intéressons pas ici.
Le canal à bruit blanc additif gaussien : le signal reçu r(t) s’écrit comme l’addition du signal
émis s(t) et du bruit blanc gaussien b(t). b(t) est modélisé, dans une bande de fréquence limitée, par
un processus aléatoire centré de moyenne nulle, de variance σ
2
, dont la densité de probabilité est :
9Chapitre 1. Introduction à la Transmission du signal Numérique
p(b) = 1
√
2πσ2
e
−b
2
2σ2
La qualité d’une transmission analogique se mesure à l’aide du rapport signal à bruit, noté SNR
(Signal to Noise Ratio) et exprimé généralement en décibels. Il mesure le rapport de puissance entre
le signal et le bruit. Plus le bruit est élevé plus le rapport signal à bruit diminue. La qualité d’une
transmission numérique se mesure quant à elle à l’aide de deux outils distincts qui sont le rapport
signal à bruit par bit, Eb/N0, et le Taux d’Erreur Binaire (TEB ou BER pour Bit Error Rate). Le
rapport signal à bruit par bit mesure le rapport entre l’énergie véhiculée par un bit, Eb, et la densité
spectrale de puissance du bruit, N0.
Le taux d’erreur binaire définit la probabilité pour un bit d’être faux :
BER =
nombre de bit f aux
nombre de bits transmis
Il est possible de calculer le taux d’erreur binaire en fonction du rapport signal à bruit par bit. Ce
calcul dépend fortement de la modulation choisie et du mapping utilisé. On trouve ce calcul dans la
littérature pour différents types de modulation ([22, 39, 40]).
Le canal binaire symétrique : les entrées et sorties du canal binaire symétrique sont des valeurs
binaires. Il est caractérisé par la probabilité d’erreur p qu’un bit (0 ou 1) soit modifié (en son opposé)
lors de la transmission. La probabilité qu’un bit ne soit pas modifié lors de la transmission est alors
1 − p. Il est représenté par la Figure 1.7.
0 0
1 1
p p
1 − p
1 − p
Figure 1.7 – Canal binaire symétrique de probabilité d’erreur p
On considère que le canal binaire symétrique regroupe alors la modulation, le canal et la démodulation
dans le schéma d’un système de communication.
Il est courant de considérer deux modèles de canaux de transmission :
– Un modèle dit interne AWGN (Additive White Gaussian Noise), pour lequel est calculé le taux
d’erreur binaire (en fonction de la modulation et du mapping).
– Un modèle dit externe BSC (Binary Symetric Channel) ayant pour probabilité d’erreur p la
probabilité définie par le BER du canal interne.
Ce qui rend transparent la modulation et la démodulation pour le codage canal.
1.4 Démodulation
On appelle démodulation l’extraction des paramètres αk et βk contenus dans les composantes sI (t)
et sQ(t) d’un signal émis s(t). Le signal reçu s
′
(t) correspond au signal s(t) transformé par le bruit du
101.4 Démodulation
canal de transmission. Les composantes s
′
I
(t) et s
′
Q(t) reçues correspondent alors à des modifications
des composantes sI (t) et sQ(t) et la donnée d’un couple (s
′
I
(t), s′
Q(t)) donnera lieu à interprétation,
dans le sens où l’on évaluera la distance entre le point de coordonnées (s
′
I
(t), s′
Q(t)) et les points de la
constellation.
En effet, l’objectif est de retourner les symboles les plus probablement émis. Un détecteur a maximum
de vraisemblance (ML pour Maximum Likelihood) fait l’hypothèse que les symboles émis sont
équiprobables. Il calcule alors la distance euclidienne entre les symboles reçus et les symboles possibles.
La décision se fait, pour un symbole reçu donné, en faveur du symbole de l’alphabet le plus proche au
sens de la distance euclidienne.
De cette manière une erreur de décision peut être commise si le point de coordonnées (s
′
I
(t), s′
Q(t))
est plus proche géométriquement d’un point de la constellation différent de celui correspondant au
signal émis à l’instant t. Lorsqu’une telle erreur se produit, le plus souvent, un point de la constellation
est interprété comme étant un de ses plus proches voisins.
11Chapitre 1. Introduction à la Transmission du signal Numérique
12Chapitre 2
Mappings
Le mapping est l’association réalisée entre les points d’une constellation et les différents symboles
binaires possibles pour une taille de constellation donnée. La taille d’une constellation en désigne
le nombre de points, elle détermine alors le débit de transmission. À une constellation de M = 2a
points, est associé un ensemble de 2a
symboles binaires de longueur a. Nous utilisons tout au long de
ce manuscrit la notation a pour désigner le nombre de bits par symbole binaire du mapping. Nous
rappelons la définition de mapping comme étant une bijection de la constellation C dans {0, 1}
a
.
Définition 2.0.1 (Mapping) Soit C une constellation à M = 2a points. On appelle mapping toute
bijection f, de C dans {0, 1}
a
, qui à un point P de C associe un symbole binaire de longueur a.
Nous rappelons que le nombre de mappings, pour une constellation donnée, est le nombre de
permutations de {0, 1}
a
, c’est-à-dire (2a
)!. Nous pouvons alors décrire l’ensemble des mappings en
décrivant l’ensemble de ces permutations, pour de petites tailles de constellations (ie a = 2 ou
a = 3).
Il existe cependant des mappings permettant de limiter le Taux d’Erreur Binaire (T EB ou BER
pour Bit Error Rate) en réception. Il définit le nombre d’erreurs de transmission ou d’écriture pour une
information numérique. Un taux d’erreur de 10−2
signifie qu’un bit sur 100 est erroné. Les mappings
Gray [30] permettent de limiter les erreurs de transmission et donc de diminuer le BER.
Définition 2.0.2 (Mapping Gray) Soit C une constellation à M = 2a points. Soit f un mapping
de C. On dit que f est un mapping Gray si pour tous points Pi
, Pj de C, voisins pour la distance
euclidienne, alors f(Pi) et f(Pj ) sont à distance de Hamming de 1.
Le terme mapping est essentiellement utilisé pour désigner l’association des symboles binaires et
des points d’une constellation en dimension 2. Il est alors courant d’utiliser le terme codage dans le
cas d’une constellation en dimension 1.
La décision réalisée lors de la démodulation consiste à associer le point reçu, à l’instant t, au
point de la constellation le plus proche, au sens de la distance euclidienne. Si le symbole binaire,
correspondant au point de la constellation le plus proche, est à distance de Hamming de 1, du symbole
binaire émis à l’instant t, alors un seul bit est erroné à cet instant.
F. Gray a introduit en 1953 ce type de codage. Il a pour but de limiter les erreurs de transmission.
Le code Gray impose des éléments successifs ayant un seul bit différent. Nous pouvons par exemple
coder les entiers de 0 à 7 en binaire naturel : 000, 001 , 010 , 011, 100, 101, 110, 111 ou selon le codage
13Chapitre 2. Mappings
Gray : 000, 001, 011, 010, 110, 111, 101, 100. Le codage Gray assure de plus un minimum d’opérations
lors du passage d’un élément au suivant. Ce codage, également appelé binaire réfléchi, est le codage
initialement introduit par F. Gray.
Il existe d’autres codages que nous pouvons qualifier de codage Gray puisqu’ils respectent la
distance de Hamming de 1 entre deux symbole successifs. Nous voyons en effet dans ce chapitre
différents types de codage Gray, réfléchis ou non réfléchis et de quelle façon les générer d’après les
travaux de E.N. Gilbert [29].
Ces codages sont utilisés pour construire des mappings Gray pour des constellations P SK, QAM
carrées. Les travaux de R.D. Wesel, X. Liu, J.M Cioffi et C. Komminakis [56] ont permis de décrire
la méthode de construction de mappings Gray à partir du produit direct de deux codages Gray. Ainsi
il nous est possible d’énumérer tous les mappings Gray. Ils ont également mis en avant l’impossibilité
de construire un mapping Gray pour une constellation en croix. Nous décrivons alors des méthodes
issues essentiellement de ces travaux [32, 56] d’une part et des travaux de J.G. Smith [45] d’autre
part, permettant de définir des mappings approchant le critère de Gray. Ils sont communément appelés
des mappings quasi-Gray. On pourra également citer les travaux de P.K. Vitthaladevuni, M.S.
Alouini et J.C. Kieffer [51, 52] dans ce domaine. Cependant il n’existe pas de définition formelle des
mappings quasi-Gray au sens où tous les mappings peuvent être considérés comme quasi-Gray avec
des caractéristiques se rapprochant plus ou moins du critère de Gray.
2.1 Codages Gray réfléchis
Nous définissons ici un codage Gray réfléchi et sa méthode de construction. Un tel codage est
construit comme suit : à l’étape 0 on choisit un symbole parmi les 2a possibles. Ce symbole sert
de labellisation pour le point le plus à gauche de la constellation. À l’étape i on choisit un bit à
complémenter (non utilisé pendant les étapes précédentes). À cette étape, 2i points sont déjà labellisés.
Nous labellisons alors les 2i
suivants par symétrie en complémentant le bit précédemment choisi.
L’exemple d’un codage Gray réfléchi pour une constellation unidimensionnelle à 8 points est donné
ci-dessous, il permet d’illustrer cette construction.
Le symbole d’origine est choisi :
b b b b b b b b
001
Le 3ème bit est complémenté pour obtenir le symbole suivant :
b b b b b b b b
001 000
Les deux symboles suivants sont obtenus par symétrie et en complémentant le 2ème bit de chaque
symbole.
b b b b b b b b
001 000 010 011
142.2 Codages Gray non réfléchis
Les derniers symboles s’obtiennent alors en complémentant le 1er bit de chaque symbole, en utilisant
également une symétrie :
b b b b b b b b
001 000 010 011 111 110 100 101
Cette construction permet de décrire 23
.3! codages Gray réfléchis différents : 23 pour le choix du
symbole d’origine et 3! pour le choix de l’ordre des bits à complémenter. Plus généralement, pour une
constellation à 2a points il existe 2a
.a! codages Gray réfléchis.
2.2 Codages Gray non réfléchis
F. Gray a introduit les codes Gray réfléchis. Il existe cependant des codages également appelés
codages Gray qui sont de type non réfléchis. Le codage donné ci-dessous en est un exemple. Nous
pouvons cependant remarquer que les symboles situés aux extrémités sont à distance de Hamming de
1. Nous appelons de tels codages des codages Gray cycliques. Les codages Gray réfléchis sont d’ailleurs
des codages cycliques.
b b b b b b b b
101 001 000 010 011 111 110 100
Il existe donc trois familles de codages Gray : les codages Gray réfléchis, les codages Gray cycliques
et enfin les codages qui ne sont ni réfléchis ni cycliques.
2.3 Codages Gray
E.N. Gilbert [29] a décrit en 1957 une méthode de génération de l’ensemble des codages Gray basée
sur la description de chemins dans un graphe. On définit Qa comme étant un graphe à 2a
sommets
où deux sommets sont reliés par une arête si leurs labels respectifs ne diffèrent que d’un bit. Une
représentation de ces graphes dans le cas a = 2, 3, 4 est donnée par la Figure 2.1, où chaque
sommet est labellisé par l’écriture binaire de son numéro.
0 1
2 3
0 1
2 3
4 5
6 7
Figure 2.1 – Représentation des graphes Qa, de gauche à droite a = 2, 3, 4
15Chapitre 2. Mappings
Les cubes ainsi construits permettent d’obtenir d’une part le nombre de codages Gray pour a ∈
J1, 4K, et d’autre part les codages Gray en eux-mêmes. En effet, la description d’un codage Gray est
équivalente à la description d’un chemin, de longueur 2a de Qa, ne parcourant qu’une seule fois chacun
des sommets.
Le chemin défini par les sommets 0, 1, 3, 2, dans Q2, permet d’obtenir, par le biais de ses labels, le
codage Gray suivant : 00, 01, 11, 10. Le chemin 0, 2, 3, 1 définit également un codage Gray. Il existe
deux chemins de longueur 4 parcourant chacun des sommets de Q2 et ayant pour origine le sommet
0, ainsi que pour chacune des origines possibles. Il y a donc 8 codages Gray à 2 bits. Nous pouvons
déterminer le nombre de codages Gray cycliques pour a ∈ J1, 4K en posant la contrainte suivante : les
chemins retenus sont ceux ayant pour extrémités des sommets voisins.
Le nombre de codage Gray obtenu par simulation est :
– pour a = 2 : 8 dont 8 cycliques
– pour a = 3 : 144 dont 96 cycliques
– pour a = 4 : 91392 dont 43008 cycliques
Les codages Gray réfléchis sont utilisés pour la construction de mappings quasi-Gray, à savoir
des mappings respectant “au maximum” le critère de Gray, dans le cas de constellation comme les
32 − QAM et 128 − QAM. Les codages Gray cycliques sont utilisés pour la construction de mappings
Gray valides pour les constellations P SK. L’ensemble des codages Gray est également utilisé dans le
cas des constellations QAM carrées ou rectangulaires.
2.4 Mappings Gray PSK
Une constellation P SK est un ensemble de points dans le plan répartis sur un cercle de rayon A
(l’amplitude du signal). Un codage Gray cyclique permet donc de définir un mapping Gray pour ce
type de constellation en “enroulant” ce code sur lui-même. Ainsi il existe 96 mappings Gray P SK,
dont 48 sont des mappings issus de codages Gray réfléchis.
Nous remarquons que la notion de points voisins dans une constellation diffère selon sa configuration.
Un point a uniquement deux voisins dans une constellation P SK tandis qu’il peut en avoir
jusqu’à quatre dans une constellation QAM.
2.5 Mappings Gray QAM
Nous décrivons ici la méthode de génération d’un mapping Gray, pour une constellation QAM
carrée ou rectangulaire, issue des travaux Wesel, Liu, Cioffi, Komminakis. Cette méthode utilise le
produit direct de deux codages Gray. Elle permet notamment la génération de l’ensemble des mappings
Gray. Soit une constellation QAM à 2a × 2
b points. Soient deux codages Gray à 2a
et 2b points
respectivement. L’un est utilisé verticalement, l’autre horizontalement. Nous pouvons alors labelliser
un point en adjoignant ses labels verticaux et horizontaux correspondants. En vue de générer l’ensemble
des mappings Gray possibles sans parcourir deux fois le même mapping, il faut fixer la contrainte de
ne pas inverser l’ordre des bits issus d’un même codage. Il y a alors
a+b
a
mappings possibles pour
deux codages horizontaux et verticaux fixés. Deux exemples de tels mappings sont donnés par la
Figure 2.2.
162.6 Mappings quasi-Gray
b
b
b
b
b
b
b
b 10
00 01 11
11
01
00
10
0000
0001
0010
0011
0100
0101
0110
0111
1000
1001
1010
1011
1100
1101
1110
1111
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b 10
00 01 11
11
01
00
10
0000
0001
0100
0101
0010
0011
0110
0111
1000
1001
1100
1101
1010
1011
1110
1111
b
b
b
b
b
b
b
b
Figure 2.2 – Deux mappings Gray construits par produit direct de codes Gray
On note nl (respectivement nc) le nombre de codages Gray lignes (respectivement colonnes). Le
nombre de mappings Gray pour une constellation QAM rectangulaire de taille 2a × 2
b
est de
nl
. nc .
a + b
a
!
Le nombre de mappings Gray pour les constellations 4 − P SK, 8 − P SK, 16 − QAM, 64 − QAM
et enfin 256 − QAM est donné par la Table 2.1.
Constellation Nombre de mappings Gray
4 − P SK 8
8 − P SK 96
16 − QAM 384
64 − QAM 414 720
256 − QAM 584 674 836 480
Table 2.1 – Nombre de mappings Gray
La génération de mappings Gray réfléchis pour les constellations QAM carrées ou rectangulaires
peut se faire par une méthode similaire à celle définie pour les codages Gray. Elle peut également se
faire par produit direct de deux codages Gray réfléchis. Les mappings Gray minimisent les erreurs de
réception. Ils sont potentiellement très utilisés et sont à ce titre des cibles privilégiées pour la suite de
notre travail. Il est impossible d’utiliser des mappings Gray pour les constellations en croix, 32−QAM
et 128 − QAM, nous nous intéressons donc aux mappings dits quasi-Gray.
2.6 Mappings quasi-Gray
Wesel & al. ont démontré qu’il n’est pas possible de construire de mappings Gray pour les constellations
en croix, notamment 32−QAM et 128−QAM. Il est cependant possible d’utiliser des mappings
dits quasi-Gray respectant autant que possible le critère de Gray. Il existe dans la littérature différents
17Chapitre 2. Mappings
mappings quasi-Gray. Le but de cette section est d’en présenter quelques uns. La qualité d’un mapping
quasi-Gray peut être jugée grâce aux deux critères suivants : la pénalité de Gray moyenne, la pénalité
de Gray maximum. Comme il n’existe pas de définition formelle des mappings quasi-Gray, en pratique,
on recherche des mappings qui minimisent les pénalités de Gray moyenne et maximum.
Définition 2.6.1 (Pénalité de Gray moyenne) On définit la pénalité de Gray moyenne, notée Gp,
comme le nombre moyen de bits différents entre deux symboles binaires voisins.
Définition 2.6.2 (Pénalité de Gray maximum) On définit la pénalité de Gray maximum, notée
Gp
k , comme le nombre maximum de bits différents entre deux symboles binaires voisins.
Mappings 32 − QAM
Méthode par déplacement de labels
La première approche se base sur la définition de mappings quasi-Gray à partir de mappings
rectangles. Deux méthodes sont schématisées ici, la première issue de [56] est vue dans la Figure 2.3,
la seconde issue de [45] est vue dans la Figure 2.4.
b b b b
b b b b b b
b b b b b b
b b b b b b
b b b b b b
b b b b
(2)
(4)
(1)
(3)
b b b b b b b b
b b b b b b b b
b b b b b b b b
b b b b b b b b
(2)
(4)
(1)
(3)
Figure 2.3 – Construction d’un mapping 32 − QAM par la méthode de Wesel & al.
b b b b
b b b b b b
b b b b b b
b b b b b b
b b b b b b
b b b b
(2)
(4)
(1)
(3)
b b b b b b b b
b b b b b b b b
b b b b b b b b
b b b b b b b b
(2)
(4)
(1)
(3)
Figure 2.4 – Construction d’un mapping 32 − QAM par la méthode de J.G. Smith
Méthode par définition de transitions
La seconde approche se base sur la notion de transition. On appelle transition entre deux symboles
binaires s1 et s2, un vecteur v, de taille a tel que s2 = s1 + v. Les transitions pour les constellations
32 − QAM sont des vecteurs de taille 5. Wesel & al. ont étudié ces transitions pour en déterminer
le nombre nécessaire à l’obtention d’un mapping 32 − QAM, ainsi que les agencements décrivant
des mappings quasi-Gray raisonnables. Il en résulte qu’il est possible de labelliser entièrement une
182.6 Mappings quasi-Gray
constellation, pour a impair, avec a + 1 transitions : les transitions unitaires (de poids de Hamming
1) et une transition combinaison linéaire des précédentes.
Pour les mappings 32 − QAM, ils proposent ainsi six schémas (Figure 2.5). La construction d’un
mapping avec cette méthode consiste à choisir le symbole binaire correspondant à l’un des points de la
constellation et à appliquer les transitions successivement afin d’obtenir la labellisation de l’ensemble
de la constellation.
Nous avons matérialisé les transitions non unitaires en les soulignant de gris dans ces schémas de
construction. Cela permet de remarquer les positions où les contraintes de Gray ne sont pas respectées.
Le nombre de ces positions détermine en partie la qualité du mapping quasi-Gray ainsi défini. Le
nombre de mappings quasi-Gray obtenus grâce à l’un des six schémas correspond à 5!.32 ( 5! pour le
choix des transitions e1 à e5, e6 étant fixe, 32 pour le choix du symbole d’origine).
Correspondance des méthodes
Le premier schéma de la Figure 2.5 (en haut à gauche) correspond à un mapping Gray réfléchi
pour lequel les points situés aux extrémités droite et gauche ont été déplacés. Ce schéma correspond
à la construction de la Figure 2.3. On peut également représenter la construction de la Figure 2.4
sous forme de schéma de transition ( Figure 2.6) à partir du schéma de transition d’un mappings
rectangulaire réfléchi (Figure 2.7).
b b b b
b b b b b b
b b b b b b
b b b b b b
b b b b b b
b b b b
e4 e2 e2
e6 e7 e7 e6
e5 e5 e1 e1
e2
e1 e1
e3
e1 e1
e2
e1 e1
e6 e7 e7 e6
e2 e2
e6 = e1 ⊕ e5, e7 = e2 ⊕ e5
Figure 2.6 – Schéma de transition des mappings quasi-Gray de J.G. Smith
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
b
e1 e5 e4 e1
e3
e2
e1 e1 e5
e2
Figure 2.7 – Schéma de transition d’un mappings Gray réfléchi rectangulaire 32 − QAM
19Chapitre 2. Mappings
b b b b
b b b b b b
b b b b b b
b b b b b b
b b b b b b
b b b b
e4 e2 e2
e6 e5 e5 e6
e5 e5 e1 e1
e2
e1 e1
e3
e1 e1
e2
e1 e1
e6 e5 e5 e6
e2 e2
e6 = e1 ⊕ e2 ⊕ e5
(a) Construction 1
b b b b
b b b b b b
b b b b b b
b b b b b b
b b b b b b
b b b b
e1 e3 e3
e4
e5 e3 e3 e5
e4 e6 e5 e5 e6 e4
e3 e4 e4 e3
e2
e3 e4 e4 e3
e4 e6 e5 e5 e6 e4
e5 e3 e3 e5
e4
e3 e3
e6 = e3 ⊕ e4 ⊕ e5
(b) Construction 2
b b b b
b b b b b b
b b b b b b
b b b b b b
b b b b b b
b b b b
e1
e4 e4
e2
e5 e4 e4 e5
e4 e6 e3 e3 e6 e4
e3 e5 e5 e3
e2
e3 e5 e5 e3
e4
e3 e5 e5 e3
e2
e5 e5
e6 = e3 ⊕ e4 ⊕ e5
(c) Construction 3
b b b b
b b b b b b
b b b b b b
b b b b b b
b b b b b b
b b b b
e1
e6 e6
e2
e3 e6 e6 e3
e4 e4 e3 e3 e4 e4
e3 e5 e5 e3
e2
e3 e5 e5 e3
e4 e6 e4 e4 e6 e4
e5 e3 e3 e5
e2
e3 e3
e6 = e3 ⊕ e4 ⊕ e5
(d) Construction 4
b b b b
b b b b b b
b b b b b b
b b b b b b
b b b b b b
b b b b
e5 e1 e5
e2
e4 e4
e5 e3 e3 e3 e3 e5
e6 e6
e2
e6 e6
e5 e4 e4 e4 e4 e5
e3 e3
e2
e6 = e3 ⊕ e4 ⊕ e5
(e) Construction 5
b b b b
b b b b b b
b b b b b b
b b b b b b
b b b b b b
b b b b
e1 e6 e6
e2
e4 e6 e6 e4
e3 e5 e4 e4 e5 e3
e6 e3 e3 e6
e2
e6 e3 e3 e6
e3 e4 e5 e5 e4 e3
e5 e6 e6 e5
e2
e6 e6
e6 = e3 ⊕ e4 ⊕ e5
(f) Construction 6
Figure 2.5 – Six schémas de transitions pour générer des 32-QAM quasi-Gray. Les traits en pointillés
signifient que toute la ligne, ou toute la colonne, est construite avec la même transition
202.6 Mappings quasi-Gray
Pénalité de Gray
Nous pouvons calculer pour chacun des schémas présentés ici la pénalité de Gray moyenne. Ainsi
pour la méthode de la Figure 2.4 la pénalité moyenne est de 7
6
:
A B D′ C
′
E I M Q U Y
F J N R V Z
G K O S W A′
H L P T X B′
D C E′ F
′
A E I M Q U Y C
′
B F J N R V Z D′
C G K O S W A′ E′
D H L P T X B′ F
′
Avec les notations précédentes, les points J, N, R, V , K, O, S, W puis E, F, G, H, Y , Z, A′
,
B′ ont une pénalité moyenne de 1. En effet, ils respectent le critère de Gray. Les points A, C
′
, D et
F
′ont une pénalité de 3
2
, les points B, D′
, C, E′ ont une pénalité de 4
3
et enfin les points restants ont
une pénalité de 5
4
. La pénalité moyenne est donc de 7
6
.
De la même manière, il est possible de calculer les pénalités de Gray pour les autres méthodes de
construction, elles sont données par la Table 2.2
Figure 2.5a 2.5b 2.5c 2.5d 2.5e 2.5f 2.4
Gp
19
16
9
8
17
16
118
96
110
96
71
48
7
6
Gk
p
3 3 3 3 3 3 2
Table 2.2 – Pénalité de Gray de mappings 32 − QAM
Mappings 128 − QAM
Nous présentons ici deux types de mappings quasi-Gray pour les constellations 128 − QAM cruciformes.
Ces deux méthodes se basent sur la modification de mappings Gray rectangulaires. La seconde
méthode est issue des travaux de P.K. Vitthaladevuni, M.S. Alouini et J.C. Kieffer [52]. Elles sont
données par la Figure 2.8 et la Figure 2.9.
21Chapitre 2. Mappings
b
b b b b b b b b b b b b b b b b
b b b b b b b b b b b b b b b
b b b b b b b b b b b b b b b b
b b b b b b b b b b b b b b b b
b b b b b b b b b b b b b b b b
b b b b b b b b b b b b b b b b
b b b b b b b b b b b b b b b b
b b b b b b b b b b b b b b b b
b
bb
b b b b b b b b b b b b
b
b
b b b b b b b b b b b b
b
b
b
b
b b b b b b b b b b b b
b
b b
b
b b b b b b b b b b b b
b
b
bbb b
bbbb
b b b b b b b b b b b b
b
b
b b b b b b b b b b b b
b
b
b b b b b b b b b b b b
b
b
b b b b b b b b b b b b
b
b
b
(1) (2)
(3) (4)
b b b b b b b b b b b b b b b
(3) (4)
(1) (2)
Figure 2.8 – Construction d’un mapping 128 − QAM par la méthode de Wesel & al.
b
b b b b b b b b b b b b b b b b
b b b b b b b b b b b b b b b
b b b b b b b b b b b b b b b b
b b b b b b b b b b b b b b b b
b b b b b b b b b b b b b b b b
b b b b b b b b b b b b b b b b
b b b b b b b b b b b b b b b b
b b b b b b b b b b b b b b b b
b
bb
b b b b b b b b b b b b
b
b
b b b b b b b b b b b b
b
b
b
b
b b b b b b b b b b b b
b
b b
b
b b b b b b b b b b b b
b
b
bbb b
bbbb
b b b b b b b b b b b b
b
b
b b b b b b b b b b b b
b
b
b b b b b b b b b b b b
b
b
b b b b b b b b b b b b
b
b
b
(1)
(2)
(3)
(4)
b b b b b b b b b b b b b b b
(1) (2) (3) (4)
(5)
(6)
(7)
(8)
(5) (6) (7) (8)
Figure 2.9 – Construction d’un mapping 128 − QAM par la méthode de Vitthaladevuni & al.
La pénalité de Gray du mapping présenté Figure 2.9 est donnée dans [52] est vaut
1 +
1
√
2 ∗ 128
+
1
3 ∗ 128
≃ 1.0651
Ces méthodes s’étendent au cas des constellations 512 − QAM. Dans la suite de ce travail nous
utilisons les mappings quasi-Gray définis à partir de mappings Gray rectangles. Elles sont efficaces
dans le sens où elles nécessitent peu de transformations alors que nous sommes déjà en mesure de
générer les mappings Gray rectangulaires.
22Chapitre 3
Codes Convolutifs et Codes de Reed-Solomon
Ce chapitre introductif a pour objectif de donner des notions de théorie des codes. Notamment
nous présentons ce que sont les codes convolutifs et les codes de Reed-Solomon. Ces deux types de
codes sont ceux utilisés dans le Chapitre 6 pour la reconnaissance du mapping bien que nous nous
soyons essentiellement concentrés sur le cas des codes convolutifs. Nous présentons en effet de plus
une méthode de détection des codes convolutifs dans le Chapitre 4.
3.1 Introduction aux codes correcteurs d’erreurs
Les codes correcteurs d’erreurs sont des systèmes visant à réduire les erreurs de transmission.
Le codage de l’information binaire à transmettre, par ce type de systèmes, permet d’ajouter de la
redondance ; c’est-à-dire que l’on transmet plus de données que la quantité d’informations initiale.
La redondance introduite est utilisée lors de la réception des données afin de détecter et corriger les
erreurs de transmission.
Il existe deux grandes familles de codes : les codes en blocs et les codes convolutifs. Pour chacune de
ces deux familles, l’information est séparée en blocs de taille constante k appelés mots d’information.
Les blocs obtenus par codage de ces mots d’informations sont appelés des mots de code.
On note u = (u1, . . . , uk), ui ∈ Fq, un mot d’information et y = (y1, . . . , yn), yi ∈ Fq, le mot de
code associé où n > k. On appelle n la longueur du code.
Codes en blocs Nous allons à présent voir des exemples de codes en blocs et les premières définitions
de codes, notamment de codes dits linéaires.
Un exemple de code : le code à répétition
Le principe du code à répétition est simplement de répéter un certain nombre de fois n chacun
des bits du message à transmettre. Pour n = 3 le message 0110 devient 000111111000. Si une erreur
se produit lors de la transmission alors on retrouvera le message initial par vote majoritaire. Cette
méthode permet de corriger toutes les erreurs de poids 1 (un seul bit sur les trois répétés est faux).
Ce code a l’avantage de pouvoir corriger autant d’erreurs que l’on souhaite en augmentant le
nombre de répétition, mais le nombre de bits à transmettre est alors trop important. Pour n = 3 si le
message à transmettre est de longueur m alors le message codé sera de longueur 3m.
23Chapitre 3. Codes Convolutifs et Codes de Reed-Solomon
On définit le rendement d’un code par le ratio k/n où k est la longueur des mots d’informations
et n celle des mots de code. Dans l’exemple du code à répétition k = 1 et n = 3.
On définit la distance minimale d’un code, noté d, comme la plus petite distance séparant deux
mots de code (pour la distance de Hamming). Le code à répétition a pour distance minimale d = n.
La question du décodage est liée à la notion de capacité de correction, c’est-à-dire pour un code
donné, combien d’erreurs est-on en mesure de corriger. Soit C un code de longueur n, dont la longueur
des mots d’informations est k et de distance minimale d. Soit y = (y1, . . . , yn), yi ∈ Fq un mot de
code. Lors de la transmission du signal, ce mot de code peut être modifié. Le mot reçu s’écrit alors
y
′ = y + e où e correspond à l’erreur ajoutée.
On appelle décodage par maximum de vraisemblance le décodage qui consiste à associer à y
′
le
mot de code y le plus proche (au sens de la distance de Hamming). Alors on peut décoder de manière
unique tous mots reçus ayant au plus t = ⌊
d−1
2
⌋ erreurs. t est appelé la capacité de correction.
L’objectif de la théorie des codes est de définir des codes assurant à la fois de bon taux de transmission
et de bonnes capacités de correction.
Un exemple de code : le code de Hamming
Soit G =
1 0 0 0 0 1 1
0 1 0 0 1 0 1
0 0 1 0 1 1 0
0 0 0 1 1 1 1
. Le code défini par l’ensemble des y = uG, avec u = (u1, u2, u3, u4),
ui ∈ F2, a pour longueur 7, des mots d’informations de longueur 4 et une distance minimale de 3.
Il a donc pour capacité de correction t = 1, pour un rendement de 4
7
. Il est ainsi un code de même
distance minimale que le code à répétition mais a un meilleur rendement.
Le code de Hamming présenté ici est défini par une matrice G de taille k × n, à coefficients dans
F2, que l’on appelle une matrice génératrice. Il peut également être défini par une matrice dite de
parité, notée H, de taille (n − k) × n, à coefficients dans F2, telle que GH⊤ = 0k×(n−k)
. Alors, pour
tout mot de code y de C on a yH⊤ = 0. On peut ainsi déterminer l’appartenance d’un mot à un code
en connaissant une matrice de parité.
Nous nous attachons maintenant à définir les notions de code, matrice génératrice et matrice de
parité pour les codes dit linéaires.
Définition 3.1.1 (Code) Un code C sur Fq de longueur n est un sous-ensemble de F
n
q
Définition 3.1.2 (Code linéaire) Un code linéaire C sur Fq de longueur n et de dimension k est
un sous-espace vectoriel de F
n
q de dimension k.
On écrit [n, k, d]q les paramètres d’un code linéaire C de longueur n, dimension k, et distance
minimale d défini sur Fq et [n, k, d] lorsque qu’il n’y a pas d’ambiguïté sur le corps de base.
Définition 3.1.3 (Matrice génératrice) Une matrice génératrice d’un code linéaire C est une matrice
dont les vecteurs lignes forment une base de C .
243.2 Codes cycliques
Une matrice génératrice n’est donc pas unique et un code possède autant de matrices génératrices
que de bases.
Définition 3.1.4 (Code dual) Soit C une code linéaire de longueur n et dimension k. On note C
⊥
le code dual de C tel que C
⊥ = {y ∈ F
n
q
| uy = 0, ∀u ∈ C } où uy =
Pn
i=1 uiyi
, ui
, yi ∈ Fq
Lors de l’utilisation d’un code en bloc, chaque mot d’information est codé indépendamment des
autres. Le mot de code y dépend uniquement du mot d’information u. On définit la fonction de codage
pour les codes en blocs comme l’application linéaire injective φ : F
k
q → F
n
q qui à un mot d’information
u associe un mot de code y = φ(u). On peut d’ailleurs définir un code en bloc comme l’ensemble des
mots de code y = uG où G est une matrice de l’application φ dans une base donnée. D’autre part,
lorsque l’on dispose d’une séquence binaire à coder, cette dernière est décomposée en blocs de taille k
qui seront codés pour former des blocs de taille n, constituant ainsi la séquence codée. On note alors
respectivement uj et yj les mots d’informations et de codes obtenus au temps j. On obtient donc la
relation suivante : yj = ujG. Lorsque les séquences d’informations et les séquences codées sont vues
comme des séquences infinies, on écrit U(D) = P
j≥0 ujDj où D est une variable indéterminée et
uj = (u0, . . . , uk)j = (u0,j , . . . , uk,j ). On a alors Y (D) = U(D)G avec Y (D) = P
j≥0
yjDj
.
3.2 Codes cycliques
Soient c = (c0, c1, . . . , cn−1) appartenant à F
n
q
et c
′ = (cn−1, c0, . . . , cn−2) le décalé de c. Un
code de longueur n est dit cyclique si pour tout mot de code c = (c0, c1, . . . , cn−1) son décalé
c
′ = (cn−1, c0, . . . , cn−2) est aussi un mot de code. Ce qui implique que (cn−2, cn−1, c0, . . . , cn−3),
(cn−3, cn−2, cn−1, . . . , cn−4) et ainsi de suite sont aussi des mots de code.
Pour les mots de codes d’un code cyclique on adopte usuellement l’écriture suivante
c(x) = c0 + c1x + · · · + cn−1x
n−1
D’où
c
′
(x) = cn−1 + c0x + · · · + cn−2x
n−1
D’autre part
xc(x) = c0x + c1x
2 + · · · + cn−1x
n
= cn−1(x
n − 1) + (c0x + c1x
2 + · · · + cn−2x
n−1 + cn−1)
et
xc(x) mod (x
n − 1) = cn−1 + c0x + · · · + cn−2x
n−1
donc
c
′
(x) = xc(x) mod (x
n − 1)
De même, si c est décalé de deux rangs vers la droite, on obtient (cn−2, cn−1, c0, . . . , cn−3), ce qui
correspond à x
2
c(x) mod (x
n − 1). C’est également vrai pour les décalés suivants.
25Chapitre 3. Codes Convolutifs et Codes de Reed-Solomon
L’ensemble des opérations sur c(x) se fait alors dans l’anneau quotient Fq[x]/(x
n−1) et on identifie
F
n
q
à Fq[x]/(x
n − 1).
En montrant que C est un idéal de cet anneau, on obtient alors l’existence d’un unique polynôme
unitaire g(x) de degré minimal et tel que g(x) est un générateur de C . De plus g(x) divise x
n −1 dans
Fq[x].
Notons r le degré de g(x) = g0 + g1x + · · · + grx
r
. Ce polynôme g(x) est un générateur du code
alors tout mot de code c(x) est un multiple de g(x), c’est-à-dire c(x) = m(x)g(x) avec m(x) =
m0 +m1x+· · · +mk−1x
k−1
. Le code est de dimension k et {g(x), xg(x), x2
g(x), . . . , xk−1
g(x)} est une
base de C . Le polynôme c(x) = m(x)g(x) de degré inférieur ou égal à n − 1 s’écrit :
c(x) = m0g(x) + m1xg(x) + · · · + mk−1x
k−1
g(x)
ce qui se représente sous la forme matricielle suivante :
m0 m1 . . . mk−1
g(x)
xg(x)
.
.
.
x
k−1
g(x)
ou encore
m0 m1 . . . mk−1
g0 g1 . . . gr
g0 g1 . . . gr
.
.
.
.
.
.
.
.
.
g0 g1 . . . gr
Cette matrice de taille k × n est une matrice génératrice de C . D’autre part soit h(x) tel que
g(x)h(x) = x
n − 1 alors
H(n−k)×n =
hk hk−1 . . . h0
hk kk−1 . . . g0
.
.
.
.
.
.
.
.
.
hk hk−1 . . . h0
est une matrice génératrice du dual où h(x) = h0 + h1x + · · · + hk−1x
k−1
Codes cycliques raccourcis Soit C
′
le sous-ensemble de C composé de l’ensemble des mots de
code c
′
(x) tels que c
′
(x) = m(x)g(x) avec
m(x) = m0 + m1x + · · · + mk−i−1x
k−i−1
et i un entier positif. C’est-à-dire
m =
m0 m1 . . . mk−i−1 0 . . . 0
.
Alors C
′
est un code de dimension k − i et de longueur n − i. Un tel code est dit raccourci.
263.2 Codes cycliques
Codes Reed-Solomon Les codes Reed-Solomon font partie des codes cycliques les plus utilisés, ils
permettent de corriger les erreurs se produisant par paquets. Il ont été inventés en 1960 par Reed et
Solomon.
Nous supposons à présent que n est premier avec q. Il existe deux façons de décrire un code
de Reed-Solomon. La première que nous donnons est la première définie historiquement et permet de
donner des résultats théoriques, la seconde est cependant utilisée pour décrire des codeurs et décodeurs
de ces codes.
Définition 3.2.1 Soient α un élément primitif de Fqm, n = q
m − 1 et m(x) = m0 + m1x + · · · +
mk−1x
k−1 ∈ Fqm[x] un mot d’information sous forme polynomiale.
Soit φ : m(x) → c tel que
c = (c0, c1, . . . , cn−1) =
m(1), m(α), m(α
2
), . . . , m(α
n−1
)
Le code de Reed-Solomon de longueur n = q
m −1 et de dimension k sur Fqm est l’ensemble des images,
par φ, des polynômes de degré inférieur ou égal à k − 1 à coefficients dans Fqm.
La seconde construction se rapproche de celle des codes BCH (ils doivent leur nom à Bose, Chaudury
et Hocquenghem) que nous allons évoquer à présent.
Rappelons que le polynôme minimal d’un élément de Fqm est le polynôme (non nul) de plus faible
degré dont il est racine. De plus les éléments admettant le même polynôme minimal sont dits conjugués.
Un polynôme primitif est un polynôme minimal dont au moins une racine est un élément primitif
de Fqm.
Un code BCH de longueur n capable de corriger au moins t erreurs se construit selon la procédure
suivante : Prendre m le plus petit entier tel que Fqm a une racine n-ième primitive α. Choisir un entier
b positif (souvent b = 1). Déterminer ensuite les polynômes minimaux de α
b
, αb+1, . . . , αb+2t−1 à
coefficients dans Fq. Le polynôme générateur g(x) du code est le plus petit multiple commun de ces
polynômes minimaux.
Ainsi, les coefficients de g(x) sont dans Fq ainsi que les mots du code tandis que les racines de g(x)
sont elles dans Fqm. De plus, certains des α
i
sont potentiellement conjugués donc g(x) est de degré au
plus 2t.
Le code ainsi construit est un code de longueur n, de dimension n − deg g(x) et de distance minimale
supérieure ou égale à δ = 2t + 1.
Les α
b
, αb+1, . . . , αb+2t−1
sont par définition racines de leur polynômes minimaux respectifs et
sont alors racines de g(x) sur Fqm. Donc pour tout α
i
, (i = b, b + 1, . . . , b + 2t − 1 ), g(α
i
) = 0 et par
conséquent c(α
i
) = m(α
i
)g(α
i
) = 0. Ceci se traduit par
c0 + c1α
i + c2(α
i
)
2 + · · · + cn−1(α
i
)
n−1 = 0, ∀i = b, b + 1, . . . , b + 2t − 1
27Chapitre 3. Codes Convolutifs et Codes de Reed-Solomon
Donc
c0 c1 . . . cn−1
1
α
i
(α
i
)
2
.
.
.
(α
i
)
n−1
= 0
et
H =
1 α
b
(α
b
)
2
. . . (α
b
)
n−1
1 α
b+1 (α
b+1)
2
. . . (α
b+1)
n−1
.
.
.
.
.
.
.
.
.
.
.
.
1 α
b+2t−1
(α
b+2t−1
)
2
. . . (α
b+2t−1
)
n−1
est également une matrice génératrice du dual.
Passons à présent aux codes de Reed-Solomon. Dans Fqm le polynôme minimal d’un élément α est
égal à (x − α). Un tel code prend comme polynôme générateur
g(x) = (x − α
b
)(x − α
b+1)· · ·(x − α
b+2t−1
).
g(x) est alors de degré exactement 2t. Donc n − k = 2t. Et le code est en mesure de corriger t erreurs.
Un exemple de code Reed-Solomon : Nous décrivons ici un code de longueur 15 et de dimension
9 sur F2
4 . Ce code est en mesure de corriger 3 erreurs. De plus F2
4 est identifié à F2[x]/(x
4+x+1).
Soit α dans F2
4 une racine de x
4 + x+ 1. Nous avons α
15 = 1. On peut d’autre part décrire l’ensemble
des puissances successives de α. En effet α
4 = α + 1 puisque α est racine de x
4 + x + 1. Ensuite
α
5 = α
2 + α. Les puissances suivantes se calculent de la même manière et dépendent uniquement de
1, α, α
2
et α
3
. On peut donc en donner une représentation vectorielle dans cette base. Les 7 premières
puissances sont données dans le tableau ci-dessous :
Puissance de α Représentation dans la base Représentation vectorielle
1 1 (1, 0, 0, 0)
α α (0, 1, 0, 0)
α
2 α
2
(0, 0, 1, 0)
α
3 α
3
(0, 0, 0, 1)
α
4 α + 1 (1, 1, 0, 0)
α
5 α
2 + α (0, 1, 1, 0)
α
6 α
3 + α
2
(0, 0, 1, 1)
et α est bien un élément primitif de F2
4. Prenons b = 1, on a n = 15 et k = 9 donc 2t = 6 et
g(x) = (x − α)(x − α
2
)(x − α
3
)(x − α
4
)(x − α
5
)(x − α
6
).
L’avantage de tels codes est que l’on maîtrise très bien la capacité de correction. De plus, les codes
définis sur F2
8 sont souvent utilisés du fait de leur praticité. En effet, chaque élément de F2
8 se repré-
sente dans la base {1, α, . . . α7} sur un octet.
Par ailleurs, il est possible de donner des matrices systématiques pour les matrices génératrices
de C ainsi que pour C
⊥. En effet, la division euclidienne de x
n−k+i par g(x) pour i = 0, 1, . . . , k − 1
283.3 Codes convolutifs
donne
x
n−k+i = qi(x)g(x) + ri(x)
avec ri(x) = ri,0 + ri,1x + · · · + ri,n−k−1x
n−k−1
. C’est-à-dire
x
n−k+i − ri(x) = qi(x)g(x)
donc x
n−k+i − ri(x) est un multiple de g(x) et est aussi un mot de code. Le polynôme ri(x) s’écrit
sous forme matricielle
ri,0 ri,1 . . . ri,n−k−1 0 . . . 0
donc x
n−k − r0(x) correspond à
−r0,0 −r0,1 . . . −r0,n−k−1 1 0 . . . 0
et on obtient la matrice génératrice suivante :
G =
−r0,0 −r0,1 . . . −r0,n−k−1 1 0 0 . . . 0
−r1,0 −r1,1 . . . −r1,n−k−1 0 1 0 . . . 0
.
.
.
.
.
.
.
.
.
.
.
.
−rk−1,0 −rk−1,1 . . . −rk−1,n−k−1 0 0 0 . . . 1
et
H =
1 0 0 . . . 0 r0,0 r1,0 . . . rk−1,0
0 1 0 . . . 0 r0,1 r1,1 . . . rk−1,1
.
.
.
.
.
.
.
.
.
.
.
.
0 0 0 . . . 1 r0,n−k−1 r1,n−k−1 . . . rk−1,n−k−1
Les codes en blocs ont l’avantage d’être largement étudiés et permettent à ce titre des constructions
variées. En revanche la complexité de codage et décodage peut varier selon le type de code. Les codes
convolutifs sont eux implémentés sous forme de registres à décalage et présentent ainsi l’avantage
d’offrir un codage simple et un décodage rapide au fur et à mesure de la réception de l’information.
Cependant, ils fournissent généralement de plus faibles capacités de correction.
On définit pour les codes convolutifs linéaires la notion de matrice génératrice de manière similaire
à la notion de matrice génératrice pour les codes en blocs. Les définitions présentées dans le paragraphe
suivant sont essentiellement issues de [38]. Nous parlerons ici uniquement de codes convolutifs linéaires,
nous utiliserons donc le terme code convolutif pour signifier code convolutif linéaire.
3.3 Codes convolutifs
Lors de l’utilisation d’un code convolutif, le mot de code yj dépend du mot d’information uj mais
également des mots d’informations reçus aux instants précédents. yj dépend donc de uj , uj−1, . . . , uj−M
où M correspond à la mémoire du codeur. On définit donc la fonction de codage d’un code convolutif
comme l’application linéaire injective φ : F
k
2 → F
n
2
telle que yj = φ(uj , uj−1, . . . , uj−M). Ainsi,
29Chapitre 3. Codes Convolutifs et Codes de Reed-Solomon
k
n
G0 G1 G2
. . .
G0 G1 G2
. . .
G0 G1
.
.
.
GM
GM
. . . GM
.
.
.
0k×n
0k×n
0k×n
0k×n
G2
Figure 3.1 – Matrice génératrice binaire d’un code convolutif
la matrice G de cette application dans une base donnée prendra la forme d’une matrice shiftée infi-
nie comme définie par la Figure 3.1 , où chacune des matrices Gi est une matrice binaire de taille k×n.
On pourra également décrire la matrice G comme une matrice à coefficients dans F2(D). On note
G(D) = G0 +G1D +G2D2 +. . . GM DM, G(D) est alors une matrice de taille k ×n à coefficients dans
F2(D).
On peut d’ailleurs voir les codes en blocs comme des codes convolutifs de mémoire nulle.
On distinguera ici la notion de code et de codeur. Le code est l’ensemble des mots de code tandis
que le codeur (ou encodeur) est la réalisation physique de la fonction de codage. D’autre part, la réalisation
physique d’une fonction de codage correspond à l’implémentation de registres à décalage. Mais
au même titre qu’un code dispose de plusieurs matrices génératrices, il existe différentes réalisations
pour un même code généré. Les registres nécessitant le moins de mémoire sont à priori les plus utilisés
et donc les plus intéressants du point de vue de la reconnaissance. Nous verrons alors que l’algorithme
de reconnaissance de codes convolutifs que nous utilisons dans la suite se propose de retourner une des
matrices génératrices correspondant à ces registres. On note alors (n, k) les paramètres d’un codeur
convolutif ayant k entrées et n sorties.
Nous ne décrirons pas précisément le fonctionnement de cet algorithme mais en donnerons les
principales composantes. Cet algorithme sera ensuite pour nous un moyen de discriminer les mappings
lors de la reconnaissance de mapping en présence de données codées par un codeur convolutif.
Définition 3.3.1 (Code convolutif) Un (n, k) code convolutif C est un sous-espace vectoriel de
dimension k de F2(D)
n
.
Définition 3.3.2 (Matrice génératrice) Une matrice génératrice G(D) du code C de paramètres
(n, k) est une matrice de taille k × n dont les lignes forment une base de C .
Une matrice génératrice d’un code convolutif est donc une matrice à coefficients dans F2(D). On
parle de matrice génératrice polynomiale lorsque les coefficients de G(D) appartiennent à F2[D].
On peut écrire U(D) = P
j≥0 ujDj avec uj = (u0, . . . , uk)j = (u0,j , . . . , uk,j ) et Y (D) =
P
j≥0
yjDj
. On a alors Y (D) = U(D)G(D).
303.3 Codes convolutifs
(u0, u1, . . . , uM, uM+1, . . .) ×
G0 G1 . . . GM 0 . . .
G0 G1 . . . GM 0 . . .
.
.
.
G0 G1 . . . GM 0
G0 G1 . . . GM
.
.
.
.
.
.
.
.
.
|{z} |{z} |{z} |{z}
. . .
y0 y1 yM yM+1
Figure 3.2 – Codage d’une séquence par un code convolutif
3.3.1 Représentation binaire
Rappelons que du point de vue binaire la séquence codée (composée des mots de code concaténés),
notée y0y1 . . . yM . . . est telle que :
y0 = u0G0
y1 = u0G1 + u1G0
. . .
yM = u0GM + u1GM−1 + · · · + uM G0
yM+1 = u1GM + u2GM−1 + · · · + uM+1G0
où uj est le mot d’information à l’instant j et les Gi
les blocs de la matrice génératrice binaire
infinie de C présentée précédemment.
Remarquons que dès lors que j ≥ M + 1, yj ne dépend plus de u0. En effet la mémoire du codeur
est de M et yj = φ(uj , uj−1, . . . , uj−M).
Lorsque j = 0, . . . , M − 1 , yj ne dépend pas de tous les Gi (i = 0, . . . , M). Cela constitue une
phase d’initialisation.
Dès lors que j ≥ M, yj dépend de tous les Gi et la sortie yj est obtenue en effectuant le produit
de la séquence d’entrée par la matrice binaire infinie. Nous avons alors :
yj =
X
M
i=0
uj−iGi
.
Ce produit est représenté par la Figure 3.2
31Chapitre 3. Codes Convolutifs et Codes de Reed-Solomon
3.3.2 Équations de parité
Soit H =
H0 H1 . . . HM 0 . . .
H0 H1 . . . HM 0 . . .
.
.
.
.
.
.
H0 H1 . . . HM 0
H0 H1 . . . HM 0
.
.
.
.
.
.
une matrice duale de C . On a
y0 y1 . . . yM
H0 . . . HM
⊤
= 01×(n−k)
.
On dit que
y0 y1 . . . yM
vérifie n−k équations de parité. Il en est de même pour
y1 y2 . . . yM+1
,
y2 y3 . . . yM+2
et ainsi de suite. Les équations de parité s’appliquent à toutes les sous-séquences
de longueur n(M + 1) par blocs glissants (avec un décalage de n).
3.3.3 Représentation en série
La séquence d’information s’écrit comme étant la série
U(D) = X
j≥0
ujDj
.
Notons
Y (D) = X
j≥0
yjD
j
.
Nous avons alors la relation Y (D) = U(D)G(D) avec G(D) = G0 + G1D + · · · + GMDM. En effet
G(D) = G0 + G1D + · · · + GMDM donc
X
j≥0
ujD
j
G(D) = X
j≥0
ujG0D
j +
X
j≥0
ujG1D
j+1 + · · · +
X
j≥0
ujGM D
j+M
=
X
j≥0
ujG0D
j +
X
j≥1
uj−1G1D
j + · · · +
X
j≥M
uj−MGM D
j
= u0G0 + (u0G1 + u1G0)D + . . .
+ (u0GM + u1GM−1 + · · · + uMG0)D
M +
X
j>M
X
M
i=0
uj−iGi
D
j
=
X
j≥0
yjD
j = Y (D)
323.3 Codes convolutifs
u1,t
u2,t
s1,t
s2,t
s3,t
y1,t
y3,t
y2,t
Figure 3.3 – Codeur de rendement 2/3
3.3.4 Codeurs
Les sorties d’un codeur convolutif dépendent des entrées à différents instants. En termes d’implé-
mentation, il faut donc stocker différents états de l’entrée dans des registres. Notons m ce nombre de
registres. Les m registres représentent alors l’état interne du codeur, noté sj (sj est un vecteur binaire
de taille m). Notons que dans le cas particulier où k = 1 alors m = M. L’entier m est également
appelé la longueur de contrainte du codeur.
Il est possible de déterminer une matrice génératrice du code C en fonction du vecteur d’entrée
uj , du vecteur d’état sj et du vecteur de sortie yj pour un codeur donné. Le vecteur d’état sj dépend
de l’état sj−1 à l’instant précédent et de l’entrée uj à l’instant j. La sortie yj dépend de l’entrée uj à
l’instant j et de l’état interne sj . L’opération de codage se décrit alors comme suit :
sj+1 = sjAm×m + ujBk×m
yj = ujUk×n + sjVm×n
avec Am×m, Bk×m, Uk×n, Vm×n des matrices binaires et s0 = 01×m. En posant
E(D) = B.
D
−1
Idm − A
−1
nous obtenons
Y (D) = U(D) [U + E(D)V ]
d’où
G(D) = U + E(D)V.
33Chapitre 3. Codes Convolutifs et Codes de Reed-Solomon
Nous proposons à présent un exemple de codeur convolutif de rendement 2/3 donné par la Figure
3.3. Notons
uj = (u1, u2)j = (u1,j , u2,j )
yj = (y1, y2, y3)j = (y1,j , y2,j , y3,j )
sj = (s1, s2, s3)j = (s1,j , s2,j , s3,j ).
Le codage est décrit comme suit :
y1,j = u1,j + s3,j
y2,j = s1,j + s2,j
y3,j = u2,j + s2,j
Nous obtenons alors
Uk×n =
1 0 0
0 0 1 !
Vm×n =
0 1 0
0 1 1
1 0 0
Am×m =
0 0 1
0 0 0
0 0 0
Bk×m =
1 0 0
0 1 0 !
Et finalement
E(D) =
D 0 D2
0 D O !
d’où
G(D) =
1 + D2 D O
0 D 1 + D
!
Nous utilisons également dans ce manuscrit une notation décimale pour représenter les polynômes
générateurs dont la représentation en base 2 donne les coefficients des polynômes dans l’ordre décroissant.
Dans le cas de l’exemple nous obtenons
5 2 0
0 2 3!
.
3.4 Reconstruction de codes
La méthode décrite par A. Valembois dans [47] et [48] est actuellement utilisée pour la reconstruction
de codes en blocs et de codes convolutifs. Cette méthode permet la reconstruction d’une matrice
343.4 Reconstruction de codes
génératrice du dual. Elle s’appuie sur la méthode de Canteaut-Chabaud pour trouver des mots candidats
du dual et décide selon un test statistique de leur appartenance au dual.
Il existe de plus des méthodes spécifiques au type de codes recherchés. En effet, connaître une
matrice binaire du dual n’est pas suffisant pour le décodage. Il faut d’une part retrouver une matrice
génératrice du code puis en extraire la structure algébrique.
B. Rice a initié des travaux sur la reconnaissance des codes convolutifs (n, 1) dans le cas non bruité
dans [41]. E. Filiol a ensuite proposé une méthode de reconstruction des codes convolutifs lorsque
les données observées sont bruitées dans [28] et [27]. Puis une méthode algébrique a été donnée par
J. Barbier, G. Sicot et S. Houcke dans [5], elle est ensuite détaillée dans la thèse de J. Barbier [3].
De nombreuses autres études ont depuis été menées sur la reconstruction des codes convolutifs dont
[14, 21, 24, 33, 35–37, 53, 59–61]
3.4.1 Codes Convolutifs
Soit C un code tel que les polynômes générateurs soient premiers entre eux et de longueur de
contrainte m. Le codeur utilisé nécessite m bits pour remplir ses registres. Une séquence d’information
de taille ks + m s’envoie sur une séquence codée de taille ns. Soit Cs cette restriction :
Cs : F
ks+m
2 → F
ns
2
Le théorème suivant, issue de [14], donne le rang de l’application Cs en fonction de s et montre
qu’à partir de s > km
n−k
toutes les séquences de taille ns ne correspondent pas à une séquence codée.
Le critère du rang est à la base de la plupart des résultats sur la reconnaissance de codes convolutifs.
Théorème 3.4.1 Soit s ∈ N
∗
. Soit Cs : F
ks+m
2 → F
ns
2
l’application linéaire obtenue par restriction.
Si tous les polynômes générateurs sont premiers entre eux alors
rang(Cs) = (
ns si s ≤
km
n−k
k(s + m) si s ≥
km
n−k
Il en découle que la matrice dont les lignes sont des séquences codées de taille ns n’est pas de rang
plein lorsque s > km
n−k
. Ce défaut de rang peut alors s’identifier par un pivot de Gauss. Malgré tout,
lorsque la séquence observée est bruitée, cette méthode n’est plus envisageable.
Les alternatives sont alors de chercher des plages non bruitées, d’utiliser une méthode appelée
Gauss randomisé issue des travaux de G. Sicot et S. Houcke [42, 43] qui est applicable pour de faibles
taux d’erreur ou encore d’utiliser la méthode introduite par A. Valembois [47, 48]. M. Cluzeau dans
[15] a également repris et fait évoluer l’approche proposée par A. Valembois
L’algorithme de reconnaissance de codes convolutifs linéaires dont nous disposons (issu de [20, 21])
utilise la méthode de A. Valembois et se propose alors de retourner une matrice génératrice correspondant
à un codeur minimisant le nombre de registres nécessaires à l’implémentation, lorsque la séquence
binaire observée est une séquence codée et bruitée. Cet algorithme retourne alors une matrice génératrice
parmi les matrices génératrices polynomiales (à coefficients F2[D]) appelée une matrice canonique
35Chapitre 3. Codes Convolutifs et Codes de Reed-Solomon
(voir [20, 38]). Nous allons à présent décrire dans les grandes lignes le fonctionnement de cet algorithme.
A partir d’une séquence, codée et bruitée, tronquée, nous cherchons à retrouver une matrice gé-
nératrice du code utilisé ainsi que le taux d’erreur associé. Nous ne connaissons ni n (la longueur du
code) ni k (la dimension du code), et effectuons alors cette recherche également.
Nous avons vu précédemment que pour un mot observé, nous disposons d’un critère d’appartenance
au code C utilisé ; à savoir y ∈ C si et seulement si yH⊤ = 01×(n−k) avec H une matrice génératrice
du dual de C et si et seulement si pour tout h ∈ C
⊥ on a yh = 0
Cet algorithme procède en 3 étapes principales. Le premier objectif est de trouver une matrice gé-
nératrice du dual de C , noté H, autrement appelée matrice de parité. Il utilise pour cela l’algorithme
de A. Valembois et la méthode de Canteaut-Chabaud. Cette recherche s’effectue à partir d’une matrice
formée de mots issus de la séquence observée.
La séquence observée étant bruitée, cette première étape permet de sélectionner des mots du dual
non bruités. La seconde étape utilise alors ces mots du dual non bruités pour reconstruire le dual du
dual, à savoir une matrice génératrice du code lui-même.
La dernière étape a pour but d’extraire une matrice canonique de la matrice reconstruite à l’étape 2.
A ces étapes se rajoutent (entre la première et la deuxième étape) une étape de recherche de la
longueur n du code et en fin d’algorithme une étape de recherche du taux d’erreur. La recherche
du taux d’erreur consiste à décoder la séquence observée par l’algorithme de Viterbi avec la matrice
génératrice retournée par l’algorithme de reconnaissance de codes.
Première étape : Reconstruction d’une matrice H du dual de C
Nous disposons d’une séquence observée S à partir de laquelle nous formons une matrice R˜ de la
manière suivante : la séquence est découpée en blocs de taille n(m + 1) (quitte à itérer sur la taille des
blocs lorsque ces paramètres sont inconnus), chacun de ces blocs constitue une ligne de R˜.
Si R˜ n’est pas une matrice bruitée : pour h ∈ C
⊥, alors Rh˜ ⊤ vaut 0. C’est-à-dire h appartient au
noyau de R˜. Si R˜ est bruitée : pour h ∈ C
⊥, alors Rh˜ ⊤ est de poids faible.
L’algorithme de recherche de mots de poids faibles de Canteaut-Chabaud permet alors de retrouver
des h candidats et l’algorithme de A. Valembois permet de décider s’ils appartiennent ou non à C
⊥
selon le poids de Hamming de Rh˜ ⊤ et de h.
En sortie de cette première étape, nous disposons alors de mots du dual. Le produit d’une ligne
de R˜ par h détermine une équation de parité.
M. Côte et N. Sendrier [20] utilisent alors ces mots du dual h pour former une seconde matrice, que
l’on notera R et reconstituer une matrice génératrice du dual. Cette reconstruction se base sur une
élimination de Gauss. En effet, une application de l’élimination de Gauss sur la matrice R la transforme
en une matrice de forme particulière dans laquelle il est possible d’identifier un bloc minimal :
363.4 Reconstruction de codes
c’est-à-dire un ensemble de lignes et de colonnes adjacentes engendrant le sous-espace vectoriel décrit
par R. Ce bloc, noté H, engendre C
⊥.
Deuxième étape : Reconstruction d’une matrice génératrice de C à partir du dual
Cette étape consiste à retrouver le dual du dual de C, c’est-à-dire à retrouver le code lui-même. La
matrice H précédemment reconstituée est utilisée pour former une nouvelle matrice H′
sur laquelle
est pratiquée également une élimination de Gauss afin de trouver le bloc minimal, noté G, engendrant
le sous-espace vectoriel décrit par H′
.
Troisième étape : Reconstruction d’une matrice génératrice polynomiale canonique de C
Après utilisation d’algorithmes de basicité et réduction [20] sur la matrice G reconstruite à l’étape
2, une matrice G(D) polynomiale canonique de C est fournie.
Les étapes présentées ici reposent sur le fait que la longueur n soit connue. N. Sendrier propose
d’appliquer la méthode de Canteaut-Chabaud et l’algorithme de A. Valembois à une matrice R˜ pour
quelques longueurs de blocs bien choisies de telle sorte que cette longueur puisse être un multiple de
la longueur n du code. D’autre part, le calcul de wH(Rh˜ ⊤) fournit une indication sur le taux d’erreur
potentiel du canal. Il est alors possible de distinguer la plus petite longueur de code fournissant pour
l’ensemble des mots du dual un faible taux d’erreur. Cette longueur est la longueur n du code C .
Cet algorithme de reconnaissance de codes convolutifs permet d’effectuer une reconnaissance de
codes lorsque la séquence observée est bruitée. Des tests de résistance au bruit ont été effectués
dans [20]. Il permet de plus d’effectuer cette recherche à paramètres inconnus. Cette méthode fournit
également le taux d’erreur du canal en appliquant un décodage de la séquence observée.
3.4.2 Codes Reed-Solomon
La difficulté de la reconstruction des codes de Reed-Solomon réside dans la recherche de la structure
algébrique. En effet il existe des méthodes de reconstruction de codes en blocs permettant de
reconstruire une base du code dual et ainsi de reconstruire une base du code. Il est possible notamment
d’effectuer un pivot de Gauss sur une matrice contenant les données observées, de faire appel à
le méthode de Gauss randomisé ou enfin d’utiliser la méthode A. Valembois ou de M. Cluzeau.
Cependant ce n’est pas suffisant pour caractériser un code de Reed-Solomon. Les méthodes énoncées
plus haut offrent la possibilité de reconstruire une base du code vu sous forme binaire mais ne
permettent pas de donner la structure algébrique du code. Pour cela il existe des techniques spécifiques
au type de code utilisé.
L’algorithme de V.M. Sidelnikov et S.O. Shestakov [44] répond à ce problème pour les codes de
Reed-Solomon. Il prend en entrée une matrice de taille génératrice k × n, contenant des éléments de
Fq, mise sous forme systématique. Nous avons vu que la matrice systématique d’un tel code dispose
d’une forme particulière, ceci permet d’écrire un ensemble d’équations qui après résolution fournissent
les paramètres du code. Cet algorithme fonctionne de plus lorsque les coordonnées du code ont été permutées.
Nous verrons que dans notre cas ce point fort sera à notre désavantage. Aussi nous utiliserons
finalement un algorithme moins performant qui sera évoqué ultérieurement.
37Chapitre 3. Codes Convolutifs et Codes de Reed-Solomon
38Chapitre 4
Signature de codes convolutifs et recherche du
dual par tests statistiques
Lors de l’étude d’un système de communication et de la partie codage canal qui le compose, nous
souhaitons avant toute chose identifier la famille de codes utilisée, voire les paramètres du code. En
effet, ces informations permettent respectivement d’utiliser un algorithme de reconnaissance de code
approprié et d’accélérer la recherche. Nous nous intéressons alors dans ce chapitre à une méthode permettant
de distinguer si une séquence observée est aléatoire ou codée par un codeur convolutif. Cette
technique possède notamment l’avantage de fonctionner lorsque le mapping utilisé est inconnu. Elle
permet alors de distinguer la longueur d’un code convolutif sans connaissance du mapping. De plus
nous étendons cette méthode à une méthode de reconstruction du dual d’un code convolutif lorsque
le mapping est connu.
Nous appelons signature un biais observé via un test statistique, appliqué à une séquence codée
et bruitée, permettant d’identifier l’utilisation d’un code correcteur d’erreurs. Nous supposons dans la
suite que nous disposons d’une séquence codée éventuellement bruitée. Christophe Chabot [14] s’est
intéressé à divers tests statistiques, dédiés aux générateurs pseudo-aléatoires, comme la série de test
du NIST (National Institute of Standards and Technology) [1] . Ces tests ont été expérimentés dans le
cadre de l’identification de séquences codées et bruitées par des codes en blocs, des codes convolutifs
et des turbo-codes. Le résultat de ces tests a montré que les codes en blocs ne sont en général pas
identifiables de cette façon sauf pour de petites longueurs et dimensions non réalistes. Cependant, le
test de compression de Lempel-Ziv (méthode de compression par dictionnaire) s’est révélé adapté pour
l’identification de codes convolutifs et turbo-codes et ce dans un contexte bruité également. Nous nous
intéressons cependant dans la suite de ce chapitre aux codes convolutifs uniquement.
Christophe Chabot s’est alors intéressé à d’autres méthodes de compression comme la compression
utilisée dans bzip2, faisant appel à la transformée de Burrows-Wheeler [11]. Les meilleurs taux
de compression étant obtenus avec bzip2, il a défini un test statistique basé sur le calcul du nombre
de runs (séquences maximales de bits identiques) dans une séquence codée après application de la
transformée de Burrows-Wheeler. Ce test permet l’identification des paramètres d’un code convolutif.
Il existe également un test dit de profondeur permettant d’obtenir la longueur de contrainte d’un
code convolutif de longueur 2.
39Chapitre 4. Signature de codes convolutifs et recherche du dual par tests statistiques
Il est clair que les codes convolutifs offrent l’avantage d’être de petites longueurs n et dimensions
k (pour que le décodage en treillis soit possible), et de degré d compris typiquement entre 2 et 10. Les
objets que nous manipulons sont donc de tailles bien inférieures à celles nécessaires pour des codes en
blocs. La méthode de détection que nous définissons dans ce chapitre s’applique en théorie pour des
codes en blocs mais elle n’est cependant applicable en pratique que pour de petits codes et est donc
particulièrement adaptée pour la détection des codes convolutifs. C’est pourquoi nous nous intéressons
à ce type de code dans ce chapitre.
Dès lors que nous observons une équation de parité sur une séquence, l’espace ambiant n’atteint
pas l’ensemble de toutes les séquences possibles. Pour un code de longueur n et de degré maximum
d, les séquences de taille t = n(d + 1) sont au nombre de 2t−1 au plus contre 2t pour une séquence
aléatoire. En effet il existe au moins un bit de redondance donc au moins un bit est entièrement déterminé
par les autres. Les tests qui sont décrits dans ce chapitre utilise ce phénomène. Nous l’utilisons
également en définissant un test basé sur le comptage de blocs de taille t dans une séquence codée et
bruitée. En itérant sur la taille des blocs, nous pouvons observer une diminution du nombre de blocs
possibles sur certaines longueurs. Nous effectuons de plus cette mesure par comptage de collisions.
Nous observons alors une probabilité de collisions différente pour des données codées et des données
aléatoires. L’utilisation de blocs glissants permet de plus de caractériser la présence d’un code de type
convolutif. Cette méthode autorise également la reconnaissance des paramètres du code utilisé dans un
contexte bruité. Nous savons par ailleurs grâce au paradoxe des anniversaires que seulement 2t/2 blocs
environ sont nécessaires à l’observation de collisions. Nous définissons ensuite une méthode de reconstruction
du dual par comptage de collisions en poinçonnant la séquence observée de manière adéquate.
Nous verrons enfin que la signature d’un code convolutif peut se détecter sans connaissance a
priori du mapping utilisé. Ce qui offre un avantage considérable pour la reconnaissance de système de
communication. En effet nous sommes en mesure grâce à ce test de déterminer la longueur du code
convolutif utilisé sans avoir reconnu le mapping utilisé. Ceci permettra alors d’effectuer la recherche
du mapping avec une information non négligeable sur le code à rechercher. La reconnaissance du
mapping est l’objet du Chapitre 6. Cependant ce travail sur la détection de codes convolutifs a été
effectué ultérieurement au travail sur la reconnaissance du mapping et n’a donc pas pu être utilisé alors.
L’estimation du cardinal d’un observable, tout en minimisant la quantité de mémoire utilisée, est
un défi primordial pour l’analyse de trafic internet par exemple. Marianne Durand s’intéresse dans sa
thèse [26] à divers algorithmes d’estimation de cardinal. Nous n’avons pas exploré ces possibilités pour
estimer la cardinalité d’une séquence codée vue par blocs mais il serait intéressant d’étudier l’efficacité
de ces algorithmes dans le contexte de la reconstruction de codes.
404.1 État de l’art
4.1 État de l’art
4.1.1 Test de profondeur
Le test de profondeur décrit dans [31] s’applique au cas d’un code convolutif de longueur 2 et donc
de dimension 1. Dans ce cas la longueur de contrainte du code coïncide avec d + 1 où d est le degré
maximum du code.
Soit C tel que P1 et P2 soient des polynômes générateurs. Le codeur utilisé nécessite M bits pour
remplir ses registres. Une séquence d’information de taille s + m s’envoie sur une séquence codée de
taille 2s. Soit Cs cette restriction :
Cs : F
s+m
2 → F
2s
2
Le théorème suivant est à la base de la plupart des résultats sur la reconnaissance de codes convolutifs.
Il donne en effet le rang de l’application Cs en fonction de s et montre qu’à partir de s > m
toutes les séquences de taille 2s ne correspondent pas à une séquence codée.
Théorème 4.1.1 ?? Soit s ∈ N
∗
. Soit Cs : F
s+m
2 → F
2s
2
l’application linéaire obtenue par restriction.
Si pgcd(P1,P2)=1 alors
Cs est surjective ⇔ s ≤ m
Cs est injective ⇔ s ≥ m
et
rang(Cs) = (
2s si s ≤ m
s + m si s ≥ m
Dès lors que s > m, Cs est injective et non surjective, on cherche donc le plus petit s tel que Cs+1
n’est pas surjective. Il existe des séquences de longueur 2s qui ne sont pas des séquences codées dans
ce cas. La distribution de ces séquences n’est pas uniforme lorsque s > m
Le test de profondeur consiste alors à choisir un nombre significatif de séquences de longueur 2s
(s peut être initialisé à 2). Pour chaque bloc de taille 2, on regarde la probabilité d’apparition des 2
bits suivants. Si la répartition est uniforme, on incrémente s de 1 sinon s correspond à la longueur
de contrainte du code. Ce test est applicable pour un canal binaire symétrique de probabilité d’erreur
allant jusqu’à 0,05.
4.1.2 Test de Burrows-Wheeler et Runs
La transformée de Burrows-Wheeler effectue un arrangement sur les données tel que les motifs
récurrents d’une séquence observée entraînent des suites de bits identiques en sortie de la transformée.
Cette modification de la séquence facilite ensuite la compression par dictionnaire. Elle est ainsi
utilisée dans bzip2. Les compressions obtenues en appliquant la transformée de Burrows-Wheeler à
une séquence codée indiquent que le taux d’erreur et les paramètres de longueur de contrainte sont
identifiables. Christophe Chabot a donc élaboré un test basé sur la transformée de Burrows-Wheeler
et une Pvalue mesurant la variation entre le nombre de runs observés et le nombre de runs théoriques
pour une séquence aléatoire.
41Chapitre 4. Signature de codes convolutifs et recherche du dual par tests statistiques
Il a de plus remarqué que pour des séquences de longueur donnée, générées par des codes de
paramètres n, k et m, les Pvalue observées sont identiques quel que soit le code de même paramètres
utilisé (codes non dégénérés) et sont fonction du taux d’erreur du canal. Il obtient ainsi des courbes
types pour différents paramètres. Ces courbes sont de plus toutes distinctes. Lorsque que la Pvalue
observée correspond à plusieurs courbes, on peut augmenter artificiellement le bruit jusqu’à identifier
une seule courbe. Ceci donne alors n, k et m ainsi que le taux d’erreur initial.
Nous pouvons également tester le calcul de l’entropie sur une séquence codée lue par blocs de taille
t. Lorsque t atteint la longueur nécessaire pour disposer d’une équation de parité, l’entropie calculée
vaut bien t − 1.
Les tests que l’on vient de voir se basent sur le fait que le cardinal des motifs observés lorsque
l’on regarde une séquence codée lue par blocs de taille t ne vaut pas 2t
lorsque l’on dépasse une
certaine taille de blocs. Donc, pour mesurer cette diminution du nombre de motifs possibles, à partir
d’un certain rang, il faut effectuer un comptage sur ces motifs. Mais l’inconvénient est la taille des
données nécessaires pour obtenir ce résultat. C’est pourquoi nous nous sommes intéressés ensuite à
élaborer une mesure de ce cardinal par comptage de collisions. Ce test repose alors sur le paradoxe
des anniversaires.
4.2 Test de collisions
L’objectif de ce chapitre est de décrire dans un premier temps une méthode de reconnaissance
des paramètres d’un code convolutif. Elle s’appuie sur le comptage du nombre de collisions dans une
séquence binaire lue par bloc. La probabilité de collisions entre deux symboles binaires de taille t,
pour des données aléatoires, est de 1
2
t
. Dès lors que les données sont codées, la probabilité de collisions
augmente. Le comptage des collisions permet donc de distinguer des données aléatoires de données
codées lorsque t est suffisamment grand pour correspondre à la taille d’une équation de parité.
Nous pouvons lire la séquence par blocs disjoints ou par blocs glissants. Mais les équations de parité
d’un code convolutif étant valides par blocs glissants (avec un décalage correspondant à la longueur
du code) nous tirons parti de ce phénomène en effectuant le comptage par blocs glissants.
Les paramètres du code sont alors identifiés en itérant sur la taille des blocs de lecture. Ce procédé
a l’avantage d’avoir un faible coût et d’être résistant au bruit.
Le test que nous effectuons repose sur le paradoxe des anniversaires. Nous observons une séquence
binaire par blocs de taille t. Lorsqu’un symbole, de taille t, apparaît i fois dans la séquence on dit qu’il
y a
i.(i−1)
2
collisions. Nous comptons alors le nombre total de collisions que nous notons XN pour une
séquence composée de N blocs. Dans un contexte non bruité cela correspond à
XN =
X
N
i=1
X
j>i
x(si
, sj )
où
x(si
, sj ) = (
1 si si = sj
0 sinon.
424.2 Test de collisions
Nous pouvons alors comparer la probabilité de collisions observée et l’espérance de ce nombre pour
des données aléatoires ou codées. En effet pour des données aléatoires, vues par bloc de taille t on a
P(s = s
′
) = 1
2
t
et par linéarité de l’espérance on a :
E [XN ] = X
N
i=1
X
j>i
E[x(si
, sj )]
=
1
2
t
|{i, j ∈ J1, NK, j > i}|
=
N.(N − 1)
2
t+1
Le test statistique se déroule alors comme suit : Soit une séquence binaire observée, composée de
N blocs de taille t. Nous comptons le nombre, noté Xobs, de collisions observées sur cette séquence.
Après normalisation, la probabilité empirique, xobs, de collision, vaut
xobs =
2.Xobs
N.(N − 1)
Pour observer de manière sûre une collision, pour des données aléatoires, il faut disposer d’au moins
2
t + 1 symboles soit t.(2t + 1) bits. Mais d’après le paradoxe des anniversaires on a une collision avec
une probabilité supérieure ou égale à α pour cαt
√
2
t bits où cα =
p
−2 ln(1 − α). Lorsque nous avons
i équations de parité, il faut disposer de cαt
√
2
t−i bits pour obtenir au moins une collision avec une
probabilité supérieure ou égale à α. Le tableau suivant donne alors les quantités de données nécessaires
pour différentes valeurs de α lorsque il existe une équation de parité avec t = 20.
α Nombre de bits nécessaires
1/2 17 051
2/3 21 467
3/4 24 114
Nous nous plaçons dans le cas du canal binaire symétrique de probabilité d’erreur p et nous
calculons dans la suite de ce chapitre la probabilité de collisions pour le code de parité ainsi que
lorsque les données sont codées par un codeur convolutif et possèdent une équation de parité. Le
cas du code de parité n’est pas utile en soit puisque nous nous intéressons uniquement aux codes
convolutifs mais il facilite la compréhension de la probabilité de collisions en présence d’une équation
de parité.
Dans le cas non bruité, le modèle de probabilité de collisions s’étend lorsqu’il y a plusieurs équations
de parité. Il est en revanche plus difficile d’établir des formules génériques pour les probabilités de
collisions lorsqu’il existe plusieurs équations de parité. Nous verrons alors expérimentalement pour le
canal binaire symétrique que la distinction entre des données codées possédant plusieurs équations de
parité et des données aléatoires est claire.
De plus, nous utilisons comme mesure le rapport entre la probabilité de collisions pour des données
aléatoires et la probabilité de collisions empirique.
43Chapitre 4. Signature de codes convolutifs et recherche du dual par tests statistiques
4.3 Espérance du nombre de collisions
Dans un contexte non bruité, deux symboles reçus sont égaux si et seulement si les symboles émis
sont égaux. Cependant, dans un canal bruité, on peut obtenir une collision entre deux symboles reçus
pour des symboles émis différents et inversement, deux symboles émis égaux peuvent correspondre à
des symboles reçus différents.
Nous pouvons donc observer des collisions sur la séquence reçue là où il n’y en avait pas sur la
séquence non bruitée et inversement. Nous calculons alors la probabilité de collisions entre deux mots
de code bruités pour le code de parité de longueur t. Ensuite, nous calculons cette même probabilité
de collisions entre deux symboles ayant la taille d’une équation de parité.
4.3.1 Code de parité
Nous supposons ici que la séquence émise est constituée de mots de code du code de parité de
longueur t. Nous notons s et s
′ deux mots de code du code de parité choisis uniformément dans
l’ensemble des mots de code. Ils sont émis dans un canal binaire symétrique de probabilités d’erreur
p, et r et r
′
sont les symboles reçus correspondants. Nous calculons alors la probabilité que r soit égal
à r
′
.
Proposition 4.3.1 Soient r et r
′ deux mots de code du code de parité, de taille t, reçus après transmission
à travers un canal binaire symétrique de probabilité d’erreur p alors
P
r = r
′
=
1
2
t−1
X
t
i=0
i pair
p
2 + (1 − p)
2
t−i
(2p(1 − p))i
t
i
!
Démonstration : Tout d’abord dans un bloc de taille t, le dernier bit dépend des t − 1 précédents
par définition du code de parité. Donc il existe seulement 2t−1 blocs distincts.
Lorsque le canal n’est pas bruité, c’est à dire p = 0, P(r = r
′
) = P(s = s
′
) = 1
2
t−1 .
Notons
s = s0s1 . . . st−i−1st−i
. . . st−1
et
s
′ = s
′
0
s
′
1
. . . s′
t−i−1
s
′
t−i
. . . s′
t−1
Sans perdre de généralité on peut supposer que s et s
′
sont différents sur les i dernières positions et
identiques sur les t−i premières. Appelons r et r
′
les versions bruitées de s et s
′
respectivement. Alors
P(r = r
′
) = P(r0 = r
′
0
, . . . , rt−i−1 = r
′
t−i−1
, rt−i = r
′
t−i
, . . . , rt−1 = r
′
t−1
)
Ces évènements sont indépendants dans un canal binaire symétrique donc
P(r = r
′
) =
t
Y−1
i=0
P(ri = r
′
i
)
444.3 Espérance du nombre de collisions
Alors
P(r0 = r
′
0
) = P(r0 = s0, r′
0 = s
′
0
) + P(r0 = s0, r′
0 = s0
′
)
= (1 − p)
2 + p
2
et
P(rt−1 = r
′
t−1
) = P(rt−1 = st−1, r′
t−1 = st−1
′
) + P(rt−1 = st−1, r′
t−1 = s
′
t−1
)
= 2p(1 − p)
De plus
P(r0 = r
′
0
) = . . . = P(rt−i−1 = r
′
t−i−1
)
et
P(rt−i = r
′
t−i
) = . . . = P(rt−1 = r
′
t−1
).
D’où pour s et s
′ fixé
P(r = r
′
) =
(1 − p)
2 + p
2
t−i
(2p(1 − p))i
.
Or la différence de s et s
′
est de poids pair puisque la somme de deux mots de code est un mot de
code. Donc il y a Pt
i=0
i pair
t
i
possibilités de positionner cette différence. D’où
P(r = r
′
) = 1
2
t−1
X
t
i=0
i pair
(1 − p)
2 + p
2
t−i
(2p(1 − p))i
t
i
!
Remarque 4.3.2 Remarquons que lorsque p = 0
X
t
i=0
i pair
(1 − p)
2 + p
2
t−i
(2p(1 − p))i
t
i
!
= 1
donc on a bien P(r = r
′
) = 1
2
t−1 dans ce cas. Ce qui correspond bien à l’intuition que l’on a.
Donc, lorsque p = 0, la probabilité de collision est deux fois plus élevée pour le code de parité que
pour des données aléatoires. Nous pouvons alors distinguer aisément des données codées par le code
de parité, de données aléatoires, sur des blocs de taille t, quitte à itérer sur t. Dans ce cas, les blocs
sont lus de manière disjointe naturellement.
Notons PC la probabilité de collision pour le code de parité et Paléa la probabilité de collision, pour
des données aléatoires. Le rapport PC
Paléa
est représenté dans la Figure 4.1 pour différents niveaux de
bruit. Nous remarquons que lorsque le canal est bruité jusqu’à p = 10−3
, nous distinguons clairement
la présence d’un code car le rapport des probabilités de collisions est proche de 2. Cependant, lorsque
le bruit augmente, nous voyons qu’il sera toujours aisé de distinguer de très petits codes tandis que
pour les codes de plus grandes longueurs (au delà de n = 10), cette distinction risque d’être moins
claire voire impossible.
Nous nous intéressons dans la suite de ce chapitre à la reconnaissance des paramètres d’un code
convolutif. Soit C un code convolutif possédant une équation de parité de taille t, nous montrons à
présent qu’il est possible de distinguer la présence d’une telle équation en observant la probabilité de
collision sur des blocs de taille t. Nous établissons pour cela la probabilité de collisions attendue.
45
Caractérisation et d´etection de malware Android basées
sur les flux d’information
Radoniaina Andriatsimandefitra
To cite this version:
Radoniaina Andriatsimandefitra. Caract´erisation et d´etection de malware Android bas´ees sur
les flux d’information. Cryptography and Security. Sup´elec, 2014. French.
HAL Id: tel-01095994
https://hal.inria.fr/tel-01095994
Submitted on 16 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.2014
THÈSE DE DOCTORAT
DOMAINE : STIC
Spécialité : Informatique
Ecole doctorale MATISSE
présentée par
Radoniaina Andriatsimandefitra
Ratsisahanana
préparée à l’unité de recherche CIDRE
Confidentialité, Intégrité, Disponibilité, Répartition
Supélec/INRIA
Caractérisation et
détection de malware
Android basées sur les
flux d’information
Thèse soutenue à Supélec
le (date)
devant le jury composé de :
Pascal Caron
Maître de Conférence à l’université de Rouen / examinateur
Anthony Desnos
Ingénieur chez Google / examinateur invité
Jean-Yves Marion
Professeur à l’université de Lorraine / rapporteur
Ludovic Mé
Professeur à Supélec / directeur de thèse
David Pichardie
Professeur à l’ENS Rennes / examinateur
Radu State
Chercheur à l’université du Luxembourg/rapporteur
Valérie Viet Triem Tong
Professeur associé à Supélec / encadrant de thèseiiTable des mati`eres
Table des figures vii
Liste des tableaux xi
1 Introduction 1
2 Etat de l’art 5 ´
2.1 Syst`eme Android . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.1 Architecture du syst`eme Android . . . . . . . . . . . . . . 6
2.1.2 Applications Android . . . . . . . . . . . . . . . . . . . . 9
2.2 S´ecurit´e du syst`eme Android . . . . . . . . . . . . . . . . . . . . 16
2.2.1 M´ecanismes issus de Linux . . . . . . . . . . . . . . . . . 16
2.2.2 M´ecanismes propres `a Android . . . . . . . . . . . . . . . 17
2.3 Limites des m´ecanismes de s´ecurit´e Android . . . . . . . . . . . . 21
2.3.1 Abus de permission . . . . . . . . . . . . . . . . . . . . . 21
2.3.2 Permissions : attaques par d´el´egation et attaques par collusion
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
2.3.3 Communication entre composants via les intents . . . . 21
2.3.4 Failles logicielles : ´el´evation de privil`ege . . . . . . . . . . 23
2.4 Malware Android . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4.1 D´efinitions . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2.4.2 Malwares Android : 2010 `a 2011 [113] . . . . . . . . . . . 25
2.4.3 Malwares Android en 2013 . . . . . . . . . . . . . . . . . 28
2.5 Renforcement de la s´ecurit´e sous Android . . . . . . . . . . . . . 30
2.5.1 Protection des ressources sensibles . . . . . . . . . . . . . 30
2.5.2 Communication entre processus et entre composants . . . 35
2.5.3 Abus des permissions . . . . . . . . . . . . . . . . . . . . 39
2.6 Suivi de flux d’information . . . . . . . . . . . . . . . . . . . . . . 41
2.6.1 Suivi de flux au sein d’une application . . . . . . . . . . . 42
2.6.2 Suivi de flux au niveau syst`eme . . . . . . . . . . . . . . . 43
2.6.3 Suivi de flux au niveau hardware . . . . . . . . . . . . . . 44
2.7 Classification et d´etection de malware . . . . . . . . . . . . . . . 46
2.8 Analyse d’applications Android . . . . . . . . . . . . . . . . . . . 48
2.8.1 D´esassembleur, d´ecompilateur . . . . . . . . . . . . . . . . 48
iiiiv TABLE DES MATIERES `
2.8.2 Comparaison d’applications . . . . . . . . . . . . . . . . . 49
3 Blare : un moniteur de flux d’information 55
3.1 Mod`ele th´eorique . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.1.1 Conteneurs d’information . . . . . . . . . . . . . . . . . . 56
3.1.2 Information et contenu courant d’un objet : itag . . . . . 56
3.1.3 Politique de flux d’information : pxqptag . . . . . . . . . . 57
3.1.4 Suivi et contrˆole de flux d’information . . . . . . . . . . . 59
3.2 D´efinition d’une politique de flux d’information . . . . . . . . . . 62
3.3 KBlare : suivi et contrˆole de flux via LSM . . . . . . . . . . . . . 65
3.4 AndroBlare : Blare sous Android . . . . . . . . . . . . . . . . . . 68
3.4.1 Communication entre processus : Binder . . . . . . . . . . 69
3.4.2 Suivi de flux d’information dans le Binder . . . . . . . . . 72
3.4.3 Ex´ecution des applications Android . . . . . . . . . . . . 74
3.4.4 Description des flux observ´es . . . . . . . . . . . . . . . . 84
3.4.5 Outils en espace utilisateur . . . . . . . . . . . . . . . . . 84
3.5 AndroBlare : analyse d’applications Android . . . . . . . . . . . 85
4 Graphes de flux syst`eme 89
4.1 Graphe de flux syst`eme . . . . . . . . . . . . . . . . . . . . . . . 89
4.2 Quelques op´erations utiles sur les SFG . . . . . . . . . . . . . . . 92
4.2.1 Intersection de deux SFG : g1 [ g2 . . . . . . . . . . . . . 92
4.2.2 Inclusion d’un SFG dans un autre : g1 Ď g2 . . . . . . . . 93
4.2.3 Nœuds et arcs d’un SFG . . . . . . . . . . . . . . . . . . . 93
4.3 Construction d’un graphe de flux syst`eme . . . . . . . . . . . . . 93
4.4 SFG : profil comportemental d’une application . . . . . . . . . . 95
4.4.1 Analyse de DroidKungFu1 avec AndroBlare . . . . . . . . 95
4.4.2 Analyse du SFG de DroidKungFu1 . . . . . . . . . . . . . 96
4.5 Politique de flux d’information `a partir d’un SFG . . . . . . . . . 100
5 Caract´erisation et d´etection de malware 107
5.1 Caract´erisation de malware Android . . . . . . . . . . . . . . . . 108
5.2 Evaluation de la m´ethode de classification . . . . . . . . . . . . . ´ 111
5.2.1 Jeu de donn´ee . . . . . . . . . . . . . . . . . . . . . . . . 111
5.2.2 Exp´erimentation et r´esultat . . . . . . . . . . . . . . . . . 112
5.3 De la n´ecessit´e du filtrage . . . . . . . . . . . . . . . . . . . . . . 118
5.4 D´etection d’ex´ecution de malware Android . . . . . . . . . . . . . 121
5.5 Evaluation de la capacit´e de d´etection . . . . . . . . . . . . . . . ´ 122
6 Conclusion 129
A Ev`enements d´eclencheurs de code malveillant 133 ´
A.1 Outils . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
A.2 BadNews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
A.3 DroidKungFu1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
A.4 DroidKungFu2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144TABLE DES MATIERES ` v
A.5 jSMSHider . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Publications 147
Bibliographie 149vi TABLE DES MATIERES `Table des figures
2.1 Architecture de la plateforme Android . . . . . . . . . . . . . . . 8
2.2 Fichier MANIFEST.MF de l’application HelloActivity . . . . . . . . 18
2.3 Fichier .SF de l’application HelloActivity . . . . . . . . . . . . . 19
3.1 Extrait de la sortie de la commande ps sous Android 4.4 . . . . . 58
3.2 Exemple de contrˆole de flux d’information effectu´e par Blare . . 61
3.3 Design de Linux Security Module . . . . . . . . . . . . . . . . . . 66
3.4 Appel d’une m´ethode distante grˆace au Binder . . . . . . . . . . 70
3.5 S´equence de d´emarrage d’Android . . . . . . . . . . . . . . . . . 75
3.6 M´ecanisme de notification de l’ex´ecution d’une application Android 77
3.7 Exemple de message lev´e par Blare sous Linux . . . . . . . . . . 84
3.8 Format des flux observ´es par Blare sous Android . . . . . . . . . 85
3.9 AndroBlare : environnement d’analyse d’application Android . . 87
4.1 Exemple de flux d’information causant l’apparition d’arcs parall`eles
dans les SFG . . . . . . . . . . . . . . . . . . . . . . . . . 90
4.2 Exemple de SFG avec des arcs parall`eles . . . . . . . . . . . . . . 90
4.3 Graphe de d´ependance et SFG repr´esentant les flux d’information
ayant pr´ec´ed´e la corruption d’un fichier f ilex . . . . . . . . . . . 92
4.4 Permissions demand´ees par un ´echantillons de DroidKungFu . . . 96
4.5 Liste des applications dans le menu du t´el´ephone apr`es l’installation
d’une nouvelle application par un ´echantillon de DroidKungFu 97
4.6 Extrait du SFG d’un ´echantillon de DroidKungFu . . . . . . . . 98
4.7 Extrait des alertes lev´ees par l’´echantillon de DroidKungFu1 lors
de l’´evaluation de la politique de Finger Scaner . . . . . . . . . . 104
5.1 S0 : sous-graphe en commun des ´echantillons de BadNews . . . . 115
5.2 S1 : sous-graphe en commun des ´echantillons de DroidKungFu 1 116
5.3 S2 : sous-graphe en commun des ´echantillons de DroidKungFu 2 117
5.4 S3 : Sous-graphe en commun des ´echantillons de jSMSHider . . . 117
5.5 Profil calcul´e lorsqu’aucun filtrage n’est r´ealis´e . . . . . . . . . . 119
5.6 Premier profil calcul´e en utilisant aucune liste blanche . . . . . . 120
5.7 Second profil calcul´e en utilisant aucune liste blanche . . . . . . . 120
5.8 Troisi`eme profil calcul´e en utilisant aucune liste blanche . . . . . 120
viiviii TABLE DES FIGURES
5.9 Quatri`eme profil calcul´e en utilisant aucune liste blanche . . . . . 120
A.1 Extrait du graphe d’appel de fonction d’un ´echantillon de BadNews137
A.2 Extrait du graphe d’appel de fonction d’un ´echantillon de DroidKungFu
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141Liste des listings
2.1 Partage d’une page web grˆace `a un intent implicite. Extrait du
code du navigateur par d´efaut d’Android . . . . . . . . . . . . . 11
2.2 Fichier AndroidManifest.xml d’Angry Birds Space . . . . . . . 15
2.3 Exempe de code Java avec et sans r´eflexion . . . . . . . . . . . . 29
2.4 Extrait du code de l’application JetBoy fourni avec le SDK Android 49
2.5 Extrait du code smali de l’application JetBoy . . . . . . . . . . . 52
2.6 Extrait du code r´esultant de la d´ecompilation de l’application
JetBoy avec le d´ecompilateur par d´efaut d’Androguard . . . . . . 53
3.1 Exemple de politique App Armor . . . . . . . . . . . . . . . . . . 62
3.2 Liste des op´erations sur les fichiers support´ees par Binder . . . . 71
3.3 Signature de la fonction binder ioctl . . . . . . . . . . . . . . . 71
3.4 Fonction de chargement en m´emoire du code d’une application . 78
3.5 D´eclaration d’une famille Generic Netlink dans le noyau pour le
m´ecanisme de coop´eration . . . . . . . . . . . . . . . . . . . . . . 79
3.6 D´efinition d’une commande Generic Netlink pour notifier l’ex´ecution
d’une application . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
3.7 Enregistrement de la famille servant `a la notification d’ex´ecution
des applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.8 Notification de l’ex´ecution d’une application par la machine virtuelle
Dalvik . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.1 Entr´ee dans le fichier packages.xml ajout´ee suite `a l’installation
d’une nouvelle application par un ´echantillon de DroidKungFu . 99
4.2 Extrait de la politique BSPL de l’application Finger Scanner . . 105
5.1 Contenu du fichier sstimestamp.xml d’un ´echantillon de DroidKungFu1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
A.1 Fichier AndroidManifest.xml d’un ´echantillon de BadNews . . . 135
A.2 Code appel´e `a la r´eception d’un Intent par les composants de
type Receiver d’un ´echantillon de BadNews . . . . . . . . . . . . 136
A.3 Extrait du code de la m´ethode sendRequest d’un ´echantillon de
BadNews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
A.4 Code appel´e `a l’ex´ecution du composant AdvService d’un ´echantillon
de BadNews . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
A.5 Extrait du contenu du fichier AndroidManifest.xml d’un ´echantillon
de DroidKungFu1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
ixx LISTE DES LISTINGS
A.6 M´ethode onCreate du composant SearchService d’un ´echantillon
de DroidKungFu1 . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
A.7 Contenu du fichier sstimestamp.xml d’un ´echantillon de DroidKungFu1
. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
A.8 M´ethode onCreate d’un composant service d’un ´echantillon de
DroidKungFu2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144Liste des tableaux
2.1 Types de permission Android . . . . . . . . . . . . . . . . . . . . 17
2.2 Exploits root connus et leur usage par les malware Android de
2010 `a 2011 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.1 Intervalle de valeur du type int selon sa taille en bits . . . . . . 56
3.2 Blare : m´ethode de suivi de flux . . . . . . . . . . . . . . . . . . . 60
3.3 Un extrait de la politique de flux d’information . . . . . . . . . . 64
3.4 Liste des hooks LSM utilis´es par KBlare pouvant engendrer un
flux d’information . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4.1 Nombre d’alertes lev´ees par Blare lors de l’ex´ecution des versions
originales et infect´ees de trois applications en appliquant une politique
BSPL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
5.1 Classification des 19 ´echantillons de malware. . . . . . . . . . . . 114
5.2 Nombre de profils obtenus en variant le filtrage . . . . . . . . . . 118
5.3 R´esultat de d´etection sur les applications b´enignes provenant de
Google Play. Taux de faux positif : 0% . . . . . . . . . . . . . . . 124
5.4 R´esultats de la d´etection sur 39 ´echantillons de malware. Taux
de Vrai Positif : 100% . . . . . . . . . . . . . . . . . . . . . . . . 125
xixii LISTE DES TABLEAUXListe des algorithmes
1 Construction d’un SFG `a partir des entr´ees d’un journal de Blare 94
2 Calcul d’une politique de flux d’information Blare `a partir d’un SFG101
3 Calcul des parties communes de SFG d’application caract´erisant
son comportement malveillant et regroupement de ces SFG . . . . 109
4 One-step-classification function . . . . . . . . . . . . . . . . . 109
5 D´etection de l’ex´ecution de malware Android bas´e sur les flux d’information
caus´e dans le syst`eme . . . . . . . . . . . . . . . . . . . 122
xiiixiv LISTE DES ALGORITHMESRemerciements
Avant d’aborder le pourquoi de ce document, je tenais avant tout `a remercier
les membres du jury d’avoir accept´e d’´evaluer mon travail : David Pichardie
pour avoir accept´e de pr´esider le jury de ma th`ese, Radu State et Jean-Yves
Marion pour avoir accept´e d’ˆetre les rapporteurs de ce m´emoire, Pascal Caron et
Anthony Desnos pour avoir accept´e d’examiner mon travail. Je tiens ´egalement `a
remercier Ludovic M´e et Val´erie Viet Triem Tong pour leur encadrement et leur
implication dans la r´ealisation de ma th`ese, ainsi que le reste de l’´equipe pour
ces trois ann´ees pass´ees ensemble. Finalement, un grand merci aux membres de
ma famille et aux amis qui m’ont soutenu tout au long de la th`ese. Kudos au
Langomatic (organisateurs, participants et staff du O’Connell’s) pour toutes ces
soir´ees du lundi riches en rencontres et en diversit´es culturelles.
xvxvi LISTE DES ALGORITHMESChapitre 1
Introduction
Lanc´e officiellement en 2008, Android est devenu en quelques ann´ees le
syst`eme d’exploitation le plus r´epandu sur les plateformes mobiles de type
smartphone et tablette [72, 107, 71]. Au del`a de sa large adoption par le grand
public, il a ´egalement suscit´e l’int´erˆet des d´eveloppeurs d’applications malveillantes
qui voient dans le syst`eme Android, une cible potentielle d’attaque au
mˆeme niveau que les ordinateurs de bureau `a cause de la diversit´e des donn´ees et
services qu’ils proposent. Les appareils tournant sous Android offrent diff´erentes
fonctionnalit´es allant du simple t´el´ephone `a celles des ordinateurs de bureau
et assistants num´eriques personnels (pockets PC ou PDA). La combinaisons
de toutes ces fonctionnalit´es font de ces appareils un point de concentration
de divers donn´ees et services sensibles (liste de contact, messages, donn´ees de
g´eolocalisation, etc.) et en cons´equence une cible de valeur pour les d´eveloppeurs
de malware. Ces derni`eres ann´ees, nous avons ainsi vu l’apparition d’un nombre
toujours grandissant d’applications malveillantes qui cherchent `a voler les donn´ees
du t´el´ephone, les corrompre, espionner l’utilisateur, abuser des services offerts
par le t´el´ephone, etc. A la vue du nombre grandissant des malware Android, il `
devient n´ecessaire de d´evelopper des outils d’analyse de malware afin de comprendre
leur fonctionnement et plus tard les d´etecter.
L’une des raisons de la prolif´eration de ces malware est l’insuffisance des
m´ecanismes de s´ecurit´e Android `a d´etecter et bloquer de telles attaques et la
facilit´e d’acc`es `a une partie des ressources sensibles du t´el´ephone. Android propose
un ensemble de m´ethodes pour acc´eder ces ressources et ces acc`es n´ecessite
une autorisation de la part de l’utilisateur au moment de l’installation. L’application
est install´ee uniquement si l’utilisateur valide toutes les autorisations
demand´ees par l’application. Toute application install´ee sur le t´el´ephone a ainsi
acc`es aux ressources dont elle a demand´e l’acc`es sans que le syst`eme ne contrˆole
l’usage qui est fait des ressources. Les premiers travaux li´es `a la s´ecurit´e d’Android
sont donc focalis´es sur l’analyse des limites de la s´ecurit´e sous Android
et sur une mani`ere de les combler. Enck et al. proposent par exemple dans [47]
une v´erification des permissions demand´ees par les applications afin de s’assurer
qu’elles ne soient trop dangereuses. Ce type d’approche a cependant une prin-
12 CHAPITRE 1. INTRODUCTION
cipale limitation qui est de ne d´etecter que ce que nous savons ˆetre dangereux.
Il ne permet donc pas de d´etecter et d’apprendre de nouvelles attaques.
Dans ce th`ese nous adoptons une approche diff´erente qui est bas´ee sur les
flux d’information. Un flux d’information d´ecrit un transfert d’information entre
deux objets. Au niveau du syst`eme d’exploitation, il d´ecrit par exemple des communications
entre deux applications ou des acc`es `a un fichier. Au lieu de nous
focaliser sur les limitations du syst`eme Android pour identifier les sc´enarios
d’attaque et les d´etecter par la suite, nous proposons d’apprendre comment
les attaques ont lieu en analysant directement les malware et utiliser la base
de connaissance acquise durant l’apprentissage pour d´etecter les malware. Selon
les travaux de Zhou et al. la m´ethode d’infection principale utilis´ee par les
d´eveloppeurs de malware est d’ajouter leur code malicieux `a des applications
existantes et proposer les versions infect´ees de ces applications en t´el´echargement
sur les plateformes de t´el´echargement tels que Google Play. En supposant qu’un
malware soit distribu´e sous la forme de diff´erentes applications, nous pouvons
supposer que les applications infect´ees par le mˆeme code malveillant ont partiellement
un comportement similaire. En analysant les ´echantillons des malware et
en isolant ces comportements similaires, nous pouvons ainsi `a la fois apprendre
le comportement malveillant d’un malware et calculer un profil pour ce malware
afin de le d´etecter. Le reste de ce document est divis´e comme suit.
Le chapitre 2 pr´esente le contexte de ce travail et est divis´e en deux parties.
La premi`ere partie concerne le syst`eme Android : l’architecture du syst`eme, ses
points communs et diff´erences avec les syst`emes Linux, la notion d’applications
Android, l’analyse des limites du mod`ele de s´ecurit´e d’Android, les menaces que
repr´esentent les malware Android et les travaux essayant de combler ces limites.
La deuxi`eme partie du chapitre introduit les bases n´ecessaires `a l’accomplissement
de notre objectif. Nous y pr´esentons dans un premier temps la notion
de suivi de flux d’information et les diff´erents niveaux existant pour observer
les flux d’information. Par la suite nous pr´esentons comment les m´ethodes d’apprentissage
peuvent ˆetre utilis´ees afin de classifier et d´etecter des malware. Nous
pr´esentons pour cela quelques travaux connus exploitant les traces d’ex´ecution
des malware pour les classifier.
Le chapitre 3 pr´esente Blare le moniteur de flux d’information et son portage
pour le syst`eme Android. Blare est un outil de d´etection d’intrusion param´etr´e
par une politique de flux d’information afin de d´etecter les intrusions dans un
syst`eme. Ayant ´et´e d´evelopp´e pour les syst`emes Linux, il ne prenait ainsi pas
en compte une partie des flux existant sous Android. Ces flux sont li´es `a des
m´ecanismes propres `a Android qui n’existent pas sous Linux. Dans un premier
temps, nous pr´esentons donc ces m´ecanismes et les flux d’information qu’ils
causent qui ´etaient invisibles `a Blare. Ensuite, nous pr´esentons comment nous
avons pris en compte ces m´ecanismes et am´elior´e ainsi l’observation des flux
d’information sous Android. Le r´esultat de ces am´eliorations, AndroBlare, est
ce qui nous sert d’environnement d’analyse durant cette th`ese.
Le chapitre 4 introduit une structure de donn´ee appel´ee graphe de flux
syst`eme ou System Flow Graph. Cette structure d´ecrit de mani`ere compacte et
plus compr´ehensible les flux d’information que Blare observe dans les syst`emes.3
Un des objectifs de cette th`ese est de comprendre le fonctionnement d’un malware
en l’analysant dans notre environnement d’analyse AndroBlare. Apr`es
avoir pr´esent´e la structure, nous montrons dans ce chapitre, `a travers l’analyse
d’un ´echantillon de malware, l’utilit´e de la structure pour repr´esenter le
comportement d’un malware et comprendre son comportement. Cette structure
repr´esentant le comportement d’une application, nous montrons ´egalement
qu’elle peut assister un d´eveloppeur dans la cr´eation d’une politique de flux
d’information pour son application.
Enfin, le chapitre 5 pr´esente notre approche afin de classifier et d´etecter les
malware Android. La classification consiste `a regrouper les ´echantillons d’un
malware avec un comportement similaire et extaire un profil caract´erisant les
´echantillons d’un mˆeme groupe. Cette classification s’apparente `a un apprentissage
non supervis´e et nous pr´esentons dans ce chapitre comment nous le r´ealisons
puis l’´evaluons avec un ensemble d’´echantillons de malware. La d´etection consiste
`a utiliser les profils calcul´es durant la classification pour d´etecter d’autres ´echantillons
de malware. Nous pr´esentons ainsi en deuxi`eme partie de ce chapitre
comment nous utilisons AndroBlare et les profils calcul´es pour d´etecter
l’ex´ecution de malware et ´evaluons l’approche avec d’autres ´echantillons.4 CHAPITRE 1. INTRODUCTIONChapitre 2
Etat de l’art
´
L’objectif de cette th`ese est de d´evelopper une m´ethode afin de caract´eriser
et d´etecter les malwares Android. La r´ealisation de cet objectif s’est faite en
plusieurs ´etapes : le portage du moniteur de flux d’information Blare pour le
syst`eme Android, la proposition d’une structure de donn´ee pour repr´esenter
les profils d’une application et une m´ethode de calcul de profil des malwares
Android ainsi que de leur d´etection. Dans ce premier chapitre, nous introduisons
dans un premier temps le syst`eme Android : son architecture, la notion
d’application Android et le mod`ele de s´ecurit´e d’Android. Ensuite, nous montrons
en section 2.3 et 2.4 les limites du m´ecanisme de s´ecurit´e Android ainsi
qu’un aper¸cu des menaces que repr´esentent les malware Android. La section 2.5
pr´esente ensuite les diff´erents travaux visant `a combler les limites du m´ecanisme
de s´ecurit´e d’Android ainsi qu’`a d´etecter les attaques visant le syst`eme. L’approche
pour laquelle nous avons opt´ee est bas´ee sur les flux d’information au
niveau du syst`eme. La section 2.6 pr´esente ainsi diff´erents travaux li´es au suivi
de flux d’information et une discussion sur les apports et limitations de ces
approches. Une partie des exp´erimentations que nous menons dans cette th`ese
consiste `a ex´ecuter des ´echantillons de malware Android et plus pr´ecis´ement leur
code malveillant. Comme ´evoqu´e dans les travaux de Zhou et al. dans [113], certains
malware v´erifient un nombre de conditions avant d’ex´ecuter leur code malveillant.
Afin d’identifier ces conditions, il est n´ecessaire d’analyser statiquement
les ´echantillons des malware concern´es. Nous pr´esentons ainsi en section 2.8 un
ensemble d’outils d’analyse statique des applications Android.
2.1 Syst`eme Android
Android partage une base commune aux syst`emes Linux qui est le noyau et
un ensemble de commandes et utilitaires n´ecessaires. Dans cette section, nous
pr´esentons dans un premier temps l’architecture du syst`eme Android, celle de
ses applications et les m´ecanismes de s´ecurit´e fournis avec le syst`eme.
56 CHAPITRE 2. ETAT DE L’ART ´
2.1.1 Architecture du syst`eme Android
Le syst`eme Android est divis´e en plusieurs couches comme illustr´e sur la
figure 2.1. La partie la plus basse repr´esente le cœur du syst`eme, c’est-`a-dire le
noyau, et le reste l’espace utilisateur.
2.1.1.1 Noyau Android
Le noyau Android est une version modifi´ee du noyau Linux 1
et repr´esente
le cœur du syst`eme. Le noyau est le programme servant d’interface entre les
diff´erents composants du syst`eme (p´eriph´eriques, processus, fichiers etc). Parmi
les modifications notables apport´ees dans le noyau Android, nous pouvons citer
les m´ecanismes binder, ashmem, wakelock, low memory killer, logger,
RAM console et Paranoid Networking.
Binder est un m´ecanisme de communication entre processus et d’appel de
m´ethodes distantes. L’appel de m´ethodes distantes, appel´e Remote Procedure
Call en anglais, consiste `a faire ex´ecuter une m´ethode par une entit´e distante.
Il est inspir´e du projet OpenBinder [81]. Comme nous le verrons par la suite, il
est un ´el´ement essentiel du fonctionnement du syst`eme Android.
Ashmem pour Anonymous Shared Memory est un m´ecanisme de partage de
m´emoire similaire `a celui du noyau Linux shm. Il est utilis´e pour partager
les donn´ees entre applications Android. Parmi les ”nouveaut´es” apport´ees par
ashmem il y a par exemple l’usage de compteur pour connaˆıtre le nombre de
processus faisant r´ef´erence `a une zone de m´emoire partag´ee et ´eviter les fuites
de m´emoire.
Wakelock est un m´ecanisme servant `a notifier le noyau de ne pas se mettre en
veille. Contrairement aux syst`emes Linux, le syst`eme Android essaie par d´efaut
de se mettre en veille ´etant donn´e qu’il est destin´e `a tourner sur des appareils
`a ressources limit´ees. Lors d’ex´ecution de code ne devant ˆetre interrompu, le
wakelock est ainsi utilis´e pour dire au syst`eme de rester ´eveill´e.
Low memory killer est un m´ecanisme utilis´e par le noyau pour lib´erer de
la m´emoire lorsqu’il ne reste plus assez de m´emoire.
Logger est un m´ecanisme de journalisation qui ´ecrit les ´ev`enements du
syst`eme uniquement dans des zones allou´ees en m´emoire. Contrairement aux
syst`emes Linux traditionnels, les ´ev`enements ´ecrits dans le journal du syst`eme
ne sont ainsi jamais ´ecrits dans un fichier.
RAM Console est un m´ecanisme qui pr´eserve en m´emoire le contenu des
´ev`enements syst`emes ajout´es par du code noyau (via la fonction printk) lors
de la pr´ec´edente ex´ecution du syst`eme. Son contenu est accessible via le fichier
/proc/last kmsg. Sous Linux, le contenu du journal des ´ev`enements syst`emes
sont stock´es de mani`ere persistante dans les fichiers sous le r´epertoire /var/log/.
Ce n’est pas le cas sous Android et en cas de crash du syst`eme par exemple,
il devient impossible de r´ecup´erer les ´ev`enements qui ont amen´e au crash. RAM
Console est ainsi ´et´e cr´e´e pour r´esoudre cette limitation du syst`eme de journalisation
sous Android.
1. Noyau utilis´e par les distributions de type Linux telles que Debian et Ubuntu2.1. SYSTEME ANDROID ` 7
Paranoid Network est un m´ecanisme contrˆolant l’acc`es des applications au
r´eseau. Sous Linux, toute application a le droit d’utiliser les sockets et acc´eder
au r´eseau. La socket est la structure de base li´ee aux op´erations r´eseaux sous
Linux. Sous Android, l’inverse est la r`egle car seule les applications avec une
autorisation explicite sont autoris´ees `a cr´eer des sockets et communiquer sur le
r´eseau.
2.1.1.2 Espace utilisateur
L’espace utilisateur sous Android peut ˆetre divis´e en plusieurs parties comme
illustr´e sur la figure 2.1.
La couche Applications renferme les applications fournies par d´efaut sur le
t´el´ephone ainsi que celles qui seront install´ees plus tard par l’utilisateur. Il s’agit
des applications avec lesquelles l’utilisateur pourra interagir en g´en´eral (ex :
application de messagerie et gestion des contacts). Les applications Android sont
principalement ´ecrites en Java. Android donne cependant la possibilit´e d’´ecrire
du code natif et de l’appeler au sein de l’application grˆace `a une interface appel´ee
Java Native Interface dont le rˆole est d’interfacer du code Java avec du code
natif ´ecrit en C.
Android framework est l’ensemble des services et ressources fournies par le
syst`eme Android. Il s’agit principalement de services tournant dans quelques
processus cl´es du syst`eme Android tels que system server et mediaserver. La
commande service list retourne sous Android la liste des services pr´esents
dans le syst`eme. Sous Android 2.3, la commande retourne une liste de 50 services
et sous Android 4.2 68 services. Parmi ces services nous pouvons citer ServiceManager,
LocationManager. ServiceManager recense tous les autres services
tournant sur le t´el´ephone et joue un rˆole d’annuaire pour les applications souhaitant
acc´eder `a un service en particulier sur le t´el´ephone. Lorsqu’une application
de navigation souhaite par exemple connaˆıtre la localisation de l’utilisateur,
elle va dans un premier temps demander au Service-Manager la r´ef´erence de
Location Service. Une fois cette r´ef´erence r´ecup´er´ee, elle pourra demander `a
Location Service les donn´ees de g´eolocalisation. Surfaceflinger est un autre
service avec un rˆole crucial sous Android. C’est lui qui est charg´e de composer
et dessiner ce que les diff´erentes applications souhaitent afficher `a l’´ecran de
l’appareil.
Android runtime est l’environnement d’ex´ecution des applications Android.
Il contient la biblioth`eque Java utilisable par les applications ainsi qu’une machine
virtuelle appel´ee Dalvik. La biblioth`eque reprend une partie de la biblioth`eque
Java standard plus quelques biblioth`eques suppl´ementaires propres
`a Android. La machine virtuelle Dalvik elle interpr`ete le bytecode dans lequel
les applications Android ont ´et´e compil´ees. Le bytecode dalvik est diff´erent du
bytecode Java d’o`u l’usage de Dalvik `a la place des machines virtuelles Java
standard. Depuis Android 4.4, une deuxi`eme machine virtuelle, ART [85, 99],
qui est livr´ee sous forme exp´erimentale avec la plateforme.
Libraries renferme les biblioth`eques natives du syst`eme. Elles sont g´en´eralement
utilis´ees par les applications natives du syst`eme. Parmi les biblioth`eques nous8 CHAPITRE 2. ETAT DE L’ART ´
Kernel
Libraries HAL
Android framework Android runtime
Applications
Binder Audio
driver
ext4
Power
management
Ashmem
Dalvik VM
Bionic OpenGL
Webkit SSL
Camera HAL
Audio HAL
... ...
Surface
Flinger
Camera
Service
Package
Manager
Native tools
and
daemons
Wakelock
...
Core libraries
Location
Service
...
Clock Contacts Launcher Email ...
Display driver LSM Bluetooth
driver
SMS
SQLite
Service
Manager Figure 2.1 – Architecture de la plateforme Android
pouvons par exemple citer bionic qui renferme entre autres une biblioth`eque C
et une biblioth`eque pour le support du C++. Selon la page Wikip´edia sur
bionic [3], il s’agit d’une version modifi´ee de la biblioth`eque standard C de
BSD et est propre `a Android.
Si les applications utilisateurs sont des applications ´ecrites en Java, il existe
tout de mˆeme quelques applications natives dans le syst`eme. Il s’agit de services
propres au syst`eme et de quelques outils en ligne de commande qui peuvent
s’av´erer utiles pour un d´eveloppeur. Ces applications n’ont pas pour but d’ˆetre
utilis´ees par l’utilisateur lambda.
HAL ou Hardware Abstraction Layer sert d’interface standard entre le syst`eme
et les pilotes des p´eriph´eriques pr´esents sur l’appareil (ex : cam´era, capteur etc).
Les constructeurs ´ecrivent ainsi les pilotes `a leur guise mais doivent fournir les
m´ethodes correspondant aux interfaces HAL pour que le syst`eme puisse utiliser
les p´eriph´eriques.2.1. SYSTEME ANDROID ` 9
2.1.1.3 Communications entre processus
Android est un environnement d’ex´ecution o`u les applications sont pouss´ees
`a collaborer pour fonctionner. Le but de cette collaboration est de limiter la duplication
de code dans les applications et de proposer un ensemble assez grand
de fonctionnalit´es aux diff´erentes applications du syst`eme. Un exemple illustrant
cette collaboration est l’application cam´era. Pour utiliser la cam´era d’un
appareil, une application doit connaˆıtre son mode de fonctionnement exact sachant
qu’une cam´era peut ˆetre diff´erente d’un mod`ele de t´el´ephone `a un autre.
Pour faciliter la tˆache au d´eveloppeur de l’application, l’application cam´era du
t´el´ephone propose une interface permettant aux autres applications de prendre
des photos ou enregistrer des vid´eos `a leur place puis leur transmettre le r´esultat.
Ce syst`eme de collaboration repose plusieurs fonctionnalit´es du syst`eme. Du
point de vue des d´eveloppeurs d’application, la collaboration repose sur l’usage
des intents et des composants Content Provider pour ´echanger des messages
et partager du contenu. Nous donnons plus de d´etail sur ces m´ecanismes dans
la section 2.1.2.1. A un niveau plus bas, la collaboration repose sur deux fonc- `
tionnalit´es d’Android que sont Binder et Ashmem. Comme nous l’avons ´ecrit en
section 2.1.1, ces deux m´ecanismes servent `a effectuer des appels distants de
proc´edure et partager des zones de m´emoire entre processus.
2.1.2 Applications Android
2.1.2.1 Architecture d’une application : les diff´erents composants
Une application Android est ´ecrite en Java. Contrairement aux applications
Java standard, une application Android peut poss´eder plusieurs points
d’entr´ee. Plus pr´ecis´ement, une application Android peut avoir plusieurs composants
et chacun d’eux peut-ˆetre un point d’entr´ee dans le programme. Il
existe quatre types de composants : Activity, ContentProvider, Service et
BroadcastReceiver.
Activity Un composant Activity est une interface utilisateur. Une application
de messagerie ´electronique peut par exemple avoir trois composants
Activity : un pour naviguer entre les r´epertoires de la messagerie, le deuxi`eme
pour l’affiche d’un message et le dernier pour l’´edition et l’envoi.
ContentProvider Un ContentProvider est un composant servant au partage
de donn´ees d’une application. Son rˆole est de servir d’interface entre l’application
souhaitant acc´eder aux donn´ees et les donn´ees. Ces donn´ees sont
g´en´eralement stock´ees dans une base de donn´ees locale SQLite mais aucune
restriction n’est impos´ee sur la mani`ere de stocker les donn´ees. La liste des
contacts est par exemple stock´ee dans une base de donn´ees locales dont l’acc`es
se fait `a travers un composant de type ContentProvider.10 CHAPITRE 2. ETAT DE L’ART ´
Service Un service est un composant effectuant des tˆaches en arri`ere plan. Il
est utilis´e pour effectuer de longue tˆaches internes `a l’application ou `a ex´ecuter
une tˆache `a la demande d’une application. Dans un client File Transfer Protocol,
un service est utilis´e pour envoyer les donn´ees sur le r´eseau `a les recevoir. Cela
´evite de bloquer l’application jusqu’`a la fin de l’envoi.
BroadcastReceiver Un BroadcastReceiver est un composant utilis´e pour
´ecouter les messages en large diffusion sur le syst`eme. Un exemple de ce type de
message est la r´eception d’un nouveau SMS. Lorsqu’un nouveau SMS est re¸cu
par le t´el´ephone, le syst`eme envoie un message en broadcast pour notifier les
diff´erentes applications d’envoi et r´eception de SMS. Ce composant ne poss`ede
aucune interface graphique et n’est pas cens´e ex´ecuter de longues tˆaches.
2.1.2.2 Intents : communication entre composants
Un intent est un message utilis´e par les composants des applications pour
communiquer entre eux. Plus pr´ecis´ement, il est utilis´e pour ex´ecuter que le
destinataire ex´ecute une requˆete `a la demande de l’´emetteur. Le composant
´emettant l’intent et celui la recevant ne font pas forc´ement partie de la mˆeme
application. Un intent a deux usages principaux : lancer un composant Activity
ou Service et diffuser un message dans le syst`eme aux composants BroadcastReceiver.
Nous parlerons alors dans ce cas de broadcast intent. Il existe
diff´erentes m´ethodes fournies par l’API Android lancer un composant Activity
ou Service et diffuser un intent dans le syst`eme. Ces m´ethodes peuvent ˆetre
class´ees selon le type de composant cibl´e. Les m´ethodes utilis´ees pour envoyer
un intent `a un composant de type Activity et Service sont les m´ethodes
dont le nom commencent respectivement par startActivity et startService.
Quant aux m´ethodes utilis´ees pour diffuser un intent `a des composants BroadcastReceiver,
leur noms sont pr´efix´es par sendBroadcast.
Un intent peut avoir plusieurs attributs dont quatre principaux : component
name, action, data et category. Ces attributs servent `a d´efinir le(s) destinataire(s)
de l’intent et les donn´ees `a transmettre. Component name d´esigne le
nom du composant destin´e `a recevoir le message. Si une valeur est associ´ee `a cet
attribut, l’intent est dit explicite. Dans le cas contraire, il est dit implicite et il
appartient au syst`eme de d´efinir le destinataire du message. S’il existe plusieurs
destinataires possibles, le syst`eme demandera `a l’utilisateur de choisir le destinataire
`a qui le message sera envoy´e. Ce m´ecanisme est appliqu´e uniquement
lorsque les destinataires possibles sont de type Activity. S’il s’agit de Service,
le syst`eme fera lui-mˆeme le choix. Dans le code du listing 2.1 par exemple, la
fonction sharePage ´emet un intent afin de partager une URL sans d´efinir le
composant destinataire. A son ´emission, le syst`eme d´eterminera donc une liste `
de destinataires pouvant recevoir l’intent et proposera `a l’utilisateur de choisir
parmi les ´el´ements de cette liste. Pour ce type d’action, Android proposera
au moins dans la liste l’application de messagerie ´electronique, le presse papiers
et le bluetooth. Pour les messages de type broadcast intent, le syst`eme
enverra `a tous les composants Broadcast Receiver ´eligibles. Action est une2.1. SYSTEME ANDROID ` 11
chaˆıne de caract`ere et d´esigne l’action demand´ee par l’application. Data est
une adresse pointant vers la donn´ee `a traiter ou le type de donn´ees `a traiter.
Category d´esigne une ou plusieurs cat´egories de composants cens´es recevoir le
message. Les cat´egories n’ont aucun lien avec les quatre types de composant
d’une application Android. A partir de ces attributs, le syst`eme d´efinit le ou les `
destinataires de l’intent.
Deux autres attributs peuvent s’ajouter aux quatre pr´ec´edents : les flags
et les extras. Le syst`eme ne les utilise pas pour d´efinir le ou les destinaire(s) de
l’intent. Les flags sont des attributs destin´es plus au syst`eme qu’au destinataire
du message. Une analyse rapide de la liste des flags fournis par Android
montre qu’ils ont un usage assez vari´e. Ils servent par exemple `a d´el´eguer une permission
d’acc`es en lecture ou ´ecriture aux donn´ees associ´ees `a l’intent ou `a choisir
des groupes d’applications pouvant recevoir le message. Nous ne donnerons
pas plus de d´etail sur cet attribut dans cette th`ese mais la liste des flags fournis
par Android sont disponibles dans la documentation de la m´ethode setFlags
de la classe Intent [84]. Les extras permettent de transmettre des informations
additionnelles au destinataire du message. Il s’agit d’une liste de couple cl´e valeur.
Dans le code du listing 2.1, l’intent ´emis par la fonction contient quatre
attributs de type extras. Ces attributs servent dans cet exemple `a transmettre
des donn´ees li´ees `a l’URL de la page `a partager : le titre de la page, une icˆone
et une capture d’´ecran.
1 static final void sharePage(Context c, String title, String url,
2 Bitmap favicon, Bitmap screenshot) {
3 Intent send = new Intent(Intent.ACTION_SEND);
4 send.setType("text/plain");
5 send.putExtra(Intent.EXTRA_TEXT, url);
6 send.putExtra(Intent.EXTRA_SUBJECT, title);
7 send.putExtra(Browser.EXTRA_SHARE_FAVICON, favicon);
8 send.putExtra(Browser.EXTRA_SHARE_SCREENSHOT, screenshot);
9 try {
10 c.startActivity(Intent.createChooser(send, c.getString(
11 R.string.choosertitle_sharevia)));
12 } catch(android.content.ActivityNotFoundException ex) {
13 // if no app handles it, do nothing
14 }
15 }
Listing 2.1 – Partage d’une page web grˆace `a un intent implicite. Extrait du
code du navigateur par d´efaut d’Android
Remarque : Afin qu’un composant A puisse recevoir un intent d’un composant
appartenant `a une application autre que la sienne, il faut que ce composant
A soit d´eclar´e avec l’attribut exported dans le fichier AndroidManifest.xml de12 CHAPITRE 2. ETAT DE L’ART ´
son application (section 2.1.2.4). Cet attribut est cependant implicite lorsqu’un
intent filter est d´eclar´e pour ce composant.
2.1.2.3 Intent-filter
Dans la section pr´ec´edente, nous avons pr´esent´e les intents, un type de
message utilis´e par les composants d’une application pour communiquer avec
d’autres composants. Lors de l’´emission de l’intent, le syst`eme calcule `a partir
des attributs associ´es `a l’intent le(s) destinataire(s) du message. Deux
cas peuvent se pr´esenter. Dans le premier cas, l’´emetteur a d´efini explicitement
le destinataire (explicit intent). Le message est donc transmis directement
au destinataire choisi par l’´emetteur. Dans le second cas, l’´emetteur n’a pas
d´efini de destinataire et il appartient au syst`eme de le d´efinir (implicit intent).
Lorsque ce cas se pr´esente, le syst`eme d´efinit la liste des destinataires possibles
grˆace `a un filtre d´eclar´e par chaque application appel´ee intent filter.
Ce dernier d´efinit pour chaque composant quels sont les intents que le composant
souhaite recevoir et est d´eclar´e dans le fichier AndroidManifest.xml
qui accompagne chaque application Android. Nous donnons plus de d´etail sur
le contenu de ce fichier dans la section 2.1.2.4 et nous nous contentons ici
d’expliquer la partie sur les intent filters. Chaque composant d’une application
est d´eclar´ee dans ce fichier et chaque d´eclaration est accompagn´ee
de diverses informations telles que l’intent filter. L’intent filter d´eclare
au syst`eme les intents que chaque composant peut traiter. Ce filtrage est
d´ecrit par une liste d’attributs d’intents que les intents transmis aux composants
doivent avoir. Dans le listing 2.2 par exemple, l’application filtre les
intents que deux de ses composants peuvent recevoir. Le premier composant,
App, ne peut recevoir que les intents dont les attributs action et category
ont respectivement comme valeur associ´ee android.intent.action.MAIN et
android.intent.category.LAUNCHER. Quant au deuxi`eme composant, BillingReceiver,
il ne peut recevoir que des intents auquel l’attribut action est
associ´e `a la valeur com.android.vending.billing.RESPONSE CODE.
2.1.2.4 Android Package
Android Package est la forme sous laquelle une application est propos´ee `a
l’utilisateur. Il s’agit d’une archive, commun´ement appel´ee apk, contenant le
code de l’application et les ressources qu’elle utilise. Nous pr´esentons dans ce
qui suit le contenu principal d’un apk.
AndroidManifest.xml
AndroidManifest.xml est un fichier xml contenant les informations li´ees `a
l’application qui sont n´ecessaires au syst`eme. Il est cr´e´e par le d´eveloppeur de
l’application. Parmi les informations qu’il contient, nous pouvons citer :
— le nom du package de l’application
— le composant Activity `a lancer au lancement de l’application2.1. SYSTEME ANDROID ` 13
— la liste des composants de l’application et les informations qui sont li´es
aux composants (ex : permission pour acc´eder `a un composant Service
sensible, les Intents attendus par les composants de l’application etc)
— les permissions demand´ees par l’application (ex : read sms pour lire les
SMS)
— les permissions d´eclar´ees par l’application
— les biblioth`eques utilis´ees par l’application
— le niveau minimal du SDK Android pour que l’application puisse fonctionner
Le listing 2.2 pr´esente le fichier AndroidManifest.xml d’une version d’Angry
Birds Space. A la deuxi`eme ligne, sont d´efinis l’endroit o`u l’application sera `
install´ee (ici laiss´e au choix du syst`eme) et le nom du package de l’application.
De la ligne 4 `a la ligne 11 sont ensuite list´ees les permissions demand´ees par
l’application. Ici l’application demande par exemple acc`es `a la m´emoire externe,
au r´eseau, aux informations li´ees au t´el´ephone, aux donn´ees de g´eolocalisation
et au syst`eme de payement propos´e par Google.
La ligne 13 d´ecrit comment l’application sera pr´esent´ee dans le menu des
applications une fois install´ee : l’icˆone `a utiliser et le nom `a afficher. Le reste du
fichier liste les composants de l’application et les informations qui y sont li´ees.
L’application a ainsi quatre composants dont deux de type Activity, un de type
Service et un de type BroadcastReceiver. Comme expliqu´e pr´ec´edemment,
filtrer les messages Intent `a destination des composants de l’application est possible.
Dans AndroidManifest.xml, cela se fait via les entr´ees intent-filter.
Ainsi le premier Activity ne recevra que les intents dont l’attribut action a la
valeur android.intent.action.MAIN et la cat´egorie est android.intent.category.LAUNCHER.
Cela signifie que c’est ce composant qui sera lanc´e lorsque
l’utilisateur cliquera sur l’icˆone de l’application dans le menu de son t´el´ephone.
Quant au Broadcast Receiver, il ne r´eagira qu’aux intents dont l’attribut
action vaut com.android.vending.billing.RESPONSE CODE
Classes.dex
Le code de chaque classe d’une application Java standard est stock´e dans des
fichiers .class diff´erents. Sous Android, ce n’est pas le cas. Tout est stock´e dans
un seul et unique fichier qui est classes.dex. De plus, si le code des applications
Java est lui compil´e en bytecode Java, celui des applications Android est lui
compil´e dans un autre format qui est le bytecode dalvik. C’est le contenu de ce
fichier, ou plus pr´ecis´ement une version optimis´ee de celui-ci, qui sera interpr´et´e
par la machine virtuelle Dalvik pour ex´ecuter l’application.
Autres
Un apk contient d’autres entr´ees telles que les r´epertoires META-INF, res,
jni et lib. Le r´epertoire META-INF contient ainsi des fichiers li´es au contrˆole
d’int´egrit´e de l’application et `a l’identification de son d´eveloppeur. Le r´epertoire res
contient les ressources utilis´ees par l’application telles que des images, sons, etc.14 CHAPITRE 2. ETAT DE L’ART ´
Les r´epertoires jni et lib contiennent les biblioth`eques utilis´ees par l’application.
Nous avons pr´esent´e dans cette section le syst`eme Android : le noyau, l’espace
utilisateur en insistant sur les applications et la mani`ere dont ils coop`erent.
Dans la section qui suit, nous pr´esentons les diff´erents m´ecanismes de s´ecurit´e
prot´egeant ce syst`eme.2.1. SYSTEME ANDROID ` 15
1
5
9
21
22
27
32
33
36
37
40
42
43
44
Listing 2.2 – Fichier AndroidManifest.xml d’Angry Birds Space16 CHAPITRE 2. ETAT DE L’ART ´
2.2 S´ecurit´e du syst`eme Android
Nous avons ´ecrit dans la section pr´ec´edente que le noyau d’Android ´etait
un noyau Linux avec un ensemble de modifications et d’ajouts. Une partie des
m´ecanismes de s´ecurit´e offerts par Android proviennent ainsi du syst`eme Linux
auxquels s’ajoutent des m´ecanismes propres `a Android. Ces m´ecanismes ont
pour but de prot´eger les applications les unes des autres, les communications
entre applications et les ressources sensibles disponibles dans le syst`eme.
2.2.1 M´ecanismes issus de Linux
Le noyau d’Android est une version modifi´ee du noyau Linux. Il b´en´eficie
ainsi des m´ecanismes offerts par les noyaux et syst`emes Linux : syst`eme multiutilisateur,
contrˆole d’acc`es (lecture, ´ecriture et ex´ecution) bas´e sur les utilisateurs
et isolation par processus.
2.2.1.1 Syst`eme multi-utilisateur et contrˆole d’acc`es
Android supporte l’existence de plusieurs utilisateurs dans le syst`eme et
utilise le m´ecanisme de contrˆole d’acc`es fourni par Linux. L’acc`es aux diff´erentes
ressources dans le syst`eme est ainsi d´efini par des droits d’acc`es en lecture,
´ecriture et ex´ecution. Ces acc`es sont d´efinis pour trois entit´es : le propri´etaire,
le groupe propri´etaire et les autres.
Il existe un ensemble pr´ed´efini d’utilisateurs par d´efaut sur les syst`emes Android
dont une partie est associ´ee au fonctionnement interne du syst`eme. Parmi
ces utilisateurs nous pouvons citer root qui est l’utilisateur avec les droits les
plus ´elev´es dans les syst`emes de type Linux et Android et l’utilisateur system qui
est associ´e aux diff´erentes ressources n´ecessaires au fonctionnement du syst`eme
tels que les biblioth`eques natives partag´ees. Tout au long de l’ex´ecution du
syst`eme, la liste des utilisateurs peut ensuite ´evoluer. En effet, d’autres utilisateurs
sont cr´e´es `a chaque fois qu’une application est install´ee sur le syst`eme 2
.
Ces utilisateurs ont g´en´eralement des droits restreints `a savoir qu’ils ont uniquement
acc`es aux ressources appartenant `a l’application `a laquelle ils sont
associ´es. Cette restriction ´evite ainsi que les donn´ees de fichier appartenant `a
une application ne soit lues ou modifi´ees par une autre application.
2.2.1.2 Isolation des applications
En plus d’associer des utilisateurs diff´erents `a chaque application, Android
les cloisonne ´egalement en les ex´ecutant dans des processus diff´erents et en leur
attribuant des r´epertoires diff´erents dans lesquels les applications stockent les
donn´ees qu’il manipulent. Les processus associ´es `a chaque application s’ex´ecutent
avec les droits de l’utilisateur associ´e `a l’application et les r´epertoires appartiennent
´egalement `a l’utilisateur auquel l’application est associ´ee. Ce cloison-
2. Il existe une exception `a cette r`egle o`u une application peut demander `a partager le
mˆeme identifiant d’utilisateur que d’autres applications. Voir la section 2.1.2.4.2.2. SECURIT ´ E DU SYST ´ EME ANDROID ` 17
Type Description
normal Valeur par d´efaut des permissions. Elle est automatiquement
accord´ee a toute application la demandant.
dangerous N´ecessite une validation de la part de l’utilisateur
afin d’accorder la permission. Exemple : read sms
pour l’acc`es aux SMS.
signature Permission accord´ee uniquement si l’application
la demandant est sign´ee avec le certificat du
d´eveloppeur ayant d´eclar´ee la permission.
signatureOrSystem Permission accord´ee uniquement aux applications
system, plus pr´ecis´ement celles dans la partition
system, ou `a celles ayant ´et´e sign´ees avec le mˆeme
certificat que l’application ayant d´eclar´ee la permission.
Table 2.1 – Types de permission Android
nement ´evite ainsi qu’une application interf`ere avec l’ex´ecution d’une autre application
ou qu’elle modifie les donn´ees d’une autre application.
2.2.1.3 Chiffrement de la partition de donn´ees
Depuis la version 3.0 d’Android, le syst`eme offre la possibilit´e de chiffrer la
partition data. Cette partition contient l’ensemble des applications du t´el´ephone,
`a l’exception des applications fournies par d´efaut que l’utilisateur ne peut d´esinstaller,
ainsi que les donn´ees qu’elles manipulent. Le chiffrement est r´ealis´e grˆace
au module dm-crypt [15] fourni par le noyau.
2.2.2 M´ecanismes propres `a Android
2.2.2.1 Permissions
Android propose un ensemble de ressources sensibles aux applications install´ees
sur le t´el´ephone (r´eseau, cam´era, syst`eme de g´eolocalisation, bluetooth,
etc.). Pour les utiliser, une application devra d´eclarer les permissions correspondantes.
Une application souhaitant lire les sms devra par exemple avoir la
permission read sms. A l’installation, l’utilisateur valide les permissions de- `
mand´ees par l’application. Pour que l’installation se fasse, il doit toutes les accepter.
Une fois l’application install´ee, plus aucune validation n’est n´ecessaire de
la part de l’utilisateur. La seule exception est l’envoi de messages `a des num´eros
surtax´es o`u l’utilisateur doit valider 3
chaque envoi. Il existe quatre types de
permission que nous r´esumons dans le tableau 2.1.
3. fonctionnalit´e disponible depuis Android 4.218 CHAPITRE 2. ETAT DE L’ART ´
Name: AndroidManifest.xml
SHA1-Digest: 9FiHXTmeVecbFb3enszaSlXIZp0=
Name: res/layout/hello_activity.xml
SHA1-Digest: BJz/aHbKT/Or0LwKJZ/jxN+WzmE=
Name: resources.arsc
SHA1-Digest: khWw+6lJ8dfajIaKkvbCuQ7YYzI=
Name: classes.dex
SHA1-Digest: +aR5lPSRcAvOrX+OhsxELXB1qGg=
Figure 2.2 – Fichier MANIFEST.MF de l’application HelloActivity
2.2.2.2 Signature des applications
Android requiert que chaque application soit sign´ee afin d’ˆetre install´ee sur
le t´el´ephone. Les d´eveloppeurs signent ainsi leur application avec un certificat
dont la cl´e priv´ee leur est propre.
Les applications Android sont sign´ees avec l’outil jarsigner. Il prend en
entr´ee une archive jar ou zip et un certificat. Il donne en sortie l’archive `a
laquelle ont ´et´e ajout´es deux fichiers : un fichier avec l’extension .sf et un autre
fichier avec l’extension .rsa ou .dsa selon les cl´es utilis´ees. L’entˆete du premier
fichier correspond au hash du fichier MANIFEST.MF. Le reste de son contenu
est similaire au fichier meta-inf/manifest.mf qui est pr´esent dans chaque
archive jar. MANIFEST.MF recense pour chaque fichier pr´esent dans l’archive
son nom, son hash et l’algorithme de hachage utilis´e. La figure 2.2 est le fichier
manifest.mf de l’application HelloActivity fourni en exemple avec le kit de
d´eveloppement Android. Pour chaque fichier pr´esent dans l’archive nous avons
son nom, un algorithme de hachage et le hash du fichier. Le fichier .SF contient
les mˆemes types d’information que MANIFEST.MF. Pour chaque fichier pr´esent
dans l’archive nous avons une entr´ee constitu´ee du nom du fichier, un algorithme
de hachage et un hash. Contrairement `a un hash dans MANIFEST.MF, il s’agit
cette fois-ci du hash de l’entr´ee correspondant au fichier dans MANIFEST.MF.
La figure 2.3 liste le contenu du fichier cert.sf de l’application HelloActivity.
Le fichier .rsa lui contient la signature du fichier .sf ainsi que la cl´e publique
correspondant `a la cl´e priv´ee utilis´ee pour la signature.
La signature des applications Android a plusieurs objectifs. Elle sert `a filtrer
les applications qui peuvent ˆetre install´es sur le t´el´ephone. Par d´efaut, seules les
applications provenant de Google Play peuvent ˆetre install´ees sur le t´el´ephone.
Il s’agit plus pr´ecis´ement des applications dont le d´eveloppeur a un certificat
reconnu sur Google Play. Toute application avec une signature inconnue sera
bloqu´ee `a l’installation `a moins que l’utilisateur n’autorise explicitement l’installation
d’applications provenant d’autres plateformes.
La signature identifie ´egalement toutes les applications d’un mˆeme d´eveloppeur.
Si celui-ci est malveillant, il est ainsi possible d’enlever ses applications de Google2.2. SECURIT ´ E DU SYST ´ EME ANDROID ` 19
Signature-Version: 1.0
Created-By: 1.0 (Android SignApk)
SHA1-Digest-Manifest: Qenbz+ZjLsHBpHWbAHMYhLpfies=
Name: AndroidManifest.xml
SHA1-Digest: uziqi6KmjjgyRnooQ7j5ZHIKVTw=
Name: res/layout/hello_activity.xml
SHA1-Digest: who+PyjjYjRHN6maNog494Cr+CE=
Name: resources.arsc
SHA1-Digest: WlDZ0LWZ+zrAmxUTKZuz99hUoZo=
Name: classes.dex
SHA1-Digest: QjwcQAkf4iVckku4qf7kiLRSndo=
Figure 2.3 – Fichier .SF de l’application HelloActivity
Play et des t´el´ephones des utilisateurs.
La signature assure ´egalement que l’application n’a pas ´et´e modifi´ee par
une tierce personne avant d’ˆetre publi´ee. La v´erification se fait `a l’installation
de l’application. Le syst`eme v´erifie que le fichier .SF a bien ´et´e g´en´er´e par le
d´eveloppeur. Il v´erifie ensuite que le fichier MANIFEST.MF n’a pas ´et´e modifi´e
en comparant son empreinte avec celui list´e dans le fichier .SF. Il v´erifie enfin
l’int´egrit´e des fichiers dans l’archive en comparant leur empreite avec les valeurs
list´ees dans le fichier MANIFEST.MF. L’installation est arrˆet´ee si une incoh´erence
est d´etect´ee.
Par d´efaut, les applications Android tournent avec des UIDs diff´erents dans
des processus distincts. Un d´eveloppeur peut cependant vouloir faire tourner
ses applications avec le mˆeme UID ou dans un seul processus. Il suffit pour
cela qu’il le d´eclare dans le fichier AndroidManifest.xml de son application.
Plus pr´ecis´ement, le d´eveloppeur d´eclare un alias d’UID qui sera partag´e s’il
souhaite utiliser le mˆeme UID pour plusieurs de ses applications. S’il souhaite
faire tourner ses applications au sein d’un mˆeme processus, il d´eclare un alias
de nom de processus.
Pour ´eviter que des d´eveloppeurs ne s’attribuent ´egalement le mˆeme UID ou
ne s’attache au processus faisant tourner les applications d’un autre d´eveloppeur,
le syst`eme v´erifie que l’application demandant `a partager le mˆeme UID ou `a
ˆetre ex´ecut´e dans le processus qu’une autre application soit sign´ee par le mˆeme
d´eveloppeur.
2.2.2.3 Analyse des applications
Google analyse r´eguli`erement les applications propos´ees en t´el´echargement
sur Google Play ainsi que celles en instance d’ˆetre install´ees sur les t´el´ephones des
utilisateurs. Si aucune information sur la nature exacte des analyses n’est fournie20 CHAPITRE 2. ETAT DE L’ART ´
par Google, nous savons qu’une analyse statique et dynamique des applications
sont faites pour d´etecter des motifs synonymes de menace dans l’application ou
des comportements malveillants. J. Oberheide et C. Miller ont montr´e dans [78]
que les applications soumises sur Google Play sont ex´ecut´ees dans une machive
virtuelle et qu’il ´etait possible de construire un profil de cette machine.
2.2.2.4 Protection de l’appareil et de ses donn´ees
Android poss`ede un ensemble d’outils destin´es aux d´eveloppeurs du syst`eme.
Parmi ces outils nous pouvons citer adb et fastboot. La commande adb permet
de communiquer avec un ´emulateur Android ou un t´el´ephone. Parmi les
fonctions propos´ees, il y a l’ouverture d’un shell distant sur le t´el´ephone, l’installation
ou la suppression d’application et le transfert de fichier. Pour prot´eger
le t´el´ephone de tout usage malveillant de ces outils, la communication est possible
uniquement si le mode debug est activ´e. Une authentification par cl´e de
l’ordinateur aupr`es du t´el´ephone s’ajoute ´egalement `a cela depuis la version 4.2
d’Android afin de filtrer les machines pouvant communiquer avec le t´el´ephone via
adb. La commande fastboot sert `a effacer/remplacer le contenu des diff´erentes
partitions sur le t´el´ephone. Afin de l’utiliser, l’utilisateur doit dans un premier
temps d´ebloquer cette fonctionnalit´e au d´emarrage et ce processus de d´eblocage
implique la suppression du contenu de la partition data du t´el´ephone. Cette
partition contient les donn´ees de l’utilisateur ainsi que des diff´erentes applications.
L’action de remplacer le contenu d’une partition est souvent d´esigner par
l’expression flasher une image, l’image ´etant le nouveau contenu de la partition.
Un attaquant d´esirant ainsi remplacer une partie des composants logiciels du
syst`eme via fastboot ne pourra ainsi acc´eder aux donn´ees de l’utilisateur.
2.2.2.5 Administration de l’appareil
Android propose depuis sa version 2.2 une API permettant de d´evelopper des
applications afin d’administrer les t´el´ephones [83]. L’API permet de renforcer la
politique sur les mots de passe (ex : taille, expiration et nombre de tentatives),
imposer le chiffrement des partitions, activer / d´esactiver la cam´era (fonctionnalit´e
disponible depuis Android 4.0), demander la cr´eation d’un nouveau mot de
passe, verrouiller le t´el´ephone et remettre le t´el´ephone `a la configuration d’usine.
Nous avons pr´esent´e dans cette section les m´ecanismes de s´ecurit´e d’Android.
Ces m´ecanismes ont pour but de prot´eger les applications, les ressources qu’elles
utilisent et les communications entre ces processus. Ces m´ecanismes ne sont
cependant pas parfaits et nous montrons dans la section qui suit leur limites
ainsi qu’un aper¸cu des menaces que repr´esentent les malware Android.2.3. LIMITES DES MECANISMES DE S ´ ECURIT ´ E ANDROID ´ 21
2.3 Limites des m´ecanismes de s´ecurit´e Android
2.3.1 Abus de permission
Les permissions donnent acc`es aux ressources sensibles du t´el´ephone aux
applications. Si l’utilisateur souhaite installer une application, il doit lui accorder
toutes les permissions qu’elle a demand´ees. Si les permissions filtrent l’acc`es
aux ressources sensibles, il n’existe cependant aucune v´erification au niveau de
l’usage de ces ressources. Seule la confiance aux d´eveloppeurs de l’application
permet de s’assurer qu’il n’y aura aucun abus. Les attaques les plus simples
utilisent ainsi les permissions de mani`ere abusive et c’est le cas de la plupart
des malware ayant pour but de faire fuir des donn´ees sensibles du t´el´ephone. Un
exemple r´ecent est une application ayant ´et´e d´etect´ee comme un logiciel espion 4
qui cible des manifestants `a Hong Kong [26]. L’application demande un ensemble
assez large de permissions pour espionner les utilisateurs des t´el´ephones sur
lesquels l’application est install´ee. Les permissions demand´ees donnent acc`es
aux SMS, aux appels, `a la localisation de l’utilisateur, au micro pour enregistrer
l’utilisateur, etc.
Une application avec trop de permissions peut paraˆıtre suspecte aux yeux
des utilisateurs avertis. Afin de ne pas ´eveiller la suspicion des utilisateurs, une
solution pour les d´eveloppeurs de malware consiste `a utiliser d’autres applications
pr´esentes sur le syst`eme pour mener l’attaque ou `a diviser l’attaque entre
plusieurs applications qui collaboreront pour ex´ecuter l’attaque.
2.3.2 Permissions : attaques par d´el´egation et attaques
par collusion
Une attaque par d´el´egation [49] consiste `a d´el´eguer l’ex´ecution de la tˆache
n´ecessitant une permission que l’application malveillante ne poss`ede pas `a une
autre application qui elle la poss`ede. Par exemple, une application n’ayant pas
la permission de communiquer sur le r´eseau pourrait se servir du navigateur
pour poster des informations ou t´el´echarger des fichiers. Les ´echantillons de
BadNews [91] font par exemple appel au navigateur du t´el´ephone afin de lancer
le t´el´echargement d’applications sur le t´el´ephone. Une attaque par collusion
consiste en une coop´eration entre plusieurs applications pour mener une attaque.
Il n’existe aucun malware utilisant ce type d’attaque `a notre connaissance. Cependant,
J. Boutet et T. Leclerc ont montr´e la faisabilit´e d’une telle attaque
dans [28].
2.3.3 Communication entre composants via les intents
Les intents sont des messages ´echang´es entre les composants des applications
pour transmettre des requˆetes. La possibilit´e d’envoyer des intents
entre deux deux composants de deux applications diff´erentes apporte une surface
d’attaque suppl´ementaire. Dans [34], Chin et al. d´ecrivent en se basant sur
4. Empreinte MD5 :15e5143e1c843b4836d7b6d5424fb4a522 CHAPITRE 2. ETAT DE L’ART ´
leur analyse du fonctionnement des ^ıntents des sc´enarios d’attaques qui pourraient
exploiter cette surface d’attaque afin d’espionner les ´echanges de message
entre application, les bloquer, les modifier, ´elever ses privil`eges et influencer sur
le comportement d’une application.
Interception des messages diffus´es dans le syst`eme
Les broadcast intents sont des messages diffus´es dans tout le syst`eme.
Ils peuvent ainsi avoir un ou plusieurs destinataires. L’une des vuln´erabilit´es
qu’introduit ce type de communication est la possibilit´e d’observer les informations
diffus´ees dans le syst`eme et ´eventuellement les intercepter, bloquer
ou modifier. Lorsqu’une application diffuse un broadcast intent, elle d´efinit
un ensemble d’attributs qui permettent au syst`eme d’identifier les composants
BroadcastReceiver pr´esents dans le syst`eme qui attendent ce type de message.
Pour observer les messages attendus par le composant BroadcastReceiver
d’une application, il suffit ainsi `a une application malveillante de d´eclarer un
composant du mˆeme type avec le mˆeme intent-filter. Pour observer les
messages re¸cus par le composant BillingReceiver d´eclar´e dans le listing 2.2,
une application malveillante n’a qu’`a d´eclarer un composant du mˆeme type en
pr´ecisant que ce composant n’accepte que les intents avec un attribut action
dont la valeur associ´ee est com.android.vending.billing.RESPONSE CODE.
Un broadcast intent peut ˆetre transmis de mani`ere simultan´e `a tous les
destinataires ou en suivant un ordre. Dans le cas de ce dernier, l’intent est
transmis d’un composant `a l’autre dans un ordre d´efini par le syst`eme. Chaque
composant BroadcastReceiver peut ainsi modifier ou bloquer les informations
transmises avant que le message ne soit transmis au prochain destinataire. Si une
application malveillante se trouve au milieu de la chaˆıne de transmission, elle
peut donc modifier le contenu de l’intent ´emis et envoyer de fausses donn´ees
aux composants en attente du message. Elle peut ´egalement d´ecider de ne pas
faire suivre le message et empˆecher les autres composants de le recevoir.
D´etournement des intents `a destination des composants Activity et
Service
Lorsqu’une application ´emet un intent, il peut soit d´efinir explicitement le
destinataire soit laisser le syst`eme le d´efinir `a sa place. Dans le deuxi`eme cas,
l’´emetteur n’a aucune garantie sur l’identit´e du destinataire ce qui donne ainsi
la possibilit´e de d´etourner les messages du destinataire l´egitime. Une application
malveillante souhaitant intercepter un implicit intent n’a donc qu’`a d´eclarer
un composant ayant un intent filter correspondant `a l’intent qu’il souhaite
d´etourner. Par exemple, une application malveillante souhaitant d´etourner le
partage de page effectu´ee dans le listing 2.1 n’a qu’`a d´eclarer un composant
Activity avec un intent filter correspondant aux attributs de l’intent `a
intercepter : un attribut action et un attribut data auxquels sont associ´es
respectivement les valeurs ACTION SEND et text/plain.2.3. LIMITES DES MECANISMES DE S ´ ECURIT ´ E ANDROID ´ 23
Si le d´etournement est th´eoriquement possible, il n’a en r´ealit´e qu’une probabilit´e
de succ`es. Lorsqu’il existe plusieurs destinataires possibles de l’intent, un
choix qui est ind´ependant de l’application malveillante est effectu´e. Si l’intent
a ´et´e ´emis pour un composant de type Activity, le syst`eme demande `a l’utilisateur
de choisir le destinataire parmi la liste des applications pouvant recevoir
l’intent. Si l’intent a ´et´e ´emis pour un composant de type Service, le syst`eme
effectuera lui-mˆeme le choix et ce choix est effectu´e de mani`ere al´eatoire.
Vol/abus des permissions
Nous avons ´ecrit en section 2.1.2.2 que les intents pouvaient ´egalement servir
`a transmettre des permissions pour acc´eder `a des donn´ees au destinataire du
message. Positionner le flasg FLAG GRANT WRITE URI PERMISSION donne par
exemple l’acc`es en lecture aux donn´ees li´ees `a l’intent au destinataire du message.
Une application malveillante interceptant des intents transmettant des
permissions peut ainsi abuser de ces permissions et voler ou modifier les donn´ees
auxquelles les permissions donnent acc`es.
Intents malveillants
Le but de cette attaque est d’envoyer des requˆetes malveillantes `a traiter par
un composant cible. Un composant qui peut recevoir des intents d’autres applications
n’est pas seulement expos´e aux applications que son d´eveloppeur pensait
servir mais `a toutes applications sur le syst`eme. Cette exposition `a toutes les
applications du syst`eme offre ainsi une surface d’attaque aux applications malveillantes
qui elles aussi peut demander au composant de traiter une requˆete,
mˆeme si cette requˆete est malicieuse. Les navigateurs web sous Android ont par
exemple un composant Activity qui ouvre les URL `a la demande d’autres applications.
Cette fonctionnalit´e peut ainsi ˆetre d´etourn´ee par une application qui
n’a pas acc`es au r´eseau afin de faire fuir des donn´ees ou t´el´echarger des fichiers.
Pour cela l’application malveillante ´emettra un intent `a destination du navigateur
afin que ce dernier ouvre une adresse web. Les ´echantillons de BadNews [91]
utilisent par exemple cette approche afin de t´el´echarger des applications sur le
t´el´ephone.
2.3.4 Failles logicielles : ´el´evation de privil`ege
Comme tout programme, le syst`eme Android a ´egalement des failles logicielles.
Exploiter certaines d’entre elles permet d’´elever les privil`eges d’une application
et ainsi ex´ecuter des op´erations sensibles que nous ne pouvions faire.
Obtenir les droits root permet par exemple de modifier le contenu de la partition
system sous Android pour installer des applications syst`eme ou les remplacer.
Le noyau Android ´etant bas´e sur un noyau Linux, il h´erite ainsi de ses
vuln´erabilit´es. Certaines d’entre elles [5, 4] ont par exemple ´et´e exploit´ees obtenir
des acc`es root sur les t´el´ephones.24 CHAPITRE 2. ETAT DE L’ART ´
Des failles permettant d’´elever les privil`eges des applications existent ´egalement
dans l’espace utilisateur. D’apr`es les travaux de Y. Zhou et X. Jiang [113], six
vuln´erabilit´es permettant d’´elever les privil`eges des applications existaient au
moment de leur analyse (voir tableau 2.2) et quatre d’entre elles ´etaient effectivement
utilis´ees par les malware pour ´elever leurs privil`eges : Asroot [1],
exploid [31], RATC / Zimperlich [93] et GingerBreak [32]. Plus r´ecemment,
J. Forristal a pr´esent´e `a la Black Hat 2013 une vuln´erabilit´e [51] concernant la
v´erification des signatures des applications Android `a l’installation. La vuln´erabilit´e
permet d’installer une version modifi´ee d’une application dont la signature reste
celle de la version originale. Si la vuln´erabilit´e ne permet pas d’obtenir les droits
root (aucune application ne tourne avec l’UID root), elle rend cependant caduque
les protections offertes par la signature en section 2.2.2. Un d´eveloppeur
malveillant peut faire ex´ecuter son code avec les mˆemes droits que l’application
originale qu’il a modifi´ee. Il peut ´egalement faire tourner son code dans le
mˆeme processus ou avec le mˆeme UID qu’une autre application. S’il n’est pas
possible d’obtenir les droits root, il est cependant possible d’obtenir les droits
des applications system. Ces applications ont acc`es `a plus de permissions que
les applications tierces et de plus sont persistantes sur le syst`eme. Un utilisateur
ne peut les enlever sans avoir un acc`es root sur son t´el´ephone.
Bien que Google mette `a jour r´eguli`erement le code d’Android, les constructeurs
eux mettent plus de temps `a proposer des mises `a jour pour leur t´el´ephone.
La fenˆetre d’exploitation des vuln´erabilit´es est ainsi bien plus large que sur les
ordinateurs.
Nous avons pr´esent´e dans cette section, les limitations des m´ecanismes de
s´ecurit´e sous Android. Ces limitations peuvent ˆetre class´ees en trois groupes. Le
premier groupe concerne les limites de la s´ecurit´e offerte par les permissions. Le
second concerne les risques introduits par les communications entre composants
via les intents. Le troisi`eme groupe concerne les failles logicielles dans le code
d’Android qui permettent d’´elever les privil`eges des applications dans le syst`eme.
Dans la section suivante, nous pr´esentons les malware Android et les menaces
qu’ils repr´esentent.
2.4 Malware Android
2.4.1 D´efinitions
Nous appelons malware un programme ou un code dont le but est de nuire
`a un syst`eme donn´e. Dans le reste du document nous ferons souvent usage des
termes ´echantillon de malware et famille de malware. Un ´echantillon d’un malware
est une application, comprendre ici application Android correspondant `a
un fichier apk, qui contient ce malware. Quant `a une famille de malware, il s’agit
de l’ensemble des ´echantillons d’un malware. Analyser un malware revient ainsi2.4. MALWARE ANDROID 25
`a analyser un ou plusieurs de ses ´echantillons afin d’extraire des informations
li´ees au malware et d´etecter un malware revient `a d´ecider si une application
donn´ee est un ´echantillon d’un malware.
Les premiers travaux qui ont consist´e `a dresser un bilan des menaces que
repr´esentent les malwares Android sont les travaux de Y. Zhou et X. Jiang
dans [113]. Leurs travaux sont bas´es sur l’analyse de plus de 1200 ´echantillons
de malware qu’ils ont collect´e de 2010 `a 2011. Dans ce qui suit, nous pr´esentons
les r´esultats de cette analyse et l’enrichissons avec une analyse plus r´ecente bas´ee
sur les menaces que repr´esentent les malware Android en 2013.
2.4.2 Malwares Android : 2010 `a 2011 [113]
M´ethode d’infection
Pour infecter les t´el´ephones des utilisateurs, les d´eveloppeurs de malware
ajoutent leur code malveillant `a des applications existantes et proposent leur
version modifi´ee sur des plateformes de t´el´echargement : Google Play ou toute
autre plateforme alternative. Les applications infect´ees sont pr´esent´ees comme
une version gratuite d’une application payante ou des versions avec plus de fonctionnalit´es.
86% des ´echantillons r´ecolt´es sont ainsi des applications originales
auxquelles un code malveillant a ´et´e ajout´e. Le type d’application infect´ee est
vari´e : application payante, jeux populaires, outils tels que des mises `a jour de
s´ecurit´e ainsi que des applications pour adultes. Un des ´echantillons de DroidKungFu2
est par exemple une version modifi´ee d’une application simulant un
scanner d’empreinte pour d´everrouiller le t´el´ephone. En arri`ere plan, le code
malveillant exploite une vuln´erabilit´e [92, 93] pour ´elever ses privil`eges et installer
des binaires sur le t´el´ephone `a l’insu de l’utilisateur.
Tout le code malveillant ne se trouve pas forc´ement ajout´e `a l’application
originale. Certains ´echantillons ne contiennent ainsi qu’une partie du code malveillant
dont le reste sera r´ecup´er´e `a l’ex´ecution. Ce dernier peut ˆetre stock´e
en tant que ressource de l’application ou sur un serveur distant que l’application
infect´ee devra t´el´echarger. L’avantage ´etant que le code malveillant ne
pourra ˆetre d´etect´e lors de la soumission de l’application sur les plateformes de
t´el´echargement. Les ´echantillons d’AnserverBot [112] ont ainsi une charge cach´ee
en tant qu’image dans les ressources des applications et r´ecup`erent ´egalement
une autre application malveillante sur un serveur distant.
D´eclenchement du code malveillant
Le d´eclenchement du code malveillant ne se fait pas forc´ement d`es le lancement
de l’application. Le code malveillant peut attendre des ´ev`enements
sp´ecifiques tels que l’arriv´ee d’un sms ou l’´ecoulement d’un certain laps de temps
avant de s’ex´ecuter. Parmi les ´ev`enements les plus utilis´es pour d´eclencher le
code malveillant, nous pouvons citer la fin d’initialisation au d´emarrage du26 CHAPITRE 2. ETAT DE L’ART ´
Programme
vuln´erable
Exploit Date Malware les
utilisant
Noyau Asroot 2009/08/16 Asroot
init (ď 2.2) Exploid 2010/07/15 DroidDream,
zHash, DroidKungFu*
adbd (ď 2.2.1)
zygote
(ď 2.2.1)
RATC / Zimperlich 2010/08/21
2011/02/24
DroidDream,
BaseBridge,
DroidKungFu,
DroidDeluxe,
DroidCoupon
ashmem
(ď 2.2.1)
KillingInTheNameOf 2011/01/06 Aucun
vold (ď 2.3.3) GingerBreak 2011/04/21 GingerMaster
libsysutils
(ď 2.3.6)
zergRush 2011/10/10 Aucun
Table 2.2 – Exploits root connus et leur usage par les malware Android de
2010 `a 2011
syst`eme. Quand le syst`eme est prˆet `a ex´ecuter des applications Android, il
le signale en envoyant un intent avec le message boot completed `a tous
les composants BroadcastReceiver `a l’´ecoute cet ´ev`enement. Les autres messages
´ev`enements servant de d´eclencheur sont la r´eception de message, les appels,
les ´ev`enements li´es aux applications (ex : ajout, suppression, mise `a jour
et red´emarrage), l’´etat de la batterie, l’´etat de la connectivit´e r´eseau, et des
´ev`enements syst`emes (ex : carte sim remplie, changement de clavier). Le d´eveloppeur
du code malveillant ajoute un composant de type BroadcastReceiver pour intercepter
l’un de ces ´ev`enements et ex´ecuter par la suite le code malveillant.
Actions effectu´ees
Les actions effectu´ees par les codes malveillants peuvent ˆetre r´eparties dans
quatre groupes : ´el´evation de privil`ege, contrˆole `a distance, charge financi`ere et
vol de donn´ees.
Comme ´evoqu´e en section 2.2.2, Android poss`ede des vuln´erabilit´es qui sont
exploit´ees par les d´eveloppeurs malveillants pour effectuer des op´erations sensibles.
Le tableau 2.2 montre d’ailleurs une tendance `a utiliser les exploits
exploid [31], RageAgainstTheCage [92] et Zimperlich [93] afin ´elever les privil`eges
des applications malveillantes durant l’attaque. Le but de cette ´el´evation
de privil`eges est d’effectuer des op´erations sensibles telles que monter la partition
system avec l’option d’´ecriture pour y installer de nouvelles applications.
1172 ´echantillons soit 93% des ´echantillons analys´es sont contrˆolables `a distances.
Plus pr´ecis´ement, 1171 ´echantillons utilisent le protocole HTTP pour recevoir
des commandes des serveurs de commande et contrˆole C&C. Les adresses2.4. MALWARE ANDROID 27
des serveurs sont stock´ees en clair ou chiffr´ees dans le code.
En dehors des ´el´evations de privil`eges et communication avec des serveurs
de C&C, les ´echantillons analys´es peuvent imputer des charges financi`eres `a
l’utilisateur. Android tournant principalement sur les smartphones, les applications
ont ainsi acc`es aux fonctions d’appels et de sms. 4.4% des ´echantillons
´etudi´es envoient ainsi des messages `a des num´eros surtax´es. Les num´eros sont
soit stock´es en dur dans le code de l’application soit r´ecup´er´es `a partir des
serveurs de C&C.
En plus des actions pr´ec´edentes, les malware r´ecup`erent ´egalement les donn´ees
sensibles sur le t´el´ephone. Les donn´ees cibl´ees sont principalement les sms, la
liste de contact, et les informations sur le compte de l’utilisateur. SndApps [62]
collecte par exemple les adresses courriel de l’utilisateur et les envoie vers un
serveur distant.
Evolution des malware ´
Si les premiers malware Android sont simples, l’analyse effectu´ee dans [113]
montre que les techniques utilis´ees tendent `a se complexifier : charge utile, techniques
contre l’analyse d’application, serveurs C&C.
Tout le code malveillant est int´egr´e dans une mˆeme application dans les
premiers malware. L’analyse des ´echantillons r´ecolt´es montre une tendance `a le
diviser, mettre une partie dans l’application servant `a l’infection et le reste des
morceaux dans une ou plusieurs charges utiles. Ces charges sont int´egr´ees directement
dans l’application ayant servi `a infecter le t´el´ephone ou t´el´echarger et
apr`es l’installation de l’application. Les ´echantillons de DroidKungFu ont ainsi
deux charges utiles cach´ees en tant que ressources des applications infect´ees qui
seront install´ees dans la partition system une fois l’´echantillon lanc´e. L’installation
de ces charges sur le t´el´ephone offre une pr´esence constante sur le t´el´ephone
mˆeme si la premi`ere application est enlev´ee du t´el´ephone. De plus, si les applications
sont install´ees sur la partition syst`eme, il n’existe aucun moyen pour
l’utilisateur de les enlever sans avoir les droits root sur le t´el´ephone.
Afin d’´eviter toute d´etection, les d´eveloppeurs de malware utilisent diverses
techniques telles que le chiffrement des charges utiles, le chiffrement de certaines
valeurs utilis´ees par le malware, l’usage de techniques d’obfuscation de
code et l’usage de code natif. Le chiffrement permet de cacher la nature exacte
des donn´ees manipul´ees (ex : adresses des serveur de C&C) par l’application
et r´eduit ainsi la possibilit´e de d´etection. Les d´eveloppeurs de DroidKungFu1
chiffrent ainsi les charges utiles de leur malware afin que leur malware ne soit
d´etect´e facilement. Si une cl´e de chiffrement diff´erente est utilis´ee par chaque
´echantillon, l’analyse sera encore plus compliqu´ee. Certains d´eveloppeurs de
malware obfusquent ´egalement leur code afin de complexifier son analyse [39].
Ils modifient par exemple le nom des m´ethodes et des classes Java de l’application.
Il est cependant `a noter que le kit de d´eveloppement Android (Android
SDK) contient un outil fournissant le mˆeme type de service [87]. L’usage de code
natif complexifie ´egalement l’analyse des applications. En effet, la plupart des
outils d’analyse d’application Android se concentrent uniquement sur le code28 CHAPITRE 2. ETAT DE L’ART ´
´ecrit en Java car c’est le langage principal pour d´evelopper une application Android.
En utilisant du code natif, les d´eveloppeurs de malware se donnent ainsi
la possibilit´e de cacher une partie du code malveillant durant l’analyse.
Certains malware int`egrent ´egalement des modules cens´es pr´evenir toute
d´etection. Les ´echantillons d’AnserveBot analysent ainsi son environnement
d’ex´ecution `a la recherche d’antivirus pour Android. De plus, ces ´echantillons
tirent ´egalement profit du chargement dynamique de code [36]. Le code des
applications Android se trouve dans le fichier classes.dex de leur apk. Ce
m´ecanisme permet de charger du code en dehors de ce fichier et ce de mani`ere
dynamique rendant l’analyse de l’application plus difficile. D’autres malwares
v´erifient ´egalement que le code n’a pas ´et´e modifi´e pour d´etecter toute tentative
d’analyse du code. AnserveBot v´erifie par exemple l’int´egrit´e de son code avant
de lancer le code malveillant.
Enfin, l’analyse montre ´egalement l’usage des serveurs de C&C afin de contrˆoler
le comportement des ´echantillons de malware. Le comportement exact des
premiers malware sont dict´es `a l’avance par leur d´eveloppeur. Durant leur analyse,
Y Zhou et X Jiang ont cependant constat´e que dans le cas de certains
malware, leur comportement ´etait plutˆot dict´e par un serveur distant. Le malware
se connectait ainsi p´eriodiquement au serveur qui lui envoyait par la suite
l’action qu’il devait ex´ecuter. Sur les 49 malwares ´etudi´es, 27 utilisent ainsi un
serveur de C&C pour recevoir les commandes `a ex´ecuter sur le t´el´ephone infect´e.
L’usage de telles approches permet aux d´eveloppeurs de garder une flexibilit´e
sur les diff´erentes actions `a ex´ecuter et les faire ´evoluer en cas de besoin.
2.4.3 Malwares Android en 2013
Si les travaux de [113] pr´esent´es pr´ec´edemment concernent uniquement les
malwares de 2010 `a 2011, la r´ecente analye de V. Chebyshev et R. Unuchek
dans [33] montre une continuit´e dans les types d’action men´ee par les malware.
La distribution des malwares se fait toujours via les plateformes de t´el´echargement
ou les serveurs de C&C. A cela s’ajoute, l’usage des techniques telles `
que le drive-by download qui consiste `a faire t´el´echarger automatiquement puis
installer une application au t´el´ephone lorsque l’utilisateur visite une page web.
L’usage de techniques contre les protections anti-malware s’intensifie ´egalement.
L’´etude montre ainsi que les d´eveloppeurs de malware continuent leur
investissement dans les diverses techniques d’obfuscation de code. Un outil commercial
d’obfuscation de code aurait ´et´e par exemple utilis´e sur Opfak.bo et
Obad.a [98]. Obad.a est consid´er´e comme le malware Android le plus complexe
`a ce jour. Parmi les caract´eristiques de ce malware, nous pouvons citer l’introspection,
le chiffrement de chaine des chaines de caract`eres, l’exploitation de
vuln´erabilit´es qui affectent le syst`eme Android et dex2jar qui est un outil utilis´e
pour analyser les applications Android. Plus pr´ecis´ement, cet outil transforme
le bytecode dalvik en bytecode Java permettant par la suite d’obtenir un code
Java “´equivalent“. Selon wikibooks [12], “la r´eflexion permet l’introspection des
classes, c’est-`a-dire de charger une classe, d’en cr´eer une instance et d’acc´eder
aux membres statiques ou non (appel de m´ethodes, lire et ´ecrire les attributs)2.4. MALWARE ANDROID 29
sans connaˆıtre la classe par avance“. Le listing 2.3 pr´esente un bout code en
Java utilisant la r´eflexion et son ´equivalent sans r´eflexion. . La deuxi`eme ligne
initialise la variable foo en une instance de la classe Foo et est ´equivalente `a
la septi`eme ligne. La troisi`eme et la quatri`eme lignes initialisent r´ecup`erent la
m´ethode hello de foo et l’invoque. Elles correspondent `a la huiti`eme ligne.
1 // Avec reflexion
2 Object foo = Class.forName("complete.classpath.and.Foo").
3 newInstance();
4 Method m = foo.getClass().getDeclaredMethod("hello",
5 new Class[0]);
6 m.invoke(foo);
7
8 // Sans reflexion
9 Foo foo = new Foo();
10 foo.hello();
Listing 2.3 – Exempe de code Java avec et sans r´eflexion
L’usage des vuln´erabilit´es reste toujours d’actualit´e au niveau des malware.
Les raisons principales de cet usage est la n´ecessit´e d’effectuer des actions
sensibles sans validation de l’utilisateur (ex : installation d’application sur le
t´el´ephone) ou le maintien d’une pr´esence pertinente du malware sur l’appareil
(ex : installation d’une application dans la partition system afin d’empˆecher
sa d´esinstallation 5
). Parmi les vuln´erabilit´es ´emun´er´es par les auteurs, il y a
la vuln´erabilit´e Master Key [51] et celle li´ee aux applications avec les droits
d’administration sur le t´el´ephone.
La vuln´erabilit´e Master Key permet de modifier une application existante
sans que la modification ne soit d´etect´ee lors de la v´erification de la signature de
l’application (section 2.2.2.2). Pour exploiter cette vuln´erabilit´e, le d´eveloppeur
malveillant ajoute de nouveaux fichiers `a l’apk tel que chaque nouveau fichier
ait le mˆeme nom qu’un fichier existant dans l’apk d’origine. Il peut par exemple
ajouter un autre fichier nomm´e classes.dex. Une fois les nouveaux fichiers
ajout´es, il publie l’apk modifi´e tout en gardant la signature de l’apk d’origine.
A cause de la vuln´erabilit´e, le syst`eme ne remarque pas l’existence des doublons `
dans l’apk et v´erifie uniquement l’int´egrit´e des fichiers qui ´etaient pr´esents dans
l’apk d’origine tandis qu’`a l’installation il installera les fichiers ajout´es par le
d´eveloppeur malveillant. Cette vuln´erabilit´e a deux cons´equences directes. La
premi`ere est le vol de l’identit´e des d´eveloppeurs dont l’application a ´et´e modifi´ee.
En gardant la signature de l’application originale, le d´eveloppeur malveillant
se cache derri`ere l’identit´e des d´eveloppeurs des applications modifi´ees.
Le risque pour ces derniers est d’ˆetre accus´e `a tord comme ´etant malveillant et
voir toutes leurs applications supprim´ees des plateformes de t´el´echargement tels
5. Un utilisateur ne peut d´esinstaller les applications dans la partition system car cette
partition est mont´ee en lecture seule30 CHAPITRE 2. ETAT DE L’ART ´
que Google Play. La deuxi`eme cons´equence de cette vuln´erabilit´e est la possibilit´e
de contourner toutes les m´ecanismes de s´ecurit´e bas´ees sur les signatures
de applications. En plus de servir `a la v´erification de l’int´egrit´e des applications
`a leur installation, les signatures servent ´egalement `a appliquer des contraintes
sur certaines demandes des applications. Ils peuvent par exemple servir `a restreindre
les applications `a qui une permission peut ˆetre accord´ee (tableau 2.1)
ou les applications qui ont le droit de partager le mˆeme utilisateur. En gardant
la signature de l’application qu’il a modifi´ee, le d´eveloppeur malveillant s’assure
ainsi que sa version modifi´ee de l’application ait les mˆemes privil`eges que
l’application d’origine.
La deuxi`eme vuln´erabilit´e permet de garder une pr´esence persistante sur le
t´el´ephone grˆace aux droits d’administration. Lorsqu’une application obtient les
droits d’administration sur le t´el´ephone, il devient impossible pour l’utilisateur
de lui r´evoquer ces droits ou le d´esinstaller. Si jamais l’utilisateur tentait de
r´evoquer les droits d’administration, le syst`eme se contentait de masquer le fait
que l’application poss`ede ces droits mais ne les r´evoquait pas. L’application
reste ainsi install´ee sur le t´el´ephone avec les droits d’administration sans que
l’utilisateur ne soit au courant.
Si les diff´erents types d’attaque pr´esent´es dans [113] restent toujours d’actutait´e,
l’analyse montre cependant une tendance pour les attaques ayant un
impact financier sur l’utilisateur. Aux applications abusant des services de SMS
en envoyant des messages `a des num´eros surtax´es s’ajoutent ainsi les applications
se faisant passer pour des applications bancaires afin de voler les donn´ees
bancaires des utilisateurs telles que leur num´ero de compte.
2.5 Renforcement de la s´ecurit´e sous Android
2.5.1 Protection des ressources sensibles
2.5.1.1 TaintDroid
Dans [46], Enck et al. pr´esentent TaintDroid une version modifi´ee d’Android
capable de suivre les flux d’information dans le syst`eme. Le but de leur travail
est d’´etudier si les applications Android font fuir des donn´ees sensibles vers des
entit´es distantes. Pour cela, ils s´electionnent un ensemble d’informations qu’ils
jugent sensibles telles que la liste de contact et les donn´ees de g´eolocalisation
et observent comment elles se propagent dans le syst`eme. Ils ont analys´e 30 des
applications les plus populaires de Google Play et ont montr´e que 2{3 d’entre
elles faisaient fuir des informations sensibles vers des serveurs distants.
Pour suivre les flux d’information dans le syst`eme, ils utilisent une m´ethode
dite de tainting qui consiste `a marquer les informations sensibles afin d’en suivre
la propagation. Chaque fois qu’une information sensible se propage, le conteneur
destination re¸coit la marque de l’information sensible pour caract´eriser son nouveau
contenu. Dans TaintDroid, le suivi de flux d’information se fait `a diff´erents
niveaux : `a l’int´erieur de l’application, entre les applications et entre applications
et fichiers du syst`eme. Pour suivre les flux `a l’int´erieur des applications, Enck et2.5. RENFORCEMENT DE LA SECURIT ´ E SOUS ANDROID ´ 31
al. ont modifi´e la machine virtuelle Dalvik. Lorsqu’une application Android est
ex´ecut´ee, son code est interpr´et´e par la machine virtuelle Dalvik. TaintDroid suit
ainsi les flux d’information entre les conteneurs d’information que la machine
Dalvik utilisent. Ces conteneurs sont les variables locales d’une m´ethode, ses
param`etres, les champs statiques d’une classe, les champs des instances d’une
classe et les tableaux. A chaque fois qu’une instruction d´ecrivant un flux d’in- `
formation explicite entre deux ou plusieurs conteneurs est interpr´et´ee par la
machine virtuelle Dalvik, TaintDroid consid`ere que le conteneur destination du
flux contient le m´elange des informations provenant des conteneurs source. Par
exemple, l’affectation `a la variable vs de la valeur de la variable vd une mise `a
jour de la marque associ´ee vs. Lorsque cette affectation est interpr´et´ee par la
machine virtuelle Dalvik, TaintDroid consid`ere que vs les informations contenues
dans vs ont ´et´e remplac´ees par celles dans vd et TaintDroid affecte ainsi la
marque associ´ee `a vd `a vs.
Le suivi de flux d’information entre les applications et entre une application
et un fichier est plus simple. Le suivi de flux d’information entre les applications
est assez trivial. Comme il existe un ensemble de classes et de m´ethodes
Java fourni par Android pour impl´ementer les m´ecanismes de communication,
TaintDroid se contente de marquer les objets avec un contenu sensible quand ils
sortent d’une application et `a marquer le destinataire d’une information provenant
d’une application externe `a l’application. Les marques de chaque conteneur
sont stock´es dans une m´emoire adjacente au conteneur et propag´ees `a chaque
fois que ces conteneurs sont envoy´ees vers d’autres application. Quant aux flux
d’information entre une application et un fichier, TaintDroid utilise les attributs
´etendus. Les attributs ´etendus sont des fonctionnalit´es offertes par les syst`emes
de fichier tels que ext2/ext3/ext4 (syst`eme de fichier utilis´e principalement sur
Android) permettant de stocker des m´eta-donn´ees li´ees aux fichiers. TaintDroid
stocke ainsi dans les attributs ´etendus d’un fichier les marques des informations
sensibles qu’il contient. Lorsqu’une application acc`ede `a un fichier, TaintDroid
met `a jour la marque associ´ee au fichier (´ecriture) ou `a la variable recevant le
contenu du fichier (lecture).
Si TaintDroid est capable de suivre les flux d’information dans une application,
entre les applications Android et entre une application et un fichier,
sa port´ee est cependant limit´ee aux applications ´ecrites en Java. En effet, le
m´ecanisme de suivi de flux dans TaintDroid repose principalement sur la machine
virtuelle Dalvik. Or, il est possible d’utiliser du code natif sous Android.
Cela se fait, soit en utilisant le m´ecanisme de JNI [86] soit en ex´ecutant une
application compil´ee en code natif. Lorsque ces cas se pr´esentent, TaintDroid
devient ainsi incapable de suivre les flux d’information caus´es par le code natif
car il n’est pas interpr´et´e par la machine virtuelle Dalvik.
2.5.1.2 Contrˆole d’acc`es aux ressources sensibles `a l’ex´ecution : MockDroid
et AppFence
Sous Android, l’utilisateur valide les permissions `a l’installation des applications.
A l’ex´ecution, il n’a plus aucun contrˆole sur les acc`es et ne peut que faire `32 CHAPITRE 2. ETAT DE L’ART ´
confiance aux applications pour ne pas utiliser de mani`ere malintentionn´ee les
ressources et donn´ees auxquelles elles ont acc`es. Afin de palier cette limite d’Android,
MockDroid [24] et AppFence [59] proposent `a l’utilisateur de contrˆoler
l’acc`es effectu´e par les applications durant leur ex´ecution. Lorsqu’une application
souhaite acc´eder `a une donn´ee ou ressource sensible, le syst`eme demande
une validation de la part de l’utilisateur. L’acc`es aux informations et ressources
sensibles se font via des fonctions de l’API Android. Les auteurs de MockDroid
et d’AppFence ont ainsi modifi´e Android afin d’intercepter les appels `a ces fonctions
et introduire le m´ecanisme de validation lors de leur appel. Selon l’information
ou la ressource demand´ee par l’application, si l’utilisateur lui en refuse
l’acc`es, le syst`eme soit lui notifiera son indisponibilit´e ou son inexistence, soit
lui renverra une donn´ee factice. Les informations et ressources sensibles dont
l’acc`es est renforc´e sont les donn´ees de g´eolocalisation, la liste de contact, les
informations li´ees `a l’identit´e du t´el´ephone, les SMS, l’envoi de message de type
broadcast intent (MockDroid), les journaux d’´ev`enement (AppFence) et les
donn´ees de navigation internet (AppFence).
En cas de refus d’un acc`es `a une information sensible, MockDroid et AppFence
renvoient une donn´ee vide `a l’application. L’exception est l’acc`es aux
donn´ees identifiant l’appareil. En cas de refus, le syst`eme renverra une donn´ee
factice `a l’application. Dans AppFence l’exception s’´etend aux donn´ees de g´eolocalisation
o`u le syst`eme enverra les mˆemes coordonn´ees factices `a chaque fois.
En cas de refus d’un acc`es r´eseau, le syst`eme simule l’indisponibilit´e du r´eseau.
AppFence fait par exemple croire `a l’application que le t´el´ephone est en mode
avion.
Si AppFence et MockDroid ont les mˆemes objectifs et approches, la diff´erence
entre les deux r´eside dans le fait qu’AppFence propose ´egalement un meilleur
m´ecanisme pour prot´eger les fuites de donn´ees vers des serveurs distant. Pour
empˆecher toute fuite de donn´ee, MockDroid simulera l’indisponibilit´e du r´eseau
`a toute tentative de connexion. AppFence propose une approche plus fine en
demandant uniquement une validation quand une donn´ee sensible est susceptible
de quitter le syst`eme. Pour ce faire, AppFence int`egre le m´ecanisme de suivi de
flux d’information impl´ement´e dans TaintDroid [46]. TaintDroid est capable de
suivre les flux d’information au sein d’une application, entre les applications et
entre les applications et les fichiers. Ainsi AppFence ne demande la validation
de l’utilisateur uniquement quand les flux observ´es au sein d’une application
indiquent une fuite d’information vers l’ext´erieur. Si c’est le cas et en cas de
refus de l’utilisateur, AppFence bloquera l’envoi en simulant l’indisponibilit´e du
r´eseau ou omettra l’envoi des donn´ees sensibles tout en faisant croire le contraire
`a l’application.
2.5.1.3 Protection de contenu : Porscha
Dans [79], Ongtang et al. proposent un m´ecanisme de protection de contenu
pour Android du nom de Porscha. Porscha permet de lier des donn´ees sensibles
`a un appareil et un ensemble d´efini d’applications. A l’´emission d’un contenu `
sensible, sa source lui associe une politique de s´ecurit´e qui d´efinit les destina-2.5. RENFORCEMENT DE LA SECURIT ´ E SOUS ANDROID ´ 33
taires du contenu et les conditions sous lesquelles le contenu peut ˆetre acc´ed´e.
Une politique peut par exemple ˆetre une liste d’empreinte MD5 des applications
autoris´ees `a acc´eder au contenu prot´eg´e ainsi que des coordonn´ees GPS
auxquelles le t´el´ephone doit se trouver au moment de l’acc`es au contenu. Le
contrˆole d’acc`es aux donn´ees sensibles se fait `a diff´erents niveaux : `a la transmission
des donn´ees vers le t´el´ephone et la transmission des donn´ees aux applications
sur le t´el´ephone. Pour prot´eger le contenu lors de sa transmission vers
un t´el´ephone, Ongtang et al. proposent de chiffrer le message en utilisant un
syst`eme de chiffrement bas´e sur l’identit´e du destinataire [27]. Dans leur travail,
l’identit´e est soit le num´ero du t´el´ephone soit une adresse mail. Les messages
contenant un contenu prot´eg´e sont ainsi chiffr´es et ne peuvent ˆetre lus que par
leurs destinataires.
Sur le t´el´ephone, Porscha v´erifie l’acc`es aux donn´ees sensibles en ajoutant
des points de contrˆole dans les m´ecanismes de communication Android : `a la
transmission des donn´ees sensibles aux applications de messagerie et lors des
communications entre applications. A la r´eception des MMS et des courriels, `
Porscha v´erifie si une politique de s´ecurit´e est associ´ee au contenu du message.
Si c’est le cas, il transmet uniquement le contenu du message aux applications
autoris´ees `a le recevoir. Dans le cas des MMS, les applications non autoris´ees
ne recevront pas le message. Dans le cas des courriels, le message est transmis `a
toutes les applications courriels mais celles qui ne sont pas autoris´ees `a acc´eder
aux donn´ees sensibles ne recevront que le message vid´e de son contenu. Une fois
les donn´ees sensibles stock´ees sur le t´el´ephone, une application peut souhaiter
partager les donn´ees sensibles `a d’autres applications de confiance sur le syst`eme.
Afin de contrˆoler ce partage, Porscha contrˆole les communications et partages
de donn´ees utilisant les intents, les composants de type ContentProvider et
les appels de m´ethodes distantes. Pour prot´eger les donn´ees transmises via ces
m´ecanismes, une application attache la politique de s´ecurit´e des donn´ees au
message servant `a transmettre les donn´ees. Lors de la transmission du message,
Porscha v´erifie la pr´esence d’une politique de s´ecurit´e dans le message et si c’est
le cas limite la transmission aux destinataires autoris´es par la politique.
Pour r´esumer, le syst`eme de protection de contenu offert par Porscha permet
de d´efinir de mani`ere plus fine `a qui des donn´ees sensibles peuvent ˆetre
transmises et sous quelles conditions. Cependant, contrairement `a AppFence ou
TaintDroid qui suivent la propagation des informations dans tout le syst`eme
(applications ´ecrites en Java et fichiers), Porscha ne r´esout pas le probl`eme de
l’usage de l’information. En effet, Porscha ne prot`ege les donn´ees que lorsqu’elles
partent de leur application source (application partageant les donn´ees en leur
associant une politique de s´ecurit´e). Une fois que les donn´ees sont transmises
`a d’autres applications, il n’y a plus de contrˆole sur l’usage qui est en est fait.
Le destinataire peut ainsi faire fuir les donn´ees sans que le syst`eme ne soit au
courant.34 CHAPITRE 2. ETAT DE L’ART ´
2.5.1.4 AppIntent
Une fuite d’information ne signifie pas forc´ement qu’une attaque ait eu lieu.
Selon les cas, la fuite peut ˆetre intentionnelle (ex : partage de coordonn´ees
g´eographiques par messagerie), c’est-`a-dire faite par l’utilisateur mˆeme, ou ex´ecut´ee
par l’application sans r´eelle intervention de l’utilisateur. Dans le cas d’une
fuite intentionnelle, le risque d’une attaque est moindre. Dans le second cas,
fuite des donn´ees sans que l’utilisateur n’ait initi´e l’action, la probabilit´e qu’une
attaque ait lieu est ´elev´ee car l’utilisateur n’a pas conscience de la fuite.
Dans [106], Yang et al. pr´esentent AppIntent, un outil qui analyse les applications
Android afin de d´eterminer les ´ev`enements et entr´ees attendus par
une application et entraˆınant une fuite d’information. Le but d’AppIntent est
de fournir `a un analyste les ´ev`enements et entr´ees attendus par une application
menant `a la fuite d’une information afin que l’analyste puisse statuer de la
nature de la fuite : intentionnelle ou non (risque d’une attaque).
Pour calculer les ´ev`enements et entr´ees entraˆınant une fuite, l’outil analyse
statiquement le code de l’application. Dans un premier temps, il construit son
graphe de flux de contrˆole puis d´etermine `a partir de ce graphe les chemins
d’ex´ecution contenant une fuite d’information. Une fuite d’information est un
ensemble d’instruction qui r´ecup`erent une donn´ee sensible puis la fait fuir. Une
fois ces chemins calcul´es, AppIntent calcule la suite d’´ev`enements ainsi que
les entr´ees attendues qui m`enent `a l’ex´ecution de la fuite d’information. Les
´ev`enements sont les cr´eations et ex´ecutions des composants d’une application
(ex : cr´eation et ex´ecution d’un composant Activity ou la reprise d’ex´ecution du
composant) ainsi que les interactions avec l’interface utilisateur (ex : validation
d’un formulaire) et les entr´ees sont les donn´ees li´ees `a ces ´ev`enements tels que
les attributs d’un intent utilis´e pour lancer l’ex´ecution d’un composant ou les
valeurs des champs d’un formulaire.
A partir des ´ev`enements et entr´ees calcul´es, AppIntent cr´ee ensuite des tests `
unitaires qui correspondent qui ex´ecutent ces suites d’´ev`enement et donnent `a
l’application les entr´ees menant `a la fuite d’une information. Pour d´eterminer
de la nature des fuites d’information, l’analyste n’a ainsi qu’`a ex´ecuter ces tests
unitaires et statuer si lors de l’observation d’une fuite, les actions men´ees `a cette
fuite sont intentionnelles ou non.
Pour ´evaluer leur outil, Yang et al. ont analys´e 750 ´echantillons de malware
et 1000 applications parmi les plus populaires dans la section des applications
gratuites sur Google Play. Sur les 750 ´echantillons malware, AppIntent a d´etect´e
219 fuite de donn´ees non intentionnelles et 17 fuites intentionnelles (faites par
l’utilisateur). Quant aux applications de GooglePlay, AppIntent a d´etect´e 26 cas
de fuites de donn´ees non intentionnelles et 29 cas de fuites intentionnelles. En
comparaison, TaintDroid a d´etect´e moins de fuites de donn´ees : 125 dans le cas
des ´echantillons de malware et 40 pour les applications de Google Play.2.5. RENFORCEMENT DE LA SECURIT ´ E SOUS ANDROID ´ 35
2.5.2 Communication entre processus et entre composants
La d´el´egation d’une partie de l’attaque `a d’autres applications pr´esentes
sur le syst`eme et la collaboration entre applications permettent aux applications
malveillantes de cacher leur v´eritable nature aux yeux des utilisateurs.
Par exemple, une application demandant acc`es aux photos, aux donn´ees de
g´eolocalisation, `a la liste de contacts et `a internet paraˆıt suspecte car elle poss`ede
assez de permission pour faire fuir les donn´ees li´ees `a l’utilisateur. Par contre, la
mˆeme application avait l’acc`es internet en moins paraˆıt moins suspecte car rien
n’indique qu’elle pourrait communiquer avec une entit´e distante. Or comme nous
l’avons expliqu´e dans la section ??, les applications peuvent utiliser d’autres
applications ou collaborer avec d’autres applications pour mener une action
qu’elles ne pouvaient faire toutes seules. Dans ce qui suit, nous pr´esentons ainsi
les travaux visant `a bloquer ce type d’attaque sur Android en contrˆolant les
communications entre applications.
2.5.2.1 ComDroid
Nous avons pr´esent´e en section 2.3.3 le r´esultat d’une analyse sur les vuln´erabilit´es
introduites par les communications bas´ees sur les intents. Pour d´etecter
ces vuln´erabilit´es, Chin et al. ont ainsi pr´esent´e dans [34] un outil d’analyse d’application
du nom de ComDroid. ComDroid effectue deux types d’analyse sur le
code des applications et leur fichier AndroidManifest.xml.
La premi`ere analyse consiste `a analyser le code des applications. Durant cette
analyse, ComDroid ´etudie comment les intents sont cr´e´es puis ´emis par une application.
ComDroid ´emet une alerte `a chaque fois qu’il d´etecte qu’un implicit
intent est ´emis avec une restriction trop faible sur les destinataires. Une restriction
est faible si aucun filtrage bas´e sur les permissions du destinataire n’est
impos´e ou si les permissions impos´ees sont de type normal (voir tableau 2.1).
Une permission de type normal est une permission automatiquement accord´ee
`a toute application la demandant.
La deuxi`eme analyse consiste `a analyser les composants des applications afin
de d´eterminer s’il y a un risque que les composants re¸coivent des requˆetes malveillantes
via les intents. ComDroid consid`ere qu’il y a une possibilit´e pour
qu’un composant soit vuln´erable si ce dernier peut recevoir des intents provenant
d’autres applications 6
telles qu’il n’y ait aucune restriction bas´ee sur les
permissions ou une restriction trop faible sur les ´emetteurs de l’^ıntent. Tout
comme dans la premi`ere analyse, une restriction trop faible bas´ee sur les permissions
est une restriction bas´ee uniquement sur les permissions de type normal.
Si l’analyse des communications via les intents montre les risques que
ces communications introduisent, il n’existe cependant pas de m´ethode pour
d´eterminer si ce qui a ´et´e d´etect´e comme un risque de s´ecurit´e est une vuln´erabilit´e
de l’application ou une fonctionnalit´e impl´ement´ee par le d´eveloppeur. En effet,
le fait qu’un implicit intent soit utilis´e ou qu’un composant soit expos´e
au reste du syst`eme peut traduire une volont´e de s’adapter aux applications
6. Un attribut exported ou un intent filter est d´efini pour le composant36 CHAPITRE 2. ETAT DE L’ART ´
pr´esentes dans le syst`eme. L’exemple typique est l’ouverture d’une page web `a
partir d’une application autre que le navigateur.
Du cˆot´e du d´eveloppeur de l’application demandant l’ouverture de la page
web, le choix d’envoyer un implicit intent au lieur de d´efinir explicitement le
navigateur permet de s’assurer que le lien soit ouvert qu’importe le navigateur
sur le syst`eme. Il existe plusieurs navigateurs web sur Android (ex : Google
Chrome et Firefox) et l’utilisateur a la possibilit´e de choisir quel navigateur
installer et utiliser sur le t´el´ephone. D´efinir explicitement le destinataire de la
requˆete pour ouvrir le lien revient ainsi `a courir le risque que le lien ne soit pas
ouvert car le navigateur cibl´e n’est pas pr´esent sur le t´el´ephone. Au contraire,
en envoyant un implicit intent que tous les navigateurs peuvent recevoir,
le d´eveloppeur s’assure que le lien sera ouvert s’il existe un navigateur sur le
t´el´ephone.
Le mˆeme choix se pr´esente ´egalement aux d´eveloppeurs de navigateurs web.
En exposant leur navigateur `a toute application pr´esente dans le syst`eme, les
d´eveloppeurs s’assurent que leur application soit compatible avec toute application
souhaitant ouvrir une page web.
2.5.2.2 Saint
Les permissions sont les bases du filtrage des communications entre applications
Android pour prot´eger l’acc`es `a des ressources sensibles. Le contrˆole de
leur attribution et de leur usage est cependant assez faible sur Android. En
effet, une application ne peut restreindre l’attribution d’une permission qu’elle
a d´eclar´ee `a l’installation d’une nouvelle application qu’en d´eclarant la permission
comme ´etant signature. Dans ce cas, la permission n’est accord´ee que si
l’application la demandant a ´et´e sign´ee par le mˆeme d´eveloppeur que celui de
l’application l’ayant d´eclar´ee. Une fois l’application demandant la permission
install´ee sur le t´el´ephone, il n’existe ´egalement aucune restriction sur son usage.
Le d´eveloppeur d’une application pourrait par exemple souhaiter que les applications
communiquant avec la sienne ne puisse le faire que dans des contextes
pr´ecis tels qu’une plage d’horaire.
Partant de ce constat, Ongtang et al. proposent dans [80] une extension de
s´ecurit´e `a Android du nom de Saint dont le but est de donner plus de contrˆole
sur l’attribution des permissions et leur usage. L’apport de Saint consiste en un
module permettant des restrictions suppl´ementaires en plus des permissions `a
l’installation des applications et `a leur ex´ecution, ou plus pr´ecis´ement lors des
communications entre processus.
Saint permet aux applications de d´efinir une politique de s´ecurit´e qui contrˆole
l’attribution des permissions prot´egeant leurs interfaces `a l’installation. Par
d´efaut, la seule mani`ere de limiter l’´eligibilit´e d’une application pour l’obtention
d’une permission est de d´eclarer cette derni`ere comme ´etant de type signature
7
. Ce type de permission n’est accord´ee qu’aux applications sign´ees avec
la mˆeme cl´e que l’application ayant d´eclar´e la permission. Grˆace `a Saint, les
7. Voir le tableau 2.1 pour la liste des types de permission2.5. RENFORCEMENT DE LA SECURIT ´ E SOUS ANDROID ´ 37
applications peuvent d´eclarer des restrictions plus fine sur l’attribution des permissions
`a l’installation. Elles peuvent ainsi imposer une restriction sur une
liste d´eveloppeurs au lieu d’un seul qui est le d´eveloppeur de l’application ayant
d´eclar´ee la permission, les autres permissions demand´ees par l’application, son
num´ero de version, etc. La politique d’attribution d´efinit un comportement par
d´efaut (attribuer ou refuser) et les crit`eres qui y font exception. Une application
peut ainsi d´eclarer qu’une permission n’est accord´ee `a une autre application que
si elle satisfait un ensemble de conditions ou `a l’inverse d´eclarer que la permission
est accord´ee `a toute application sauf celles qui satisfont cet ensemble de
conditions.
A l’ex´ecution, Saint permet aussi de contrˆoler les communications entre `
applications en d´efinissant grˆace aux mˆemes types de politique de s´ecurit´e.
L’´emetteur et le destinataire peuvent tout deux d´efinir cette politique. Comme
`a l’installation, l’application d´efinit un comportement par d´efaut (autoriser ou
bloquer) et les conditions qui y font exception. La diff´erence par rapport `a
l’installation est que l’application peut d´efinir des contextes d’ex´ecution comme
condition dans la politique. Ces contextes peuvent par exemple ˆetre des plages
horaires, l’´etat de connexion au r´eseau ; la localisation du t´el´ephone, etc.
Saint offre aux applications un contrˆole plus fin sur l’attribution et l’usage des
permissions qu’ils d´eclarent pour prot´eger leurs composants. A l’ex´ecution, Saint `
souffre cependant des mˆemes limitations que Porscha [79]. En effet, la protection
offerte par Saint se limite `a l’acc`es direct au composant de l’application prot´eg´ee
par la politique de s´ecurit´e. Si une application autoris´ee par la politique de
s´ecurit´e est par exemple utilis´ee lors d’une attaque par d´el´egation pour acc´eder
au composant prot´eg´e, Saint ne verrait pas que l’acc`es est en fait r´ealis´e par
une autre application qui elle n’est peut-ˆetre pas autoris´ee par la politique de
s´ecurit´e.
2.5.2.3 Quire
Pour prot´eger les acc`es `a des composants sensibles, les travaux pr´ec´edents
se contentent de contrˆoler l’acc`es direct au composant. Ces solutions sont ainsi
inefficaces pour lutter contre les attaques par d´el´egation. Dans [42], Dietz et
al. proposent Quire une extension de s´ecurit´e `a Android dont le but est de
d´etecter et bloquer les attaques par d´el´egation. Quire modifie les m´ecanismes
de communication entre applications afin qu’`a chaque requˆete ´emise, l’´emetteur
puisse joindre la chaine d’appel ayant men´e `a l’´emission de cette requˆete et
que le destinataire de la requˆete puisse v´erifier que tous les ´el´ements de la
chaine d’appel ont les permissions n´ecessaires pour demander le traitement de la
requˆete. Par exemple, si une application A envoie une requˆete `a une application
B qui `a la suite de la r´eception de la requˆete envoie une requˆete `a l’application C
alors la chaine d’appel une fois arriv´ee `a C est A Ñ B. Si C `a la r´eception de la
requˆete effectue une op´eration sensible, elle peut v´erifier si les applications dans
la chaine d’appel ayant men´e `a l’ex´ecution cette op´eration ont les permissions
n´ecessaires. Aini, en supposant que B ait la permission n´ecessaire pour envoyer
la requˆete et que A ne l’ait pas, C peut d´ecider en connaissance de cause si oui ou38 CHAPITRE 2. ETAT DE L’ART ´
non elle ex´ecute l’op´eration demand´ee. Si l’op´eration sensible ex´ecut´ee par C est
par exemple l’´edition de la liste de contact, alors C v´erifiera que les applications
A et B poss`edent la permission pour ´editer les contacts (WRITE CONTACTS).
2.5.2.4 IPC Inspection
Porter et al. ont adopt´e une approche similaire `a Quire pour bloquer les
attaques par d´el´egation. Dans [49], ils pr´esentent IPC Inspection un m´ecanisme
qui contrˆole les communications entre applications sous Android. Quand une
application re¸coit un message, le syst`eme consid`ere que ses permissions sont
r´eduites `a l’intersection de l’ensemble de ses permissions avant la r´eception du
message et l’ensemble des permissions de l’´emetteur. En agissant ainsi, le destinataire
ne peut plus effectuer d’action sensible `a la demande de l’´emetteur si ce
dernier n’a pas la permission n´ecessaire pour effectuer l’action. Le destinataire
des messages voit ainsi ses permissions `a l’ex´ecution se r´eduire au fur et `a mesure
qu’elle re¸coit des messages de diff´erente applications avec des permissions
diff´erentes.
Quelques r`egles existent afin d’´eviter que les applications destinataires des
messages ne perdent leur permission d´efinitivement et deviennent inutilisables.
Les applications syst`emes font partie de la base de confiance. Tout message provenant
de ces applications n’entraˆınent donc aucune r´eduction des permissions.
Un intent peut servir `a demander d’ex´ecuter une action particuli`ere et `a ˆetre
notifi´e `a la fin d’ex´ecution de cette tˆache. La notification se fait par l’envoi d’un
intent `a l’´emetteur du pr´ec´edent message. Lors de la r´eception de la notification,
le syst`eme consid`ere qu’il n’y a pas risque d’attaque et n’effectue aucune
r´eduction de permission. Enfin, IPC Inspection force l’usage de multiples instances
d’une mˆeme application pour traiter les messages qui lui sont adress´es.
Le destinataire d’un message a ainsi une instance avec ses permissions d’origine
et d’autres instances qui traiteront chacun des messages et dont les permissions
seront r´eduites.
2.5.2.5 Pr´evention des attaques par d´el´egation et par collusion
Quire [42] et IPC Inspection [49] ne ciblent que les attaques par d´el´egation.
De plus, le seul m´ecanisme de communication pris en compte est celui bas´e sur
binder en utilisant les intents. Dans [30], Bugiel et al. pr´esentent une nouvelle
extension de s´ecurit´e `a Android qui est param´etr´ee par une politique de s´ecurit´e
et dont le but est de bloquer les attaques par d´el´egation ainsi que les attaques
par collusion. Contrairement aux travaux pr´ec´edents, ils prennent en compte
la possibilit´e que la communication entre les applications se fasse ´egalement
`a travers les m´ecanismes standard de communication sous Linux (fichiers et
sockets). Ils ´etendent un framework de s´ecurit´e pour Android d´evelopp´e dans
un travail ant´erieur [29] afin d’observer les interactions entre les applications,
composants du syst`eme (ContentProvider et services), fichiers et sockets. A`
chaque fois qu’une interaction est observ´ee, ils v´erifient qu’il n’y a pas un risque
d’attaque. La d´etection des attaques utilisent une repr´esentation sous forme2.5. RENFORCEMENT DE LA SECURIT ´ E SOUS ANDROID ´ 39
de graphe des interactions entre les applications, les fichiers, les sockets et des
composants du syst`eme (ContentProvider et services). La politique de s´ecurit´e
d´ecrit des propri´et´es sur ce graphe qui permettent de statuer si une interaction
correspond `a une attaque ou non. Par exemple, une attaque par d´el´egation est
d´ecrite par le fait qu’il existe un chemin `a partir du nœud repr´esentant une
application A vers le nœud repr´esentant une application B tel que B poss`ede
des permissions critiques que A ne poss`ede pas. Une attaque par collusion est
d´ecrite par le fait qu’il existe une chemin entre les nœuds de deux applications
A et B tel que l’union des permissions de A et B soit critique. Les auteurs ne
d´efinissent pas ce qu’est un ensemble critique de permissions et laisse plutˆot le
soin de le d´efinir `a l’utilisateur qui d´efinit la politique de s´ecurit´e.
Contrairement `a Quire, Bugiel et al. laissent le choix `a l’utilisateur de d´efinir
ce qu’est une attaque via la politique de s´ecurit´e, ce qui apporte `a la fois
un avantage et un inconv´enient `a l’approche. La possibilit´e de d´efinir avec
pr´ecision les sc´enarios d’attaque a l’avantage de limiter les faux positifs lors
de l’ex´ecution du syst`eme, c’est-`a-dire des communications jug´ees comme dangereuses
alors qu’elles ne le sont pas. Un des cas souvent ignor´e dans les travaux
pr´ec´edents est qu’une application puisse intentionnellement fournir un service `a
une autre application. L’inconv´enient dans cette approche est que l’utilisateur
n’a pas forc´ement les comp´etences n´ecessaires pour d´efinir une bonne politique
de s´ecurit´e ce qui pourrait ˆetre exploiter par une application malveillante afin
d’´echapper `a la d´etection.
2.5.3 Abus des permissions
2.5.3.1 Kirin
L’approche basique utilis´ee par les applications malveillantes sous Android
est de demander toutes les permissions qui leur sont n´ecessaires pour effectuer
leur tˆache malveillante. Par exemple, les applications espions dont le but est de
tracer l’utilisateur du t´el´ephone demande l’acc`es aux donn´ees de g´eolocalisation
et l’acc`es `a internet.
Afin de bloquer ce type d’attaque, Enck et al. proposent un syst`eme nomm´e
Kirin dans [47]. Le but de Kirin est de v´erifier qu’une application n’a pas un
ensemble de permissions jug´e dangereux. Par exemple, l’acc`es aux donn´ees de
g´eolocalisation et `a internet permet de faire fuir les d´eplacements de l’utilisateur
de t´el´ephone. Ainsi, Kirin v´erifie `a l’installation les permissions demand´ees
par une application. Si elle contient un ensemble dangereux, l’installation est
bloqu´ee. Il appartient `a l’utilisateur ou `a l’administrateur de l’appareil de d´efinir
les ensembles de permission dangereux.
2.5.3.2 Woodpecker
Les permissions filtrent l’acc`es aux ressources sensibles sous Android. Une
application sans la permission READ SMS ne peut par exemple lire la base de
donn´ees des SMS. Dans [54], Grace et al. ont analys´e les applications livr´ees avec40 CHAPITRE 2. ETAT DE L’ART ´
8 t´el´ephones Android et montr´e que certaines exposaient sans aucune restriction
les ressources sensibles. Les auteurs ont identifi´e deux m´ethodes.
La premi`ere m´ethode, qu’ils disent explicite, consiste `a exposer les m´ethodes
pour acc´eder aux ressources sensibles via des interfaces publiques dont l’acc`es
est plus laxiste que celui de la m´ethode prot´eg´ee. Ils consid`erent comment interface
les composants expos´es publiquement `a d’autres applications. La deuxi`eme
m´ethode, cette fois-ci implicite, consiste `a partager le mˆeme identifiant d’utilisateur
entre deux applications. Cela est possible en associant la mˆeme valeur
`a l’attribut sharedUserId dans le fichier AndroidManifest.xml des deux applications.
Les deux applications tournant avec le mˆeme identifiant utilisateur,
elles se retrouvent ainsi `a l’ex´ecution avec l’union des permissions que les deux
applications poss`edent.
Grace et al. ont ainsi d´evelopp´e Woodpecker un outil pour analyser les applications
et trouver d’´eventuelles expositions de ressources sensibles. Woodpecker
d´efinit les points d’entr´ee de l’application `a partir de son fichier AndroidManifest.xml,
construit son graphe de flux de contrˆole (Control Flow Graph en
anglais) et `a partir du CFG calcule tous les chemins d’ex´ecution possibles. L’outil
consid`ere qu’une ressource sensible est expos´ee explicitement si un chemin
d’ex´ecution partant d’une interface non prot´eg´ee contient un appel `a une fonction
sensible et qu’aucun contrˆole n’est fait avant l’appel. Pour le deuxi`eme cas,
une alerte est lev´ee si une application indique partager son identifiant utilisateur
et s’il existe un appel `a une fonction sensible dans le code de l’application telle
que la partie contenant cette fonction puisse ˆetre atteinte.
2.5.3.3 Aurasium
La plupart des approches visant `a contrˆoler le comportement des applications
se font en modifiant le syst`eme. Dans [105], Xu et al. proposent cette fois-ci
de laisser le syst`eme intact et d’ajouter le code n´ecessaire au contrˆole dans l’application.
Ils ont ainsi d´evelopp´e un service appel´e Aurasium 8 qui prend en
entr´ee une application et retourne sa version renforc´ee. Cette version renforc´ee
int`egre du code interceptant les appels aux fonctions sensibles sous Android
afin de renforcer une politique de s´ecurit´e. Les fonctions concern´ees servent `a
acc´eder `a des ressources sensibles sur le t´el´ephone et internet, et `a ex´ecuter
des op´erations potentiellement dangereuses telles que le chargement d’une biblioth`eque
ou l’ex´ecution d’un binaire.
Bien que ce genre de fonctions soient d´efinies au sein de l’API Java d’Android,
Aurasium intercepte leur appel `a un niveau plus bas, plus pr´ecis´ement au
niveau des fonctions de la biblioth`eque C du syst`eme et de la machine virtuelle
dalvik. Il existe par exemple diff´erentes fonctions dans l’API pour communiquer
sur le r´eseau. Cependant, au niveau syst`eme tout cela se traduit par un
ensemble restreint d’appels syst`eme tels que connect et sendmsg. Il en est de
mˆeme pour les IPCs bas´es sur le binder qui se font via l’appel syst`eme ioctl
/dev/binder/. Lorsque l’appel `a une fonction sensible est d´etect´ee, l’application
8. http://aurasium.com2.6. SUIVI DE FLUX D’INFORMATION 41
en informe l’utilisateur et demande `a l’utilisateur de valider l’appel s’il souhaite
qu’il se poursuive.
Pour ´evaluer la capacit´e de leur service `a instrumenter les applications et `a
fournir une version toujours fonctionnelle, ils ont soumis un ensemble de 3491
applications de Google Play et 1260 ´echantillons de malware `a leur service. Nous
entendons par version fonctionnelle, une application qui se lance sans erreur
au d´emarrage et qui `a l’ex´ecution montre bien des interceptions `a des appels
de fonction sensible. Leur ´evaluation a montr´e qu’Aurasium ´etait capable de
fournir une version fonctionnelle des applications dans plus de 99% des cas.
Aucune ´evaluation ne permet cependant d’appr´ecier la capacit´e d’Aurasium `a
intercepter les appels de fonction correspondant aux attaques sur un syst`eme.
Nous avons pr´esent´e dans cette section diff´erents travaux inh´erents `a la
s´ecurit´e d’Android. Partant du constat des limites des m´ecanismes de s´ecurit´e
Android, principalement celles li´ees `a l’acc`es aux ressources sensibles et aux
communications entre applications, les auteurs de ces travaux ont propos´e des
extensions de s´ecurit´e `a Android et des outils d’analyse d’application. Ces extensions
et outils ont pour but de d´etecter les tentatives exploitant les limites
du m´ecanisme de s´ecurit´e du syst`eme ainsi que les risques de s´ecurit´e introduit
par les m´ecanismes de communication Android. Parmi les attaques cibl´ees,
ils ciblent principalement le vol de donn´ees sensibles, l’usage malveillant des
permissions accord´ees aux applications, les attaques par d´el´egation et les attaques
par collusion. Ces travaux concernent ainsi des classes d’attaque connue
et essayent de les d´etecter ou les pr´evenir.
Dans cette th`ese, nous avons une approche diff´erente. Au lieu de d´etecter
les malware en nous basant sur les limites connues du m´ecanisme de s´ecurit´e
d’Android, nous souhaitons dans un premier temps caract´eriser les malware
(comment leur attaque fonctionne) et nous baser sur ce que nous aurons appris
pour les d´etecter. Notre approche est bas´ee sur les flux d’information que causent
les malware dans le syst`eme. Dans la section qui suit, nous introduisons ainsi la
notion de flux d’information et pr´esentons quelques travaux utilisant le suivi de
flux d’information pour d´etecter des attaques.
2.6 Suivi de flux d’information
Suivre les flux d’information consiste `a observer comment les informations
se propagent dans un environnement donn´e. En s´ecurit´e, le suivi de flux d’information
est utilis´e pour d´etecter des attaques visant soit la confidentialit´e soit
l’int´egrit´e de donn´ees dans un environnement donn´e. En plus de d´etecter des
attaques, il peut ´egalement servir `a les bloquer. Il s’agit dans ce cas de contrˆole
de flux d’information.42 CHAPITRE 2. ETAT DE L’ART ´
2.6.1 Suivi de flux au sein d’une application
Suivre les flux d’information au sein d’une application permet d’avoir une
vue fine de la mani`ere dont les informations sensibles sont trait´ees par un
programme. A l’exception du langage Perl, les langages de programmation `
n’int`egrent cependant pas de m´ecanisme de suivi ou de contrˆole de flux d’information.
Divers travaux se sont ainsi concentr´es sur le suivi et le contrˆole de flux
dans les applications soit en proposant une extension au langage de programmation
utilis´e soit en instrumentant l’environnement dans lequel l’application
tourne.
Les applications Android sont principalement ´ecrites en Java. Dans [74, 73],
Myers et Liskov pr´esentent un mod`ele de suivi de flux d’information qu’ils
impl´ementent dans Jif [75], une extension du langage Java capable de contrˆoler
les flux d’information `a l’int´erieur d’une application. Techniquement, Jif est un
pr´eprocesseur effectuant une analyse statique du code source pour contrˆoler la
conformit´e des flux d’information dans un programme par rapport `a une politique
de flux. La politique est repr´esent´ee par des labels qui sont associ´es aux
variables et fonctions dans le code. A chaque objet est assign´e un label o`u sont `
d´eclar´es l’ensemble des propri´etaires de l’information et les entit´es que chaque
propri´etaire autorise `a acc´eder `a l’information. Etant donn´e que chaque pro- ´
pri´etaire d´eclare une liste de lecteurs autoris´es, la liste des lecteurs effectifs est
ensuite calcul´ee en faisant l’intersection de la liste que chaque propri´etaire a
d´eclar´ee. Le label L “ to1 : r1, r2; o2 : r2, r3u signifie par exemple que l’objet
auquel il est attach´e contient des informations dont o1 et o2 sont propri´etaires.
o1 et o2 n’autorisent respectivement que r1 ou r2 et r2 ou r3 `a acc´eder `a l’information.
Le lecteur effectif est donc ici r2. Lors pr´etraitement du code, Jif,
qui est un pr´eprocesseur Java, calcul les flux d’information dans le programme
et v´erifie que les politiques de s´ecurit´e associ´ees aux variables sont v´erifi´ees.
L’approche propos´ee par Myers et Liskov est une approche statique qui
consiste `a annoter le code source des applications puis `a l’analyser pour contrˆoler
les flux d’information dans l’application. Un des avantages de l’analyse statique
par rapport `a l’analyse dynamique est qu’il couvre tous les chemins d’ex´ecution
possibles et permet en une seule analyse d’identifier toutes les violations `a une
politique de flux d’information. Une limite `a cette approche est cependant la
n´ecessit´e d’avoir acc`es au code source de l’application pour l’analyser, ce qui est
rarement le cas pour les applications Android et limite l’usage de cette approche.
Le code des applications Android est livr´e sous la forme de dalvik bytecode
et il est parfois obfusqu´e afin d’empˆecher des entit´es tierces de retrouver le code
original `a partir duquel le dalvik bytecode a ´et´e g´en´er´e. Ce bytecode est obtenu
en compilant dans un premier temps le code source de l’application en
bytecode Java puis en compilant ce dernier en bytecode compr´ehensible par
la machine virtuelle Dalvik.
Si les travaux pr´ec´edents s’attachent `a ajouter une extension de contrˆole
de flux d’information dans le langage de programmation et contrˆoler les flux
d’information de mani`ere statique, d’autres se sont pench´es sur une modification
de l’environnement d’ex´ecution pour suivre et contrˆoler les flux d’information `a2.6. SUIVI DE FLUX D’INFORMATION 43
l’ex´ecution des applications. Dans [46], Enck et al. proposent TaintDroid, une
version modifi´ee d’Android avec un m´ecanisme de suivi de flux d’information `a
l’ex´ecution des applications. Leur but ´etait d’´etudier si les applications Android
font fuir des donn´ees sensibles du t´el´ephone via le r´eseau ou par SMS. Ils ont
d´efini dans leur outil un ensemble d’information `a surveiller (ex : identifiants
de l’appareil et donn´ees de g´eolocalisation) et s´electionn´e les 30 applications
Android les plus populaires pour les analyser. Ils ont montr´e que plus de 2{3
d’entre elles faisaient fuir des donn´ees sensibles, principalement les identifiants
du t´el´ephone. Pour suivre les flux d’information, Enck et al. ont modifi´e la
machine virtuelle Dalvik. Ils ont impl´ement´e une m´ethode dite de tainting qui
consiste `a marquer les objets selon la nature de leur contenu. Dans la machine
virtuelle Dalvik, les objets pouvant contenir des informations sont les variables
d’une m´ethode, ses param`etres et les champs d’une classe ainsi que des ses
instances. Lorsqu’un flux est obser´e, les marques associ´ees aux objets dont le
contenu a ´et´e modifi´e est mis `a jour pour prendre en compte la nature de leur
nouveau contenu.
Contrairement `a Myers et Liskov, Enck et al. ont opt´e pour une approche dynamique
pour suivre les flux d’information au sein d’une application durant son
ex´ecution. A cause de la nature de l’analyse (dynamique), une des principales `
limitations de TaintDroid est l’impossibilit´e d’observer tous les flux d’information
possibles en une seule analyse. Seuls les flux d’information explicites qui
ont lieu durant l’ex´ecution de l’application sont d´etect´es. Si TaintDroid a une
vue plus limit´ee des flux d’information dans une application, il poss`ede cependant
un avantage non n´egligeable par rapport aux approches statiques qui est
qu’il ne n´ecessite pas l’acc`es au code source des applications analys´ees. Il est
donc plus adapt´e pour analyser les applications destin´ees `a tourn´ees dans un
environnement tels qu’Android.
2.6.2 Suivi de flux au niveau syst`eme
Un autre niveau d’observation des flux d’information est le syst`eme d’exploitation
o`u les objets du syst`eme tels que les processus et les fichiers sont
vus comme des conteneurs d’information et les interactions entre eux des flux
d’information. Dans [109, 110], Zeldovich et al. proposent HiStar, un syst`eme
d’exploitation qui int`egre un m´ecanisme de contrˆole de flux d’information au
niveau syst`eme. Le but de HiStar est de fournir un syst`eme capable de bloquer
les attaques visant `a voler ou corrompre les donn´ees sur le syst`eme. Pour suivre
et contrˆoler les flux d’information, HiStar utilise les labels Asbetos [45]. Un label
´etablit une correspondance entre une cat´egorie d’information et un niveau
marquage. Par exemple, le label L “ tw3, c2, 1u signifie que le niveau associ´e
aux cat´egories w et c sont respectivement 3 et 2. Le niveau par d´efaut est 1. Un
label est associ´e `a chaque objet du syst`eme pouvant contenir de l’information.
Le label repr´esente pour chaque objet son niveau d’acc`es pour les diff´erentes
cat´egories d’information. Lorsqu’un flux d’information d’un objet A vers un
objet B a lieu, HiStar v´erifie que le niveau d’acc`es de B pour les cat´egories
d’information d´efinies dans le label de A est sup´erieur ou ´egal au niveau d’acc`es44 CHAPITRE 2. ETAT DE L’ART ´
de A pour ces mˆemes cat´egories. Si c’est le cas, le flux est autoris´e. Dans le cas
contraire, il est bloqu´e. Par exemple, si le label de A vaut tw3, c2, 1u et que celui
de B vaut tw2, c3, h2, 1u alors B ne peut acc´eder au contenu de A car le niveau
d’acc`es de B aux `a la cat´egorie d’information w, ici 2, est inf´erieur au niveau
d’acc`es de A, ici 3, `a la mˆeme cat´egorie.
Pour contrˆoler les flux d’information dans le syst`eme, HiStar associe des
niveaux d’acc`es aux diff´erents objets du syst`eme. Contrairement `a TaintDroid
ou AppFence, il se contente d’´etablir des niveaux d’acc`es aux informations mais
ne suit pas leur propagation dans le syst`eme. Cela limite son utilit´e pour analyser
comment les donn´ees d’une application se propagent dans le syst`eme, ce qui est
l’un des nos objectifs.
Dans cette th`ese, nous utilisons un moniteur de flux d’information au niveau
du syst`eme pour observer les flux d’information. Ce moniteur est la version
Android d’un moniteur de flux d’information pour Linux, Blare [37], dont la
version actuelle a ´et´e d´evelopp´ee par Christophe Hauser. Plus pr´ecis´ement, Blare
est un outil de d´etection d’intrusion pour les syst`emes Linux param´etr´e par
une politique de flux d’information. La politique d´efinit les flux autoris´es dans
le syst`eme et toute violation de cette politique constitue une intrusion. Pour
suivre et contrˆoler les flux d’information, Blare utilise deux labels, itag et ptag,
qui sont attach´es aux objets du syst`eme. L’itag repr´esente la contamination
courante d’un objet et le ptag repr´esente sa contamination maximale autoris´ee.
L’itag d’un objet est ainsi mis `a jour `a chaque fois qu’un flux d’information
modifiant le contenu de l’objet a lieu tandis que le ptag est d´efini lors de la
cr´eation de la politique de flux. Lorsqu’un flux d’information d’un objet A vers
un objet B a lieu, Blare consid`ere que les informations de A vont dans B et v´erifie
si l’itag de A est autoris´e par le ptag de B. Si c’est le cas, il met `a jour l’itag
de B pour prendre en compte son nouveau contenu. Sinon il l`eve une alerte.
Blare ne pr´evient pas les intrusions mais les d´etecte. Il ne bloque pas le flux en
cas de violation d’une politique mais se contente de lever une alerte. Comme
HisTar, le niveau d’observation de Blare se limite au niveau syst`eme. Il voit les
objets du syst`eme comme des boˆıtes noires et effectue une surapproximation
des flux observ´es. Quand un flux d’un objet A vers un objet B est observ´e par
Blare, il consid`ere que toutes les informations dans A se propagent dans B.
Cette vision est moins fine que ce que proposerait un suivi de flux au niveau
des applications. Cependant il a l’avantage de ne pas d´ependre d’un langage
en particulier tel que le Java et ne se limite pas aux instances d’une machine
virtuelle. Il a ainsi une vue compl`ete des flux d’information directs entre les
objets du syst`eme par rapport `a TaintDroid qui est limit´e aux flux impliquant
uniquement les applications ´ecrites en Java.
2.6.3 Suivi de flux au niveau hardware
Dans [108], Yin et al. proposent un environnement virtuel bas´e sur Quemu
d’analyse dynamique d’application Windows appel´e Panorama. Panorama suit
les flux d’information au niveau machine tout en ayant connaissance des informations
li´ees aux objets du syst`eme tels que les processus et les fichiers. Le but du2.6. SUIVI DE FLUX D’INFORMATION 45
travail r´ealis´e est de d´eterminer si une application acc`ede `a une donn´ee sensible
du syst`eme et si c’est le cas comment elle l’utilise. Les donn´ees sensibles peuvent
ˆetre des donn´ees frapp´ees au clavier, des donn´ees du disque ou le contenu de paquets
r´eseaux. Dans le cadre de l’analyse, ces donn´ees sont suppos´ees ne pas ˆetre
acc´ed´ees par l’application analys´ee. Pour analyser une application, ils installent
ainsi l’application dans l’environnement d’analyse, introduisent des donn´ees sensibles
dans le syst`eme, et suivent comment ces donn´ees se propagent. A partir `
des flux observ´es, ils construisent un graphe de flux d’information repr´esentant
comment les donn´ees sensibles se sont propag´ees dans le syst`eme. Les nœuds
et les arcs du graphe repr´esentent respectivement les objets du syst`eme et les
flux d’information entre eux. L’application analys´ee est consid´er´ee comme malveillante
si un nœud la repr´esentant est pr´esent dans le graphe. Cela signifie qu’`a
un moment donn´e, l’application a acc´ed´ee aux donn´ees sensibles. Si c’est le cas,
ils analysent ensuite o`u les donn´ees se propagent `a partir du nœud repr´esentant
l’application analys´ee.
Dans des travaux plus r´ecents, Yin et al. ont propos´e DroidScope [106] qui
est un environnement d’analyse d’application Android qui est l’´equivalent de
Panorama pour Android. DroidScope suit ´egalement les flux d’information au
niveau hardware mais contrairement `a Panorama, il n’a pas seulement acc`es aux
informations li´ees aux objets du syst`eme mais ´egalement `a des donn´ees li´ees `a
l’ex´ecution des applications dans la machine virtuelle Dalvik. Il a ainsi une vue
plus fine de ce qui se passe dans une application telle que les m´ethodes qui sont
utilis´ees pour acc´eder `a une information.
Suivre les flux d’information au niveau hardware permet d’avoir une vue fine
des flux d’information s’op´erant sur un syst`eme. Le niveau de granularit´e pour le
stockage et l’acc`es `a une information peut-ˆetre r´eduit `a un octet ou un bit, ce qui
est l’unit´e de stockage des donn´ees. Avoir une telle granularit´e a cependant un
coˆut ´elev´e en terme de temps d’ex´ecution qui limite cette approche aux environnements
virtuels d’analyse d’application. Les auteurs de Panorama ont mesur´e
un temps d’ex´ecution des applications de 30 `a 40 fois plus lents que leur temps
d’ex´ecution normal. Notre but est de capturer le comportement malveillant des
malware Android et de les d´etecter. Sachant que certains malware essayent de
d´etecter la pr´esence d’environnement virtuels pour ´echapper `a toute d´etection,
ce niveau d’observation ne nous paraˆıt donc pas comme un choix viable.
Il existe diff´erents niveaux d’observation pour suivre les flux d’information
sur un syst`eme : application, syst`eme d’exploitation et hardware. Dans ce th`ese,
nous optons pour un suivi de flux au niveau du syst`eme d’exploitation afin
d’avoir une vue compl`ete des flux d’information entre les diff´erents composants
du syst`eme. Suivre les flux d’information `a l’int´erieur des applications a une
meilleure granularit´e mais suppose que nous ayons, soit acc`es au code source de
toutes les applications `a analyser, soit que toutes les applications soient ´ecrites
en Java et interpr´et´ees par la machine virtuelle Dalvik. Aucune de ces suppositions
ne s’av`ere ˆetre vraie dans la r´ealit´e. Suivre les flux d’information au niveau46 CHAPITRE 2. ETAT DE L’ART ´
du hardware apporte ´egalement une vue plus fine et contrairement au niveau
application ne n´ecessite pas d’acc`es au code source ou l’usage d’un seul langage
pour ´ecrire toutes les applications. Cependant, comme nous l’avons ´ecrit
pr´ec´edemment, il n’est adapt´e qu’aux environnements virtuels, ce qui pose le
probl`eme de la d´etection de l’environnement d’analyse [68]. Dans cette th`ese,
nous avons ainsi fait le choix de suivre les flux d’information au niveau syst`eme
afin d’ˆetre ind´ependant de la disponibilit´e du code source des applications et du
langage utilis´e pour les d´evelopper tout en ayant une vue compl`ete des flux d’information
entre les objets du syst`eme. A partir des flux d’information observ´es `
dans le syst`eme, nous proposons de calculer le profil d’un malware et apprendre
son comportement. L’approche est similaire `a de l’apprentissage. Dans la section
qui suit, nous pr´esentons donc comment des m´ethodes d’apprentissage ont ´et´e
appliqu´es pour classifier et d´etecter des malware.
2.7 Classification et d´etection de malware
La d´etection de malware se fait g´en´eralement en utilisant des signatures ou
des profils comportementaux. La signature d’un malware est un ensemble de
propri´et´es communes aux fichiers des ´echantillons du malware. Dans le cas des
applications Android, ces fichiers sont les apk. Le profil comportemental d’un
malware est un ensemble de propri´et´es communes `a l’ex´ecution des ´echantillons
du malware. Ces signatures et profils sont construits `a partir des informations
obtenues en analysant, statiquement ou dynamiquement, les ´echantillons de malware.
La tendance actuelle consiste `a utiliser des m´ethodes d’apprentissage afin
de classifier et d´etecter des malwares. Dans notre cas, nous souhaitons extraire
le profil d’un malware et son comportement `a partir des flux d’information
qu’ils causent dans le syst`eme. Dans ce qui suit, nous pr´esentons ainsi quelques
travaux ayant adopt´e cette approche. L’apprentissage consiste `a apprendre des
propri´et´es li´ees `a un jeu de donn´ees.
Il existe diff´erents travaux sur l’analyse statique d’application afin de d´etecter
des instances de malware (ex : [35] et [58]). Les signatures sont des propri´et´es
li´ees au malware telles que des chaines de caract`eres, des ressources dans l’application,
des appels `a des fonctions sp´ecifiques, ou simplement l’empreinte d’un
fichier. Sous Android, Arp et al. ont propos´e DREBIN [22] pour d´etecter les
´echantillons de malware Android sur les t´el´ephones. Les propri´et´es prises en
compte lors de l’analyse d’une application sont les permissions demand´ees, les
composants mat´eriels requis, ses composants, les filtres d’intent pour activer
les composants, les appels aux fonctions sensibles, les permissions utilis´ees, les
appels de fonction suspects et les adresses de serveur pr´esents dans le code de
l’application. Pour classifier les applications, ils utilisent une machine `a vecteurs
de support [41, 48] qui est une m´ethode d’apprentissage supervis´ee. Un apprentissage
supervis´e consiste `a calculer `a partir d’ensembles distincts un mod`ele
permettant de d´efinir l’appartenance d’un ´el´ement `a un de ces ensembles. A`
partir de deux ensembles distincts d’applications, l’une contenant des applications
malveillantes et l’autre contenant des applications b´enignes, ils calculent2.7. CLASSIFICATION ET DETECTION DE MALWARE ´ 47
ainsi un mod`ele de d´etection qui diff´erencie les applications malveillantes des
applications b´enignes. Ce mod`ele est ensuite utilis´e sur le t´el´ephone afin de
d´etecter les applications malveillantes. L’´evaluation effectu´ee par les auteurs de
DREBIN sur la capacit´e de d´etection montre que leur outil atteint un taux
de d´etection de 93.90% sur un ensemble de 1834 ´echantillons de malware. Le
taux de d´etection d´efinir pourcentage d’´echantillons d´etect´es sur tout le jeu de
donn´ees. Le r´esultat est proche des meilleurs r´esultats obtenus par les produits
anti-virus qu’ils ont test´e sur le mˆeme jeu de donn´ees. Les meilleurs taux de
d´etection sont de 96.41% et de 93.71% tandis que le pire est de 3.99%.
La d´etection par analyse statique montre cependant ses limites lorsque les
d´eveloppeurs de malware utilisent des techniques d’obfuscation [21, 23, 70] afin
de cacher la v´eritable nature de leurs application ou des techniques de polymorphisme
et de m´etamorphisme [50] afin de changer l’aspect du code des diff´erentes
instances d’un malware. Les d´eveloppeurs du malware Obad.a [98] utilisent par
exemple des chaines al´eatoires pour les noms de variables, m´ethode et classes. Ils
utilisent ´egalement des fonctions de chiffrement afin de masquer les chaines de
caract`eres utilis´ees dans le malware et ces fonctions changent d’un ´echantillon
`a l’autre.
Contrairement `a l’approche statique, l’approche dynamique repose uniquement
sur l’ex´ecution des applications pour d´etecter les ´echantillons de malware
et n’est pas ainsi affect´ee par ces m´ethodes d’´evasion. Dans [67], Bayer et al.
appliquent une m´ethode d’apprentissage non supervis´ee afin de classifier les
applications et d´etecter les ´echantillons de malware. L’apprentissage non supervis´ee
consid`ere qu’il n’y a pas de groupement pr´ed´efinis des ´el´ements dans le jeu
de donn´ees et calcule lui-mˆeme les regroupements possibles de ces ´el´ements.
Les applications `a classifier sont analys´ees dans Anubis [69] afin d’en extraire
un profil. Le profil est constitu´e des diverses interactions avec le syst`eme tels
que les acc`es aux fichiers et registres ainsi que les communications r´eseaux.
Ils appliquent ´egalement une m´ethode de tainting afin d’observer comment les
informations issues du syst`eme sont utilis´ees dans les prochains appels syst`eme.
Cela s’av`ere utile pour filtrer les informations `a extraire. Par exemple, si le
programme utilise la date du syst`eme pour g´en´erer le nom d’un nouveau fichier,
il ne sert `a rien de stocker le nom car il sera diff´erent `a chaque ex´ecution.
Dans [90], Rieck et al. proposent d’utiliser les interactions entre les applications
analys´ees et le reste du syst`eme afin de les classifier et de se servir du
mod`ele obtenu lors de l’apprentissage pour d´etecter d’autres ´echantillons de
malware. Pour obtenir les interactions des applications avec le reste du syst`eme,
ils ex´ecutent les applications dans CWSandbox [101], un environnement d’analyse
dynamique d’application. Ils construisent ensuite un vecteur repr´esentant
le comportement de l’applications analys´ee `a partir des interactions observ´ees
o`u chaque dimension repr´esente une suite d’interaction et utilisent ces vecteurs
afin de classifier de mani`ere non supervis´ee les applications analys´ees. Les classes
obtenues `a la suite de cette ´etape servent ensuite de mod`ele afin de d´etecter de
nouvelles instances de malware.
Rieck et al. ont compar´e la qualit´e des classes cr´ees durant l’apprentissage
rapport `a celle de Bayer et al. et ont montr´e que leur approche obtient un48 CHAPITRE 2. ETAT DE L’ART ´
meilleur score, 0.950, par rapport `a celle de Bayer et al., 0.881. Le score calcul´e,
appel´e F-Score [8], combine `a la fois la qualit´e de la pr´ecision ainsi que
du rappel des classes calcul´ees durant l’apprentissage. La pr´ecision mesure la
correspondance entre les classes calcul´ees et les familles de malware tandis que
le rappel mesure l’´eparpillement des ´echantillons d’un malware dans plusieurs
classes. Une pr´ecision ´elev´ee signifie que chaque classe correspond `a une famille
de malware. Un rappel ´elev´e signifie que chaque famille de malware correspond
`a une classe. La valeur maximale du F-score est de 1 tandis que la pire est de
0. Plus le score est ´elev´e, plus la qualit´e de l’apprentissage est meilleure.
Les travaux pr´esent´es ont mont´e que l’apprentissage pouvait servir `a calculer
des mod`eles afin de classifier et d´etecter des malware. Cet apprentissage
est effectu´e `a partir des propri´et´es li´ees aux fichiers contenant les applications
`a analyser ou de leurs traces d’ex´ecution. Dans notre cas, l’apprentissage est
effectu´e sur les flux engendr´es par les ´echantillons de malware dans le syst`eme.
Nous ex´ecutons ainsi chaque ´echantillon de malware pour capturer ces flux d’information.
Un des buts de notre approche est d’identifier le comportement malveillant
des malware. Pour cela, il faut capturer ce comportement durant l’analyser.
Pour nous en assurer, nous avons analys´e statiquement les ´echantillons de
certains malware pour identifier les ´ev`enements d´eclenchant l’ex´ecution du code
malveillant. Dans la section qui suit, nous pr´esentons donc un ensemble d’outils
li´es `a l’analyse d’applications Android.
2.8 Analyse d’applications Android
Analyser une application a pour but d’extraire des informations li´ees `a
l’application telles que son comportement, les ressources qu’elle utilise et les
´ev`enements attendus pour ex´ecuter une partie de son code.
2.8.1 D´esassembleur, d´ecompilateur
Afin de comprendre le fonctionnement d’une applications sans avoir `a l’ex´ecuter,
un analyste a souvent recours `a un d´esassembleur ou un d´ecompilateur.
D´esassembler le code d’une application consiste `a le retranscrire dans un langage
bas niveau dont les instructions et celles de l’architecture cens´ee interpr´et´ee le
code `a d´esassembler ont une forte correspondance. L’architecture interpr´etant le
code d’une application Android est la machine virtuelle Dalvik. Parmi les outils
pour d´esassembler les applications Android, nous pouvons citer dedexer [6],
apktool, qui utilise smali [13], Androguard [97] et IDA Pro [9]. Le listing 2.4 est
un extrait du code de l’application JetBoy disponible dans le SDK Android. Le
listing 2.5 est la partie correspondante, ´ecrite en smali, apr`es avoir d´esassembl´e
l’application avec apktool. La syntaxe des langages utilis´es par ces outils est
assez explicite pour comprendre ce que fait l’application et avoir une id´ee de
l’aspect du code Java d’origine. Nous remarquons par exemple que l’instruction
`a la ligne 4 dans le listing 2.4 correspond aux instructions de la ligne 24 `a 28 du
listing 2.5.2.8. ANALYSE D’APPLICATIONS ANDROID 49
1 public void onClick(View v) {
2 // this is the first screen
3 if (mJetBoyThread.getGameState() == JetBoyThread.STATE_START) {
4 mButton.setText("PLAY!");
5 mTextView.setVisibility(View.VISIBLE);
6
7 mTextView.setText(R.string.helpText);
8 mJetBoyThread.setGameState(JetBoyThread.STATE_PLAY);
9 }
10 ...
11 }
Listing 2.4 – Extrait du code de l’application JetBoy fourni avec le SDK Android
D´ecompiler une application revient `a le retranscrire dans un langage haut niveau
(ex : Java et C). Les applications Android ´etant ´ecrites en Java, le but de la
d´ecompilation sera ici d’obtenir un code Java `a partir du dalvik bytecode. Parmi
les outils notables nous pouvons citer Androguard et la combinaison dex2jar [43]
et JD-Gui [10]. Androguard int`egre un d´ecompilateur natif, dad, mais il peut
´egalement faire appel `a d’autres d´ecompilateurs. dex2jar est un outil qui transforme
le dalvik bytecode en java bytecode et JD-Gui est un outil graphique de
d´ecompilation de java bytecode. D´ecompiler une application Android en optant
pour la combinaison de ces outils revient ainsi `a extraire le fichier classes.dex
de l’apk, cr´eer avec dex2jar un fichier jar (Java Archive) et `a d´ecompiler ce
dernier avec JD-Gui. Un avantage que JD-Gui a sur Androguard est la possibilit´e
d’exporter le r´esultat de la d´ecompilation dans les fichiers .class. Le
listing 2.6 liste le code produit par la d´ecompilation de l’application JetBoy avec
Androguard. Une diff´erence notable avec le code orignal est l’usage des valeurs
`a la place des variables constantes pr´esentes dans le code original.
Si le r´esultat de la d´ecompilation a le m´erite d’ˆetre dans un langage haut
niveau, cette op´eration int`egre cependant le risque d’une erreur de transcription.
Lors de la d´ecompilation de certaines applications, nous avons ainsi d´etecter des
erreurs dans le r´esultat de la d´ecompilation pour les deux outils.
2.8.2 Comparaison d’applications
Une autre fonctionnalit´e int´eressante d’Androguard est sa capacit´e `a ´evaluer
la similarit´e entre deux applications. Androguard compare le code des deux
applications et calcule quelles sont les m´ethodes qui sont identiques, similaires et
celles qui sont pr´esentes dans l’une mais pas dans l’autre. L’un des cas d’usage de
cette fonctionnalit´e est par exemple de trouver le code rajout´e `a une application
entre deux versions. Elle peut ´egalement servir `a identifier les applications vol´ees
`a leur auteur original.50 CHAPITRE 2. ETAT DE L’ART ´
2.8.2.1 Extraction de m´etadonn´ees
L’analyse peut ´egalement avoir pour but d’extraire des m´etadonn´ees li´ees `a
l’application. Dans le cas de applications Android, ces donn´ees sont g´en´eralement
le contenu du fichier AndroidManifest.xml. Ce fichier contient diff´erentes informations
: permissions utilis´ees par l’application, son num´ero de version, la
liste de ses composants, etc. L’acc`es `a son contenu ne n´ecessite pas forc´ement un
outil particulier car il s’agit d’un fichier XML. Androguard ou les outils d’analyse
dynamique d’application tels que Andrubis propose cependant d’extraire
automatiquement ces donn´es.
2.8.2.2 Scanner de virus
Il existe plusieurs scanners de virus sous Android dont certains sont disponibles
directement sur Google Play. Il existe cependant pour les analystes
des services permettant d’analyser les applications Android pour d´etecter les
´echantillons de malware sans avoir `a les analyser avec une application dans un
t´el´ephone. VirusTotal [14] est un exemple de ce type d’outil en ligne. Pour effectuer
une analyse, les utilisateurs soumettent le fichier `a analyser via une page
de soumission. Chaque fichier soumis est ensuite analys´e par diff´erents produits
anti-virus afin de d´etecter si oui ou non il est malveillant. VirusTotal utilise
`a ce jour 49 produits anti-virus. Le r´esultat des analyses de chaque anti-virus
est ensuite retourn´ee `a l’utilisateur. AndroTotal [2] est un autre outil similaire
`a VirusTotal. Comme son nom l’indique, AndroTotal est uniquement d´edi´e `a
l’analyse d’application Android alors que VirusTotal n’impose aucune restriction
sur le type de fichier `a analyser. Ce type d’outil peut s’av´erer utile pour
identifier rapidement des ´echantillons de malware. Zhou et al. ont par exemple
utilis´e VirusTotal afin de classifier les ´echantillons de malware qu’ils ont analys´e
dans [113].
2.8.2.3 Analyse dynamique d’application
Analyser dynamiquement une application consiste `a l’ex´ecuter pour observer
son comportement. L’ex´ecution se fait g´en´eralement `a l’int´erieur d’un environnement
virtuel simulant un environnement d’ex´ecution tel qu’un syst`eme
d’exploitation ou une machine. Ils existent plusieurs environnements d’analyse
d’application Android. Certains d’entre eux sont disponibles via leur code source
(ex : DroidBox) ou en tant que service en ligne (ex : Andrubis). Ils ont souvent
une base commune d’informations surveill´ees : permissions utilis´ees, appels de
fonction sensible de l’API Android, composants de l’application qui ont ´et´e
ex´ecut´ees, acc`es aux syst`emes de fichier, communications r´eseaux, et ´emissions
d’appel et SMS.
Pour observer toutes ces informations, les auteurs de ces outils ont recours
`a diff´erentes techniques : r´e´ecriture de code, suivi de flux d’information, observation
des appels syst`eme, introspection de l’environnement virtuel d’ex´ecution
et stimulation d’entr´ee.2.8. ANALYSE D’APPLICATIONS ANDROID 51
La r´e´ecriture de code consiste `a injecter le code n´ecessaire `a l’analyse dans
l’application avant de l’ex´ecuter. Durant l’ex´ecution, le code inject´e renseignera
sur les comportements d’int´erˆet. Les auteurs de DroidBox ont par exemple opt´e
pour cette m´ethode afin d’observer les appels aux diff´erentes fonctions sensibles
de l’API Android.
Le suivi de flux d’information permet d’observer comment une information
se propage dans un environnement donn´e. Un appareil Android contient un certain
nombre d’informations sensibles (ex : liste de contact) dont l’usage par une
application aurait une certaine utilit´e pour un analyste. Andrubis, AppsPlayground
et DroidBox int`egrent ainsi TaintDroid afin de suivre les flux d’information
dans les applications Android pour d´etecter toute fuite d’information.
DroidScope a son propre moniteur de flux d’information
Ces environnements d’analyse dynamique d’application peuvent ˆetre fournis
sous deux formes. Soit leurs auteurs fournissent un acc`es en tant que service,
l’analyse est effectu´ee en soumettant l’application `a analyser et l’utilisateur
r´ecup`ere le r´esultat de l’analyse sous forme de page web ou de fichiers XML ou
JSON, soit ils fournissent l’environnement en t´el´echargement afin que l’utilisateur
l’ex´ecute sur sa proche machine.
DroidBox [7] est un environnement d’analyse dynamique d’application Android
`a t´el´echarger et ex´ecuter sur sa propre machine. Durant l’ex´ecution de
l’application, l’outil enregistre les communications r´eseaux effectu´ees par l’application,
les acc`es aux fichiers, les services lanc´es, les composants Broadcast Receiver,
les classes charg´ees, les op´erations cryptographiques via l’API Android,
les messages et les appels ´emis. Afin de suivre le rythme d’´evolution d’Android,
DroidBox instrumente le code des applications pour intercepter l’appel des fonctions
d’int´erˆet. DroidBox int`egre ´egalement une version de TaintDroid afin de
d´etecter les ´eventuelles fuites d’information sensible. Son rapport int`egre ainsi
les fuites d’information via le r´eseau et par SMS que l’application aurait pu faire.
Le lancement de l’application est automatique mais il appartient `a l’utilisateur
d’interagir avec l’application.
Andrubis [100], version Android d’Anubis, est un service d’analyse d’application
en ligne. Il fournit les mˆemes types d’information que DroidBox. Si
DroidBox se limite aux fonctions de l’API Android, Andrubis lui consid`ere le
fait que les applications puissent ´egalement utiliser du code natif. Ils enregistrent
ainsi dans leur rapport l’usage des appels syst`eme utilis´es par l’application. Une
autre diff´erence par rapport `a DroidBox est la g´en´eration d’´ev`enements afin de
couvrir tout le code. DroidBox se contente de lancer l’application en ex´ecutant
son Activity principal. Andrubis prend en compte le fait que chaque composant
d’une application est un point d’entr´ee du programme et essaie de tous les
lancer.
D’apr`es l’´etude effectu´ee par Neuner et al. dans [77], DroidBox aurait ´et´e utilis´e
comme base pour d’autres environnements d’analyse tels qu’ANANAS [44]
et Mobile Sandbox [94]. Il existe ´egalement d’autres environnements ind´ependants
de DroidBox tels que SmartDroid [111], CopperDroid [88], DroidScope [106]
AASandbox [25] etc.52 CHAPITRE 2. ETAT DE L’ART ´
1 .method public onClick(Landroid/view/View;)V .locals 5
2 .parameter "v"
3 .prologue const v4, 0x7f050004
4 const/4 v3, 0x4
5 const/4 v2, 0x0
6 .line 92 iget-object v0, p0,
7 Lcom/example/android/jetboy/JetBoy;->mJetBoyThread:
8 Lcom/example/android/jetboy/JetBoyView$JetBoyThread;
9 invoke-virtual {v0},
10 Lcom/example/android/jetboy/JetBoyView$JetBoyThread;
11 ->getGameState()I
12 move-result v0
13 const/4 v1, -0x1
14 if-ne v0, v1, :cond_0
15 .line 93 iget-object v0, p0,
16 Lcom/example/android/jetboy/JetBoy;->
17 mButton:Landroid/widget/Button;
18 const-string v1, "PLAY!"
19 invoke-virtual {v0, v1},
20 Landroid/widget/Button;->setText(Ljava/lang/CharSequence;)V
21 .line 94 iget-object v0, p0,
22 Lcom/example/android/jetboy/JetBoy;->mTextView:
23 Landroid/widget/TextView;
24 invoke-virtual {v0, v2},
25 Landroid/widget/TextView;->setVisibility(I)V
26 .line 96 iget-object v0, p0,
27 Lcom/example/android/jetboy/JetBoy;->mTextView:
28 Landroid/widget/TextView;
29 invoke-virtual {v0, v4},
30 Landroid/widget/TextView;->setText(I)V
31 .line 97 iget-object v0, p0,
32 Lcom/example/android/jetboy/JetBoy;->mJetBoyThread:
33 Lcom/example/android/jetboy/JetBoyView$JetBoyThread;
34 invoke-virtual {v0, v2},
35 Lcom/example/android/jetboy/JetBoyView$JetBoyThread;->
36 setGameState(I)V
Listing 2.5 – Extrait du code smali de l’application JetBoy2.8. ANALYSE D’APPLICATIONS ANDROID 53
1 public void onClick(android.view.View p6)
2 {
3 if(this.mJetBoyThread.getGameState() != 15) {
4 ...
5 } else {
6 this.mButton.setText("PLAY!");
7 this.mTextView.setVisibility(0);
8 this.mTextView.setText(1.76787404569e+38);
9 this.mJetBoyThread.setGameState(0);
10 }
11 return;
12 }
Listing 2.6 – Extrait du code r´esultant de la d´ecompilation de l’application
JetBoy avec le d´ecompilateur par d´efaut d’Androguard54 CHAPITRE 2. ETAT DE L’ART ´
Nous avons pr´esent´e dans ce chapitre le syst`eme Android et introduit la base
de connaissance n´ecessaire pour comprendre notre approche. Au lieu de d´etecter
des sc´enarios d’attaque pr´ed´efinis, nous souhaitons en d´ecouvrir de nouvelles et
les d´etecter. La premi`ere ´etape `a l’atteinte de cet objectif est d’analyser les flux
d’information caus´es par les ´echantillons de malware Android. Pour observer
ces flux, nous utilisons un moniteur de flux d’information Blare que nous avons
port´e sous Android. Dans le chapitre suivant, nous pr´esentons ce moniteur et
expliquons les ajouts effectu´es `a Blare lors du portage sous Android.Chapitre 3
Blare : un moniteur de flux
d’information pour Linux et
Android
Pour suivre les flux d’information, nous utilisons Blare [37], un syst`eme de
d´etection d’intrusion param`etr´e par une politique de flux d’information. La politique
de flux d’information d´ecrit les flux autoris´es dans le syst`eme et l`eve une
larte `a chaque violation de la politique. Blare est bas´e sur un mod`ele d´ecrit en
section 3.1 et est impl´ement´e pour les syst`emes de type Linux comme d´ecrit
en section 3.3. Android int´egrant des fonctionnalit´es qui lui sont propres, le
premier apport de la th`ese a donc consist´e `a modifier Blare pour prendre en
compte certaines fonctionnalit´es d’Android. La prise en compte de ces fonctionnalit´es
donne une vue plus compl`ete des flux d’information sous Android. La
section 3.4 d´ecrit les modifications apport´ees `a Blare. Le r´esultat de ce portage,
AndroBlare, nous sert d’environnement d’analyse dynamique d’application afin
d’apprendre le comportement des applications `a partir des flux d’information
qu’elles causent dans le syst`eme. Dans la section 3.5, nous expliquons ainsi comment
nous analysons les applications dans cet environnement.
3.1 Mod`ele th´eorique
Le mod`ele th´eorique de Blare [55, 56] d´ecrit comment suivre et contrˆoler
les flux d’information au niveau du syst`eme. Pour suivre les flux d’information,
il utilise une m´ethode de marquage qui consiste `a marquer les objets selon
la nature de leur contenu. Il existe ainsi une distinction importante entre les
conteneurs d’information et leur contenu.
5556 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION
Taille 8 16 32 64
Intervalle r´2
7
, 2
7 ´ 1s r´2
15
, 2
15 ´ 1s r´2
31
, 2
31 ´ 1s r´2
63
, 2
63 ´ 1s
Table 3.1 – Intervalle de valeur du type int selon sa taille en bits
3.1.1 Conteneurs d’information
Blare suit les flux d’information au niveau du syst`eme d’exploitation. Il a
ainsi une vue des flux entre les objets du syst`eme. Le mod`ele de Blare d´efinit trois
types de conteneur d’information : les conteneurs persistants, les conteneurs volatiles
et les utilisateurs. Un conteneur persistant est un conteneur qui peut exister
sur plusieurs cycles d’ex´ecution du syst`eme. Un fichier est l’exemple typique
d’un conteneur persistant. Un conteneur volatile est conteneur qui n’existe que
le temps d’un cycle d’ex´ecution du syst`eme. Il n’est cr´e´e qu’apr`es le d´emarrage
du syst`eme et est d´etruit `a l’arrˆet. Les sockets sont des exemples de conteneurs
volatiles. Les utilisateurs sont les utilisateurs du syst`eme. A chacun de `
ces conteneurs sera associ´e un ensemble de marques ou tags qui permettent de
suivre et contrˆoler les flux d’information. Nous noterons par la suite C l’ensemble
des conteneurs d’information, PC l’ensemble des conteneurs persistants,
VC l’ensemble des conteneurs volatiles et U l’ensemble des utilisateurs.
3.1.2 Information et contenu courant d’un objet : itag
Il existe deux types d’information dans le mod`ele de Blare. Le premier
est l’information morte qui correspond `a toute donn´ee non ex´ecut´ee sur le
syst`eme. Le contenu d’un fichier est l’exemple typique d’une information morte.
Le deuxi`eme est l’information ex´ecut´ee qui correspond `a toute donn´ee ex´ecut´ee.
Nous ne la retrouvons que dans les processus car seuls les processus peuvent
ex´ecuter des donn´ees. A chaque donn´ee dont nous souhaitons contrˆoler la pro- `
pagation est associ´ee un entier unique l’identifiant. L’ensemble des identifiants
d’information morte est not´ee I “ t1, 2, . . .u et correspond l’ensemble des entiers
strictement positifs. L’ensemble des identifiants d’information ex´ecut´ee est not´ee
X “ t´1, ´2...u et correspond `a l’ensemble des entier strictement n´egatifs. En
th´eorie, il est possible de suivre autant d’information que souhait´e mais dans la
pratique l’impl´ementation imposera toujours une valeur maximale et minimale
des identifiants. Les identifiants sont repr´esent´es par des entiers sign´es de type
int dans la version actuelle de Blare. La taille des types varie selon l’architecture
du syst`eme (chapitre 11 de Linux Device Drivers [40]), ce qui rend impossible
de d´efinir une intervalle de valeur fixe pour les identifiants. Le tableau 3.1 liste
les intervalles de valeur pour un int selon le nombre de bits utilis´es pour le
stocker. Il est `a noter que le type int d´esigne un entier sign´e et le dernier bit
de sa repr´esentation en m´emoire est ainsi utilis´e pour coder son signe.
Si I et X sont deux ensembles distincts, il existe cependant une relation entre
leurs ´el´ements. Pour chaque ´el´ement n de I, ´n identifie la donn´e identifi´ee par
n lorsqu’elle est ex´ecut´ee dans un processus. Par exemple, si nous supposons que3.1. MODELE TH ` EORIQUE ´ 57
le contenu du fichier /system/bin/cat 1
est identifi´e par 1 alors le processus qui
ex´ecutera cat contiendra l’information identifi´ee par ´1.
Itag Le mod`ele de Blare marque chaque conteneur d’information par tag appel´e
itag pour caract´eriser son contenu. Sa valeur est un sous ensemble de I YX
et pour tout conteneur c, itagpcq “ ti1, . . . inu signigie que le contenu de c
contient les informations initialement identifi´ees par i1, . . . in.
@c P C, itagpcq P PpI Y Xq
3.1.3 Politique de flux d’information : pxqptag
Blare est param´etr´e par une politique de flux d’information. Cette politique
d´efinit les flux autoris´es entre les conteneurs d’information et est repr´esent´ee
par l’ensemble des ptags dans le syst`eme. A chaque conteneur d’information `
est ainsi associ´e un deuxi`eme tag : ptag. Le ptag d´efinit les diff´erents contenus
maximaux autoris´es pour le conteneur. Sa valeur est une collection de sousensemble
de I Y X et chacun de ses ´el´ements repr´esente un contenu maximal
l´egal pour le conteneur.
@c P C, ptagpcq P PpPpI Y Xqq
Le contenu courant d’un conteneur c est l´egal si itagpcq est inclus dans au
moins un des ´el´ements de ptagpcq. Le ptag d’un conteneur est nul par d´efaut. Le
conteneur n’a donc pas le droit d’acc´eder `a une donn´ee `a laquelle un identifiant
a ´et´e associ´e. Toute information n’ayant aucun identifiant associ´e est consid´er´e
comme non sensible et a le droit de se propager dans n’importe quel conteneur.
Le contenu de c est l´egal si De P ptagpcq tel que itagpcq Ď e
Par exemple, si le ptag d’un conteneur vaut tt1, 2u, t2, 3uu cela signifie que
l’ensemble des contenus l´egaux possibles pour ce conteneur sont H, t1u, t2u,
t3u, t1, 2u et t2, 3u.
Politique d’un programme, politique d’un processus : xptag
Une distinction importante est faite entre programme et processus. Toute
donn´ee pouvant ˆetre ex´ecut´ee dans le syst`eme est un programme tandis qu’un
processus est une instance d’un programme ou plus pr´ecis´ement une entit´e
ex´ecutant un programme. Le contenu d’un fichier com.android.browser.dex
est un exemple de programme Android et le processus com.android.browser
est une instance de ce programme.
1. cat est une application en ligne de commande qui concat`ene et affiche le contenu de
fichiers58 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION
USER PID PPID NAME
root 1 0 /init
drm 179 1 /system/bin/drmserver
media 180 1 /system/bin/mediaserver
install 181 1 /system/bin/installd
keystore 183 1 /system/bin/keystore
radio 186 1 /system/bin/netmgrd
nobody 187 1 /system/bin/sensors.qcom
root 190 1 /system/bin/thermal-engine-hh
root 1678 1 /system/xbin/su
Figure 3.1 – Extrait de la sortie de la commande ps sous Android 4.4
xptag La politique d’un programme est exprim´ee par un troisi`eme tag appel´e
xptag qui est attach´e au conteneur stockant le programme. Tout comme le ptag,
le xptag est ´egalement une collection de sous-ensemble de I Y X. Il n’est pas
utilis´e pour v´erifier la l´egalit´e d’un contenu mais plutˆot `a calculer la valeur du
ptag des processus.
@c P C, xptagpcq P PpPpI Y Xqq
Un processus est une instance d’un programme `a l’ex´ecution. Dans les syst`emes
Unix/Linux, les processus peuvent ˆetre list´es avec la commande ps. La figure 3.1
pr´esente un extrait de la sortie de la commande ps sous Android. Les informations
d’int´erˆet sont celles de la premi`ere, la deuxi`eme et la derni`ere colonnes.
Chaque ligne liste des informations sur un processus. La premi`ere colonne identi-
fie l’utilisateur ex´ecutant le processus. La deuxi`eme colonne liste les identifiants
des processus. Enfin la derni`ere colonne liste les programmes ex´ecut´es par les
processus. Ainsi, le programme /init est ex´ecut´ee par l’utilisateur root dans
le processus identifi´e par 1.
Un processus ´etant le r´esultat de l’ex´ecution d’un programme par un utilisateur,
sa politique est calcul´ee `a partir de celle de l’utilisateur et celle du
programme qu’il ex´ecute. Nous noterons execpc, uq le processus r´esultant de
l’ex´ecution du programme c par l’utilisateur u par la suite. Plus pr´ecis´ement, la
politique d’un processus r´esulte de l’intersection de la politique de l’utilisateur
et de celle du programme qu’il souhaite ex´ecuter. Soient un programme c et un
utilisateur u. La politique associ´ee au processus execpc, uq est l’intersection des
´el´ements de la politique de c avec ceux de la politique de u.
@p P P rog et @u P U, ptagpexecpc, uqq “ tec X euu, ec P ptagpcq et eu P ptagpuqu
Parmi les processus list´es par la commande ps dans la figure 3.1 se trouve un
processus ex´ecut´e par l’utilisateur media et ex´ecutant le programme dans le fi-3.1. MODELE TH ` EORIQUE ´ 59
chier /system/bin/mediaserver. En supposant que la politique associ´ee respectivement
au programme et `a l’utilisateur soit tt1, 2, 3u, t3, 4uu et tt2, 3, 5u, t5, 12uu,
alors la politique associ´ee au processus serait tt2, 3uu. Cet unique ´el´ement de
la politique r´esulte de l’intersection du premier ´el´ement de la politique du programme
avec celui de l’utilisateur. Les autres intersections sont toutes vides.
Cela signifie que le processus peut contenir tout au plus les informations identifi´ees
par 2 et 3.
3.1.4 Suivi et contrˆole de flux d’information
Le contenu courant d’un objet et sa politique de flux sont repr´esent´es respectivement
par l’itag et le ptag attach´es `a l’objet. L’itag caract´erisant le contenu
courant d’un objet, sa valeur ´evoluera en fonction de l’´evolution du contenu de
l’objet auquel il est attach´e. Le ptag par contre lui n’´evoluera que si la politique
de flux d’information n’´evolue. Le suivi et le contrˆole de flux d’information se
fait en deux ´etapes. La premi`ere ´etape consiste `a la mise `a jour de l’itag de
l’objet dont le contenu a ´et´e modifi´e suite au flux observ´e. La deuxi`eme ´etape
consiste `a v´erifier la l´egalit´e du flux observ´e. Un flux est l´egal si le contenu
des objets modifi´es par le flux est l´egal. La v´erification de la l´egalit´e se fait en
comparant la nouvelle valeur de l’itag de l’objet modifi´e suite au flux avec la
politique associ´ee `a l’objet, `a savoir son ptag.
3.1.4.1 Suivi de flux d’information
Blare observe les ´ev`enements du syst`eme provoquant des flux d’information
et `a chaque flux observ´e, il met `a jour l’itag des objets dont le contenu a ´et´e
modifi´e par le flux. Ces flux peuvent ˆetre class´es dans diff´erents groupes comme
list´e dans le tableau 3.2. Chaque ligne d´ecrit l’interaction entre deux objets du
syst`eme causant un flux d’information et la mani`ere dont les tags sont mis `a
jours quand Blare observe le flux. Non seulement l’itag de l’objet modifi´e est
mis `a jour mais aussi son xptag, sauf dans le cas de l’ex´ecution d’un programme.
Le xptag repr´esente la politique d’un programme. Or un programme est une
donn´ee stock´ee dans un conteneur. Un programme peut ainsi ˆetre propag´e dans
le syst`eme lors des flux d’information. Afin de s’assurer que la politique d’un
programme reste associ´ee `a ce programme malgr´e le fait qu’il puisse ˆetre copi´e
dans d’autres conteneurs, Blare propage le xptag des fichiers en mˆeme temps
que l’itag du fichier.
A chaque fois Blare observe un flux d’information, il effectue une suraproxi- `
mation du flux observ´e. Il consid`ere le pire des cas qui est que le contenu entier
de la source du flux d’information s’est propag´e vers le conteneur destination.
Nous expliquons ci-dessous ces mises `a jour effectu´ees par Blare list´ees dans le
tableau 3.2.
Lorsqu’un processus p lit le contenu d’un conteneur f, Readpp, fq, Blare
consid`ere que le contenu de f s’est propag´e dans p. Le contenu du processus
est modifi´e par le flux et son itag change de valeur. Le pire des cas ´etant que
tout contenu de f se soit propag´e dans p, Blare consid`ere alors que le nouveau60 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION
Type d’´ev`enement Description Mise `a jour des tags
Readpp, fq Lecture de f par p itagppq Ð itagppq Y itagpfq
xptagppq Ð xptagpfq X xptagppq
W ritepp, fq Ecriture de ´ f par p itagpfq Ð itagppqzX
xptagpfq Ð xptagppq
W riteapppp, fq Ecriture de ´ f par p itagpfq Ð pitagppqzXq Y itagpfq
xptagpfq Ð xptagpfq X xptagppq
Execpp, fq Ex´ecution du
contenu de f par p
itagppq Ð t´nu, n P itagpfq
ptagppq Ð xptagpfq
Table 3.2 – Blare : m´ethode de suivi de flux
contenu de p est un m´elange de son ancien contenu et du contenu de f. La
nouvelle valeur de l’itag de p est donc l’union de son ancien itag avec celui
de f. L’exemple typique de ce type de flux est la lecture d’un fichier par un
processus. Les fichiers ne sont cependant pas les seuls conteneurs d’information
du syst`eme `a partir duquel un processus peut lire des donn´ees. Un processus
peut ´egalement lire des donn´ees `a partir d’un socket ou d’un message via les files
de message [65]. Le conteneur f ne repr´esente donc pas uniquement un fichier
mais tout autre conteneur `a partir duquel un processus peut lire des donn´ees.
Lorsqu’un processus p ´ecrit dans un conteneur f, W ritepp, fq, Blare consid`ere
que les informations dans p se propagent vers le conteneur f. Le contenu de f
change et Blare met `a jour son itag. Le pire des cas ´etant que tout le contenu
de p se propage dans f, le nouveau contenu de f est en cons´equent un m´elange
de son ancien contenu avec le contenu de p `a l’exception des donn´ees ex´ecut´ees.
Blare consid`ere qu’un processus ne propage pas le code qu’il ex´ecute. Les identi-
fiants n´egatifs ne sont donc pas propag´es dans l’itag du destinataire. La nouvelle
valeur de l’itag de f est ainsi l’union de son ancienne valeur avec l’ensemble des
identifiants positifs dans l’itag de p.
Comme expliqu´e en section 3.1.2, les donn´ees sensibles ex´ecut´ees dans un
processus sont identifi´ees par un entier strictement n´egatif. Lorsqu’un processus
ex´ecute un programme, Blare consid`ere que son contenu courant est remplac´e
par le code provenant du fichier contenant le programme. Son itag devient ainsi
l’ensemble des valeurs n´egatives des identifiants pr´esents dans l’itag du fichier.
Les interactions entre les objets d’un syst`eme ne se limite `a la lecture, ´ecriture
et l’ex´ecution. D’autres ´ev`enements tels que la cr´eation de conteneur ou l’envoi
de signaux existent ´egalement. Ces ´ev`enements n’engendrent pas de flux
d’information explicites entre les objets et sont ignor´es par Blare. Il est cependant
techniquement possible de se servir de ces ´ev`enements pour faire fuir des
informations et ainsi ´echapper au contrˆole effectu´e par Blare.
3.1.4.2 Contrˆole de flux d’information
Un flux d’information est l´egal si le contenu de l’objet qui a ´et´e modifi´e par
le flux est l´egal. Le contrˆole d’un flux d’information se fait en deux ´etapes.3.1. MODELE TH ` EORIQUE ´ 61
c1 c2 ptag = {{1, 2, 3}} ptag = {{1,2}, {2,3}}
itag = {3} itag = {1}
c1 c2 ptag = {{1,2}, {2,3}}
itag = {3} itag = {1,3}
c1 c2 ptag = {{1,2}, {2,3}}
itag = {3} itag = {1,3}
(a)
(b)
(c)
ptag = {{1, 2, 3}}
ptag = {{1, 2, 3}}
Figure 3.2 – Exemple de contrˆole de flux d’information effectu´e par Blare
1. Mise `a jour de l’itag de l’objet dont le contenu a ´et´e chang´e.
2. Contrˆole de la l´egalit´e du nouveau contenu de l’objet modifi´e par le flux.
Si le contenu est ill´egal alors, Blare consid`ere que le flux observ´e est ill´egal
et l`eve une alerte.
La figure 3.2 illustre un exemple de contrˆole de flux lorsque Blare observe la
lecture d’un fichier c1 par un processus c2. (a) Les deux conteneurs sont marqu´es
pr´ealablement avant la lecture. (b) Lors de la lecture du fichier, Blare consid`ere
que le contenu de c1 se propage vers c2. Il met ainsi `a jour la valeur de itagpc2q
comme d´ecrit dans le tableau 3.2 pour la lecture de fichier. La valeur de itagpc2q
devient t2, 3u. (c) Apr`es la mise `a jour de l’itag, Blare contrˆole la l´egalit´e du
nouveau contenu afin de d´eterminer si le flux observ´e est l´egal ou non. Il n’existe
pas d’´el´ement de ptagpc2q qui inclut itagpc2q. Le nouveau contenu est ill´egal, ce
qui signifie que le flux observ´e est ill´egal. Une alerte est donc lev´ee.
Blare est outil de d´etection d’intrusion param´etr´e par une politique de flux
d’information. Pour d´etecter une intrusion, il faut ainsi dans un premier temps
d´efinir une politique de s´ecurit´e qui identifie les informations `a prot´eger et o`u
ces informations ont le droit de se propager. Dans la section suivante, nous
pr´esentons une mani`ere de d´efinir cette politique de flux sous Android.62 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION
3.2 D´efinition d’une politique de flux d’information
Prot´eger un syst`eme avec un outil tel que Blare signifie qu’il faut dans un
premier temps d´efinir une politique de s´ecurit´e. Dans le cas de Blare, cette
politique est une politique de flux d’information. Elle identifie les informations
`a prot´eger et comment les prot´eger, c’est-`a-dire la liste des conteneurs o`u elles
ont le droit de se propager. D´efinir une politique de flux d’information pour
Blare se r´esume en quatre ´etapes.
1. Identifier les informations sensibles `a prot´eger.
2. Associer `a chacune de ces informations un identifiant unique.
3. Identifier les conteneurs l´egaux pour ces informations.
4. D´efinir la valeur des ptags `a associer `a ces conteneurs.
Il existe deux approches pour d´efinir la politique de s´ecurit´e. La premi`ere
consiste `a la calculer `a partir d’une autre politique existante telle qu’une politique
de contrˆole d’acc`es. Dans [56], Geller et al. ont propos´e un algorithme
qui transforme une politique de contrˆole d’acc`es mandataire App Armor en une
politique de flux d’information Blare. Les politiques App Armor d´efinissent des
profils de programme limitant leur acc`es aux autres objets du syst`eme tels que
les fichiers. L’algorithme propos´e prend en entr´ee un ensemble de profils App
Armor et donne en sortie leur ´equivalent en terme de politique Blare. Cette
approche a le m´erite d’ˆetre automatique et rapide mais elle ne permet pas d’exploiter
toute l’expressivit´e d’une politique Blare. Un exemple de ce manque
d’expressivit´e est la restriction sur les m´elanges d’information. Un conteneur a
le droit d’acc´eder aux informations i et j mais n’a pas le droit de les m´elanger,
c’est-`a-dire que le conteneur contient soit i soit j mais pas les deux en mˆeme
temps. Le listing 3.1 pr´esente une politique App Armor pour le programme
apache. Cette politique autorise le programme `a lire le contenu des fichiers
apache2.conf et index.php. La politique de flux qui peut ˆetre d´eduite de cette
politique est que les donn´ees dans les deux fichiers ont tout deux le droit de se
propager vers le programme apache. Cependant, le propri´etaire du contenu de
ces deux fichiers peut souhaiter que le contenu de ces fichiers ne se m´elangent
pas. Cette contrainte ne peut-ˆetre exprim´ee avec une politique App Armor et
une politique de flux exprimant une telle restriction ne peut donc ˆetre calcul´ee
`a partir d’une politique App Armor.
{/usr/bin/apache,
{(/etc/apache2.conf, w),
(/etc/apache2.conf, r),
(/www/index.php,r), (/usr/bin/ftpd, px)}
}
Listing 3.1 – Exemple de politique App Armor3.2. DEFINITION D’UNE POLITIQUE DE FLUX D’INFORMATION ´ 63
La deuxi`eme approche consiste `a d´efinir manuellement la politique de flux
d’information. Cette approche est plus longue car elle implique une analyse
compl`ete du syst`eme mais permet d’exploiter toute l’expressivit´e d’une politique
Blare.
Construction manuelle d’une politique pour Android
Dans [16], nous avons propos´e une politique de flux d’information pour le
syst`eme Android. La politique a ´et´e construite `a la main en se basant sur une
analyse manuelle du syst`eme. Le but ´etait de fournir une politique `a taille r´eelle
pour un syst`eme entier. Comme ´ecrit pr´ec´edemment, la d´efinition d’une politique
de flux se fait en quatre ´etapes.
La premi`ere ´etape est l’identification des informations sensibles `a surveiller.
Nous avons construit la liste des informations sensibles `a partir des donn´ees que
nous avons jug´ees sensibles sur le syst`eme Android. Ces informations incluent les
donn´ees li´ees `a l’utilisateur (ex : liste de contact et donn´ees de g´eolocalisation)
mais aussi celles li´ees aux applications (ex : code et param`etres de configuration).
Les donn´ees sensibles ont ´et´e identifi´ees en analysant manuellement le contenu
des fichiers sur le syst`eme et en prenant en compte celles qui sont prot´eg´ees par
le m´ecanisme de permission. Notre politique recense 150 informations sensibles
m´elangeant donn´ees non ex´ecut´ees et code ex´ecut´e `a l’int´erieur des processus. Il
existe encore plus d’information sur un syst`eme Android 2 mais nous avons jug´e
cette quantit´e d’information `a surveiller suffisante pour construire une politique
de flux d’information pour tout un syst`eme.
La deuxi`eme ´etape consiste `a identifier les conteneurs d’information. La liste
des fichiers et programmes install´ees sur un syst`eme Android est assez simple `a
construire. Grˆace `a la commande find, nous pouvons lister tous les fichiers du
syst`eme. Quant aux applications, les applications livr´ees sous forme d’apk sont
connues grˆace `a la commande pm et les applications natives sont stock´ees dans
/system/bin et /system/xbin. La liste des utilisateurs est elle par contre moins
´evidente `a construire car contrairement `a un syst`eme Linux standard, il n’existe
pas de fichier /etc/passwd ni de fichier /etc/shadow. Android d´efinit en dur
un ensemble restreint d’utilisateur n´ecessaire au fonctionnement de base du
syst`eme tels que root, radio et system. Puis pour chaque application non native
install´ee sur le syst`eme, il associe un utilisateur unique. Pour ´etablir la liste des
utilisateurs associ´es aux applications, nous nous sommes bas´es sur le contenu
des fichiers /data/system/packages.list ou /data/system/packages.xml.
Ils recensent les informations li´ees aux applications install´ees sur le t´el´ephone
dont l’utilisateur qui leur associ´e.
Une fois les donn´ees sensibles et conteneur identifi´es, nous avons ensuite
construit la politique de flux. La politique de chaque programme a ´et´e construite
en analysant ses sources pour comprendre `a quelles informations il acc`ede. La
politique de chaque utilisateur a ´et´e obtenue en faisant l’union des politiques
des programmes qu’il peut ex´ecuter. Dans la plupart des cas, il n’y aura qu’un
2. Il existe plus des milliers de fichiers r´eguliers lors de l’ex´ecution du syst`eme.64 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION
Identifiant des informations
11 -44 10 6 -55 -39 3 9 37 -37
Fichiers
calendar.db ˆ
contacts2.db ˆ ˆ
mms.db ˆ
telephony.db ˆ
TelephonyProvider.apk ˆ
Programmes
com.android.calendar ˆ ˆ
com.android.providers.contact
ˆ ˆ ˆ
com.android.providers.telephony
ˆ ˆ ˆ
Utilisateurs
10024 ˆ ˆ
10004 ˆ ˆ ˆ ˆ
1001 ˆ ˆ ˆ
Table 3.3 – Un extrait de la politique de flux d’information
seul programme car en dehors des utilisateurs syst`eme les autres utilisateurs
n’ex´ecuteront que l’application `a laquelle ils ont ´et´e associ´es. La politique des
fichiers a ´et´e construite `a partir des donn´ees qu’elles contiennent lors de l’analyse
et de la politique des programmes qui y acc`edent. Si une donn´ee sensible a ´et´e
trouv´ee dans un fichier, nous avons suppos´e que ce fichier avait le droit de
contenir la donn´ee. A ces donn´ees s’ajoutent celles auxquelles les applications `
qui ont le droit d’´ecriture au fichier peuvent acc´eder. Nous avons suppos´e que
toute application avait le droit de stocker les donn´ees contenues dans les fichiers
auxquels l’application a un acc`es l´egal. G´en´eralement, il s’agit des fichiers dans
le r´epertoire local de l’application. Pour les 150 informations identifi´ees lors de
la premi`ere ´etape, nous avons identifi´e 186 conteneurs d’information pouvant
acc´eder `a ces informations o`u les stocker. La politique contient donc 186 ptags.
La politique finale a ´et´e repr´esent´ee sous la forme d’une matrice dont un
extrait est pr´esent´ee dans le tableau 3.3. Le chemin complet des fichiers a ´et´e
omis pour une meilleure lisibilit´e. Une croix `a l’intersection d’une ligne et d’une
colonne signifie que le conteneur correspondant `a la ligne a le droit de stocker
l’information correspondant `a la ligne. L’ensemble des croix sur une ligne l
d´etermine ainsi le contenu maximal autoris´e pour le conteneur correspondant `a
l. L’utilisateur 10004 (avant derni`ere ligne) a par exemple le droit d’acc´eder aux
informations identifi´ees par 6, 10, ´39 et ´55. Autrement dit, son ptag vaut
tt´55, ´39, 6, 10uu.
Si la pertinence de la politique n’a pas ´et´e ´evalu´ee dans ce travail, le travail
effectu´e a cependant permis de mettre en ´evidence deux points. Le premier est3.3. KBLARE : SUIVI ET CONTROLE DE FLUX VIA LSM ˆ 65
la difficult´e de la cr´eation de la politique `a la main car elle a n´ecessite une
analyse compl`ete du syst`eme pour identifier les informations sensibles et leurs
conteneurs l´egaux. Le deuxi`eme point est le nombre d’information sensible sur
le syst`eme. Contrairement `a ce que les permissions Android pourraient laisser
croire, il peut y avoir un nombre assez cons´equent d’information sensible sur le
syst`eme. La politique que nous avons construite recense 150 informations mais
il y a encore plus d’information que cela dans un syst`eme.
3.3 KBlare : suivi et contrˆole de flux via LSM
Le cœur de Blare a ´et´e d´evelopp´ee en tant que module de s´ecurit´e Linux.
Il r´eside dans le noyau et est appel´e KBlare. Dans le reste du document, nous
d´esignons par KBlare l’impl´ementation de Blare dans le noyau et Blare tout
l’environnement d’ex´ecution Blare (KBlare plus les outils en espace utilisateur
li´e `a Blare). Les flux d’information au niveau du syst`eme se font via les interactions
entre les objets du syst`eme et plus pr´ecis´ement via les appels syst`eme
effectu´es par les processus. Pour contrˆoler les flux d’information, KBlare intercepte
ainsi les appels syst`eme en utilisant les hooks LSM [103, 102]. LSM est
un framework de s´ecurit´e dans le noyau utilis´e pour impl´ementer les modules
de s´ecurit´e Linux. Les hooks sont des appels aux modules de s´ecurit´e du noyau.
Ils sont plac´es dans le flux d’ex´ecution des appels syst`eme afin que les modules
de s´ecurit´e puisse intercepter et contrˆoler ces appels. Pour intercepter un appel
syst`eme, un module de s´ecurit´e enregistre une fonction `a associer au hook correspondant
`a l’appel syst`eme. A chaque fois que ce ` hook est atteint, le noyau
appelle la fonction enregistr´ee afin que le module de s´ecurit´e effectue le contrˆole
souhait´e.
La figure 3.3 illustre le fonctionnement g´en´eral de LSM. Lors d’un appel
syst`eme, le noyau v´erifie si l’acc`es demand´e est autoris´e pour le processus effectuant
l’appel. Il commence par v´erifier la conformit´e avec la politique DAC
du syst`eme. Ensuite, il donne la main `a LSM qui lui demande au module de
s´ecurit´e actif 3
s’il autorise ou non l’acc`es demand´e. Cette ´etape correspond au
moment o`u un hook est atteint dans le flux de traitement de l’appel syst`eme.
La fonction enregistr´ee au hook est ainsi appel´ee et statue si l’acc`es est autoris´e.
Lorsqu’un processus fait un appel syst`eme, KBlare intercepte l’appel, calcule le
flux correspondant, met `a jour les tags des objets modifi´es et contrˆole la l´egalit´e
du flux observ´e. KBlare se contente cependant de d´etecter les intrusions mais ne
les pr´evient pas. Mˆeme en cas de violation de la politique de flux d’information,
il autorise le noyau `a continuer le traitement de l’appel syst`eme.
Le tableau 3.4 liste les hooks utilis´es par KBlare dont l’op´eration correspondante
peut engendrer des flux d’information. La premi`ere colonne liste les
hooks, le deuxi`eme les op´erations intercept´ees via le hook et la derni`ere colonne
les types de flux que KBlare peut observer. D’autres hooks sont utilis´es pour
le fonctionnement interne de KBlare mais les op´erations correspondantes n’induisent
aucun flux d’information.
3. En g´en´eral un seul module LSM est actif66 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION
process
Syscall #n
Security
module
DAC
LSM
User space
Kernel space
exec syscall
authorize?
Figure 3.3 – Design de Linux Security Module3.3. KBLARE : SUIVI ET CONTROLE DE FLUX VIA LSM ˆ 67
Hook Op´eration Flux possible observ´e
file permission Lecture/´ecriture `a un fi-
chier ouvert
Entre le processus et le
fichier acc´ed´e
file mmap Chargement en m´emoire
du contenu d’un fichier
Du fichier vers le processus
inode permission Acc`es `a un i-node Entre un pipe et un processus
bprm set creds Ex´ecution d’une application
native
Du fichier contenant
l’application vers le
processus
socket sock rcv skb R´eception d’un paquet
r´eseau
De paquet re¸cu vers le
processus
socket sendmsg Envoi d’un message
dans un socket r´eseau
Du processus vers le socket
et le paquet
socket recvmsg R´eception d’un message
via un socket
Du socket vers le processus
unix may send Envoi d’un message via
un socket UNIX
Du processus vers le socket
UNIX
msg queue msgrcv R´eception d’un message
via une file de message
Du processus vers le
message envoy´e
msg queue msgsnd Envoi d’un message
dans une file de message
Du message re¸cu vers
le processus destinataire
du message
Table 3.4 – Liste des hooks LSM utilis´es par KBlare pouvant engendrer un flux
d’information
Stockage des tags
KBlare repr´esente les tags des objets du syst`eme avec des structures contenant
l’itag, le ptag et le xptag associ´es aux objets. En dehors des hooks, LSM a
´egalement modifi´e les structures repr´esentant les objets du syst`eme pour ajouter
un champ appel´e security. Ce champ est un pointeur g´en´erique destin´e `a
ˆetre utilis´e par les modules de s´ecurit´e. KBlare utilise ce champ pour stocker le
pointeur vers la structure repr´esentant les tags.
Les structures repr´esentant l’ensemble des tags existent uniquement en m´emoire
et n’existent donc que le temps d’un cycle d’ex´ecution du syst`eme. Afin
de stocker de mani`ere persistante les tags associ´es aux fichiers, KBlare stocke
´egalement leurs tags dans les attributs ´etendus des fichiers. Les attributs ´etendus
sont des zone de m´emoire sur le disque qui sont utilis´ees par les syst`emes de
fichier pour stocker des m´eta-donn´ees li´ees aux fichiers.68 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION
KBlare contrˆole les flux d’information en interceptant les appels syst`eme
et pour intercepter les appels syst`eme il utilise les hooks LSM. Ces appels permettent
les interactions entre les objets du syst`eme : acc`es aux fichiers, ex´ecution
de code natif et communication entre processus. Le noyau d’Android est bas´e
sur celui de Linux mais contient des fonctionnalit´es en plus. Dans la section
suivante, nous pr´esentons comment nous avons modifi´e KBlare afin de prendre
en compte les fonctionnalit´es sp´ecifiques `a Android.
3.4 AndroBlare : Blare sous Android
Le premier apport de cette th`ese est le portage de Blare sous Android. Nous
avons montr´e pr´ec´edemment que Blare contrˆolait les flux d’information traduisant
les acc`es aux fichiers, les ex´ecution de code et les communications entre
processus. Ces contrˆoles sont bas´es uniquement sur les interactions possibles
entre les objets du syst`eme sous Linux. Or, Android int`egre des fonctionnalit´es
qui lui sont propres pouvant engendrer des flux d’information. Ces fonctionnalit´es
sont l’ex´ecution des applications par les machines virtuelles Dalvik et les
communications via le Binder.
Le Binder est un m´ecanisme de communication impl´ement´e principalement
dans le noyau Android. Il est la base des communications entre processus propos´es
par le framework Android tels que les intents. Android n’utilise pas
les m´ecanismes de communication offerts par Linux. Les communications entre
applications ´etaient donc invisibles `a KBlare.
Les applications que nous avons d´esign´ees par la couche Applications sur
la figure 2.1 sont livr´ees sous la forme de dalvik bytecode et interpr´et´ees par la
machine virtuelle Dalvik. Elles ne sont donc pas ex´ecut´ees de mani`ere native.
A leur ` ex´ecution, le processus contenant la machine virtuelle qui va interpr´eter
le code n’effectue pas d’appel syst`eme execve mais se contente de lire puis
charger le code de l’application en m´emoire. Aucun appel syst`eme traduisant
l’ex´ecution d’une application n’ayant lieu, KBlare ne voyait donc pas l’ex´ecution
des applications. En cons´equent, aucune politique ne pouvait ˆetre appliqu´ee aux
applications Android et aucun processus n’´etait marqu´e comme ex´ecutant une
application lorsque le code de cette application ´etait associ´ee `a un identifiant.
Limitations de Blare
(1) Il n’y avait aucune visibilit´e sur les communications entre
applications Android.
(2) KBlare ne d´etectait pas l’ex´ecution des applications Android.
Les tags des processus n’indiquaient jamais l’ex´ecution
d’une application dont le code est sensible et aucune politique
ne pouvait ˆetre appliqu´ee aux applications.
Dans ce qui suit, nous pr´esentons comment nous avons modifi´e Blare pour
combler ce manque de visibilit´e au niveau des flux d’information sous An-3.4. ANDROBLARE : BLARE SOUS ANDROID 69
droid. Nous pr´esentons le fonctionnement du Binder puis comment nous avons
impl´ement´e le suivi des flux d’information via ce m´ecanisme. Ensuite, nous expliquons
comment les applications Android sont ex´ecut´ees et comment nous
avons ajout´e a prise en compte de leur ex´ecution dans Blare.
3.4.1 Communication entre processus : Binder
3.4.1.1 Fonctionnement
Les applications Android tournent dans des processus distincts mais communiquent
souvent entre elles grˆace `a divers m´ecanismes IPC tels que les intents
et les Content Providers. Ces m´ecanismes sont fournis par le framework Java
Android mais se basent tous `a un niveau plus bas sur le Binder. Le Binder est un
m´ecanisme IPC qui permet `a une application d’appeler une m´ethode distante,
c’est-`a-dire impl´ement´ee au sein d’une autre application tournant dans un autre
processus. Le cœur de ce m´ecanisme est impl´ement´e dans le noyau sous forme
de driver 4 dans le noyau. Par la suite nous adopterons les termes suivants. Le
Binder fait r´ef´erence au code du Binder dans le noyau. Un service est une application
dont les m´ethodes peuvent ˆetre appel´ees par d’autres applications. Un
client est une application qui appelle une m´ethode d’un service.
La figure 3.4 illustre le fonctionnement du binder lors de l’appel d’une
m´ethode distante. Tout client doit avoir une r´ef´erence du service impl´ementant
la m´ethode qu’il souhaite invoquer. Le client commence ainsi par demander la
r´ef´erence du service cibl´e `a un autre service appel´e Context. Context, impl´ement´e
sous Android par le Service Manager, est un service d’annuaire qui fait correspondre
`a chaque nom de service une r´ef´erence unique. Chaque service doit
s’enregistrer aupr`es du Service Manager afin que ses m´ethodes puissent ˆetre invoqu´ees
par d’autres applications. Lorsqu’un client souhaite obtenir la r´ef´erence
d’un service, il appelle ainsi la m´ethode getService du Service Manager en lui
donnant en argument le nom du service. Une fois la r´ef´erence du service obtenu,
le client appelle la m´ethode. L’invocation de la m´ethode n’est pas directe. Le
client ne communique pas directement avec le serveur mais transmet l’appel au
binder qui lui le transmet au serveur. Une fois l’appel re¸cu puis ex´ecut´e par le
serveur, ce dernier renvoie le r´esultat au binder qui lui le transmet au client.
3.4.1.2 Impl´ementation du Binder dans le noyau
Techniquement parlant, le Binder est impl´ement´e sous forme de driver dans
le noyau. Cela signifie qu’il est pr´esent´e dans l’espace utilisateur en tant que
fichier, /dev/binder, et que les seules interactions possibles sont des appels
syst`eme sur ce fichier. Le listing 3.2 liste les op´erations sur les fichiers, voir le
chapitre 3 de [40], support´es par Binder. Elles sont list´es dans une structure
appel´ee file operations qui associe `a chaque op´eration support´ee la fonction
correspondante. Par exemple, la valeur du champ open correspond `a la fonc-
4. /drivers/staging/android/binder.c70 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION
Client App Context Binder Driver Service App
get service
service ref
call func(param)
relay call func(param)
call return
relay call return
Figure 3.4 – Appel d’une m´ethode distante grˆace au Binder
tion, ici binder open, qui sera appel´ee `a chaque fois qu’un processus ouvre
/dev/binder.
Celle qui a int´erˆet pour nous est la fonction binder ioctl (listing 3.3). Elle
est appel´ee quand un processus effectue un appel syst`eme ioctl et prend les
arguments de l’appel syst`eme. Le deuxi`eme argument de la fonction, cmd, correspond
`a la commande `a ex´ecuter par le Binder. Binder reconnaˆıt 5 commandes.
— BINDER WRITE READ est la commande la plus importante. Elle sert `a l’envoi
et r´eception de donn´ees.
— BINDER SET MAX THREADS d´efinit le nombre maximal de threads par processus
pour traiter les messages re¸cus via le Binder.
— BINDER SET CONTEXT MGR d´efinit le Context Manager. Une fois d´efini, il
ne peut ˆetre modifi´e.
— BINDER THREAD EXIT notifie l’arrˆet d’un thread utilis´e pour le traitement
des messages re¸cus via le Binder.
— BINDER VERSION retourne le num´ero de version du Binder.
Lorsqu’un processus envoie la commande BINDER WRITE READ dans le but
d’envoyer des donn´ees, il d´efinit une deuxi`eme commande pr´ecisant le type
d’envoi. Il existe 14 commandes 5
li´ees `a l’envoi de donn´ees mais seules deux
d’entre elles correspondent `a l’envoi des transactions : BINDER TRANSACTION
et BINDER REPLY. BINDER TRANSACTION correspond `a l’´emission d’une transaction
d’un processus client appelant une m´ethode distante. BINDER REPLY correspond
`a l’envoi du r´esultat de l’appel par le processus ayant ex´ecut´e la fonction.
L’envoi d’un message ayant un de ces deux types initie l’appel `a la fonction
binder transaction qui impl´emente la troisi`eme et la cinqui`eme ´etapes de l’appel
d’une m´ethode distante comme d´ecrit sur la figure 3.4 : call func(param)
et call return. Toute action ex´ecut´ee par le noyau se fait dans le contexte
5. Voir la fonction binder thread write3.4. ANDROBLARE : BLARE SOUS ANDROID 71
d’un processus `a l’exception des interruptions 6
. Dans le cas des appels syst`eme,
le contexte d’ex´ecution est celui du processus ayant fait l’appel ce qui signifie
que l’envoi des transactions se fait dans le contexte de l’´emetteur.
Lorsque le Binder transmet une transaction `a un processus, il l’ajoute `a une
liste de tˆache `a traiter par ce processus. Les processus en attente de transaction
consultent ainsi cette liste de tˆache pour traiter les transactions qui lui ont
´et´e transmises grˆace `a la commande BINDER WRITE READ. Chacune des tˆaches a
un type d´efini. Il existe 6 types de tˆache en tout dont BINDER WORK TRANSACTION
qui correspond au traitement d’une transaction en attente. A la r´eception `
d’une tˆache de ce type, les informations li´ees `a la transaction sont envoy´ees au
processus en espace utilisateur afin qu’il puisse ex´ecuter l’appel.
Le Binder est le cœur des IPC sous Android mais son usage n’´etait pas
contrˆol´e par KBlare. Il y a deux raisons `a cela. La premi`ere est que son usage
se fait via l’appel syst`eme ioctl or KBlare n’utilise pas le hook permettant
d’intercepter cet appel. La deuxi`eme raison est que Binder est un m´ecanisme
propre `a Android. Aucun travail ne s’est donc int´eress´e `a ´etendre LSM afin de
pouvoir contrˆoler l’usage du Binder au moment o`u nous nous sommes int´eress´es
au Binder durant la th`ese. A cause de ces raisons, KBlare ignorait les flux `
d’information via le Binder et ne pouvait observer les communications entre
applications Android. Nous pr´esentons dans la section qui suit comment KBlare
a ´et´e ´etendu pour suivre les flux d’information caus´es par son usage.
1 static const struct file_operations binder_fops =
2 {
3 .owner = THIS_MODULE,
4 .poll = binder_poll,
5 .unlocked_ioctl = binder_ioctl,
6 .mmap = binder_mmap,
7 .open = binder_open,
8 .flush = binder_flush,
9 .release = binder_release,
10 };
Listing 3.2 – Liste des op´erations sur les fichiers support´ees par Binder
1 static long binder_ioctl(struct file *filp, unsigned int cmd, unsigned long arg);
Listing 3.3 – Signature de la fonction binder ioctl
6. Ce n’est jamais notre cas dans le Binder72 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION
3.4.2 Suivi de flux d’information dans le Binder
Pour suivre les flux d’information li´ees aux transactions via le Binder, deux
solutions ont ´et´e envisag´ees. La premi`ere solution est d’intercepter l’appel syst`eme
ioctl grˆace au hook file ioctl. Cette solution est limit´ee car elle ne
permettrait de voir que l’interaction entre les processus et /dev/binder. Or nous
avons expliqu´e que le v´eritable flux s’op´erait entre processus et non entre un
processus et /dev/binder. Cette limitation pourrait cependant ˆetre contourn´e
en impl´ementant tout le m´ecanisme de traitement des commandes envoy´ees via
ioctl au Binder mais cette approche est assez lourde.
La deuxi`eme solution, celle que nous avons retenu, consiste `a ´etendre LSM
afin de permettre aux modules de s´ecurit´e de contrˆoler l’envoi et la r´eception des
transactions via le Binder. L’extension de LSM que nous avons apport´e consiste
`a rajouter un champ security `a la structure repr´esentant les transactions et
deux nouveaux hooks pour intercepter l’envoi et la r´eception de transaction.
Tout comme les messages envoy´es dans les files de message, nous consid´erons que
les transactions sont des conteneurs volatiles. Nous avons ainsi ajout´e un champ
g´en´erique security `a la structure les repr´esentant. KBlare utilisera ensuite ce
champ pour r´ef´erencer les tags associ´es `a la transaction. Les deux nouveaux
hooks ont ´et´e rajout´es dans le code de Binder 7
. Quant aux hooks, nous les avons
ajout´e dans le corps du Binder pour intercepter les ´echanges de transaction.
Plus pr´ecis´ement, nous avons ajout´e un hook pour intercepter l’envoi d’une
transaction et une autre pour la r´eception. Sous Android, KBlare utilise ces
hooks pour suivre et contrˆoler les flux d’information 8 via le Binder.
Interception de l’envoi d’une transaction binder transaction write
Nous avons ins´er´e ce hook dans le corps de la fonction binder transaction.
Cette fonction est utilis´ee par Binder pour transmettre les transactions ´emises
par les processus. C’est dans cette fonction que la nouvelle tˆache correspondant
`a la transaction est ajout´ee `a la liste de tˆache en attente du destinataire. Le
hook est ins´er´e avant l’ajout de la nouvelle tˆache.
Dans KBlare, nous avons d´eclar´e une fonction correspondant `a ce hook qui
propage les tags du processus vers la transaction. La fonction cr´ee une instance
de la structure contenant le tag des conteneurs d’information, l’associe `a la transaction
et copie les tags du processus (itag et xptag) vers la structure contenant
les tags de la transaction. Nous consid´erons que les transactions ont le droit de
contenir n’importe quelle information. Aucun contrˆole n’est ainsi effectu´e.
Interception de la r´eception d’une transaction binder thread read
Le deuxi`eme hook est ins´er´e dans le corps de la fonction binder thread
read. Cette fonction est utilis´ee pour r´ecup´erer et transmettre au processus
destinataire en espace utilisateur les tˆaches dans la liste d’attente. La fonction
7. drivers/staging/android/binder
8. Fonctions correspondantes impl´ement´ees dans security/blare/binder ops.c3.4. ANDROBLARE : BLARE SOUS ANDROID 73
associ´ee `a ce hook propage les tags (itag et xptag) associ´es `a la transaction vers
le processus destinataire. Un contrˆole de la l´egalit´e du flux est effectu´ee. Si le flux
est ill´egal alors une alerte est lev´ee. Afin que l’alerte soit plus compr´ehensible,
le flux correspondant `a l’alerte est d´ecrite comme un flux de processus ayant
´emis la transaction vers le processus destinataire. De plus, une transaction est un
conteneur volatile impl´ement´e sous la forme d’une structure uniquement connue
du noyau. Sa description dans une alerte n’apportera ainsi aucune information
utile `a un analyste. Selon les transactions, les informations li´ees `a l’´emetteur ne
sont pas ajout´ees dans la transaction. C’est le cas, par exemple des r´eponses
retourn´ees par un appel distant. Nous avons modifi´e le Binder afin que cette
information soit toujours comprise dans la transaction.
Remarque sur le suivi de flux d’information dans le Binder
Une autre mani`ere de propager les tags entre les processus aurait ´et´e de
le faire directement `a l’envoi de la transaction par le processus ´emetteur. Cependant,
nous avons opt´e pour un suivi de flux en deux temps. Les tags sont
propag´es du processus ´emetteur vers la transaction puis de la transaction vers
le processus destinataire. Chaque action effectu´ee par le noyau se fait toujours
dans le contexte d’un processus. Pour les appels syst`eme, il s’agit du processus
ayant effectu´e l’appel syst`eme. Lors de l’envoi de la transaction, le Binder
s’ex´ecute ainsi dans le contexte du processus ´emetteur. Propager directement
les tags `a l’envoi signifie modifier la structure associ´ee au processus destinataire
tout en ´etant dans le contexte de l’´emetteur. Cette pratique n’est cependant
pas conseill´ee dans la programmation noyau. Nous aurions ´egalement pu faire
la propagation lors du traitement des tˆaches de la liste d’attente. Cela se fait
dans le contexte du processus destinataire mais le risque est la possibilit´e de
changement du contenu du processus ´emetteur entre l’envoi et la r´eception de la
transaction. Cela pourrait par exemple permettre d’´echanger des donn´ees tout
en faisant croire `a KBlare qu’aucune d’entre elles n’est sensible.
En optant pour la propagation en deux temps des tags, nous ne modifions
pas la structure d’un processus autre que celui qui sert de contexte d’ex´ecution
et nous maintenons une coh´erence entre les identifiants des informations partant
du processus ´emetteur et ceux des informations r´ecup´er´ees par le destinataire.
Afin de prendre en compte les flux d’information s’op´erant via le Binder,
nous avons ´etendu le framework LSM. Nous avons ajout´e deux nouveaux hooks
permettant d’intercepter l’envoi et la transmission des transactions. Dans le
code du Binder, les transactions repr´esentent les appels de m´ethodes distantes
ainsi que le retour de ces appels. Nous avons ensuite ajout´e deux fonctions
suppl´ementaires `a KBlare qui correspondent `a ces nouveaux hooks et effectuent
la propagation des tags entre les applications qui communiquent via le Binder.74 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION
3.4.3 Ex´ecution des applications Android
3.4.3.1 Interpr´etation de code vs ex´ecution
Dans Blare, la prise en compte de l’ex´ecution d’un code se fait en interceptant
les appels syst`eme execve et mmap quand la page est marqu´ee comme
´etant ex´ecutable. Sous Android, `a l’exception des applications n´ecessaires au
fonctionnement syst`eme, les applications tournent au sein d’instance de la machine
virtuelle dalvik. Pour comprendre comment ces instances sont cr´e´ees, il
est n´ecessaire de comprendre la s´equence de d´emarrage d’Android. La figure 3.5
illustre cette s´equence.
Comme pour les syst`emes de type Linux, le premier processus lanc´e est
init qui est en charge d’initialiser l’environnement Android. Les initialisations
qu’il effectue sont d´efinies dans les fichiers init.*rc `a la racine du syst`eme
de fichier. Il d´efinit par exemple les variables d’environnement et monte les
partitions. Il lance ´egalement les diff´erents processus d´emons du syst`eme tels
que servicemanager, surfaceflinger et Zygote. A son lancement, ce dernier `
lance une instance de la machine virtuelle dalvik, cr´ee un socket serveur, charge
un ensemble de ressources et classes Java, se duplique pour cr´eer le processus
system server et attend les connexions sur le socket cr´e´e. System server est le
processus qui ex´ecute les diff´erents services du syst`eme (ex : Activity Manager).
A sa cr´eation, il les lance donc et les enregistre aupr`es de ` servicemanager afin
qu’ils puissent ˆetre appel´es par les diff´erentes applications du syst`eme.
Zygote est un processus cl´e pour l’ex´ecution des diff´erentes applications Android
car c’est `a partir de ce processus que les autres applications sont lanc´ees.
Par exemple, lorsque l’utilisateur lance une nouvelle application via le menu
principal du t´el´ephone, l’application Lancher appelle la fonction startActivity
d´efinie dans Activity Manager. A l’ex´ecution de la m´ethode, ce dernier envoie `
une requˆete `a Zygote pour lancer l’application. A la r´eception de la requˆete, ce `
dernier se duplique 9
et lance dans le processus fils la nouvelle application.
Au l’ex´ecution d’une nouvelle application, le processus l’ex´ecutant charge le
code de l’application en m´emoire. Ce code est sous format dalvik et n’est pas
ex´ecut´e, comprendre via l’appel syst`eme execve ou mmap et marqu´e ex´ecutable,
mais charg´e comme une simple donn´ee en m´emoire. L’ex´ecution des applications
se traduit par la lecture de leur code en m´emoire et son interpr´etation par la
machine virtuelle dalvik. Comme aucun appel syst`eme synonyme d’ex´ecution
de code pour Blare n’est effectu´e alors Blare, dans sa version avant nos modi-
fications, ne d´etectait jamais l’ex´ecution des applications Android. Cela avait
deux cons´equences directes. Premi`erement, l’ex´ecution des applications Android
dont le code est marqu´e comme sensible ne causait pas le marquage des processus
comme ex´ecutant du code sensible. L’itag des processus ex´ecutant les
applications Android ne contenait jamais d’identifiant n´egatif. Ensuite, il ´etait
impossible d’appliquer une politique par application car du point de vue de
Blare ils ex´ecutent tous le mˆeme programme (app process).
9. appel syst`eme fork3.4. ANDROBLARE : BLARE SOUS ANDROID 75
Native daemons
- servicemanager
-netd
-vold
-mediaserver
- app_process -X
Init
- Set up env
variables
- mount partitions
-
Zygote
- etc
start native
daemons
- etc
Zygote
- Start a dalvik virtual machine
- Execute main function of zygote
- Create a server socket
- Preload resources and classes
- Start system_server
- Wait for application launch request
system_server
- Launch services
(Activity Manager,
Clipboard etc)
- Register services
App App
App
startActivity
fork
fork
Figure 3.5 – S´equence de d´emarrage d’Android76 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION
3.4.3.2 Prise en compte de l’ex´ecution des applications Android
Pour d´etecter l’ex´ecution des applications, nous avons introduit un syst`eme
de coop´eration entre la machine virtuelle Dalvik et KBlare. Il permet `a la machine
virtuelle de notifier KBlare quand elle va interpr´eter du code et donc
permettre `a KBlare de voir quand une application est ex´ecut´ee. A la r´eception `
de la notification, KBlare met ainsi `a jour les tags convenablement et applique
la politique de flux associ´ee `a l’application.
L’ex´ecution d’une application se traduit par le chargement des ressources de
l’application en m´emoire ainsi que de son code. Lorsqu’une application Android
est install´ee, le syst`eme extrait `a partir de son apk une version optimis´ee du code.
C’est cette version optimis´ee qui est charg´ee en m´emoire et interpr´et´ee par la
machine virtuelle. Un bon point d’insertion pour la notification semble ainsi
ˆetre le chargement de cette version optimis´ee. Aucune documentation technique
n’existe sur le fonctionnement de Dalvik mais en analysant son code source, nous
trouvons que le chargement est effectu´e par la fonction dvmDexFileOpenFromFd
(listing 3.4). Cette fonction charge en m´emoire le code optimis´e d’une application
et analyse syntaxiquement son contenu. Elle est appel´ee par deux autre
fonctions 10 qui ouvrent un fichier jar ou dex, cr´ee la version optimis´ee du code
`a partir du contenu du fichier ouvert et le charge en m´emoire. Cela correspond
bien `a l’ex´ecution d’une application. Nous avons ainsi ajout´e la notification,
fonction odex is mapped, au corps de la fonction dvmDexFileOpenFromFd.
La figure 3.6 illustre les diff´erentes ´etapes de la prise en compte de l’ex´ecution
de l’application. Les tags vert et bleu correspondent respectivement au contenu
du fichier .dex et `a ce mˆeme contenu lorsqu’il est ex´ecut´e par un processus. Le
tag marron correspond `a la politique de s´ecurit´e de l’application. Le syst`eme
de notification est similaire `a une architecture client/serveur. Au d´emarrage du
syst`eme, KBlare se met en ´ecoute des notifications provenant des machines virtuelles
Dalvik. (a) Lorsqu’un processus initie l’ex´ecution d’une application (chargement
du fichier .dex en m´emoire), elle charge le contenu du fichier .dex en
m´emoire. KBlare voit ce chargement et marque le processus qui va ex´ecuter l’application
comme contenant le contenu du fichier .dex. (b) La machine virtuelle
notifie ensuite KBlare qu’elle va interpr´eter le contenu du fichier .dex, c’est-
`a-dire l’ex´ecuter. (c) et (d) A la r´eception de la notification, KBlare consid`ere `
que le processus contenant la machine virtuelle ayant envoy´ee la notification va
ex´ecuter l’application dont le code est stock´e dans le fichier .dex. KBlare met
donc `a jour les tags du processus. Il indique que le processus contient la version
ex´ecut´ee du contenu du fichier .dex et applique `a ce processus la politique de
flux associ´ee au code que la machine virtuelle va interpr´eter.
Impl´ementation de la notification de l’ex´ecution d’une application
La notification est envoy´ee grˆace `a un canal de communication entre la machine
virtuelle Dalvik et KBlare. Ce canal est impl´ement´e avec Generic Net-
10. dvmJarFileOpen et dvmRawDexFileOpen respectivement d´efinies dans
dalvik/vm/JarFile.cpp et dalvik/vm/RawDexFile.cpp3.4. ANDROBLARE : BLARE SOUS ANDROID 77
VM init :
- Load
ressources
- Load optimzed
dex
- Notify KBlare
- ...
KBlare :
- Listen to notification
- Upon notification:
* Get tags associated to
the odex file
* Update tags associated
to the process
odex file (a)
(b)
(c)
(d)
Figure 3.6 – M´ecanisme de notification de l’ex´ecution d’une application Android
link [52] qui lui utilise les sockets Netlink [63]. Netlink est un m´ecanisme de
communication qui permet de faire communiquer entre eux des morceaux de
code qui sont dans le noyau ou en espace utilisateur. La communication entre
ces diff´erentes entit´es se font dans des bus Netlink, appel´es ´egalement protocoles.
Il existe un nombre d´efini de bus dans les syst`emes Linux et leur nombre
maximum est limit´e `a 32. Certains d’entre eux sont par exemple utilis´es par
des outils de gestion du trafic r´eseau tels que iproute2 [53]. Generic Netlink
est un m´ecanisme de communication bas´e sur Netlink et plus pr´ecis´ement un
multiplexeur construit au dessus d’un bus Netlink [76]. Les canaux de communication
sont appel´es familles et il est possible d’en d´efinir jusqu’`a 65520 pour
un seul et mˆeme bus Netlink. Nous pr´esentons dans ce qui suit le syst`eme de
coop´eration permettant de faire communiquer les machines virtuelles Dalvik
et KBlare. Plus pr´ecis´ement, nous pr´esentons la d´eclaration de la famille servant
de canal de communication, le comportement associ´e `a la r´eception d’une
notification et la mise en attente.
Comme ´ecrit pr´ec´edemment, le syst`eme de notification est une architecture
client/serveur. KBlare est le serveur qui se met en attente des notifications
d’ex´ecution d’application et les machines virtuelles Dalvik sont les clientes qui
envoient les notifications au serveur. La cr´eation d’un serveur d’´ecoute avec
Generic Netlink se fait en trois ´etapes : cr´eation d’une famille, d´efinition des
commandes reconnues par le serveur et enregistrement de la famille.
Afin que KBlare puisse recevoir les notifications, nous d´efinissons dans son
code une famille servant de canal de communication. Le listing 3.5 montre la
d´eclaration de la famille. Nous d´eclarons en premier les attributs possibles d’un
message. Nous en d´eclarons deux : DOC EXMPL A MSG et DOC EXMPL A INT. Ensuite,
nous d´efinissons le type associ´e aux attributs. Le premier attribut est une78 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION
1 int dvmDexFileOpenFromFd(int fd, DvmDex** ppDvmDex)
2 {
3 DvmDex* pDvmDex;
4 DexFile* pDexFile;
5 MemMapping memMap;
6 int parseFlags = kDexParseDefault;
7 int result = -1;
8
9 if (gDvm.verifyDexChecksum)
10 parseFlags |= kDexParseVerifyChecksum;
11
12 if (lseek(fd, 0, SEEK_SET) < 0) {
13 ALOGE("lseek rewind failed");
14 goto bail;
15 }
16
17 if (sysMapFileInShmemWritableReadOnly(fd, &memMap) != 0) {
18 ALOGE("Unable to map file");
19 goto bail;
20 }
21
22 // Nofify KBlare
23 odex_is_mapped(fd);
24 ...
25 }
Listing 3.4 – Fonction de chargement en m´emoire du code d’une application
chaˆıne de caract`ere et le second un entier non sign´e sur 32 bits. Enfin, nous
d´eclarons la famille : variable doc exmpl gnl family. Chaque famille doit avoir
un identifiant unique 11. Le champ id contient l’identifiant num´erique de la famille.
En lui associant la valeur GENL ID GENERATE, nous laissons au syst`eme le
choix de l’identifiant. Le champ hdrsize d´efinit la taille de l’en-tˆete des messages
transitant par cette famille. Nous n’avons besoin d’aucune en-tˆete sp´ecifique.
Nous le mettons ainsi `a 0. Le champ name d´efinit le nom de la famille. Chaque
nom doit ˆetre unique et elle permet aux clients de r´ecup´erer l’identifiant de la
chaine. Les champs restant d´efinissent le num´ero de version de la famille et le
nombre d’attributs.
Une fois la famille d´efinie, il faut ensuite d´eclarer les commandes qu’elle supporte
ainsi que les fonctions qui leur sont associ´ees. Les commandes d´efinissent
les op´erations support´ees par le serveur. Nous en d´efinissons un, DOC EXMPL EXEC
DEX, dans le listing 3.6 qui correspond `a la notification de l’ex´ecution d’une
application. A cette commande, nous associons la fonction ` doc exmpl exec dex.
11. champ id3.4. ANDROBLARE : BLARE SOUS ANDROID 79
1 // USE GENERIC NETLINK
2 /* Family declaration */
3 /* attributes */
4 enum {
5 DOC_EXMPL_A_UNSPEC,
6 DOC_EXMPL_A_MSG,
7 DOC_EXMPL_A_INT,
8 __DOC_EXMPL_A_MAX,
9 };
10 #define DOC_EXMPL_A_MAX (__DOC_EXMPL_A_MAX - 1)
11
12 /* attribute policy */
13 static struct nla_policy doc_exmpl_genl_policy[DOC_EXMPL_A_MAX + 1] = {
14 [DOC_EXMPL_A_MSG] = { .type = NLA_NUL_STRING },
15 [DOC_EXMPL_A_INT] = { .type = NLA_U32 },
16 };
17
18 #define VERSION_NR 1
19 static struct genl_family doc_exmpl_gnl_family = {
20 .id = GENL_ID_GENERATE,
21 .hdrsize = 0,
22 .name = "BLARE_COOP", // family name
23 .version = VERSION_NR, //version number
24 .maxattr = DOC_EXMPL_A_MAX,
25 };
26 /* End of family declaration */
Listing 3.5 – D´eclaration d’une famille Generic Netlink dans le noyau pour le
m´ecanisme de coop´eration
Cette fonction r´ecup`ere `a partir de la charge utile du message re¸cu par le serveur
un entier repr´esentant le descripteur du fichier charg´e par la machine virtuelle
(ligne 24 `a 26). A partir de ce descripteur, il r´ecup`ere la structure correspondant `
au fichier puis met `a jour les tags associ´es au processus (ligne 36 `a 38).
Enfin, nous enregistrons la famille et les op´erations qu’elle supporte (listing
3.7). Ces enregistrements sont effectu´es dans la fonction netlink init qui
est appel´ee pendant l’initialisation des modules de noyau (ligne 22).
Du cˆot´e client, la communication avec KBlare est plus simple. Elle se traduit
par l’envoi d’un message avec la commande DOC EXMPL EXEC DEX et le descripteur
de fichier correspondant au code charg´e en m´emoire. La biblioth`eque
libnl [11] offre une API les sockets Netlink et Generic Netlink. Cependant,
dans la version actuelle du code, nous avons utilis´e les fonctions d´efinies dans
l’exemple du client fourni par A. Keller dans [64]. Le listing 3.8 pr´esente une
version ´epur´ee 12 du code servant `a la notification de l’ex´ecution des applications
Android. La variable req est le message Netlink `a envoyer dans le noyau.
12. sans v´erification des codes d’erreur80 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION
Il contient l’en-tˆete du message Netlink, celui de Generic Netlink et la charge
utile du message. Rappelons que Generic Netlink n’est qu’un multiplexeur au
dessus d’un bus Netlink. L’envoi d’une notification se fait en plusieurs ´etapes.
1. R´ecup´erer l’identifiant du canal de communication (lignes 13, 14). Il est
n´ecessaire afin d’envoyer le message dans le bon canal de communication.
2. Initialiser les en-tˆetes Netlink et Generic Netlink. Dans le cas de Generic
Netlink, il s’agit de d´efinir la commande `a envoyer, DOC EXMPL EXEC DEX.
3. Composer le message. Cela consiste `a d´efinir les attributs `a passer dans
le message ainsi que la valeur qui leur est associ´ee. Nous d´efinissons ainsi
comme attribut un entier et le descripteur du fichier dex comme valeur
associ´ee (ligne 23 `a 28).
4. Envoyer le message. Generic Netlink est un multiplexeur au dessus d’un
bus Netlink. Nous d´eclarons ainsi un socket Netlink et envoyons le message
avec ce socket.
Lorsqu’une machine virtuelle va interpr´eter le contenu d’un fichier .dex, il
appelle la fonction odex is mapped (listing 3.4) en lui donnant en param`etre le
descripteur du fichier .dex. Cette fonction envoie un message, via une famille
de communication Generic Netlink, au noyau et plus pr´ecis´ement `a KBlare. Le
message contient deux informations. La premi`ere est une commande qui permet
au destinataire de choisir le traitement `a effectuer `a la r´eception du message. La
deuxi`eme information est le descripteur du fichier .dex. Il permettra `a KBlare
d’identifier le fichier dont le contenu va ˆetre interpr´et´e par la machine virtuelle et
propager les tags de ce fichier vers le processus contenant la machine virtuelle.
A la r´eception du message dans le noyau, ce dernier extrait du message la `
commande que le message contient. KBlare ayant associ´ee `a la commande, la
fonction doc exmpl dex (listing 3.6), le noyau transfert le traitement du message
`a cette fonction. La fonction r´ecup`ere `a partir du message le descripteur de fichier
et `a partir de ce descripteur, il r´ecup`ere la structure repr´esentant le fichier
contenant le code qui va ˆetre interpr´et´e. A partir de cette structure, KBlare `
r´ecup`ere les tags associ´es aux fichiers et les propage comme dans le cas d’une
ex´ecution au processus ayant envoy´e la notification. A la r´eception du message, `
KBlare tourne dans le contexte du processus ayant envoy´e la notification. Ce
sont donc les tags de ce processus qui sont mis `a jour.3.4. ANDROBLARE : BLARE SOUS ANDROID 81
1 /* commands: enumeration of all commands (functions),
2 * used by userspace application to identify command to be executed
3 */
4 enum {
5 DOC_EXMPL_C_UNSPEC,
6 DOC_EXMPL_C_EXEC_DEX,
7 __DOC_EXMPL_C_MAX,
8 };
9
10 #define DOC_EXMPL_C_MAX (__DOC_EXMPL_C_MAX - 1)
11
12 static int doc_exmpl_exec_dex(struct sk_buff *skb_2, struct genl_info *info) {
13 struct nlattr *na;
14 struct sk_buff *skb;
15 int rc;
16 void *msg_head;
17 int * mydata;
18 struct file * dexfile;
19 struct blare_file_struct *fstruct;
20
21 if (info == NULL)
22 goto out;
23
24 na = info->attrs[DOC_EXMPL_A_INT];
25 if (na) {
26 mydata = (int *) nla_data(na);
27 if (!mydata)
28 printk(KERN_INFO "[BLARE_NETLINK] error while"
29 "receiving data\n");
30 } else {
31 printk(KERN_INFO "[BLARE_NETLINK] no fd from userspace");
32 goto out;
33 }
34
35 rcu_read_lock();
36 dexfile = fcheck(*mydata);
37 if (dexfile) {
38 interp_exec(dexfile);
39 } else {
40 printk(KERN_INFO "[BLARE_NETLINK] could not find"
41 "struct file of %d\n", *mydata);
42 }
43 rcu_read_unlock();
44 out:
45 return 0;
46 }
47
48 /* Map command and function */
49 struct genl_ops doc_exmpl_gnl_ops_exec_dex = {
50 .cmd = DOC_EXMPL_C_EXEC_DEX,
51 .flags = 0,
52 .policy = doc_exmpl_genl_policy,
53 .doit = doc_exmpl_exec_dex,
54 .dumpit = NULL,
55 };
Listing 3.6 – D´efinition d’une commande Generic Netlink pour notifier
l’ex´ecution d’une application82 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION
1 static int __init netlink_init() {
2 int rc;
3 printk(KERN_INFO "Blare init generic netlink");
4
5 /* register new family */
6 rc = genl_register_family(&doc_exmpl_gnl_family);
7 if (rc != 0)
8 goto failure;
9
10 /* register operations */
11 genl_register_ops(&doc_exmpl_gnl_family,
12 &doc_exmpl_gnl_ops_exec_dex);
13
14 return 0;
15
16 failure:
17 printk(KERN_INFO "[BLARE_NETLINK] an error occured while"
18 "inserting the generic netlink example module\n");
19 return -1;
20 }
21
22 __initcall(netlink_init);
Listing 3.7 – Enregistrement de la famille servant `a la notification d’ex´ecution
des applications3.4. ANDROBLARE : BLARE SOUS ANDROID 83
1 int odex_is_mapped(int fd) {
2 int nl_sd; // Netlink socket
3 int id;
4 int r;
5 struct {
6 struct nlmsghdr n;
7 struct genlmsghdr g;
8 char buf[256];
9 } req;
10 struct nlattr *na;
11
12 /* Get the identifier of the family */
13 nl_sd = create_nl_socket(NETLINK_GENERIC,0);
14 id = get_family_id(nl_sd);
15
16 /* Init netlink header */
17 ...
18
19 /* Init generic netlink header */
20 req.g.cmd = DOC_EXMPL_EXEC_DEX;
21
22 /* Compose message */
23 na = (struct nlattr *) GENLMSG_DATA(&req);
24 na->nla_type = DOC_EXMPL_A_INT;
25 int mlength = sizeof(int);
26 na->nla_len = mlength + NLA_HDRLEN;
27 memcpy(NLA_DATA(na), &fd, mlength);
28 req.n.nlmsg_len += NLMSG_ALIGN(na->nla_len);
29
30 /* Send message */
31 struct sockaddr_nl nladdr;
32 memset(&nladdr, 0, sizeof(nladdr));
33 nladdr.nl_family = AF_NETLINK;
34 r = sendto(nl_sd, (char *)&req, req.n.nlmsg_len, 0,
35 (struct sockaddr *) &nladdr, sizeof(nladdr));
36 close(nl_sd);
37 return 0;
38 }
Listing 3.8 – Notification de l’ex´ecution d’une application par la machine virtuelle
Dalvik84 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION
3.4.4 Description des flux observ´es
KBlare d´ecrit les flux impliquant des donn´ees sensibles dans un format assez
verbeux et sans fournir assez d’information parfois. La figure 3.7 est un
exemple de description de flux ´emis par KBlare lorsqu’il d´etecte un flux d’un
fichier vers un processus. Parmi les informations que nous aurions aim´e avoir
´etaient le chemin complet du fichier, son identifiant et les informations li´ees au
processus. Avoir le chemin complet du fichier permet `a un analyste d’identifier
avec pr´ecision le fichier impliqu´e dans le flux. L’identifiant du fichier, son inode,
peut ´egalement s’av´erer utile si le nom du fichier est amen´e `a changer au cours
de l’ex´ecution du syst`eme.
Sous Android, nous avons ainsi mis les alertes sous la forme d´ecrite en fi-
gure 3.8. Un message est d´ecoup´e en trois parties s´epar´ees par le caract`ere ’>’.
Les deux premi`eres parties d´ecrivent le conteneur source et destination du flux.
C TYPE repr´esente le type du conteneur (fichier, socket et processus). C NAME est
le nom du conteneur. Dans le cas des sockets, il s’agit de l’adresse IP associ´ee `a la
socket. Dans le cas des processus, nous donnons `a la fois le nom du thread courant
et du processus. Les deux noms peuvent diff´erer. Par exemple, les services
dans system server tournent dans des threads avec des noms diff´erents. Avoir
le nom des deux peut ainsi aider `a comprendre quelle partie de l’application est
`a l’origine du flux.
3.4.5 Outils en espace utilisateur
Il existe sous Linux des outils en ligne de commande pour manipuler les tags
Blare associ´es aux fichiers. Leur code est disponible dans la branche master
du d´epˆot kblare-tools [38]. Ces outils ont ´et´e port´es sous Android, branche
android version du mˆeme d´epˆot, et une version sous forme d’extension d’un
navigateur de fichier Android a ´egalement ´et´e d´evelopp´ee lors d’un stage de 2
mois par Q. Dion. L’extension permet de manipuler via l’interface tactile d’un
appareil Android les tags associ´es aux fichiers et ´evite ainsi d’avoir `a ouvrir
une interface en ligne de commande. Dans le cadre d’un autre stage, T. Saliou
a d´evelopp´e Blare Policy Manager (BPM). BPM impl´emente les fonctions de
composition et de v´erification des politiques ´ecrites en BSPL et applique la
politique r´esultant de la composition sur le syst`eme. Nous avons utilis´e BPM
dans [20] pour composer et appliquer les politiques d’application tierce sur un
t´el´ephone avec l’environnement AndroBlare.
Process with pid 98 running cat made an illegal READ access to
file toto.txt
Figure 3.7 – Exemple de message lev´e par Blare sous Linux3.5. ANDROBLARE : ANALYSE D’APPLICATIONS ANDROID 85
C TYPE C NAME C ID > C TYPE C NAME C ID > ITAG
Figure 3.8 – Format des flux observ´es par Blare sous Android
3.5 AndroBlare : environnement d’analyse d’applications
Android
Dans cette th`ese, nous avons utilis´e AndroBlare en tant que environnement
d’analyse d’application Android. La figure 3.9 illustre l’environnement ainsi que
l’usage que nous en aurons dans les chapitres suivants. Pour analyser les applications,
nous utilisons un t´el´ephone Nexus S faisant tourner la version AOSP
d’Android Ice Cream Sandwich. Nous avons ajout´e au t´el´ephone tout l’environnement
AndroBlare : le module de s´ecurit´e dans le noyau, le syst`eme de notification
d’ex´ecution d’application Android et les outils utilisateurs pour manipuler
les tags. Nous avons ´egalement rajout´e les application Super User afin de recevoir
une notification visuelle `a chaque fois qu’une application demande les acc`es
root ainsi que busybox, un ´equivalent plus complet de toolbox.
Dans cet environnement, nous ex´ecutons toute application dont nous souhaitons
analyser le comportement. Ce comportement est la propagation des donn´ees
de l’application dans le syst`eme et est obtenu grˆace au suivi de flux d’information
effectu´e par AndroBlare. Pour chaque application `a analyser, nous r´ep´etons le
processus suivant. Nous installons l’application sur le t´el´ephone puis marquons
son fichier apk avec un identifiant unique. Nous consid´erons que le fichier apk
est la source des donn´ees appartenant `a l’application car il contient `a la fois son
code et les ressources qu’elle utilise telles que les images. Nous ex´ecutons ensuite
l’application et observons avec AndroBlare comment les donn´ees de l’application
se propagent dans le syst`eme. A partir des flux observ´es, nous pouvons effectuer `
deux types d’action : construire une repr´esentation compacte et humainement
compr´ehensible des flux observ´es (chapitre 4) ou d´etecter l’ex´ecution d’instance
de malware (chapitre 5).
Nous laissons les tags des autres conteneurs d’information `a leur valeur par
d´efaut, ensemble vide, sauf pour les fichiers servicemanager et surfaceflinger
dans /system/bin. A l’exception de ces deux fichiers, les autre conteneurs ne `
contiennent donc aucune information sensible du point de vue d’AndroBlare
et n’ont aucune politique de flux d’information. Quant aux deux fichiers, nous
leur assignons l’itag t0u pour signifier que les processus les ex´ecutant sont `a
ignorer pendant le suivi de flux d’information. L’identifiant 0 n’est pas utilit´e
dans le mod`ele de Blare pour identifier une information `a surveiller. Dans
l’impl´ementation, nous nous servons de cette valeur pour indiquer `a Blare quand
ignorer des flux d’information. Le but est d’´eviter une trop grande surapproximation
des flux observ´es par AndroBlare. Les applications servicemanager et surfaceflinger
sont deux processus cl´es du syst`eme Android. Le premier est un
service d’annuaire r´epertoriant tous les autres services du syst`eme. Les applications
souhaitant utiliser ces services doivent demander au servicemanager leur
r´ef´erence avant de pouvoir les utiliser. Le second est en charge de dessiner sur86 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION
l’´ecran toute interface graphique. Les applications sont uniquement conscients
de ce qu’ils veulent afficher `a l’´ecran. Elles le transmettent `a surfaceflinger
qui lui composera les affichages des diff´erentes applications et affichera le rendu
final sur l’´ecran de l’appareil.3.5. ANDROBLARE : ANALYSE D’APPLICATIONS ANDROID 87
Android Kernel
User space
BLARE
Analyzed
application
Information
container 1 ... Information
container n
Analysed
application apk file
Blare log
Parser
Malware
detection
Trusted containers
surfaceflinger servicemanager
Figure 3.9 – AndroBlare : environnement d’analyse d’application Android88 CHAPITRE 3. BLARE : UN MONITEUR DE FLUX D’INFORMATION
R´esum´e
Dans ce chapitre, nous avons pr´esent´e Blare un syst`eme de d´etection d’intrusion
param´etr´e par une politique de flux d’information, le mod`ele sur lequel
il est bas´e et le processus de portage de Blare sous Android (AndroBlare). AndroBlare
utilise le mˆeme mod`ele th´eorique que Blare mais diff`ere de ce dernier
au niveau de l’impl´ementation. Lors du portage de Blare sous Android, nous
avons ajout´e la prise en compte de deux types de flux d’information : flux d’information
via le Binder et l’interpr´etation du code des applications Android
par la machine virtuelle Dalvik. Les applications Android n’utilisent pas les
m´ecanismes de communication fournis par le noyau Linux pour communiquer
entre elles. A la place, elles utilisent diff´erents m´ecanismes fournis par le frame- `
work Java qui reposent tous sur le Binder. Afin de suivre les flux d’information
entre les applications, nous avons pris en compte ce m´ecanisme de communication
dans AndroBlare. Sa prise en compte a consist´e `a ajouter deux nouveaux
hooks `a LSM et `a d´efinir dans le code de KBlare les fonctions correspondant `a
ces hooks. Le deuxi`eme type de flux d’information pris en compte dans AndroBlare
concerne l’ex´ecution des applications et plus pr´ecis´ement l’interpr´etation
de leur code par la machine virtuelle Dalvik. Les applications Android ne sont
pas des applications natives et leur ex´ecution ´etait donc invisible `a Blare. Lorsqu’une
application est ex´ecut´ee, son code est en r´ealit´e interpr´et´ee par la machine
virtuelle Dalvik. Le probl`eme pos´e par cette interpr´etation du code est
que l’ex´ecution ´etait invisible et donc KBlare ne pouvait mettre `a jour correctement
les tags des processus ex´ecutant du code sensible. Aucun processus n’´etait
marqu´e comme ex´ecutant du code et aucune politique ne pouvait ˆetre appliqu´ee
par application. Afin de permette `a KBlare d’observer l’ex´ecution d’une application
Android, nous avons ainsi ajout´e un m´ecanisme de coop´eration entre la
machine virtuelle Dalvik et KBlare. Cette coop´eration consiste `a notifier KBlare
via les sockets Netlink de l’ex´ecution d’une application par la machine virtuelle.
Lors de la pr´esentation du mod`ele de Blare, nous avons ´egalement expliqu´e
comment nous avons d´efini manuellement une politique de flux d’information
pour le syst`eme Android. La politique identifie 150 informations `a prot´eger et
186 conteneurs d’information pouvant acc´eder `a ces informations ou les stocker.
Cette politique a fait l’objet d’une publication `a ICC 2012 [16].Chapitre 4
Graphes de flux syst`eme
Pour chaque flux d’information observ´e qui implique une donn´ee sensible,
Blare ajoute une entr´ee d´ecrivant le flux dans un journal. Au fur et `a mesure
que le syst`eme s’ex´ecute, le taille du journal augmente et peut devenir rapidement
difficile `a analyser pour un ˆetre humain. Quelques minutes d’ex´ecution
du syst`eme peut suffire pour avoir des milliers d’entr´ees dans le journal de
Blare. Nous proposons donc dans ce chapitre une structure appel´ee System
Flow Graph pour repr´esenter les flux observ´es de mani`ere plus compacte et plus
compr´ehensible.
4.1 Graphe de flux syst`eme
Un graphe de flux syst`eme, que nous abr´egeons SFG (System Flow Graph)
dans le reste du document, est un multigraphe orient´e G “ pV, Eq o`u les nœuds
repr´esentent des conteneurs d’information et les arcs des flux d’information entre
les conteneurs.
Un nœud v P V a trois attributs v.type, v.name et v.id qui repr´esentent
respectivement le type du conteneur (fichier, processus et socket) correspondant
au nœud, son nom et son identifiant du conteneur dans le syst`eme. Selon le
type du conteneur, le nom du nœud est soit le chemin complet du fichier, le
nom du processus concat´en´e `a celui du thread ou l’adresse IP associ´ee `a la
socket. L’identifiant est le num´ero d’i-node pour les fichiers et le PID pour les
processus.
Un arc e P E a deux attributs e.timestamp et e.flow qui correspondent
respectivement `a la liste des moments auxquels le flux a ´et´e observ´e et les
identifiants des informations impliqu´ees dans le flux. Un arc repr´esente un flux
d’information unique du conteneur repr´esent´e par sa source vers le conteneur
repr´esent´e par sa destination. Le flux peut ˆetre observ´e plusieurs fois et inclut
`a chaque observation les mˆemes informations sensibles, i.e les identifiants des
informations qui se propagent sont les mˆemes `a chaque observation.
Un SFG est un multigraphe car il peut contenir des arcs parall`eles. Des arcs
8990 CHAPITRE 4. GRAPHES DE FLUX SYSTEME `
[1] file blob 18 > process cat 19 > {1, 2}
[2] process woman 20 > file blob 18 {3}
[3] process woman 20 > file blob 18 {3}
[4] file blob 18 > process cat 19 > {1, 2, 3}
Figure 4.1 – Exemple de flux d’information causant l’apparition d’arcs parall`eles
dans les SFG
�������� ������ �����������
�������������
�������� �����������
Figure 4.2 – Exemple de SFG avec des arcs parall`eles
parall`eles sont des arcs reliant les mˆeme nœuds. Un SFG a deux arcs parall`eles
lorsque Blare a observ´e deux flux d’information ayant la mˆeme source et la
mˆeme destination mais n’impliquant pas les mˆemes informations sensibles. La
figure 4.1 d´ecrit des flux d’information causant la cr´eation d’arcs parall`eles dans
les SFG. La premi`ere et derni`ere entr´ees d´ecrivent des flux ayant la mˆeme source
et la mˆeme destination : de blob `a cat. Cependant, le contenu de blob a ´et´e
modifi´e par le deuxi`eme et troisi`eme flux observ´es par Blare et ainsi le dernier
flux implique une information en plus par rapport `a la premi`ere. Ces deux flux
ne peuvent donc ˆetre consid´er´es comme un flux unique et sont repr´esent´es avec
deux arcs. Le deuxi`eme et le troisi`eme flux impliquent les mˆemes informations
sensibles et repr´esentent donc un flux d’information unique. Ils sont repr´esent´es
par un unique arc.
Graphe de flux syst`eme vs. graphe de d´ependance
Dans [66], Samuel T. King et Peter M. Chen utilisent un graphe de d´ependance
pour analyser les intrusions dans un syst`eme. Un graphe de d´ependance d´ecrit
sous la forme d’un graphe les flux d’information entre les objets du syst`eme. Les
nœuds sont les objets du syst`eme et un arc entre deux nœuds signifie qu’il y a eu
un flux d’information entre les objets repr´esent´es par les nœuds source et destination
de l’arc. Lorsqu’une intrusion a ´et´e d´etect´ee sur un objet du syst`eme,
ils construisent le graphe de d´ependance et l’analysent afin d’avoir un d´ebut
de diagnostic de l’intrusion. Le graphe de d´ependance est construit `a partir
des flux d’information qui ont eu lieu jusqu’`a la d´etection de l’intrusion et sa
construction est similaire `a celle d’un SFG.
Si un SFG et un graphe de d´ependance d´ecrivent tous les deux des flux4.1. GRAPHE DE FLUX SYSTEME ` 91
d’information entre les objets du syst`eme, le SFG apporte cependant plus de
pr´ecision car il est plus centr´e sur les informations que ne l’est un graphe de
d´ependance. Un graphe de d´ependance prend en compte tout flux d’information
s’op´erant dans le syst`eme et ne fait aucune distinction entre les informations qui
se propagent. Par contre, un SFG lui ne prendra en compte que les flux d’information
impliquant les donn´ees `a surveiller dans le syst`eme ce qui permet
de mieux filtrer les flux d’information `a analyser lors d’une intrusion et raccourcir
la dur´ee de l’analyse. Nous d´emontrons ce gain en repr´esentant la suite
d’´ev`enement suivante avec un SFG et un graphe de d´ependance pour analyser
une intrusion.
Soient un processus server ex´ecutant une application traitant des donn´ees
`a la demande d’applications clientes et f ilex un fichier dont l’acc`es est limit´e `a
server et dont l’int´egrit´e doit ˆetre pr´eserv´ee. Sur le mˆeme syst`eme tournent n
processus b´enins ex´ecutant diff´erents clients de server. A chaque requˆete cliente `
que server re¸coit, server se duplique et attribue le traitement de la requˆete au
processus fils r´esultant de la duplication. Un autre processus attacker ex´ecute
´egalement une application cliente de server sur le syst`eme mais contrairement
aux autres clients, il s’agit d’un processus malveillant dont le but de corrompre
le contenu de f ilex. Pour corrompre le contenu de f ilex, il envoie une requˆete
malicieuse `a server qui lors de son traitement va forcer le processus fils de server
`a corrompre f ilex. Nous supposons que la d´etection ait lieu au moment de la
corruption et que l’attaque soit men´ee seulement apr`es que les n processus aient
chacun envoy´e au moins une requˆete au serveur. Cette derni`ere supposition
permet d’avoir le pire des cas dans lors de l’analyse car tous les clients sont
d’´eventuels suspects.
En supposant que ces ´ev`enements se soient pass´es dans l’environnement
d’analyse utilis´ee dans [66], nous construisons le graphe de d´ependance illustr´e
dans la figure 4.3.a. En analysant ce graphe, le seul diagnostic que nous d´eduisons
est que l’un des processus clients a pu influencer le serveur `a modifier le contenu
de f ilex. Tous les processus clients sont de potentiels suspects car ils ont tous
envoy´es des donn´ees au serveur avant que l’attaque ne soit d´etect´ee.
Si nous supposons cette fois que les mˆeme ´ev`enements se soient produits
dans un environnement (Andro)Blare et que pour chaque client un identifiant
unique est associ´e aux donn´ees qu’il envoie alors nous aurions un SFG illustr´e
dans la figure 4.3.b. Nous supposons que l’identifiant x est associ´e aux donn´ees
provenant de l’application malveillante. En analysant le SFG, nous d´eduisons
que f ilex a ´et´e contamin´e avec des donn´ees identifi´ees par x. En filtrant le
SFG pour ne garder que les arcs impliquant les donn´ees identifi´ees par x, nous
obtenons la partie en gras du SFG qui indique clairement que le processus
attacker est `a l’origine de l’attaque.92 CHAPITRE 4. GRAPHES DE FLUX SYSTEME `
proc 1
server
... proc n attacker
child 1 ... child n child
filex
proc 1
server
{1}
... proc n
{n}
attacker
{x}
child 1
{1}
... child n
{n}
child
{x}
filex
{x}
(a) (b)
Figure 4.3 – Graphe de d´ependance et SFG repr´esentant les flux d’information
ayant pr´ec´ed´e la corruption d’un fichier f ilex
4.2 Quelques op´erations utiles sur les SFG
Dans les chapitres suivants, nous effectuerons certaines op´erations sur les
SFG. Nous pr´esentons dans cette section ces op´erations qui nous serviront par
la suite.
4.2.1 Intersection de deux SFG : g1 [ g2
L’intersection de deux SFG est le SFG dont les arcs sont l’ensemble des arcs
en commun aux deux SFG. La notion d’arcs en commun de deux SFG d´esigne
le fait qu’une partie des arcs des deux SFG sont les mˆemes. Nous consid´erons
qu’un arc e1 P g1 est le mˆeme qu’un arc e2 P g2 si :
— les deux arcs impliquent les mˆeme informations dans le flux d´ecrit par
chacun des arcs ;
— leurs nœuds de d´epart respectifs repr´esentent le mˆeme conteneur d’information
;
— leurs nœuds d’arriv´ee respectifs repr´esentent le mˆeme conteneur d’information.
Deux nœuds repr´esentant le mˆeme conteneur d’information doivent avoir le
mˆeme type et le mˆeme nom. Nous ne prenons pas en compte l’identifiant syst`eme
des conteneurs d’information car ils sont sp´ecifiques `a chaque syst`eme ou `a
une ex´ecution. Un processus n’existe tout au plus que le temps d’ex´ecution du
syst`eme. Son identifiant est donc li´e `a cette ex´ecution. L’identifiant d’un fichier
est li´e au syst`eme o`u il se trouve. Il est g´en´er´e automatiquement `a la cr´eation du
fichier. Un mˆeme fichier sur deux syst`emes diff´erents a donc deux identifiants
diff´erents.4.3. CONSTRUCTION D’UN GRAPHE DE FLUX SYSTEME ` 93
4.2.2 Inclusion d’un SFG dans un autre : g1 Ď g2
Soient deux SFG g1 et g2. Nous consid´erons que g1 est inclus dans g2 si tous
les arcs de g1 sont des arcs en commun avec g2.
4.2.3 Nœuds et arcs d’un SFG
Nous d´efinissions ´egalement les fonctions node et edges comme ´etant les
fonctions retournant respectivement l’ensemble des nœuds et des arcs d’un SFG.
4.3 Construction d’un graphe de flux syst`eme
Pour obtenir la repr´esentation compacte du journal de Blare, nous avons
d´evelopp´e un outil qui prend en entr´ee un journal de Blare et donne en sortie la
repr´esentation sous forme de SFG. L’algorithme 1 d´ecrit la transformation du
journal en SFG. Nous d´efinissons la fonction to edge comme ´etant une fonction
qui calcule l’arc correspondant `a une entr´ee d’un journal de Blare et utilisons
l’op´eration pour exprimer le fait que deux arcs repr´esentent le mˆeme flux
d’information unique. Deux arcs repr´esentent le mˆeme flux d’information unique
si leurs nœuds sources repr´esentent le mˆeme conteneur d’information ainsi que
leurs nœud de destination. Durant la construction d’un SFG, nous consid´erons
que deux nœuds v1 et v2 repr´esentent le mˆeme conteneur d’information si l’un
des cas suivants est vrai :
— v1 et v2 sont des fichiers, v1.id est ´egal `a v2.id et les fichiers correspondant
sont sur la mˆeme partition ;
— v1 et v2 sont des processus et v1.id est ´egal `a v2.id ;
— v1 et v2 sont des sockets qui sont li´ees `a la mˆeme adresse IP.
Nous utilisons l’identifiant au lieu des noms dans le cas des processus et
des fichiers car les noms peuvent changer durant l’ex´ecution du syst`eme. Les
identifiants identifient de mani`ere unique chaque objet et ne changent pas durant
l’ex´ecution du syst`eme. Utiliser le nom aurait ainsi cr´e´e une confusion pour
l’analyste car il ne pourrait plus retracer correctement la propagation des flux
dans le syst`eme. Par exemple, durant l’installation d’une application, un fichier
avec un nom al´eatoire est cr´e´e dans /data/dalvik-cache. Ce fichier contient
la version optimis´ee du code de l’application `a installer et est renomm´e en se
basant sur le nom de l’application `a la fin de l’installation. Si le conteneur est
impliqu´e dans un flux d’information avant et apr`es son renommage, nous aurions
un seul et mˆeme nœud pour le repr´esenter avec les identifiants alors que nous
aurions deux nœuds diff´erents en utilisant les noms.
Pour chaque entr´ee du journal de Blare, nous v´erifions si il existe un arc e1
correspondant au flux d´ecrit par l’entr´ee. Si c’est le cas, alors nous ajoutons le
timestamp de l’entr´ee courante `a la liste des timestamps de e1. Si ce n’est pas
le cas, nous ajoutons l’arc correspondant `a l’entr´ee courante au SFG. L’ajout
d’un nouvel arc implique ´egalement l’ajout de ses nœuds s’ils n’existaient pas
dans le SFG ; c’est-`a-dire qu’aucun des nœuds du SFG n’´etait ´egal aux nœuds94 CHAPITRE 4. GRAPHES DE FLUX SYSTEME `
source et destination du nouvel arc. La construction s’arrˆete quand il n’y a plus
d’entr´ee `a traiter et l’algorithme retourne le SFG.
Algorithme 1 : Construction d’un SFG `a partir des entr´ees d’un journal
de Blare
Input : Journal de Blare
Output : SFG correspondant aux flux d´ecrits dans le journal donn´e en
entr´ee
begin
g Ð empty SFG;
forall the entry ent in Blare log do
e0 Ð to edgepentq;
found Ð F alse;
forall the e1 P g do
if e0 e1 then
e1.timestamp Ð e1.timestamp Y e0.timestamp;
found Ð T rue;
break;
if found then
Add e0 to g;
return g;
Compacit´e du SFG
Nous avons avanc´e au d´ebut de ce chapitre que le premier atout du SFG
´etait de repr´esenter de mani`ere plus compacte les flux d’information observ´es par
Blare. Cette compacit´e a pour cons´equence de faciliter l’analyse des flux observ´es
afin de comprendre ce qui se passe dans le syst`eme. Durant la th`ese nous avons
analys´e plus d’une centaine d’application dont certaines ´etaient malicieuses et
d’autres non. L’analyse de chacune d’entre elles a dur´e entre 2 `a 5 minutes selon
les applications et le journal de Blare obtenu `a la fin de l’analyse contenait
quelques milliers d’entr´ee, c’est-`a-dire que Blare a observ´e des milliers de flux
d’information et chacun des flux observ´es par une entr´ee dans le journal. A titre `
d’exemple, l’analyse de 65 applications provenant de Google Play a produit en
moyenne plus de 130000 entr´ees dans le journal de Blare alors que les SFG
produits `a partir de chaque journal ont en moyenne une centaine d’arcs. La
raison de ce gain en compacit´e est que certains flux sont observ´es plusieurs fois
durant l’ex´ecution du syst`eme. Les ´echanges entre une application et le processus
system server sont par exemple r´ep´et´es plusieurs fois car ce processus h´eberge
les applications services du syst`eme fournies aux autres applications. Un autre
exemple de ces flux r´ep´et´es est la lecture ou l’´ecriture de donn´ees volumineuses
dans un fichier.4.4. SFG : PROFIL COMPORTEMENTAL D’UNE APPLICATION 95
4.4 Graphe de flux syst`eme : profil comportemental
d’une application
Un SFG repr´esente de mani`ere compacte les flux d’information observ´es par
(Andro)Blare. Dans cette th`ese, nous proposons d’utiliser le SFG en tant que
profil d’une application. Plus pr´ecis´ement, nous proposons d’utiliser le SFG pour
d´ecrire comment une information provenant d’une application se propage dans
le syst`eme entier. Afin de construire le SFG, nous analysons avec AndroBlare
comment l’information provenant d’une application sous surveillance se propage
dans le syst`eme. Nous installons l’application, assignons un nouvel identifiant
i `a ses donn´ees, marquons son apk avec un itag ´egal `a tiu, l’ex´ecutons et analysons
avec Blare comment ses donn´ees se propagent dans le syst`eme. Nous
assignons un nouvel identifiant aux donn´ees de l’application afin d’identifier les
flux d’information impliquant les donn´ees de l’application. L’apk contient toutes
les ressources d’une application. Nous le consid´erons donc comme l’origine des
donn´ees d’une application et le marquons avec l’itag tiu. A chaque fois que `
Blare observe un flux d’information impliquant une donn´ee identifi´ee par i il
rajoute une entr´ee d´ecrivant le flux observ´e. En utilisant l’algorithme 1, nous
construisons ensuite le SFG correspondant aux flux observ´es. Le SFG r´esultant
peut ensuite ˆetre analys´e afin de comprendre les actions d’une application. Dans
ce qui suit, nous proposons d’analyser un ´echantillon d’un malware Android.
4.4.1 Analyse de DroidKungFu1 avec AndroBlare
DroidKungFu1 [61] est un malware Android d´ecouvert en 2011 sur les plateformes
de t´el´echargement alternatives `a Google Play. Il m`ene deux types d’attaque
: le vol des donn´ees li´ees au t´el´ephone (IMEI, num´ero du t´el´ephone et
version du syst`eme d’exploitation) et l’ajout d’application sur le t´el´ephone. Le
vol des donn´ees est une attaque basique car l’application demande `a l’installation
les permissions requises pour acc´eder aux donn´ees et communiquer sur
le r´eseau. Une fois install´ee, l’application collecte les donn´ees sensibles et les
envoie dans une requˆete HTTP vers un serveur distant. En revanche, l’ajout
d’application est plus complexe et les permissions demand´ees ne laissent en
rien pr´esager l’installation d’une nouvelle application. Pour installer d’autres
applications, le malware ´el`eve ses privil`eges en exploitant une vuln´erabilit´e du
syst`eme Android [31] ou en utilisant le binaire su 1
.
L’´echantillon que nous utilisons 2 provient de la collection Contagio [82] et
a ´et´e propos´e comme un client VoIP sur des plateformes alternatives `a Google
Play. La figure 4.4 est une capture d’´ecran des permissions demand´ees `a l’utilisateur
par l’´echantillon. Parmi les acc`es demand´es, nous remarquons l’acc`es `a
l’identit´e du t´el´ephone (ex : IMEI et num´ero de t´el´ephone) et l’acc`es au r´eseau.
Nous analysons l’´echantillon avec AndroBlare comme d´ecrit en section 3.5. Nous
l’installons sur un t´el´ephone, marquons son apk, l’ex´ecutons et analysons avec
1. switch user
2. Empreinte MD5 : 39d140511c18ebf7384a36113d48463d96 CHAPITRE 4. GRAPHES DE FLUX SYSTEME `
Figure 4.4 – Permissions demand´ees par un ´echantillons de DroidKungFu
AndroBlare comment ses informations se propagent dans le syst`eme.
Le code malveillant dans l’application est automatiquement ex´ecut´e d`es que
nous lan¸cons l’application. Super User notifie que l’application a obtenu les
droits root et au bout de quelques secondes, nous remarquons une nouvelle
application, Google SSearch, dans le menu principal du t´el´ephone (figure 4.5).
Nous arrˆetons l’analyse et cr´eons `a partir du journal de Blare le SFG de l’application.
Le nombre d’entr´ees cr´e´ees dans le journal est de 3563 et `a partir de ces
entr´ees nous construisons le SFG que nous analysons dans la section suivante.
4.4.2 Analyse du SFG de DroidKungFu1
La figure 4.6 illustre un extrait du SFG de l’´echantillon 39d140511c18ebf7384a36113d48463d.
Le SFG entier est plus grand (106 arcs et 76 nœuds)
mais la figure montre la partie la plus importante du point de vue de l’attaque
(partie en gras). Le SFG a deux types de nœuds. Les ellipses repr´esentent des
processus tandis que les boˆıtes repr´esentent des fichiers. Les arcs repr´esentent
toujours des labels mais pour des raisons esth´etiques, nous nous sommes limit´es
`a afficher le nombre de fois que les flux correspondants aux arcs ont ´et´e observ´es4.4. SFG : PROFIL COMPORTEMENTAL D’UNE APPLICATION 97
Figure 4.5 – Liste des applications dans le menu du t´el´ephone apr`es l’installation
d’une nouvelle application par un ´echantillon de DroidKungFu98 CHAPITRE 4. GRAPHES DE FLUX SYSTEME `
/data/app/com.aijiaoyou.android.sipphone-1.apk
system_server
1 - 98081668
ndroid.sipphone
82 - 98349271
11 - 98341815
/data/system/packages.xml
1 - 313591933
.google.ssearch
7 - 319549869
82 - 98347483
/data/data/com.aijiaoyou.android.sipphone/gjsvro
2 - 100112038
/data/data/com.aijiaoyou.android.sipphone/legacy
1 - 312461265 1 - 100158896
gjsvro
3 - 121963546
/proc/sys/kernel/hotplug
1 - 121959054
/system/bin/gjsvr
2 - 121963729
/system/app/com.google.ssearch.apk
11 - 312503997
2 - 312993777
dexopt
1 - 313427486
2 - 319553901
cat
11 - 312938978
/data/dalvik-cache/system@app@com.google.ssearch.apk@classes.dex
2 - 313429554 1 - 313573503
1 - 319567573
7 - 319548445
12 - 312503806 12 - 312938674
Figure 4.6 – Extrait du SFG d’un ´echantillon de DroidKungFu4.4. SFG : PROFIL COMPORTEMENTAL D’UNE APPLICATION 99
ainsi que le timestamp de la premi`ere observation. L’application que nous avons
analys´e est le processus ndroid.sipphone. En analysant le SFG, nous pouvons
d´eduire que deux applications ont ´et´e install´ees sur le t´el´ephone.
Lorsque l’´echantillon s’ex´ecute, il cr´ee deux fichiers /data/data/com.aijaoyou.sipphone/gjsvro
et /data/data/com.aijaoyou.sipphone/legacy. A par- `
tir du contenu de ces fichiers, deux processus, gjsvro et cat, cr´eent deux
nouveaux fichiers dans la partition system : /system/bin/gjsvro et /system/app/com.google.search.apk.
Cela indique l’installation d’une application
native, gjsvro, et d’une application Android, com.google.search.apk.
Ces deux fichiers n’existent pas par d´efaut sous Android, ce qui laisse supposer
qu’ils ont ´et´e cr´e´es par l’´echatillon du malware que nous analysons. Les flux qui
suivent renforcent cette hypoth`ese car le contenu du fichier apk se propage vers
le processus system server qui lui le propage dans le fichier packages.xml.
Le processus system server ex´ecute divers services du syst`eme dont celui en
charge de l’installation des nouvelles applications, Package Manager. Package
Manager observe la cr´eation de nouveaux fichiers dans le r´epertoire /system/app
qui stocke les applications syst`eme. Si un fichier est cr´e´e dans ce r´epertoire, il
lance l’installation du fichier. Le fichier packages.xml contient la liste des applications
install´ees sur le t´el´ephone. De plus, le contenu du fichier apk est
´egalement lu par le processus dexopt qui est en charge d’extraire la version
optimis´ee du code d’une application `a partir de son apk. Un nouveau processus,
google.search acc`ede ensuite `a cette version optimis´ee ainsi qu’`a l’apk cr´e´e
par le malware ce qui indique l’ex´ecution d’une nouvelle application.
Pour confirmer l’installation, nous analysons le fichier packages.xml. En calculant
la diff´erence de son contenu avant et apr`es l’analyse de l’´echantillon, nous
remarquons une entr´ee d´ecrivant une nouvelle application com.google.ssearch
(listing 4.1). L’entr´ee indique que le code de l’application correspond au fichier
com.google.ssearch.apk dans la partition system. Elle indique aussi l’UID
associ´e `a l’application : 10059. A l’installation d’une application, le syst`eme lui `
associe un nouvel UID dont la valeur est le dernier UID associ´e `a une application
incr´ement´e de 1. L’UID associ´e `a l’´echantillon que nous avons analys´e est
10058. Cela signifie donc que l’application com.google.ssearch a ´et´e install´ee
apr`es l’´echantillon que nous avons analys´e.
481
484
485
486
487
488
Listing 4.1 – Entr´ee dans le fichier packages.xml ajout´ee suite `a l’installation
d’une nouvelle application par un ´echantillon de DroidKungFu100 CHAPITRE 4. GRAPHES DE FLUX SYSTEME `
Avant de cr´eer les fichiers dans la partition system, le processus gjsvro
´ecrit dans un fichier hotplug. Ce fichier est une entr´ee du procfs, un syst`eme
de fichier servant d’interface pour acc´eder `a des informations sur les processus
et d’autres ´el´ements du syst`eme tels que le noyau. Si l’´ecriture de donn´ee dans
le fichier hotplug ne signifie pas forc´ement une attaque, elle est cependant
inhabituelle et correspond `a l’exploitation de la vuln´erabilit´e pour obtenir les
droits root sur le syst`eme [31].
Un SFG est un multigraphe orient´e qui repr´esente de mani`ere compacte les
flux d’information observ´es par AndroBlare. Comme nous l’avons montr´e `a la
fin de la section 4.3, une centaine de milliers d’entr´ee dans le journal d’AndroBlare
se r´eduit en un graphe avec un moyenne une centaine d’arcs. Grˆace `a
sa compacit´e, cette structure facilite l’analyse des flux observ´es dans le syst`eme
afin de comprendre le comportement d’une application. Dans le cas d’analyse de
malware, cette fonctionnalit´e s’av`ere int´eressant pour ´etablir un d´ebut de diagnostic
d’une attaque. Pour illustrer cela, nous avons analys´e avec AndroBlare
un ´echantillon du malware DroidKungFu1 et construit le SFG correspondant
aux flux observ´es durant l’analyse. Nous avons d´eduit `a partir du SFG que
l’´echantillon analys´e installait deux applications dans le syst`eme : une native
et une sous forme d’apk. Ces deux applications sont install´ees dans la partition
system, ce qui rend leur pr´esence persistante sur le t´el´ephone. Un utilisateur
normal ne peut d´esinstaller une application dans la partition system sans les
droits root or ils ne sont pas disponibles par d´efaut sur les t´el´ephones. Le SFG a
´egalement mis en ´evidence l’exploitation de la vuln´erabilit´e pour avoir les droits
root (´ecriture de donn´ees sensibles dans le fichier hotplug).
Revenons sur le travail effectu´e dans [16] et pr´esent´e en section 3.2. Le but
de ce travail ´etait de d´efinir manuellement une politique de flux d’information
pour le syst`eme Android. Sa r´ealisation a cependant mis en ´evidence la difficult´e
d’une telle approche. L’un des pr´e-requis `a cette d´emarche est une connaissance
approfondie du syst`eme. Or ce n’est pas souvent le cas pour les d´eveloppeurs
d’application et d´efinir une politique de flux pour des applications cens´ees tourner
dans un environnement AndroBlare pourrait s’av`erer difficile. Avec T. Saliou,
nous avons ainsi propos´e dans [20] une approche semi-automatique pour
assister un d´eveloppeur dans la cr´eation de la politique d’une application.
4.5 Cr´eation d’une politique de flux d’information
`a partir d’un System Flow Graph
La difficult´e dans la d´efinition d’une politique est de connaˆıtre tous les conteneurs
l´egaux des informations `a surveiller. Lors de la d´efinition de la politique
d’une application, il s’agit donc d’identifier tous les conteneurs pouvant acc´eder
ou stocker les donn´ees de cette application. Pour les identifier, nous proposons4.5. POLITIQUE DE FLUX D’INFORMATION A PARTIR D’UN SFG ` 101
d’analyser les applications pour construire leur profil sous forme de SFG. A par- `
tir du SFG, nous d´eduisons ensuite les conteneurs l´egaux des donn´ees surveill´ees
car le SFG d´ecrit o`u les informations surveill´ees se propagent dans le syst`eme.
La construction de la politique se fait en deux ´etapes. Dans un premier
temps, le d´eveloppeur analyse son application dans un environnement AndroBlare
et construit le profil de son application comme d´ecrit en section 4.4. Le
but de cette ´etape est d’obtenir dans le SFG tous les flux d’information possibles
que l’application peut causer. Le d´eveloppeur ´etant celui qui connaˆıt le mieux
son application, il est le mieux plac´e pour stimuler son application et couvrir
ainsi toutes les fonctionnalit´es offertes par l’application.
Une fois le SFG obtenu, nous calculons la politique de flux de l’application.
L’algorithme 2 d´ecrit le processus de calcul. Les fonctions cont, ptag, xptag,
inedges et bin retournent respectivement le conteneur d’information associ´e `a
un nœud, le ptag d’un conteneur, son xptag, les arcs entrants d’un nœud et
le fichier contenant l’application ex´ecut´ee par un processus. Pour chaque nœud
du SFG, nous consid´erons que le conteneur d’information qu’il repr´esente est
un conteneur l´egal de toutes les information sensibles impliqu´ees dans les arcs
entrants du nœud. Nous consid´erons que toutes ces informations peuvent se
m´elanger dans le conteneur. Par exemple, si deux arcs e0 et e1 sont les arcs
entrants d’un nœud n alors nous consid´erons que le conteneur repr´esent´e par n
est un conteneur l´egal des informations impliqu´ees dans les flux d´ecrits par les
deux arcs.
Algorithme 2 : Calcul d’une politique de flux d’information Blare `a partir
d’un SFG
Input : Un SFG G
Output : Une politique de flux d’information
begin
ptag (socket) Ð H;
foreach n P nodes (G) do
ids Ð H ;
foreach e P inedges (n) do
ids Ð ids Y e.flow ;
switch type (n) do
case file
ptag (cont (n)) Ð tidsu;
break;
case process
xptag (bin (cont (n))) Ð tidsu;
break;
case socket
ptag (socket) Ð ptag (socket) Y tidsu;
break;102 CHAPITRE 4. GRAPHES DE FLUX SYSTEME `
En utilisant cette approche, nous avons construit la politique de trois applications
issues de Google Play : Angry Birds, Finger Scanner et Knife Game.
La politique produite est ´ecrite en BSPL [57] et le listing 4.2 est un extrait de
l’une des politiques BSPL produites. Ecrire la politique en BSPL permet de ´
la composer avec d’autres politiques, notamment celle du syst`eme sur lequel
l’application est install´ee. La politique liste les conteneurs d’information pris en
compte par la politique, les donn´ees sensibles `a surveiller et pour chaque donn´ee
sensible la liste des conteneurs l´egaux ainsi que les informations avec lesquelles
elles peuvent se m´elanger dans le conteneur.
Evaluation des politiques produites ´
Nous avons men´e deux types d’exp´erience afin d’´evaluer les politiques de flux
produites `a partir de notre approche. La premi`ere exp´erience consiste `a valider
la prise en compte des flux que l’application engendre durant son ex´ecution
par sa politique de flux. Nous nous assurons qu’aucune alerte n’est lev´ee par
AndroBlare lorsque nous ex´ecutons l’application et appliquons sa politique. La
deuxi`eme exp´erience consiste `a valider la capacit´e de d´etection de la politique
en cas d’intrusion dans le syst`eme. Plus pr´ecis´ement, nous v´erifions que la politique
de s´ecurit´e permet la d´etection des d´eviations par rapport au comportement
d’origine de l’application. Nous consid´erons ici le cas des applications
malveillantes qui sont `a l’origine des applications b´enignes mais auxquelles du
code malveillant a ´et´e rajout´e. Ce mode d’infection est le plus utilis´ee par les
auteurs de malware selon l’analyse dans [113].
Dans les deux types d’exp´eriences, nous appliquons la proc´edure suivante.
Nous installons l’application, appliquons sa politique et l’utilisons comme un
utilisateur normal l’utiliserait. En parall`ele, nous v´erifions avec AndroBlare si
les flux caus´es par l’application violent la politique de flux du mise en œuvre.
Lors de la premi`ere exp´erience, nous utilisons la version de l’application ayant
servi lors de la cr´eation de la politique et v´erifions qu’aucune alerte n’est lev´ee
lors de l’utilisation de l’application. Si aucune alerte n’est lev´ee, cela signifie que
la politique couvre tous les flux que l’application cause durant son ex´ecution.
Lors de la deuxi`eme exp´erience nous utilisons des versions infect´ees des applications
utilis´ees dans l’exp´erience pr´ec´edente. Ces versions infect´ees sont des r´eels
´echantillons de malware provenant de la collection Contagio [82]. Les versions
infect´ees d’Andry Birds, Finger Scanner et Knife Game sont respectivement des
´echantillons d’une variante de LeNa [104], DroidKungFu1 [61] et Bad News [91].
Chacun de ces malwares essaient d’installer des applications sur le t´el´ephone
soit en usant des privil`eges demand´ees `a l’installation soit en exploitant des
vuln´erabilit´es dans le syst`eme. Le but de la deuxi`eme exp´erience est donc de
d´etecter ces comportements.
Le tableau 4.1 liste le nombre d’alertes lev´ees lors de l’´evaluation des politiques
des trois applications. Lors de la premi`ere exp´erience, AndroBlare n’a
l´ev´e aucune alerte pour les 3 applications. Les politiques respectives des trois applications
couvrent donc tous les flux qu’elles engendrent durant son ex´ecution.
Lors de la deuxi`eme exp´erience, AndroBlare a lev´e des alertes pour chacune4.5. POLITIQUE DE FLUX D’INFORMATION A PARTIR D’UN SFG ` 103
des versions infect´ees des applications utilis´ees durant la premi`ere exp´erience.
Les alertes lev´ees ´etant nombreuses, nous ne les mettrons pas dans le pr´esent
document mais la figure 4.7 est un extrait de ces alertes. Elle liste les alertes
lev´ees par AndroBlare lors de l’analyse de la version infect´ee de Finger Scanner.
La version infect´ee d’Angry Birds est un ´echantillon de LeNa. Les analyses
sur LeNa indiquent que le malware exploitent une vuln´erabilit´e du syst`eme
afin d’obtenir les privil`eges root puis installer une nouvelle application. Lors
de l’analyse de l’´echantillon, AndroBlare a lev´e des alertes indiquant l’acc`es en
lecture et ´ecriture `a des fichiers dans le r´epertoire de l’application par d’autres
applications : logo et logcat. Logo est une application binaire incluse par l’auteur
du malware dans l’application. Logcat est une application qui permet de
lire le contenu du journal du syst`eme. Ces deux applications lisent et ´ecrivent
dans les fichiers logo, crashlog, flag, exec et .e1240987052d situ´es dans
le r´epertoire de l’application analys´ee. Si ces acc`es n’indiquent pas forc´ement une
intrusion dans le syst`eme, elles correspondent cependant `a la premi`ere ´etape de
l’attaque men´ee par le malware, l’exploitation de la vuln´erabilit´e sur le syst`eme.
L’analyse effectu´ee dans [95] indique que l’application installe ou remplace les
binaires situ´ees dans /system/bin. AndroBlare n’a lev´e aucune alerte indiquant
de tels comportements. Pour s’assurer qu’il ne s’agit pas de faux n´egatif, nous
avons list´e le contenu du r´epertoire et v´erifi´e si de nouveaux binaires ont ´et´e
cr´e´es ou si le contenu des fichiers pr´esents ont ´et´e chang´e pendant l’analyse de
l’application. Notre analyse a montr´e qu’aucun fichier n’a ´et´e cr´e´e ni modifi´e.
La version infect´ee de Finger Scanner est un ´echantillon de DroidKungFu 1.
Tout comme LeNa, DroidKungFu1 exploite une vuln´erabilit´e dans le syst`eme
Android afin d’´elever ses privil`eges et installer deux applications sur le t´el´ephone :
une native et une application Android. Lors de l’analyse de l’´echantillon de
DroidKungFu 1, AndroBlare a lev´e des alertes indiquant l’´ecriture de donn´ees
sensibles dans une entr´ee de procfs 3
, deux fichiers dans la partition system et
la propagation des donn´ees sensibles vers le fichier contenant la liste des applications
du t´el´ephone, l’application en charge d’une partie de l’installation des
nouvelles applications sur le t´el´ephone et un nouveau processus dont le nom est
une partie du nom d’un des nouveaux fichiers cr´e´es dans la partition system.
Ces alertes sont list´ees dans la figure 4.7. Ces alertes correspondent `a l’exploitation
de la vuln´erabilit´e par DroidKungFu 1 ainsi que l’ajoute de nouvelles
applications dans le syst`eme. La premi`ere alerte correspond `a l’exploitation de
la vuln´erabilit´e par le malware. Les alertes qui restent d´ecrivent l’ajout des
deux nouvelles applications system ainsi que l’ex´ecution de l’une d’entre elles
(com.google.ssearch.apk).
La version infect´ee de Savage Knife Game est un ´echantillon de BadNews.
BadNews est un malware dont le comportement est dict´e par un serveur de
commande. En analysant le code de l’´echantillon avec Androguard [97], nous
avons d´ecouvert que le malware peut recevoir X types de commande : installer
une application, afficher une notification `a l’utilisateur, changer l’adresse
des serveurs de commande, t´el´echarger des fichiers et ajouter des raccourcis
3. Syst`eme de fichier servant d’interface `a des donn´ees du syst`eme, y compris le noyau104 CHAPITRE 4. GRAPHES DE FLUX SYSTEME `
[POLICY_VIOLATION] process gjsvro:gjsvro 984 > file /proc/sys/kernel/
hotplug 4827 > itag[-3]
[POLICY_VIOLATION] process gjsvro:gjsvro 984 > file /system/bin/gjsvr
16738 > itag[-3 3]
[POLICY_VIOLATION] process gjsvro:gjsvro 984 > file /system/app/
com.google.ssearch.apk 8330 > itag[-3 3]
[POLICY_VIOLATION] process cat:cat 990 > file /system/app/com.google.
ssearch.apk 8330 > itag[3]
[POLICY_VIOLATION] process gjsvro:gjsvro 984 > socket (127.0.0.1) 0 > itag[-3 3]
[POLICY_VIOLATION] file /system/app/com.google.ssearch.apk 8330 > process
dexopt:dexopt 991 > itag[3]
[POLICY_VIOLATION] process dexopt:dexopt 991 > file /data/dalvik-cache/
system@app@com.google.ssearch.apk@classes.dex 24632 > itag[3]
[POLICY_VIOLATION] file /data/dalvik-cache/system@app@com.google.ssearch.apk
@classes.dex 24632 > process dexopt:dexopt 991 > itag[3]
[POLICY_VIOLATION] process droid.gallery3d:droid.gallery3d 995 > file /data/data/
com.android.gallery3d/shared\_prefs/com.android .gallery3d\_preferences.xml
57603 > itag[3]
[POLICY_VIOLATION] file /system/app/com.google.ssearch.apk 8330 > process
.google.ssearch:.google.ssearch 1059 > itag[3]
[POLICY_VIOLATION] file /data/dalvik-cache/system@app@com.google.ssearch.apk
@classes.dex 24632 > process .google.ssearch:.google.ssearch 1059 > itag[3]
Figure 4.7 – Extrait des alertes lev´ees par l’´echantillon de DroidKungFu1 lors
de l’´evaluation de la politique de Finger Scaner
Version originale Version infect´ee
Angry Birds 0 15
Finger scanner 0 11
Knife game 0 209
Table 4.1 – Nombre d’alertes lev´ees par Blare lors de l’ex´ecution des versions
originales et infect´ees de trois applications en appliquant une politique BSPL
soit vers des pages web soit vers des fichiers sur le t´el´ephone. Lors de l’analyse
de l’´echantillon, AndroBlare a lev´e 209 alertes. Une partie d’entre elles
correspondent au t´el´echargement de deux applications, leur installation et leur
ex´ecution sur le t´el´ephone. L’une des applications est pr´esent´ee comme ´etant
Adobe Flash mais est en r´ealit´e un jeu et l’autre application est une version
infect´ee du jeu Doodle Jump. L’autre partie des alertes d´ecrivent l’´echange de
donn´ees sensibles du navigateur avec d’autres objets du syst`eme. Ces alertes
sont dues au fait que l’´echantillon analys´e utilise le navigateur pour initier le
t´el´echargement des applications. Pour cela, il ´emet un intent pour ouvrir les
adresses web pointant vers les applications `a t´el´echarger. A partir ce moment, le `
navigateur se trouve ainsi marqu´e comme contenant une donn´ee sensible et tout
´echange qu’il aura avec les autres ´el´ements du syst`eme est vu par AndroBlare
comme impliquant une donn´ee sensible.4.5. POLITIQUE DE FLUX D’INFORMATION A PARTIR D’UN SFG ` 105
1
2
3
4
5
12
13
16
19
22
25
26 ...
27 ...
28
29
30
31
32
40
41
43
44 ...
45 ...
46
47
48
49
Listing 4.2 – Extrait de la politique BSPL de l’application Finger Scanner106 CHAPITRE 4. GRAPHES DE FLUX SYSTEME `
R´esum´e
Nous avons pr´esent´e dans ce chapitre une structure de donn´ees, SFG, repr´esentant
sous la forme de multigraphe orient´e les flux d’information qu’AndroBlare
d´etecte durant l’ex´ecution du syst`eme. Cette structure est le deuxi`eme
apport de la th`ese et la deuxi`eme ´etape vers l’accomplissement de notre objectif
principal qui est de classifier et d´etecter les malware Android. Dans l’exemple
propos´e en section 4.4, nous avons obtenu un SFG contenant moins de 100 arcs
`a partir de plus de 3000 flux observ´es. Grˆace `a sa compacit´e, le SFG permet de
comprendre rapidement les ´ev`enements qui se passent dans le syst`eme. L’analyse
du graphe obtenu `a partir des flux engendr´es par un ´echantillon de DroidKungFu
1 nous a ainsi permis d’identifier l’installation de deux applications
par le malware. En plus d’utiliser cette structure comme profil d’une application,
nous avons ´egalement montr´e qu’il ´etait possible de s’en servir pour cr´eer
la politique Blare d’une application. Nous avons test´e cette approche sur trois
applications populaires de Google Play et montr´e que les politiques produites
capturaient bien les flux caus´ees par les applications durant leur ex´ecution et
permettaient de d´etecter les d´eviations de comportement dues `a tout code malveillant
introduit dans les applications.
Le contenu de ce chapitre a fait l’objet de deux publications. La premi`ere
a ´et´e publi´ee `a WISG13 [18] et pr´esente la structure SFG ainsi que la mani`ere
dont elle peut ˆetre utilis´ee pour comprendre le comportement d’une application.
La deuxi`eme publication a ´et´e publi´ee `a IAS13 [20] et ´etendue dans un article
du journal [19]. Elle pr´esente la m´ethode de cr´eation de politique BSPL `a partir
d’un SFG ainsi que son ´evaluation.Chapitre 5
Caract´erisation et d´etection
de malware Android
Nous avons pr´esent´e dans le chapitre pr´ec´edent une structure de donn´ee qui
d´ecrit de mani`ere compacte comment les informations surveill´ees par AndroBlare
se propagent dans le syst`eme et propos´e d’utiliser cette structure pour
d´ecrire comment une application propage ses donn´ees dans le syst`eme. En analysant
le graphe d’un ´echantillon de DroidKungFu 1, nous avons montr´e qu’une
partie du graphe correspondait `a l’attaque effectu´ee par le malware. Selon l’analyse
effectu´ee dans [113], plus de 86% des ´echantillons de malware Android sont
des applications existantes auxquelles du code malveillant a ´et´e ajout´e. Cela
signifie donc que les ´echantillons d’un mˆeme malware ont un comportement partiellement
commun dˆu au code malveillant qui leur a ´et´e inject´e. Un ´echantillon
d’un malware est une application consid´er´ee comme ´etant une ´echantillon de
ce malware. Une partie des flux qu’ils causent devraient ainsi ˆetre les mˆemes.
En supposant que l’attaque observ´ee dans le graphe de l’´echantillon de DroidKungFu
1 soit dˆu `a un code qui a ´et´e inject´e dans l’application d’origine et
d’autres applications, peut-on ainsi retrouver ce sous-graphe dans le graphe des
autres ´echantillons ? Nous avons g´en´eralis´e ce probl`eme et r´epondons dans ce
chapitre aux deux questions suivantes.
1. Existe-t-il des sous-graphes communs aux SFG des applications malveillantes
telles que cette partie commune corresponde au comportement
introduit par le code malveillant dans ces applications ?
2. Si un tel sous graphe existe, permet-il de d´etecter d’autres ´echantillons
du malware ?
Afin de r´epondre `a ces questions, nous pr´esentons et ´evaluons dans ce chapitre
une m´ethode pour calculer ce sous-graphe en commun et une m´ethode de
d´etection utilisant les flux d’information et les sous-graphes en commun pour
d´etecter l’ex´ecution d’´echantillon de malware.
107108 CHAPITRE 5. CARACTERISATION ET D ´ ETECTION DE MALWARE ´
5.1 Caract´erisation de malware Android : classi-
fication d’applications malveillantes Android
Nous proposons de caract´eriser un malware avec le(s) sous-graphe(s) en
commun aux SFG de ses ´echantillons qui d´ecrit son comportement malveillant.
Afin d’extraire cette partie commune, nous calculons les arcs en commun aux
SFG des ´echantillons de malware comme d´ecrit par l’algorithme 3. Le calcul effectu´e
peut ˆetre vu comme un processus de classification non supervis´ee o`u nous
cherchons `a regrouper les SFG, implicitement les applications correspondantes,
ayant des parties communes et parall`element `a calculer un profil pour chaque
classe qui caract´erise ses ´el´ements. Id´ealement, les ´echantillons d’un mˆeme malware
seraient regroup´ees au sein d’une mˆeme classe et donc caract´eris´es par
un seul profil. Contrairement aux autres approches effectuant des classifications
non supervis´ees sur les ´echantillons de malware ou des applications en
g´en´eral [67, 89, 90, 22], nous n’utilisons aucune notion de distance entre chaque
´el´ement pour d´eterminer s’ils devraient faire partie d’une mˆeme classe. A la `
place, nous consid´erons que deux ´el´ements, ici des SFG, font partie d’une mˆeme
classe s’ils ont une partie commune non nulle.
Une classification consiste `a apprendre `a partir d’un jeu de donn´ees un
mod`ele d´efinissant comment ces donn´ees sont ou peuvent ˆetre regroup´ees. Ici
nous souhaitons calculer des classes de SFG et les profils caract´erisants les
´el´ements de chaque classe. Ce jeu de donn´ees est repr´esent´e par la premi`ere
liste donn´ee en param`etre de l’algorithme 3. Une deuxi`eme liste est donn´ee en
param`etre mais elle sert uniquement `a filtrer les arcs qui pourraient faire partie
des profils que nous calculons. Ce filtrage est effectu´e par la fonction clean au
d´ebut de la classification. Nous donnerons plus de d´etail sur cet aspect plus
tard.
Initialement, la classification associe une classe diff´erente `a chacun des SFG
des applications. Le r´esultat renvoy´e par l’algorithme, c’est-`a-dire la classifi-
cation finale, est obtenue en calculant un point fixe sur l’´evolution de cette
classification. Le calcul du point fixe est repr´esent´e par la boucle while tandis
que la mise `a jour de la classification est op´er´ee par la fonction one-step-classification
(algorithme 4). Cette fonction prend en entr´ee une liste de classe
en param`etre et fusionne les paires de classes dont les profils ont une partie
commune. En supposant ainsi qu’il y ait n classes dans la classification donn´ee
en param`etre, elle v´erifie pour toute combinaison de deux classes si leurs profils
respectifs ont une partie commune non nulle. Cela se traduit par C
2
n
calculs d’intersection
de deux SFG. Si c’est le cas, elle fusionne les deux classes et associe
comme profil `a la classe r´esultante cette partie commune non nulle. Aux ´el´ements
des deux classes ayant ´et´e fusionn´ees s’ajoutent les ´el´ements des autres classes
dont le profil contient l’intersection des profils des deux classes fusionn´ees. Si
une classe n’a ´et´e fusionn´ee avec aucune autre classe, elle est ajout´ee telle quelle
dans la nouvelle classification.5.1. CARACTERISATION DE MALWARE ANDROID ´ 109
Algorithme 3 : Calcul des parties communes de SFG d’application caract´erisant
son comportement malveillant et regroupement de ces SFG
Input :
[g0,. . . ,gn] une liste de SFG
white une liste blanche de SFG
Output : [(s0,[g01
,. . . ,g0i
]),. . . ,(sm,[gm1
,. . . ,gmk
])] une liste de couple
associant les sous-graphes communs aux graphes les contenant
begin
assoc Ð H;
new assoc Ð [(clean (g0, white),[g0]),. . . ,(clean (gn, white),[gn])];
while passoc ‰ new assocq do
assoc Ð new assoc;
new assoc Ð one-step-classificationpassocq;
return assoc;
Algorithme 4 : One-step-classification function
Input :
assoc une liste de SFG
Output : une liste d’association de SFG
begin
new assoc Ð rs ;
tmp Ð H;
forall the g1 P keyspassocq do
forall the g2 P keyspassocqztg1u do
if pg1, g2q P tmp or pg2, g1q P tmp then
continue;
tmp Ð tmp Ytpg1, g2qu;
s Ð g1 [ g2 ;
if s “ H then
v Ð valuepassoc, g1q ` valuepassoc, g2q ;
forall the g P keyspassocqztg1, g2u do
if s Ď g then
v Ð v + value (assoc, g)
new assoc Ð addpnew assoc,ps, vqq;
return new assoc;110 CHAPITRE 5. CARACTERISATION ET D ´ ETECTION DE MALWARE ´
Pr´e-traitement des ´el´ements `a classifier : filtrage des arcs
des SFG
Nous avons mentionn´e pr´ec´edemment que la deuxi`eme liste donn´ee en entr´ee
de l’algorithme 3 ´etait utilis´ee par la fonction clean pour filtrer les arcs pouvant
faire partie des profils que nous calculons. Filtrer les arcs pouvant faire partie
des profils est une n´ecessit´e car une partie des SFG des applications Android
est la mˆeme que ces applications soient b´enignes ou non. Nous filtrons ainsi
les arcs `a prendre en compte dans les profils afin de ne pas calculer des profils
g´en´eriques d´ecrivant toute application Android au lieu de profils de malwrare
d´ecrivant leur comportement malveillant.
Cette partie commune entre les SFG des applications Android est due `a
la mani`ere dont les applications sont ´ecrites et `a la mani`ere dont l’environnement
Android fonctionne. En effet, les composants des applications Android
sont des composants qui ´etendent des classes pr´ed´efinies dans Android, `a savoir
Activity, BroadcastReceiver, Service et ContentProvider. Les composants
h´eritent ainsi des fonctionnalit´es de ces classes. Ainsi, ils ont tous par exemple
la mˆeme r´ef´erence au ContextManager, classe servant `a demander les r´ef´erences
des diff´erents services du syst`eme. Cette classe effectue la requˆete au processus
servicemanager par d´efaut. De plus, l’interaction avec le reste du syst`eme se
fait souvent avec des fonctions fournies par l’API Android ce qui peut causer des
flux similaires aux applications. Pour cr´eer ou acc´eder aux pr´ef´erences de l’application,
les applications utilisent souvent la fonction getSharedPreferences
par exemple. L’usage des pr´ef´erences est conseill´e dans divers cas tels que la sauvegarde
des donn´ees lorsqu’une applications est mise en pause par le syst`eme.
Le fichier stockant les pr´ef´erences est localis´e dans le r´epertoire local de l’application
par d´efaut et son acc`es via l’API d’Android est ainsi le mˆeme pour toutes
les applications.
A cause de ce caract`ere commun, des comportements communs sont par- `
tag´es entre les applications qu’elles soient b´enignes ou non. Ce qui implique
qu’une partie des flux d’information qu’elles causent sont les mˆemes. En calculant
simplement le sous-graphe commun aux graphes des ´echantillons de malware
sans effectuer de filtrage, nous risquerions d’obtenir un graphe en commun
caract´erisant n’importe quelle application Android et tout comportement malveillant
sera ainsi absent de ce graphe. Pour palier `a ce probl`eme, il est ainsi
n´ecessaire de filtrer les ´el´ements `a prendre en compte dans les sous-graphes en
commun que nous calculons. Dans les exp´eriences men´ees en section 5.2, nous
filtrons les arcs `a prendre en compte dans les profils de malware. Nous ignorons
les arcs qui d´ecrivent un flux impliquant les processus system server, celui
ex´ecutant l’application de galerie d’images et les fichiers dans /acct/uid 1
. A`
ces flux s’ajoutent ceux d´ecrits par les ´el´ements de la deuxi`eme liste donn´ee
en entr´ee de l’algorithme 3. Les ´el´ements de cette liste sont des SFG d’applications
b´enignes que nous consid´erons comme repr´esentant les comportements
communs que nous ne souhaitons pas ˆetre pris en compte durant le calcul des
1. Voir les pages manuel de acct sous Linux5.2. EVALUATION DE LA M ´ ETHODE DE CLASSIFICATION ´ 111
profils. Nous calculons dans la section 5.3 le r´esultat obtenu quand aucun filtrage
n’est appliqu´e et montrons que les classes produites ainsi que les profils calcul´es
sont trop g´en´eriques pour refl´eter un quelconque malware. Dans la section 5.3,
nous montrons l’utilit´e de ce filtrage en r´ep´etant la classification effectu´ee en
section 5.2.
5.2 Evaluation de la m´ethode de classification ´
5.2.1 Jeu de donn´ee
Afin d’´evaluer notre algorithme de calcul de sous-graphe, nous proposons
de l’appliquer sur 19 ´echantillons de malware : 5 ´echantillons de BadNews [91],
7 de DroidKungFu1 [61], 3 de DroidKungFu2 [60] et 5 de jSMSHider [96]. En
plus de ces 19 ´echantillons, nous utilisons ´egalement 7 applications provenant
de Google Play dont les SFG constitueront la liste blanche. Ces applications
sont compos´es de quatre jeux (Angry birds, Little Dentist, Finger Scanner et
Crazy Jump), un navigateur web (Firefox), deux utilitaires (Android Term et
Busybox Free) et une application de fond d’´ecran (Ironman 3 live).
BadNews est un malware qui infecte les syst`emes Android sous la forme
d’applications l´egitimes. En analysant manuellement les 5 ´echantillons avec Androguard,
nous avons d´etermin´e que BadNews est un malware dont le comportement
est dict´e par un serveur de commande et contrˆole (C&C). A l’ex´ecution `
du code malveillant, il contacte le serveur afin d’obtenir la prochaine commande
`a ex´ecuter. D’apr`es l’analyse effectu´ee, il comprend plusieurs commandes : t´el´echarger
et installer une application, afficher des informations sous forme de
notification (page web `a visiter, mise `a jour d’une application etc), installer
de nouveaux icˆones qui m`enent vers une page web ou une application Android
qui aurait ´et´e pr´ealablement t´el´echarg´ee et changer l’adresse du serveur C&C.
Durant les p´eriodes d’exp´erimentation que nous avons men´ees, le serveur ´etait
toujours actif et envoyait les mˆemes commandes `a chaque fois : t´el´echarger deux
applications et afficher des notifications de mises `a jour `a l’utilisateur qui une
fois cliqu´ees causent l’installation des applications. Les deux applications sont
une version infect´ee de Doodle Jump et un jeu en Russe qui est pr´esent´e comme
´etant une version d’Adobe Flash pour Android.
DroidKungFu1 est un malware d´ecouvert en 2011 qui installe furtivement
des applications sur le t´el´ephone en exploitant des vuln´erabilit´es du syst`eme ou
grˆace `a la commande su. Les applications sont install´ees sur la partition system
afin de rendre permanente leur pr´esence sur le t´el´ephone. Cette partition est par
d´efaut mont´ee en lecture seule et par d´efaut un utilisateur ne peut en changer
le contenu. Un acc`es root est n´ecessaire pour cela.
DroidKungFu2 a un comportement similaire `a DroidKungFu1. Il exploite
´egalement une vuln´erabilit´e du syst`eme pour ´elever ses privil`eges et installer
des applications sur le t´el´ephone.
jSMSHider est un malware qui installe ´egalement d’autres applications sur
le t´el´ephone de mani`ere furtive. Contrairement aux deux malwares pr´ec´edents,112 CHAPITRE 5. CARACTERISATION ET D ´ ETECTION DE MALWARE ´
il n’exploite aucune vuln´erabilit´e dans le syst`eme pour installer les applications.
A la place, son d´eveloppeur a sign´e les ´echantillons du malware avec la cl´e ayant `
servie `a signer les applications syst`eme dans les images non officielles d’Android.
Ces images sont cr´e´ees par des d´eveloppeurs de la communaut´e Android qui
d´eveloppent des versions personnalis´ees du syst`eme. L’un des plus connus est
Cyanogen Mod. Cette cl´e est celle qui est pr´esente dans les d´epˆots du code source
d’Android et est ainsi accessible `a tous. Elle n’est cependant utilis´ee pour signer
les applications dans les ROM officielles. En signant les ´echantillons avec cette
cl´e, les ´echantillons obtiennent ainsi des droits r´eserv´es aux applications syst`eme
telles que l’installation d’une application sur le t´el´ephone.
5.2.2 Exp´erimentation et r´esultat
Analyse des applications
Afin d’obtenir les SFG des ´echantillons, il faut dans un premier temps les
analyser pour observer comment leurs donn´ees se propagent dans le syst`eme.
Nous avons utilis´e l’environnement d’analyse d´ecrit en section 3.5 : un t´el´ephone
Android faisant tourner la version 4.0 d’Android Ice Cream Sandwich auquel a
´et´e ajout´e l’environnement AndroBlare, c’est-`a-dire le noyau modifi´e ainsi que
les applications en espace utilisateur.
Pour chaque application, nous r´ep´etons le processus suivant. Nous l’installons
sur le t´el´ephone, associons un identifiant unique `a ses donn´ees en marquant
son apk avec cet identifiant et l’ex´ecutons. Nous utilisons chaque application
comme un utilisateur lambda le ferait selon les fonctionnalit´es propos´ees par
l’application.
En addition `a cela, nous introduisons des ´ev`enements dans le syst`eme qui
sont les ´el´ements d´eclencheurs des codes malveillants pr´esents dans les ´echantillons
´etudi´es. Ces ´ev`enements ont ´et´e d´ecouverts en analysant le code de quelques
´echantillons de ces malwares. Nous pr´esentons dans ce qui suit ces ´ev`enements
d´eclencheurs mais invitons le lecteur `a lire l’annexe A pour l’analyse d´etaill´ee
ayant men´e `a leur d´ecouverte.
Afin d’´eviter ou de retarder toute d´etection, les d´eveloppeurs de malware
ajoutent parfois des conditions `a l’ex´ecution de leur code. Le code malveillant
dans BadNews ne s’ex´ecute par exemple que lorsque le composant MainService
ne re¸coit un intent lui signifiant de s’ex´ecuter. Pour ´eviter que le composant ne
soit lanc´e `a la r´eception de n’importe quel intent, le d´eveloppeur de BadNews
ajoute une v´erification suppl´ementaire lors de la r´eception du message. Il v´erifie
que l’intent re¸cu contienne un param`etre update et que la valeur associ´ee `a
ce param`etre vaut true. Nous envoyons ainsi manuellement un intent avec un
param`etre update dont la valeur associ´ee vaut true `a ce composant afin que le
code malveillant s’ex´ecute et que nous puissions observer les flux d’information
qu’il cause. Nous effectuons l’envoi grˆa ce `a la commande am, accessible `a partir
du shell d’Android comme le montre la commande ci-dessous.
$ am startservice APP_NAME/PACKAGE_NAME.AdvService \
--ez update 15.2. EVALUATION DE LA M ´ ETHODE DE CLASSIFICATION ´ 113
Dans le cas de DroidKungFu1 et DroidKungFu2, certains ´echantillons ont
une dur´ee minimale d’attente avant d’ex´ecuter le code malveillant. Cette dur´ee
est obtenue en soustrayant l’heure du syst`eme avec une date stock´ee dans un
fichier sstimestamp.xml dans le r´epertoire local de l’application. Le listing 5.1
est le contenu du fichier avant toute modification pour un des ´echantillons de
DroidKungFu1. En rempla¸cant la valeur stock´ee dans ce fichier par une valeur
assez petite, par exemple 1, nous for¸cons l’ex´ecution du code malveillant.
Nous changeons ici le contenu du fichier sstimestamp.xml lors de l’analyse des
´echantillons de DroidKungFu1 et DroidKungFu2 afin de s’assurer que le code
malveillant soit ex´ecut´e.
1
2
Listing 5.1 – Contenu du fichier sstimestamp.xml d’un ´echantillon de DroidKungFu1
Quant aux ´echantillons de jSMSHider, il n’est pas n´ecessaire d’introduire
un quelconque ´ev`enement car le code malveillant est ex´ecut´e d`es le lancement
de l’application. Une fois les applications analys´ees, nous construisons les SFG
correspondants et calculons les parties qui leur sont communes avec un outil
impl´ementant l’algorithme 3. Nous pr´esentons dans ce qui suit les r´esultats
obtenus.
R´esultats
A partir des SFG obtenus, nous avons calcul´e 4 profils, c’est-`a-dire 4 SFG. `
A chacun d’entre eux est associ´e un sous-ensemble des SFG donn´es en entr´ee. `
Le tableau 5.1 pr´esente les r´esultats du calcul. La premi`ere colonne liste les
´echantillons utilis´es. La deuxi`eme colonne indique la famille `a laquelle l’´echantillon
appartient selon la classification effectu´ee par les auteurs de la collection d’o`u il
provient. La troisi`eme colonne indique la collection d’o`u provient l’´echantillon.
Les colonnes restantes repr´esentent chacune un profil qui a ´et´e calcul´e `a partir
des SFG des ´echantillons. Pour chaque ´echantillon, une case non vide dans
l’une de ces colonnes signifie que le SFG de l’´echantillon contient le SFG correspondant
au profil. Par cons´equent, le profil caract´erise le comportement de
l’´echantillon. Les profils calcul´es sont illustr´es par les figures 5.1, 5.2, 5.3 et 5.4.
Le SFG de l’´echantillon live.photo.savanna.apk contient par exemple S0, le
SFG illustr´e par la figure 5.1. Sur les 19 ´echantillons utilis´es, 17 d’entre eux sont
regroup´es exactement selon leur classification dans leur base d’origine.
Le profil S0, figure 5.1, caract´erise les ´echantillons de BadNews. Il d´ecrit l’envoi
des donn´ees de l’application vers un deux serveurs distant, le t´el´echargement
de deux applications et une partie de leur installation ainsi que de leur ex´ecution.
L’envoi des donn´ees correspond aux flux partant du navigateur, android.brow-114 CHAPITRE 5. CARACTERISATION ET D ´ ETECTION DE MALWARE ´
Empreinte MD5 des ´echantillons Famille: Origine§ S0 S1 S2 S3
98cfa989d78eb85b86c497ae5ce8ca19 BN C
‘
e70964e51210f8201d0da3e55da78ca4 BN I
‘
4ecf985980bcc9b238af1fdadd31de48 BN I
‘
ccab22538dd030a52d43209e25c1f07b BN I
‘
3a648e6b7b3c5282da76590124a2add4 BN I
‘
994af7172471a2170867b9aa711efb0d DKF1 G
‘
39d140511c18ebf7384a36113d48463d DKF1 G
‘
7f5fd7b139e23bed1de5e134dda3b1ca DKF1 A
‘
107af5cf71f1a0e817e36b8deb683ac2 DKF1 A
‘
6625f4a711e5afaee5f349c40ad1c4ab DKF1 G
‘
6b7c313e93e3d136611656b8a978f90d DKF1 A
‘
4f6be2d099b215e318181e1d56675d2c DKF2 G
‘
72dc94b908b0c6b7e3cb293d9240393c DKF2 G
‘
f438ed38b59f772e03eb2cab97fc7685 DKF2 G
‘
ac2a5a483036eab1b363a7f3c2933b51 DKF1 A
‘
0417b7a90bb5144ed0067e38f7a30ae0 JSH G
‘
a3c0aacb35c86b4468e85bfb9e226955 JSH G
‘
d25008db2e77aae53aa13d82b20d0b6a JSH A
‘
24663299e69db8bfce2094c15dfd2325 JSH A
‘
: BN : BadNews, DKF1 : DroidKungFu1, DKF2 : DroidKunFu2, JSH : jSMSHider
§ C : Contagio, G : Genome Project, A : Androguard, I : Internet
Table 5.1 – Classification des 19 ´echantillons de malware.5.2. EVALUATION DE LA M ´ ETHODE DE CLASSIFICATION ´ 115
57664 - files/player
24642 - /data/dalvik-cache/data@app@com.realarcade.DOJ-1.apk@classes.dex
1047 - dexopt
*
1050 - .realarcade.DOJ
*
*
81 - mediaserver
*
*
*
57667 - files/stats
*
57663 - files/4200
*
57665 - files/4201
*
57666 - files/multi
* *
32791 - /data/app/com.realarcade.DOJ-1.apk
*
* *
320 - ndroid.launcher
*
57460 - downloads.db
*
577 - iders.downloads
57361 - data_3 0 - (82.x.x.x) 762 - id.defcontainer
7958 - /mnt/asec/smdl2tmp1/pkg.apk
*
1026 - ackageinstaller
*
15 - /sdcard/download/adobe.flash.apk
*
80 - drmserver
*
14 - /sdcard/download/doodle.jump.apk
*
275 - d.process.media
*
57378 - downloads.db-journal
*
973 - android.browser
*
* *
*
8237 - /data/drm/fwdlock/kek.dat
*
* *
0 - (213.x.x.x)
* *
* *
*
*
Figure 5.1 – S0 : sous-graphe en commun des ´echantillons de BadNews116 CHAPITRE 5. CARACTERISATION ET D ´ ETECTION DE MALWARE ´
ser, vers deux sockets r´eseaux. Sur la figure, nous avons intentionnellement
masqu´e une partie des adresses IP. Apr`es v´erification, l’une des adresses, 213.
x.x.x, est celle du serveur `a partir duquel les applications sont t´el´echarg´ees.
Le t´el´echargement est d´ecrit par l’´ecriture de donn´ees sensibles dans deux fi-
chiers apk par le processus iders.downloads. Ce dernier ex´ecute l’application
par d´efaut en charge des t´el´echargements de fichier. L’acc`es `a ces deux fichiers
par les processus id.defcontainer et packageinstaller indique leur installation
et la premi`ere composante connexe du SFG en partant du haut d´ecrit
l’ex´ecution d’une nouvelle application, une de celles qui ont ´et´e t´el´echarg´ees par
le malware. Ici, il s’agit de la version infect´ee de Doodle Jump. L’ex´ecution de
l’autre application n’est pas pr´esente dans le profil car il est install´e dans un
r´epertoire chiffr´e qui ne supporte pas les attributs ´etendus. Il est ainsi impossible
pour AndroBlare de suivre les flux d’information impliquant les fichiers dans ce
type de r´epertoire.
Le profil S1, figure 5.2, caract´erise les ´echantillons de DroidKungFu1 `a l’exception
de deux d’entre elles que nous expliquerons dans le paragraphe suivant.
S1 d´ecrit la copie de deux fichiers dans la partition system et l’ex´ecution de l’une
d’entre elles par la suite. Leur destination indique qu’il s’agit d’une application
native et d’une application Android.
8330 - /system/app/com.google.ssearch.apk
338 - ndroid.launcher
*
1106 - dexopt
*
57656 - /data/data/blare-anonym/gjsvro
1056 - gjsvro
*
*
0 - (127.0.0.1)
*
16735 - /system/bin/gjsvr
*
24640 - /data/dalvik-cache/system@app@com.google.ssearch.apk@classes.dex
*
1105 - cat
*
*
57660 - /data/data/blare-anonym/legacy
* *
Figure 5.2 – S1 : sous-graphe en commun des ´echantillons de DroidKungFu 1
Le profil S2, figure 5.3, caract´erise les ´echantillons de DroidKunFu2 ainsi
que deux ´echantillons de DroidKungFu1 qui ne sont pas caract´eris´es par S1. S2
indique l’acc`es du contenu de deux fichiers au contenu teint´es par les processus
secbino et cat. Si ces flux n’indiquent rien de malveillant en soi, elles correspondent
cependant au d´ebut de l’attaque effectu´ee par le malware. Ces processus
servent en effet `a la copie d’applications malveillantes dans le syst`eme. Comme5.2. EVALUATION DE LA M ´ ETHODE DE CLASSIFICATION ´ 117
mentionn´e pr´ec´edemment, deux ´echantillons de DroidKungFu1 sont ´egalement
caract´eris´es par S2. La raison est que ces ´echantillons partagent uniquement des
comportements en commun avec les ´echantillons de DroidKunFu2 en terme de
flux. Ainsi aucune fichier gjsvro ou com.google.search.apk, ni les processus
correspondants n’ont ´et´e cr´e´es durant leur analyse.
1111 - cat
57651 - /data/data/blare-anonym/mycfg.ini
1113 - cat
*
1073 - secbino
*
971 - secbino
57656 - /data/data/blare-anonym/WebView.db
* *
57652 - /data/data/blare-anonym/secbino
*
Figure 5.3 – S2 : sous-graphe en commun des ´echantillons de DroidKungFu 2
Le profil S3, figure 5.4, caract´erise les ´echantillons de jSMSHider et d´ecrit
l’installation ainsi que le d´ebut de l’ex´ecution d’une nouvelle application. L’acc`es
au fichier testnew.apk par le processus id.defcontainer indique l’installation
d’une nouvelle application. La lecture du fichier jSMSHider.apk par le processus
dexopt puis la cr´eation d’un fichier .dex par ce dernier indique l’ex´ecution d’une
nouvelle application. En effet, le processus dexopt est celui en charge d’extraire
le code des applications `a partir de l’apk et de cr´eer sa version optimis´ee.
A partir des SFG d’´echantillons de 4 familles de malware, nous avons extrait `
4 profils comportementaux sous la forme de SFG. Chacun de ces profils correspond
`a une famille de malware et d´ecrit une partie des comportements connus
de ces malwares. Le calcul de ces profils est rendu possible grˆace aux SFG de
7 applications b´enignes qui nous servent `a filtrer les ´el´ements faisant partie de
ces profils. La liste d’application est compos´ee de 5 jeux (Angry Birds, Crazy
Jump, Fingerprint scanner et Dentist), d’un navigateur internet (Firefox) et de
deux utilitaires (un terminal et la boˆıte `a outil busybox).
883 - dexopt
24640 - /data/dalvik-cache/data@app@j.SMSHider-1.apk@classes.dex
* *
32788 - /data/app/j.SMSHider-1.apk
*
748 - id.defcontainer
57659 - /data/data/blare-anonym/files/testnew.apk
*
Figure 5.4 – S3 : Sous-graphe en commun des ´echantillons de jSMSHider118 CHAPITRE 5. CARACTERISATION ET D ´ ETECTION DE MALWARE ´
Filtrage Nombre de groupe cr´e´es
Aucun filtrage 1
Sans la liste blanche 4
Filtre de base plus 7 SFG 4
20 applications de Google Play 4
Table 5.2 – Nombre de profils obtenus en variant le filtrage
5.3 De la n´ecessit´e du filtrage
Nous appliquons un processus de filtrage dans l’´evaluation effectu´ee en section
5.2.2. Ce filtre est compos´e des arcs d´ecrivant des flux avec les processus
system server et mediaserver ainsi que ceux des SFG de 7 applications. La
raison de ce filtrage est d’´eviter de calculer des classes et profils trop g´en´eriques
qui ne refl`etent aucun malware. Afin de montrer la n´ecessit´e de ce filtrage,
nous r´ep´etons l’exp´erience mais en faisant varier le filtrage. Nous avons r´ealis´e
l’exp´erience sans utiliser aucun filtre, c’est-`a-dire sans liste blanche ni les flux impliquant
les conteneurs cit´es en section 5.1, sans la liste blanche puis en utilisant
le filtrage de la section pr´ec´edente mais en ajoutant des SFG suppl´ementaires
`a la liste blanche. Le tableau 5.2 pr´esente les r´esultats obtenus. Chaque ligne
pr´esente le r´esultat obtenu selon le filtrage appliqu´e. La premi`ere colonne liste
les diff´erents filtrages et la seconde le nombre de profils/groupes cr´e´e. Nous
discutons dans ce qui suit de la pertinence des groupes cr´e´es.
En utilisant aucun filtrage, l’algorithme extrait un seul sous-graphe qui est
une partie commune aux SFG des 19 ´echantillons de malware utilis´es. La fi-
gure 5.5 illustre ce sous-graphe. Les flux d´ecrits par le sous-graphe indique
uniquement des ´echanges d’information entrele processus system server et
diff´erents processus. Le profil calcul´e est trop g´en´erique et ne d´ecrit aucun comportement
malveillant connu des malwares utilis´es.
En filtrant sans la liste blanche, nous obtenons 4 profils associ´es `a 4 groupes
diff´erents. Si le nombre de profils correspond au nombre de malwares utilis´es,
ils ne d´ecrivent cependant aucune action malveillante et les ´echantillons dans
chaque groupe sont des ´echantillons de malware diff´erent dont le comportement
en terme de flux d’information ne devrait pas ˆetre le mˆeme. Les figures 5.6,
5.7, 5.8 et 5.9 illustrent les profils calcul´es et d´ecrivent des flux tout `a fait
normaux dans le syst`eme. La premi`ere figure d´ecrit par exemple un simple
´echange d’information entre les applications syst`eme com.android.phone et
com.android.systemui.
En ´etendant la liste blanche utilis´ee en section 5.2.2 de 20 SFG suppl´ementaires,
nous obtenons les mˆemes profils et les mˆemes groupes que ceux calcul´es dans
la section 5.2.2. Augmenter le nombre d’´el´ements dans cette liste est inutile
et les SFG des applications qui la composent repr´esentent de mani`ere satisfaisante
les comportements g´en´eriques que nous souhaitions ignorer durant notre
classification.5.3. DE LA NECESSIT ´ E DU FILTRAGE ´ 119
326 - ndroid.launcher
135 - system_server *
82 - mediaserver
*
292 - m.android.phone
*
903 - app_process *
*
*
*
206 - ndroid.systemui
*
673 - ufou.android.su
*
310 - com.android.nfc
*
*
32783 - /data/app/blare-anonym-1.apk *
Figure 5.5 – Profil calcul´e lorsqu’aucun filtrage n’est r´ealis´e120 CHAPITRE 5. CARACTERISATION ET D ´ ETECTION DE MALWARE ´
308 - m.android.phone
221 - ndroid.systemui
Figure 5.6 – Premier profil calcul´e en utilisant aucune liste blanche
202 - ndroid.systemui
32781 - /data/app/blare-anonym-1.apk
Figure 5.7 – Second profil calcul´e en utilisant aucune liste blanche
276 - d.process.media
57526 - /data/data/com.android.providers.media/databases/external.db 57524 - /data/data/com.android.providers.media/databases/external.db-wal
Figure 5.8 – Troisi`eme profil calcul´e en utilisant aucune liste blanche
1400 - m.android.email
1416 - ndroid.exchange
57472 - /data/data/com.android.email/databases/EmailProvider.db 57473 - /data/data/com.android.email/databases/EmailProvider.db-journal
Figure 5.9 – Quatri`eme profil calcul´e en utilisant aucune liste blanche5.4. DETECTION D’EX ´ ECUTION DE MALWARE ANDROID ´ 121
L’algorithme 3 que nous avons propos´e dans cette section est algorithme de
classification qui regroupe les SFG des applications ayant des parties communes
non nulles et calcule `a la fois le profil correspondant `a chaque classe. Nous avons
´evalu´e cet algorithme avec un jeu de donn´ees de 19 ´echantillons provenant de 4
familles de malware diff´erentes. En appliquant l’algorithme sur les SFG des 19
´echantillons, nous avons calcul´e 4 profils tels que chaque profil corresponde `a une
famille de malware diff´erent et d´ecrit le comportement malveillant du malware
auquel il correspond. Dans la section qui suit, nous proposons une m´ethode
de d´etection d’´echantillon de malware en utilisant les profils calcul´es par notre
algorithme.
5.4 D´etection d’ex´ecution de malware Android
Les r´esultats pr´ec´edents, tableau 5.1, montrent que les ´echantillons de malware
peuvent ˆetre caract´eris´es par un SFG qui d´ecrit une partie de comportement
malveillant qu’ils ont. Dans cette section, nous proposons cette fois d’utiliser
ces profils SFG pour d´etecter l’ex´ecution d’autres ´echantillons de malware.
Plus pr´ecis´ement, nous proposons d’utiliser ces profils SFG en tant que profil
de r´ef´erence afin de d´etecter si les donn´ees d’une application sous surveillance
se propagent de la mˆeme mani`ere que celle d´ecrite par l’un des SFG.
L’algorithme 5 d´ecrit le processus de d´etection pour une application/information
donn´ee. Il prend en entr´ee les flux observ´es par AndroBlare ainsi qu’une
liste de profil SFG avec lesquels il compare les flux observ´es pour d´etecter
l’ex´ecution de malware. A l’initialisation du processus de d´etection, nous com- `
men¸cons par construire une liste d’association dans laquelle nous associons
chaque arc des profils donn´es en entr´ee avec la liste des profils SFG(s) o`u il
est pr´esent. Cette ´etape facilite la recherche d’une correspondance entre les flux
observ´es et les arcs des profils SFG. Lors de la phase de d´etection, nous comparons
ensuite chaque flux observ´e avec les arcs des diff´erents profils SFG afin de
trouver une similarit´e entre eux. Si une similarit´e est trouv´ee, nous levons une
alerte. Nous consid´erons qu’il y a une similarit´e entre un flux d’information et
un arc si les conteneurs d’information de d´epart et d’arriv´ee du flux observ´e sont
respectivement les mˆeme que ceux d´ecrits par les nœuds de d´epart et d’arriv´ee
de l’arc et que les informations qui se propagent dans le flux observ´e et celui du
flux d´ecrit par l’arc sont les mˆemes. Le conteneur d’information dans une entr´ee
de Blare est le mˆeme que celui repr´esent´e par un nœud d’un SFG lorsqu’ils ont
le mˆeme type et le mˆeme nom. Apr`es avoir lev´e l’alerte, nous enlevons l’arc de
la liste d’association afin de ne pas lever la mˆeme alerte plusieurs fois.122 CHAPITRE 5. CARACTERISATION ET D ´ ETECTION DE MALWARE ´
Algorithme 5 : D´etection de l’ex´ecution de malware Android bas´e sur les
flux d’information caus´e dans le syst`eme
Input : L journal de Blare, sig l liste de profils SFG
begin
notseen Ð empty association list;
forall the g P sig l do
forall the e P edgespgq do
if e R keyspnotseenq then
Add pe, tguq to notseen;
else
old Ð valuepe, notseenq;
Remove pe, oldq from notseen;
Add the association pe, old Y tguq to notseen;
forall the entry e P L do
if to edgepeq Plight keyspnotseenq then
l Ð valuepto edgepeq, notseenq;
forall the g P l do
Alert that a similarity with namepgq has been found;
Remove pto edgepeq, lq from notseen;
5.5 Evaluation de la capacit´e de d´etection ´
Afin d’´evaluer la capacit´e de d´etection de l’approche pr´esent´ee pr´ec´edemment,
nous proposons deux types d’exp´erience. Le premier consiste `a ´evaluer le taux
de faux positif, c’est-`a-dire calculer le taux de fausses alertes lev´ees lorsque des
applications b´enignes sont analys´ees. Le deuxi`eme consiste `a ´evaluer le taux de
vrai positif, c’est-`a-dire calculer le taux d’alertes lev´ees lorsque des applications
malicieuses sont ex´ecut´ees. Pour mener ces exp´eriences, nous proposons d’analyser
des applications, b´enignes et malicieuses, dans l’environnement d’analyse
pr´esent´e en section 3.5 et `a partir des flux observ´es d´etecter les ex´ecutions de
malware.
Jeu de donn´ees
Nous utilisons 70 des applications les plus populaires 2 dans Google Play pour
la premi`ere exp´erience et 39 ´echantillons de malware provenant des 4 familles de
malware utilis´ees dans la section 5.2.2. Nous supposons que les 70 applications
sont b´enignes car elles n’ont lev´e aucune alerte lorsque nous les avons soumises
`a la plateforme d’analyse de VirusTotal [14].
2. au mois de Juin 20135.5. EVALUATION DE LA CAPACIT ´ E DE D ´ ETECTION ´ 123
Analyse des applications et d´etection de l’ex´ecution de malware
Le processus d’analyse de chaque applications est le mˆeme qu’en section 5.2.2.
Il se traduit par son installation dans un environnement AndroBlare, le marquage
de son apk et son ex´ecution. Nous utilisons chaque application comme
un utilisateur normal le ferait et en parall`ele, nous introduisons les ´ev`enements
d´eclenchant le code malveillant dans les ´echantillons de malware. Introduire ces
´ev`enements nous assure que le code malveillant se d´eclenche durant l’analyse
afin de d´eterminer si oui ou non notre approche permet de d´etecter l’ex´ecution
du code malveillant.
Une fois les applications analys´ees, nous analysons les flux observ´es par
AndroBlare pour d´etecter l’ex´ecution de malware. La d´etection est r´ealis´ee
ult´erieurement `a l’analyse car nous souhaitions collecter les flux et ˆetre capables
de les r´eutiliser plus tard. L’outil utilis´e est cependant capable de faire
la d´etection en temps r´eel.
R´esultat de la d´etection
Lors de l’analyse des flux engendr´es par les diff´erentes applications, notre
outil a lev´e des alertes pour chacun des ´echantillons de malware et aucune
pour les applications b´enignes. Les tableaux 5.3 et 5.4 r´esument le r´esultat des
exp´eriences men´ees respectivement sur les applications b´enignes provenant de
Google Play et les ´echantillons de malware.
Le premier tableau pr´esente les r´esultats avec les applications b´enignes provenant
de Google Play. La premi`ere colonne liste les diff´erentes cat´egories d’application
utilis´ee durant l’exp´erience. La deuxi`eme indique le nombre d’´echantillons
utilis´es pour chaque cat´egorie. La troisi`eme indique les correspondances entre
les flux observ´es et l’une des profils utilis´es. La derni`ere indique le total des flux
observ´es lors de l’analyse des applications de chaque cat´egorie.
Le deuxi`eme tableau pr´esente les r´esultats obtenus avec les ´echantillons de
malware. La premi`ere colonne liste les ´echantillons. La deuxi`eme indique comment
l’´echantillon a ´et´e cat´egoris´e dans sa collection d’origine. La troisi`eme
indique la collection d’origine de l’´echantillon. La quatri`eme indique le nombre
de flux observ´es par AndroBlare durant l’analyse. Les colonnes restantes indiquent
le nombre de correspondance entre le profil SFG et les flux observ´es.
Plus pr´ecis´ement, les valeurs dans ces colonnes indiquent le nombre d’arc du
profil SFG qui correspondent `a au moins un des flux observ´es durant l’analyse
de l’´echantillon.
L’analyse des flux caus´es par les applications b´enignes montre que notre outil
n’a d´etect´e aucun flux qui correspond `a l’un des arcs des profils utilis´es. Sur les
70 applications b´enignes analys´ees, aucune n’a ´et´e d´etect´ee comme ex´ecutant
du code malveillant, ce qui nous donne un taux de faux positif nul.
Chaque ´echantillon de malware a caus´e la lev´ee d’alerte par notre outil de
d´etection. Plus pr´ecis´ement, chaque ´echantillon a ´et´e d´etect´e avec le profil SFG
correspondant `a la famille d’origine `a laquelle il est suppos´e appartenir. Ainsi,124 CHAPITRE 5. CARACTERISATION ET D ´ ETECTION DE MALWARE ´
Cat´egorie Echantillons ´ Signature Journal
match entries
Jeux 48 0 7386736
Utilitaires 8 0 403427
R´eseaux sociaux 5 0 567605
Photo / Vid´eo 5 0 579883
Magazine 3 0 169622
Table 5.3 – R´esultat de d´etection sur les applications b´enignes provenant de
Google Play. Taux de faux positif : 0%
les ´echantillons de BadNews, DroidKungFu1, DroidKungFu2 et jSMSHider ont
´et´e d´etect´es respectivement grˆace au profil S0, S1, S2 et S3. La majorit´e des
´echantillons a caus´e autant d’alerte que de nombre d’arc que le profil pour lequel
une correspondance a ´et´e trouv´e. L’´echantillon live.photo.drop.apk a
par exemple caus´e 36 flux diff´erents qui correspondent aux 36 arcs du pro-
fil SFG de BadNews. Cependant, quelques ´echantillons n’ont caus´e la lev´ee
d’alerte que pour une partie des arcs du profil SFG de la famille de malware
`a laquelle ils sont associ´es. Cela est dˆu au fait que durant leur analyse,
une partie du comportement attendu ne s’est pas ex´ecut´e. L’´echantillon
41f7b03a94d38bc9b61f8397af95a204 n’a par exemple caus´e que 4 correspondances
sur 11 entre les flux qu’il a engendr´es et les arcs de S1. Le profil S1
d´ecrit l’installation de deux applications, une native et une apk dans la partition
system du t´el´ephone. L’´echantillon n’a cependant install´e que l’application
native durant notre analyse car l’apk cens´e ˆetre install´e est un fichier vide et la
proc´edure d’installation est ainsi avort´ee par le syst`eme.5.5. EVALUATION DE LA CAPACIT ´ E DE D ´ ETECTION ´ 125
Empreinte MD5 des ´echantillons Label: Origin§ Log size S0; S1; S2; S3;
d25008db2e77aae53aa13d82b20d0b6a JSH A 79598 4{4
24663299e69db8bfce2094c15dfd2325 JSH A 179608 4{4
39d140511c18ebf7384a36113d48463d DKF1 A / G 3565 11{11
7f5fd7b139e23bed1de5e134dda3b1ca DKF1 A 5772 11{11
a81dc5210b3444b8e6f002605a97292d DKF1 A 3233 3{11
107af5cf71f1a0e817e36b8deb683ac2 DKF1 A 7257 11{11
ac2a5a483036eab1b363a7f3c2933b51 DKF1 A 3596 5{5
e741a9bc460793b9afdadc963d6e8c1d DKF1 A 3230 3{11
6b7c313e93e3d136611656b8a978f90d DKF1 A 7740 5{5
389b416fb0f505d661716b8da02f92a2 JSH G 179702 4{4
a3c0aacb35c86b4468e85bfb9e226955 JSH G 7527 4{4
0417b7a90bb5144ed0067e38f7a30ae0 JSH G 32145 4{4
d25008db2e77aae53aa13d82b20d0b6a JSH G 122951 4{4
f0fcef1c52631ae36f489351b1ba0238 JSH G 211823 4{4
06dea6a4b6f77167eaf7a42cb9861bbe DKF1 G 72706 6{11
994af7172471a2170867b9aa711efb0d DKF1 G 13959 11{11
107af5cf71f1a0e817e36b8deb683ac2 DKF1 G 187221 11{11
71fe80d5bf6d08890de3c76a3292fc09 DKF1 G 15709 11{11
ecc4aad77ab042a4fa1693fc77afb8ac DKF1 G 107910 11{11
b763bc07f641bb915a4e745f1deff315 DKF1 G 180984 8{11
6625f4a711e5afaee5f349c40ad1c4ab DKF1 G 4982 11{11
5c593a7ab5e61f76d2e0e61c870da986 DKF1 G 99363 11{11
41f7b03a94d38bc9b61f8397af95a204 DKF1 G 13474 4{11
f438ed38b59f772e03eb2cab97fc7685 DKF2 G 34906 5{5
4f6be2d099b215e318181e1d56675d2c DKF2 G 283990 5{5
805bbc6ff9ef376c4b5f2c1b1c1006d2 DKF2 G 49404 5{5
13a491126dd11f1ef51a4b067f10f368 DKF2 G 278425 5{5
72dc94b908b0c6b7e3cb293d9240393c DKF2 G 294163 5{5
e4d348e97db481507a0cea64232c8065 DKF2 G 64616 5{5
47ffc035dd1288bad27b3681535e68c8 BN I 298819 36{36
d8943ed5be382c22c9a206af0815ff0a BN I 363578 36{36
ccab22538dd030a52d43209e25c1f07b BN I 167837 36{36
3a648e6b7b3c5282da76590124a2add4 BN I 332519 36{36
4ecf985980bcc9b238af1fdadd31de48 BN I 125167 36{36
5b08c96794ad5f95f9b42989f5e767b5 BN C 132846 36{36
422d1290422ebfbf48ec34f0990fba21 BN I 634202 35{36
98cfa989d78eb85b86c497ae5ce8ca19 BN C 568920 36{36
e70964e51210f8201d0da3e55da78ca4 BN I 253320 36{36
8b9e8a2e93c3f3c18b8f5820f21e2458 BN I 149248 36{36
: BN : BadNews, DKF1 : DroidKungFu1, DKF2 : DroidKunFu2, JSH : jSMSHider
§ C : Contagio, G : Genome Project, A : Androguard, I : Internet
Table 5.4 – R´esultats de la d´etection sur 39 ´echantillons de malware. Taux de
Vrai Positif : 100%126 CHAPITRE 5. CARACTERISATION ET D ´ ETECTION DE MALWARE ´
Bilan et discussion
Nous avons pr´esent´e et ´evalu´e dans ce chapitre une nouvelle m´ethode de
classification et de d´etection des ´echantillons de malware bas´ee sur les flux d’information
qu’ils causent dans le syst`eme d´ecrits par leur SFG. La m´ethode de
classification propos´ee peut-ˆetre vue comme un apprentissage non supervis´e o`u
nous cherchons `a construire des classes d’´echantillons de malware o`u les SFG des
´el´ements d’une mˆeme classe partagent tous une partie commune. Cette partie
commune est cens´ee d´ecrire l’attaque men´ee par le(s) malware(s) et caract´eriser
les ´echantillons de la classe qu’elle repr´esente en tant que profil comportemental.
Nous avons ´evalu´e la m´ethode propos´ee en classifiant 19 ´echantillons de 4 malwares
diff´erents. La classification de ces ´echantillons a donn´e en sortie 4 classes
distinctes qui repr´esentent chacun un des 4 malwares et la partie commune des
SFG des ´el´ements de chaque classe d´ecrit une partie de l’attaque men´ee par les
mawares.
A partir des profils caract´erisant chaque classe, nous avons propos´e de d´etecter `
des ´echantillons des 4 malawres utilis´es durant la classification. La m´ethode
de d´etection consiste `a comparer les flux observ´es caus´es par les ´echantillons
analys´es avec les arcs des profils comportementaux calcul´es. A chaque fois `
qu’une correspondance est trouv´ee, une alerte est lev´ee. Nous avons ´evalu´e cette
m´ethode avec 36 ´echantillons de malware ainsi que 70 applications b´enignes provenant
de Google Play et avons obtenu un taux de vrai positif de 100% ainsi
qu’un taux de faux positif de 0%. Les ´echantillons de malware ont bien ´et´e
d´etect´e et aucune alerte n’a ´et´e lev´ee dans le cas des applications b´enignes. De
plus, chaque ´echantillon de malware a ´et´e d´etect´e grˆace au profil caract´erisant
la classe associ´ee au malware obtenue durant la classification.
La raison de la qualit´e des r´esultats obtenus aussi bien pour la classification
que pour la d´etection est que le profil calcul´e ne se limite pas aux processus
ex´ecutant les ´echantillons de malware. Il inclut ´egalement tout ´el´ement du
syst`eme ayant acc`es aux informations provenant des ´echantillons de malware.
Mˆeme si un malware change son aspect, le profil calcul´e ne sera que tr`es peu
impact´e car le malware n’a pas de contrˆole ou alors tr`es peu sur tous les autres
´el´ements du syst`eme ayant acc`es `a ses informations au d´ebut de l’attaque. Si le
cas contraire s’av´erait ˆetre vrai, c’est-`a-dire que le malware a un contrˆole total
sur tous les autres ´el´ements du syst`eme, alors il pourrait propager ses informations
de mani`ere diff´erente `a chaque ex´ecution et empˆecher notre algorithme de
calculer un profil ou de d´etecter l’ex´ecution de l’un de ses ´echantillons.
L’approche propos´ee se base sur une analyse dynamique des applications
afin d’observer les flux d’information qu’elles causent dans le syst`eme. Comme
toute approche dynamique, elle souffre ainsi de la mˆeme limitation qui est la
couverture de code durant l’analyse et qui, pour le moment, limite la possibilit´e
d’automatiser enti`erement tout le processus d’analyse et de classification des applications.
En effet, durant l’analyse nous stimulons les applications en interagissant
avec elles via leur interface graphique et introduisons des ´ev`enements dans
le syst`eme afin de d´eclencher le code malveillant dans les ´echantillons de malware.
Cette stimulation est r´ealis´ee manuellement. De plus, il nous a n´ecessit´e5.5. EVALUATION DE LA CAPACIT ´ E DE D ´ ETECTION ´ 127
d’analyser quelques ´echantillons de malware afin de d´eterminer les ´ev`enements
d´eclenchant le code malicieux pr´esents dans leur code. Il serait ainsi int´eressant
pour stimuler les applications et couvrir le maximum de code `a l’ex´ecution.
La m´ethode de caract´erisation de malware Android propos´ee dans ce chapitre
a fait l’objet d’une publication `a la conf´erence NSS 14 [17].128 CHAPITRE 5. CARACTERISATION ET D ´ ETECTION DE MALWARE ´Chapitre 6
Conclusion
Dans cette th`ese nous avons propos´e et ´evalu´e une nouvelle m´ethode afin de
caract´eriser / classifier et d´etecter les malwares Android. Afin d’y arriver, nous
sommes pass´es par plusieurs ´etapes qui ont consist´e `a porter un moniteur de flux
d’information sur Android, proposer une structure compacte et humainement
compr´ehensible des flux d’information que le moniteur observe qui puisse aider
un analyste `a comprendre le comportement d’une application et classifier ainsi
que d´etecter les ´echantillons de malware `a partir de cette structure.
La premi`ere ´etape de la th`ese a consist´e `a cr´eer AndroBlare, une version
Android de Blare. Blare a ´et´e initialement d´evelopp´e pour les syst`emes Linux,
et plus pr´ecis´ement pour les noyaux Linux. Si le syst`eme Android est proche
des syst`emes Linux, le noyau Android ´etant bas´e sur le noyau Linux et suit la
mˆeme num´erotation, il poss`ede cependant quelques fonctionnalit´es qui lui sont
propres et qu’il a fallu prendre en compte lors du portage de Blare vers Android.
Ces fonctionnalit´es sont l’ex´ecution des applications Android et le m´ecanisme de
communication entre processus via le Binder. Nous avons ainsi introduit deux
extensions dans AndroBlare pour prendre en compte ces deux fonctionnalit´es
d’Android. Ces extensions ajoutent la prise en compte des flux d’information
s’op´erant via le Binder et un m´ecanisme de coop´eration entre les instances de la
machine virtuelle Dalvik et KBlare. Ces deux extensions sont importantes car
elles permettent d’observer les flux d’information entre les applications Android
ainsi que l’ex´ecution des applications. Diff´erents m´ecanismes sont utilis´es par
les applications pour communiquer avec le reste des applications sur le syst`eme
et tous ces m´ecanismes reposent sur le Binder. Ces communications n’´etaient
cependant pas visibles avec la version Linux de Blare car Binder est sp´ecifique
`a Android et n’est donc pas pris en compte. La premi`ere extension comble donc
cette limitation de Blare en interceptant les ´emissions et r´eception de transaction
et en effectuant les op´erations de propagation et de contrˆole des flux d’information
correspondantes. Quant aux applications Android, leur ex´ecution est
´egalement invisible avec la version Linux de Blare. Le code de ces applications
´etant livr´e sous forme de dalvik bytecode, elles ne sont pas ex´ecut´ees directement
mais interpr´et´ees par la machine virtuelle Dalvik. La deuxi`eme extension permet
129130 CHAPITRE 6. CONCLUSION
donc, grˆace au m´ecanisme de coop´eration, de combler cette autre limitation de
la version Linux de Blare. Grˆace `a ce m´ecanisme de coop´eration, les instances
de la machine virtuelle Dalvik notifient KBlare dans le noyau `a chaque fois que
le code d’une application est sur le point d’ˆetre interpr´et´e. A la r´eception d’une `
notification, KBlare met `a jour le label du processus ex´ecutant la machine virtuelle
ayant ´emis la notification pour signifier le code qu’il ex´ecute et appliquer
la politique de flux d’information de l’application au processus.
La deuxi`eme ´etape a consist´e `a proposer une structure repr´esentant de
mani`ere plus compacte et plus compr´ehensible les flux d’information observ´es
par Blare que nous avons appell´e graphe de flux syst`eme ou SFG. Pour une information
donn´ee, le SFG d´ecrit comment elle est propag´ee dans tout le syst`eme.
Comme nous l’avons montr´e dans le chapitre 4, cette structure s’av`ere utile
sur trois aspects. Premi`erement, sa repr´esentation est plus compacte et facilite
l’analyse des flux d’information observ´es dans le syst`eme. A chaque fois qu’un `
flux d’information impliquant une donn´ee sensible, comprendre une donn´ee `a laquelle
un identifiant a ´et´e associ´e, est observ´e, Blare ajoute une entr´ee d´ecrivant
ce flux dans un journal. Or comme nous l’avons montr´e dans le chapitre 4, certains
de ces flux sont r´ep´et´es plusieurs fois durant l’analyse de l’application ce
qui au bout de quelques entraˆıne la cr´eation de milliers d’entr´ees dans le journal
de Blare alors qu’en r´ealit´e seule une centaine de flux d’information uniques
ont ´et´e observ´es. Ensuite, le SFG aide `a comprendre le comportement d’une
application. Dans notre cas, nous nous sommes int´eress´es aux applications malveillantes.
L’analyse d’un ´echantillon de DroidKungFu1 a montr´e qu’une partie
de son SFG d´ecrivait l’attaque men´ee par le malware, `a savoir tentative
d’´el´evation de privil`ege et installation de deux applications dans le syst`eme.
La troisi`eme et derni`ere ´etape a consist´e consiste en la classfication et d´etection
de malware. Dans cette ´etape, nous avons propos´e d’utiliser le profil sous
forme de SFG des applications afin d’extraire le profil d’un malware. Dans
l’´etape pr´ec´edente, nous avons montr´e que une partie du SFG de l’´echantillon de
DroidKungFu1 correspondait au comportement malveillant du malware. D’apr`es
les travaux de Zhou et al. dans [113], les d´eveloppeurs de malware ajoutent souvent
leur code malveillant dans plusieurs applications existantes pour infecter les
utilisateurs. Cela signifie donc que le mˆeme code malveillant peut ˆetre retrouv´e
dans les ´echantillons d’un mˆeme malware ou qu’une similarit´e en mati`ere de
comportement peut ˆetre retrouv´e dans le code malveillant de ces ´echantillons.
Partant de ce constat, nous avons ´emis l’hypoth`ese que si une partie du SFG
d’une application malveillante correspond au comportement malveillant et que
si la m´ethode d’infection principale des d´eveloppeurs de malware ´etait d’injecter
leur code malveillant dans des applications existantes alors une partie des SFG
des ´echantillons d’un mˆeme malware devrait ˆetre le mˆeme.
Direction pour des travaux futurs
Le premier apport de la th`ese est AndroBlare, le r´esultat du portage de
Blare sous Android. AndroBlare suit les flux d’information en consid´erant les131
objets du syst`eme comme des boˆıtes noires. Comme nous l’avons ´evoqu´e en
section 2.6, une observation au niveau syst`eme offre une vue compl`ete des flux
entre les diff´erents objets du syst`eme mais a une granularit´e moins fine qu’une
observation au niveau applicatif. Par exemple, dans le cas d’AndroBlare, un
flux d’un objet A vers un objet B signifie que toutes les informations dans A
se propagent vers B (pire des cas). Cela n’est pas forc´ement le cas et il se peut
qu’aucune information sensible ne se soit propag´ee. La granularit´e d’observation
n’est donc pas assez fine. Un axe `a explorer serait ainsi de combiner les niveaux
d’observation syst`eme et applicatif sous Android afin d’affiner la granularit´e des
flux observ´es. L’apport d’une telle est non n´egligeable dans le cas de certains
processus tels que system server car ce processus ex´ecute plusieurs services
avec qui les applications interagissent tous, ce qui est une source de l’explosion
des marques dans la version actuelle d’AndroBlare.
Un autre apport de la th`ese, qui est le principal, est l’usage des SFG en
tant que profil des malware. Pour calculer ce profil, nous calculons les intersections
des SFG des ´echantillons de malware. Cette intersection n’autorise aucune
d´eviation, mˆeme moindre, dans les flux observ´es. Par exemple, les flux
d´ecrivant un processus P1 communiquant avec un processus P2 via un fichier
et les flux d´ecrivant les mˆemes processus P1 et P2 communiquant cette fois
de mani`ere directe sont consid´er´es comme des flux diff´erents. Cependant, dans
la r´ealit´e, ils d´ecrivent la mˆeme action qui est la communication entre deux
processus. Nous parlons dans ce cas de flux similaire. Il serait ainsi int´eressant
d’explorer l’usage de la similarit´e `a la place d’une correspondance stricte entre
les flux d’information observ´es. L’usage de la similarit´e pourrait par exemple
r´ev´eler la ressemblance entre deux ou plusieurs malware. Il pourrait ´egalement
am´eliorer la r´esistance de l’approche face `a des d´eviations de comportement
dans les ´echantillons des malware.
L’approche que nous proposons pour classifier et d´etecter les malware est
une approche dynamique. Nous analysons dans un environnement AndroBlare
les applications afin de capturer les flux d’information qu’ils causent dans le
syst`eme. L’une des limites de cette approche est la couverture de code. Nous
couvrons durant l’ex´ecution qu’une partie de tout le code de l’application que
nous analysons. Dans le cas de l’analyse des ´echantillons de malware, nous avons
par exemple du analys´e statiquement leur code afin de trouver les ´ev`enements
d´eclenchant le code malveillant. Ces ´ev`enements ont ensuite ´et´e introduits durant
l’analyse des ´echantillons avec AndroBlare afin de s’assurer que leur comportement
malveillant soit captur´e. Quant aux applications b´enignes, nous les
avons utilis´e comme un utilisateur normal pendant cinq minutes mais cela ne
garantie pas une couverture optimale du code. Un axe `a explorer serait ainsi
une m´ethode pour couvrir tout le code des applications durant leur analyse
avec AndroBlare afin que tout leur comportement soit captur´e et d’automatiser
tout le processus d’analyse des applications. Cela ouvrirait ´egalement la voie `a
une exp´erimentation `a plus grande ´echelle des m´ethodes de classification et de
d´etection que nous avons propos´e dans cette th`ese.
Il est souvent plus difficile de finir que de commencer.132 CHAPITRE 6. CONCLUSIONAnnexe A
Analyse d’´echantillons de
malware : recherche des
´ev`enements d´eclenchant
leur code malveillant
Lors de la validation exp´erimentale des approches pour la caract´erisation et
la d´etection de malware Android, nous avons utilis´e des ´echantillons de 4 malwares
diff´erents : DroidKungFu1, DroidKungFu2, jSMSHider et BadNews. Le
but des exp´eriences men´ees ´etait de montrer qu’il ´etait possible de caract´eriser
sous forme de SFG le comportement malveillant des malware et d’utiliser ces
SFG pour d´etecter l’ex´ecution d’autres instances des malware que nous supposions
non-connues. Pour capturer et d´etecter ce comportement malveillant, ils
nous a fallu introduire des ´ev`enements dans le syst`eme afin de d´eclencher le code
malveillant. Nous pr´esentons dans ce qui suit l’analyse de quelques ´echantillons
de malware afin de d´eterminer ces ´ev`enements.
A.1 Outils
Pour analyser les ´echantillons de malware, nous utilisons principalement les
outils Androguard et apktool. Nous nous servons principalement d’Androguard
afin de d´ecompiler `a la vol´ee le code des applications Android et d’apktool
pour extraire le contenu des fichiers apk, d´ecoder en clair le contenu des fi-
chiers AndroidManifest.xml ainsi que pour d´esassembler en smali le code des
applications.
133134ANNEXE A. EV´ ENEMENTS D ` ECLENCHEURS DE CODE MALVEILLANT ´
A.2 BadNews
BadNews est un malware Android d´ecouvert en 2013 qui se r´epandait sousforme
d’applications existantes infect´ees par un code malveillant. Le rapport
d’analyse effectu´e dans [91] indique que le comportement de BadNews est dict´e
par un serveur C&C. Lorsqu’un client se connecte, le serveur lui envoie une
commande `a ex´ecuter et attend sa prochaine connexion pour lui indiquer la
prochaine action `a effectuer. Trouver l’´ev`enement d´eclencheur du comportement
malveillant des ´echantillons de BadNews revient ainsi `a trouver l’´ev`enement qui
d´eclenche le connexion vers le serveur puis le traitement de la commande `a
ex´ecuter.
Pour identifier les ´ev`enements d´eclencheurs du code malveillants de BadNews,
nous avons analys´e l’un de ses ´echantillons 1 provenant de la collection
Contagio. L’approche que nous avons adopt´e est de partir des diff´erents points
d’entr´ee de l’application afin d’identifier le code impl´ementant le comportement
de BadNews, puis d´eterminer l’´ev`enement attendu par l’application pour
d´eclencher l’ex´ecution du code. Les composants sont les points d’entr´ee d’une
application Android. A quelques exceptions pr`es, ils doivent tous ˆetre list´es dans `
le fichier AndroidManifest.xml. Le listing A.1 pr´esente le contenu de ce fichier
pour l’´echantillon analys´e. Il indique que l’application poss`ede cinq composants :
deux de type Activity, un Service et deux de type Receiver.
L’analyse du code des deux composants Receiver indique qu’ils ex´ecutent
tous deux la mˆeme action `a la r´eception d’un intent, listing A.2, `a savoir le lancement
du composant AdvService. L’analyse du code de AdvService s’av`ere
fructueuse car parmi les m´ethodes de ce composant se trouve une m´ethode
sendRequest, listing A.3, qui impl´emente le comportement attendu de BadNews
: envoi d’une requˆete vers un serveur distant et ex´ecution de diff´erentes
actions selon la r´eponse re¸cue : installation d’application, ajout de raccourci sur
le t´el´ephone, affichage de notification etc.
Le code ayant ´et´e identifi´e, il reste `a d´eterminer comment il est appel´e et sous
quelles conditions. L’une des fonctionnalit´es d’Androguard est de construire le
graphe d’appel des fonctions d’une application et de l’exporter sous un format de
graphe reconnu par des outils de visualisation et manipulation de graphe tels que
Gephi. Grˆace `a la commande androgexf dans Androguard, nous cr´eons ainsi un
graphe sous le format gexf d´ecrivant les appels de fonction dans l’´echantillon
analys´e et que nous pouvons ouvrir avec Gephi. La figure A.1 est un extrait
du graphe d’appel produit quand nous le visualisons sous Gephi. Chaque nœud
repr´esente une m´ethode dont le label comporte le nom de la classe o`u la m´ethode
est d´eclar´ee, son nom et sa signature. Quant aux arcs, ils repr´esentent les appels
de fonction entre les m´ethodes. Un arc de A vers B signifie que la m´ethode A appelle
la m´ethode B. Ainsi la m´ethode sendRequest est directement appel´ee par
getUpdate. En analysant la premi`ere composante connexe du graphe `a partir du
bas de la figure, nous remarquons que sendRequest est uniquement appel´e durant
l’ex´ecution d’un Thread impl´ement´e par la classe AdvService$1 2
. La com-
1. SHA sum : f1b351d1280422c5d1e3d2b1b04cb96a5d195f62
2. m´ethode runA.2. BADNEWS 135
19
21
26
27
28
29
30
31
34
36
38
39
40
41
42
44
45
46
47
48
49
51
Listing A.1 – Fichier AndroidManifest.xml d’un ´echantillon de BadNews
posante connexe en haut de la figure nous r´ev`ele ´egalement que le thread n’est
instanci´e que lors de l’ex´ecution de la m´ethode onStartCommand de AdvService,
c’est-`a-dire lorsqu’AdvService re¸coit un intent lui demandant de s’ex´ecuter.
L’analyse du code de onStartCommand, listing A.4 nous le confirme et nous
indique mˆeme la condition pour que le thread soit lanc´e. En effet pour qu’il
soit ex´ecut´e, il faut que l’intent re¸cu par AdvService contienne un param`etre
update dont la valeur doit ˆetre diff´erente de 0 3
.
Ainsi pour lancer l’ex´ecution du code malveillant de BadNews, il faut envoyer
un intent avec un param`etre update dont la valeur est `a true au composant
AdvService. Dans le cas de certains ´echantillons, le composant AdvService est
nomm´e diff´eremment. Il suffit dans ce cas d’envoyer l’intent `a ce composant.
La commande am permet l’envoi de l’intent `a partir de la ligne de commande
sous Android comme illustr´e ci-dessous. Il est n´ecessaire de pr´eciser `a la fois le
3. Les bool´eens sont consid´er´es comme des entiers sous Dalvik136ANNEXE A. EV´ ENEMENTS D ` ECLENCHEURS DE CODE MALVEILLANT ´
nom complet de l’application ainsi que celui du composant afin que le syst`eme
puisse d´eterminer le destinataire exact du message.
$ am startservice APP_NAME/PACKAGE_NAME.AdvService \
--ez update 1
1 public void onReceive(android.content.Context p4, android.content.Intent p5) {
2 v0 = new android.content.Intent();
3 v0.setAction("com.mobidisplay.advertsv1.AdvService");
4 v0.putExtra("update", 1);
5 p4.startService(v0);
6 return;
7 }
Listing A.2 – Code appel´e `a la r´eception d’un Intent par les composants de
type Receiver d’un ´echantillon de BadNewsA.2. BADNEWS 137
Figure A.1 – Extrait du graphe d’appel de fonction d’un ´echantillon de BadNews138ANNEXE A. EV´ ENEMENTS D ` ECLENCHEURS DE CODE MALVEILLANT ´
1 private void sendRequest(String p24) {
2 v12 = android.net.Proxy.getDefaultHost();
3 v13 = android.net.Proxy.getDefaultPort();
4 v4 = new java.net.URL(p24);
5 if(v13 <= 0) {
6 v5 = v4.openConnection();
7 } else {
8 v5 = v4.openConnection(new java.net.Proxy(java.net.Proxy$Type.HTTP,
9 new java.net.InetSocketAddress(v12, v13)));
10 }
11 v5.setDoInput(1);
12 v5.setDoOutput(1);
13 v5.setRequestMethod("POST");
14 v5.setConnectTimeout(10000);
15 this.tmett = (System.currentTimeMillis() / 1000.0);
16 v18 = new java.io.DataOutputStream(v5.getOutputStream());
17 v18.writeBytes(new StringBuilder("kurok=").append(this.ii)
18 .append("&taket=").append(this.pacNme).append("&phone=")
19 .append(this.phoNum).append("&vesn=").append(this.vesn)
20 .append("&sysname=").append(this.syNm).append("&operator=")
21 .append(this.opNm).append("&sdk=")
22 .append(android.os.Build$VERSION.SDK).append("&tmett=")
23 .append(this.tmett, 1000.0).append("&model=").append(this.phMl)
24 .append("&lg=").append(this.lg).append("&io=").append(this.io)
25 .append("&qyNm=").append(this.qyNm).append("&devicesid=")
26 .append(android.provider.Settings$Secure.getString(this
27 .getBaseContext().getContentResolver(), "android_id"))
28 .toString());
29 v18.flush(); v18.close(); v5.connect();
30 v6 = v5.getInputStream();
31 if(v6 != 0) {
32 this.increaseQueryNum();
33 v19 = new java.io.InputStreamReader;
34 v19(v6, "UTF-8");
35 v14 = new java.io.BufferedReader(v19);
36 v3 = new StringBuilder();
37 while(true) {
38 v8 = v14.readLine();
39 if(v8 == 0) break;
40 v3.append(v8).append("\x0a");
41 }
42 v16 = new org.json.JSONTokener;
43 v16(v3.toString());
44 v7 = new org.json.JSONObject(v16);
45 v15 = v7.getString("status");
46 if(v15.equalsIgnoreCase("news") != 0) {
47 this.parseNews(v7);
48 }
49 if(v15.equalsIgnoreCase("install") != 0) {
50 this.parseInstall(v7);
51 }
52 ...
Listing A.3 – Extrait du code de la m´ethode sendRequest d’un ´echantillon de
BadNewsA.2. BADNEWS 139
1 public int onStartCommand(android.content.Intent p3, int p4, int p5) {
2 this.log("AdvService Started");
3 if(p3 == 0) {
4 this.startUpdater();
5 } else {
6 if(p3.getExtras() == 0) {
7 this.startUpdater();
8 } else {
9 if(p3.getExtras().getBoolean("update") != 0) {
10 this.startUpdateThread();
11 }
12 }
13 }
14 return 1;
15 }
16
17 private void startUpdateThread() {
18 new Thread(new com.mobidisplay.advertsv1.AdvService$1(this)).start();
19 return;
20 }
Listing A.4 – Code appel´e `a l’ex´ecution du composant AdvService d’un
´echantillon de BadNews140ANNEXE A. EV´ ENEMENTS D ` ECLENCHEURS DE CODE MALVEILLANT ´
A.3 DroidKungFu1
DroidKungFu1 [61] est un malware d´ecouvert en 2011. Certains de ses ´echantillons
n’ex´ecutent pas automatiquement le code malveillant d`es le lancement
de l’application dans laquelle ils se trouvent. Nous avons ainsi analys´e l’un des
´echantillons de ce malware 4 afin de trouver l’´ev`enement d´eclenchant le code
malveillant.
Selon l’analyse qui en a ´et´e r´ealis´ee par X. Jiang dans [61], le code malveillant
du malware est stock´e dans un service qui est ajout´e `a des applications
existantes pour infecter les utilisateurs. Les captures effectu´ees dans le rapport
montrent que le service en question s’appellerait com.google.searchservice
et que l’envoi de donn´ees sensibles vers l’ext´erieur et l’installation de nouvelles
applications se font respectivement grˆace aux fonctions doSearchReport et
cpLegacyRes. L’analyse du fichier AndroidManifest.xml, listing A.5, confirme
qu’un tel service existe dans l’application et une analyse rapide du code de ce
composant indique la pr´esence de ces deux m´ethodes. Il reste ainsi `a d´eterminer
comment ces m´ethodes sont appel´ees.
Comme dans le cas de BadNews, nous construisons le graphe d’appel de
fonction de l’application pour identifier comment ces m´ethodes sont appel´ees.
La figure A.2 est un extrait du graphe d’appel et indique que les deux m´ethodes
sont appel´ees durant la cr´eation du composant SearchService, plus pr´ecis´ement
par la m´ethode onCreate de ce composant. L’analyse du code de cette m´ethode,
listing A.6, indique que l’ex´ecution de l’attaque ne se fait qu’apr`es un laps
de temps. A la cr´eation du composant, l’application r´ecup`ere la valeur du pa- `
ram`etre start dans ses pr´ef´erences et la compare avec le temps du syst`eme. Si
la diff´erence est inf´erieure `a 14400000.0ms alors l’attaque n’est pas lanc´ee et la
valeur de start est initialis´ee au temps du syst`eme. Dans le cas contraire, l’attaque
est lanc´ee. La condition pour que l’attaque soit ex´ecut´ee est ainsi qu’au
moins 14400000.0ms se soit ´ecoul´e depuis le changement de la valeur du param`etre
start. Ce param`etre est stock´e dans le fichier sstimestamp.xml, voir
listing A.7, situ´e dans un sous-r´epertoire du r´epertoire local de l’application. En
modifiant sa valeur, nous pouvons ainsi faire croire `a l’application que plus de
14400000.0ms s’est ´ecoul´e et forcer l’ex´ecution du code malveillant.
4. MD5 : 7f5fd7b139e23bed1de5e134dda3b1caA.3. DROIDKUNGFU1 141
Figure A.2 – Extrait du graphe d’appel de fonction d’un ´echantillon de DroidKungFu142ANNEXE
A. EV´ ENEMENTS D ` ECLENCHEURS DE CODE MALVEILLANT ´
1
2
4
5
6
7
8
9
10
13
14
15
16
17
18
19
20
21
Listing A.5 – Extrait du contenu du fichier AndroidManifest.xml d’un
´echantillon de DroidKungFu1
1 public void onCreate() {
2 super.onCreate();
3 v5 = this.getSharedPreferences("sstimestamp", 0);
4 v3 = v5.getLong("start", 0.0, v8);
5 v0 = System.currentTimeMillis();
6 if(v3 != 0.0) {
7 if((v0 - v3) >= 14400000.0) {
8 this.mPreferences = this.getSharedPreferences("permission", 0);
9 if(com.google.ssearch.Utils.isConnected(this) != 0) {
10 this.doSearchReport();
11 }
12 this.getPermission();
13 this.provideService();
14 } else {
15 this.stopSelf();
16 }
17 } else {
18 v2 = v5.edit();
19 v2.putLong("start", v0, v1);
20 v2.commit();
21 this.stopSelf();
22 }
23 return;
24 }
Listing A.6 – M´ethode onCreate du composant SearchService d’un ´echantillon
de DroidKungFu1A.3. DROIDKUNGFU1 143
1
2
Listing A.7 – Contenu du fichier sstimestamp.xml d’un ´echantillon de DroidKungFu1144ANNEXE
A. EV´ ENEMENTS D ` ECLENCHEURS DE CODE MALVEILLANT ´
A.4 DroidKungFu2
DroidKungFu2 [60] est un malware d´ecouvert en 2011 et consid´er´e comme
ayant ´et´e ´ecrit par le mˆeme groupe de d´eveloppeurs que DroidKungFu1. Le
rapport sur son analyse indique qu’ils ont d’ailleurs un comportement similaire
car ils exploitent tous deux des vuln´erabilit´es dans le syst`eme pour ´elever leur
privil`eges et installer de nouvelles applciations sur le t´el´ephone. La diff´erence
entre les attaques sont les applications qu’ils installent sur le t´el´ephone. En
analysant un des ´echantillons de DroidKungFu2 5
, nous remarquons rapidement
que leur mode d’ex´ecution est le mˆeme. Voir listing A.8. Dans DroidKungFu2, le
code malveillant est ´ex´ecut´e lors de la cr´eation d’un service et sous la condition
qu’un certain temps se soit ´ecoul´e. Nous pouvons aussi d’ailleurs remarquer
que le nom de certaines m´ethodes appel´ees sont exactement les mˆemes (ex :
getPermission).
Il suffit de modifier la valeur du param`etre start dans sstimestamp.xml
pour faire ainsi croire `a l’application que plus de 1800000.0ms se sont ´ecoul´ees
et forcer l’ex´ecution du code malveillant.
1 public void onCreate() {
2 super.onCreate();
3 v5 = this.getSharedPreferences("sstimestamp", 0);
4 v3 = v5.getLong("start", 0.0, v8);
5 v0 = System.currentTimeMillis();
6 if(v3 != 0.0) {
7 if((v0 - v3) >= 1800000.0) {
8 this.mPreferences = this.getSharedPreferences("permission", 0);
9 this.updateInfo();
10 this.getPermission();
11 this.provideService();
12 } else {
13 this.stopSelf();
14 }
15 } else {
16 v2 = v5.edit();
17 v2.putLong("start", v0, v1);
18 v2.commit();
19 this.stopSelf();
20 }
21 return;
22 }
Listing A.8 – M´ethode onCreate d’un composant service d’un ´echantillon de
DroidKungFu2
5. MD5 : f438ed38b59f772e03eb2cab97fc7685A.5. JSMSHIDER 145
A.5 jSMSHider
Les ´echantillons de jSMSHider ex´ecutent tous leur code malveillant d`es le
lancement de l’application. Il n’y a ainsi nul besoin d’introduire manuellement
des ´ev`enements dans le syst`eme.146ANNEXE A. EV´ ENEMENTS D ` ECLENCHEURS DE CODE MALVEILLANT ´Publications
V Viet Triem Tong, R Andriatsimandefitra, S Geller, S Boche, F Tronel, C Hauser.
Mise en œuvre de politiques de protection des flux d’information dans l’environnement
Android. Computer & Electronics Security Applications Rendezvous,
2011. Rennes, France.
Radoniaina Andriatsimandefitra, St´ephane Geller, Val´erie Viet Triem Tong. Designing
information flow policies for android’s operating system. IEEE International
Conference on Communications, 2012 (ICC 2012). Ottawa, Canada
R Andriatsimandefitra, V. Viet Triem Tong, L M´e. Diagnosing intrusions in Android
operating system using system flow graph. Workshop Interdisciplinaire
sur la S´ecurit´e Globale, 2013 (WISG 2013). Troyes, France.
M Jaume, R Andriatsimandefitra, V. Viet Triem Tong, L M´e. Secure States versus
Secure Executions. 9th International Conference on Information Systems
Security, 2013 (ICISS 2013). Kolkata, India.
R Andriatsimandefitra, V Viet Triem Tong, T Saliou. Information Flow Policies
vs Malware. International Conference on Information Assurance and Security,
2013 (IAS 2013). Yassmine Hammamet, Tunisia.
R Andriatsimandefitra and V Viet Triem Tong. Capturing Android Malware
Behaviour using System Flow Graph. The 8th International Conference on Network
and System Security, 2014 (NSS 2014). Xi’an, China
R Andriatsimandefitra, V Viet Triem Tong, T Saliou. Information Flow Policies
vs Malware – Final Battle - . Journal of Information Assurance and Security,
Dynamic Publishers Inc., USA, 2014, 9 (2), pp.72-82.
R Andriatsimandefitra, V Viet Triem Tong. Poster Abstract : Highlighting Easily
How Malicious Applications Corrupt Android Devices. Research in Attacks,
Intrusions and Defenses, 2014 (RAID 2014). Gothenburgh, Sweden.
147148 PUBLICATIONSBibliographie
[1] Android-root 2009-08-16 source. http://www.zenthought.org/
content/file/android-root-2009-08-16-source.
[2] Andrototal. http://andrototal.org.
[3] Bionic (software). http://en.wikipedia.org/wiki/Bionic_
%28software%29.
[4] Cve-2009-2692. http://web.nvd.nist.gov/view/vuln/detail?
vulnId=CVE-2009-2692.
[5] Cve-2013-6282. http://cve.mitre.org/cgi-bin/cvename.cgi?name=
CVE-2013-6282.
[6] dedexer. http://dedexer.sourceforge.net/.
[7] droidbox. android application sandbox. https://code.google.com/p/
android-apktool/.
[8] F1 score. https://en.wikipedia.org/wiki/F-score.
[9] Ida pro. https://www.hex-rays.com/products/ida/.
[10] Java decompiler. http://jd.benow.ca/.
[11] Netlink protocol library suite (libnl). http://www.carisma.slowglass.
com/~tgr/libnl.
[12] Programmation java/r´eflexion. http://fr.wikibooks.org/wiki/
Programmation_Java/R%C3%A9flexion.
[13] smali, an assembler/disassembler for android’s dex format. https://
code.google.com/p/smali/.
[14] Virustotal. https://www.virustotal.com/.
[15] dm-crypt. http://git.kernel.org/cgit/linux/kernel/git/
torvalds/linux.git/tree/Documentation/device-mapper/
dm-crypt.txt, 2014.
[16] Radoniaina Andriatsimandefitra, St´ephane Geller, and Val´erie Viet Triem
Tong. Designing information flow policies for android’s operating system.
In IEEE International Conference on Communications, 2012.
[17] Radoniaina Andriatsimandefitra and Val´erie Viet Triem Tong. Capturing
Android Malware Behaviour using System Flow Graph. In NSS 2014 -
The 8th International Conference on Network and System Security, Xi’an,
China, October 2014.
149150 BIBLIOGRAPHIE
[18] Radoniaina Andriatsimandefitra, Val´erie Viet Triem Tong, and Ludovic
M´e. Diagnosing intrusions in android operating system using system flow
graph. In Workshop Interdisciplinaire sur la S´ecurit´e Globale, 2013.
[19] Radoniaina Andriatsimandefitra, Val´erie Viet Triem Tong, and Thomas
Saliou. Information flow policies vs malware–final battle–. Journal of
Information Assurance and Security, 9(2) :72–82, 2014.
[20] Radoniaina Andriatsimandefitra, Val´erie Viet Viet Triem Tong, and Thomas
Saliou. Information flow policies vs malware. In Information assurance
and security - 2013, 2013.
[21] Andrew W. Appel. Deobfuscation is in np, aug 2002.
[22] Daniel Arp, Michael Spreitzenbarth, Malte H¨ubner, Hugo Gascon, Konrad
Rieck, and CERT Siemens. Drebin : Effective and explainable detection
of android malware in your pocket. In NDSS 2014, 2014.
[23] Arini Balakrishnan and Chloe Schulze. Code obfuscation literature survey.
Technical report, Computer Sciences Department - University of Wisconsin,
Madison, 2005. CS701 Construction of Compilers, Instructor : Charles
Fischer.
[24] Alastair R. Beresford, Andrew Rice, Nicholas Skehin, and Ripduman Sohan.
Mockdroid : trading privacy for application functionality on smartphones.
In Proceedings of the 12th Workshop on Mobile Computing Systems
and Applications, 2011.
[25] Thomas Blasing, Leonid Batyuk, A-D Schmidt, Seyit Ahmet Camtepe,
and Sahin Albayrak. An android application sandbox system for suspicious
software detection. In Malicious and unwanted software (MALWARE),
2010 5th international conference on, pages 55–62. IEEE, 2010.
[26] Ohad Bobrov. Chinese government targets hong kong protesters
with android mrat spyware. https://www.lacoon.com/
chinese-government-targets-hong-kong-protesters-android-mrat-spyware/,
2014.
[27] Dan Boneh and Matt Franklin. Identity-based encryption from the weil
pairing. In Advances in Cryptology—CRYPTO 2001, pages 213–229.
Springer, 2001.
[28] Joany Boutet and Tom Leclerc. Grand theft android : Phishing
with permission. http://sagsblog.telinduslab.lu/index.php/
post/201309%5CS-Team-at-Hacklu-2013%3A-GRAND-THEFT-ANDROID%
3A-PHISHING-WITH-PERMISSION, 2013.
[29] Sven Bugiel, Lucas Davi, Alexandra Dmitrienko, Thomas Fischer, and
Ahmad-Reza Sadeghi. Xmandroid : A new android evolution to mitigate
privilege escalation attacks. Technical report, Technische Universitat
Darmstadt, Center for Advanced Security Research Darmstadt, 2011.
[30] Sven Bugiel, Stephan Heuser, and Ahmad-Reza Sadeghi. mytunes : Semantically
linked and user-centric fine-grained privacy control on android.
Technical report, CASED, 2012.151
[31] C-Skills. Android trickery. http://c-skills.blogspot.fr/2010/07/
android-trickery.html, 2010.
[32] C-skills. Yummy yummy, gingerbreak ! http://c-skills.blogspot.fr/
2011/04/yummy-yummy-gingerbreak.html, 2011.
[33] Victor Chebyshev and Roman Unuchek. Mobile malware evolution : 2013,
02 2014.
[34] Erika Chin, Adrienne Porter Fell, Kate Greenwood, and David Wagner.
Analyzing inter-application communication in android. In MobiSys’11,
2011.
[35] Mihai Christodorescu and Somesh Jha. Static analysis of executables to
detect malicious patterns. In Proceedings of the 12th conference on USENIX
Security Symposium - Volume 12, SSYM’03, pages 12–12, Berkeley,
CA, USA, 2003. USENIX Association.
[36] Fred Chung. Custom class loading in dalvik, July 2011.
[37] CIDRE. Blare ids. www.blare-ids.org.
[38] CIDRE. Git repositories of blare. https://git.blare-ids.org.
[39] Christian Collberg, Clark Thomborson, and Douglas Low. A taxonomy
of obfuscating transformations. Technical report, University of Auckland,
1997.
[40] Jonathan Corbet, Alessandro Rubini, and Greg Kroah-Hartman. Linux
Device Drivers. O’Reilly Media, third edition edition, 2005.
[41] Nello Cristianini and John Shawe-Taylor. An Introduction to Support
Vector Machines : And Other Kernel-based Learning Methods. Cambridge
University Press, New York, NY, USA, 2000.
[42] Anthony Desnos and Geoffroy Gueguen. Android : From reversing to
decompilation. Technical report, Black Hat Abu Dhabi 2011, 2011.
[43] dex2jar team. dex2jar tools to work with android .dex and java .class files.
https://code.google.com/p/dex2jar/.
[44] Thomas Eder, Michael Rodler, Dieter Vymazal, and Markus Zeilinger.
Ananas-a framework for analyzing android applications. In Availability,
Reliability and Security (ARES), 2013 Eighth International Conference
on, pages 711–719. IEEE, 2013.
[45] Petros Efstathopoulos, Maxwell Krohn, Steve VanDeBogart, Cliff Frey,
David Ziegler, Eddie Kohler, David Mazieres, Frans Kaashoek, and Robert
Morris. Labels and event processes in the asbestos operating system. In
ACM SIGOPS Operating Systems Review, 2005.
[46] William Enck, Peter Gilbert, Byung gon Chun, Landon P. Cox, Jaeyeon
Jung, Patrick McDaniel, and Anmol N. Sheth. Taintdroid : An
information-flow tracking system for realtime privacy monitoring on
smartphones. In In Proc. of the USENIX Symposium on Operating Systems
Design and Implementation (OSDI), 2010.152 BIBLIOGRAPHIE
[47] William Enck, Machigar Ongtang, and Patrick Mcdaniel. Mitigating android
software misuse before it happens. Technical report, The Pennsylvania
State University, 2008.
[48] Rong-En Fan, Kai-Wei Chang, Cho-Jui Hsieh, Xiang-Rui Wang, and ChihJen
Lin. Liblinear : A library for large linear classification. The Journal
of Machine Learning Research, 9 :1871–1874, 2008.
[49] Adrienne Porter Felt, Helen J. Wang, Alexander Moshchuk, Steven Hanna,
and Erika Chin. Permission re-delegation : Attacks and defenses. In Proceedings
of the 20th USENIX Conference on Security, SEC’11. USENIX
Association, 2011.
[50] Eric Filiol. Metamorphism, formal grammars and undecidable code mutation.
J. Comp. Sci, pages 70–75, 2007.
[51] Jeff Forristal. Android : One root to own them all, 2013.
[52] Linux Foundation. Generic netlink howto. http://www.
linuxfoundation.org/collaborate/workgroups/networking/
generic_netlink_howto, 2009.
[53] Linux Foundation. iproute2. http://www.linuxfoundation.org/
collaborate/workgroups/networking/iproute2, 2009.
[54] Debin Gao, Michael K. Reiter, and Dawn Song. Gray-box extraction
of execution graphs for anomaly detection. In Proceedings of the 11th
ACM conference on Computer and communications security, pages 318–
329, 2004.
[55] St´ephane Geller. Information flow and execution policy for a model of
detection without false negatives. Network and Information Systems Security
(SAR-SSI), 2011 Conference on, 2011.
[56] St´ephane Geller, Christophe Hauser, Fr´ed´eric Tronel, and Val´erie
Viet Triem Tong. Information flow control for intrusion detection derived
from mac policy. In IEEE International Conference on Communications,
2011.
[57] St´ephane Geller, Val´erie Viet Triem Tong, and Ludovic M´e. Bspl : A
language to specify and compose fine-grained information flow policies. In
SECURWARE 2013, The Seventh International Conference on Emerging
Security Information, Systems and Technologies, 2013.
[58] Kent Griffin, Scott Schneider, Xib Hu, and Tzi cker Chiueh. Automatic
generation of string signatures for malware detection. In Proceedings of the
12th International Symposium on Recent Advances in Intrusion Detection
(RAID 2009), 2009.
[59] Peter Hornyack, Seungyeop Han, Jaeyeon Jung, Stuart Schechter, and
David Wetherall. “these aren’t the droids you’re looking for” : Retrofitting
android to protect data from imperious applications. In CCS’11, 2011.
[60] Xuxian Jiang. Security alert : New droidkungfu variants found in alternative
chinese android markets. http://www.csc.ncsu.edu/faculty/
jiang/DroidKungFu2/.153
[61] Xuxian Jiang. Security alert : New sophisticated android malware droidkungfu
found in alternative chinese app markets. http://www.csc.ncsu.
edu/faculty/jiang/DroidKungFu.html.
[62] Xuxian Jiang. Questionable android apps – sndapps – found and removed
from official android market. http://www.csc.ncsu.edu/faculty/
jiang/SndApps/, 2011.
[63] Kevin Kaichuan He. Kernel korner - why and how to use netlink socket.
http://www.linuxjournal.com/article/7356, 2005.
[64] Ariane Keller. Kernel space - user space interfaces. http://people.ee.
ethz.ch/~arkeller/linux/kernel_user_space_howto.html.
[65] Michael Kerris. The linux programming interfaces - posix message
queues. http://man7.org/tlpi/download/TLPI-52-POSIX_Message_
Queues.pdf.
[66] Samuel T. King and Peter M. Chen. Backtracking intrusions. In Proceedings
of the nineteenth ACM symposium on Operating systems principles,
pages 223–236, Bolton Landing, NY, October 2003. ACM Press.
[67] Christopher Kruegel, Engin Kirda, Paolo Milani Comparetti, Ulrich
Bayer, and Clemens Hlauschek. Scalable, behavior-based malware clustering.
In Proceedings of the 16th Annual Network and Distributed System
Security Symposium (NDSS 2009), 1 2009.
[68] Mohit Kumar. Dynamic analysis tools for android fail to detect malware
with heuristic evasion techniques. http://thehackernews.com/2014/05/
dynamic-analysis-tools-for-android-fail.html, 2014.
[69] International Secure Systems Lab. Anubis - malware analysis for unknown
binaries. http://anubis.iseclab.org/.
[70] Cullen Linn and Saumya Debray. Obfuscation of executable code to improve
resistance to static disassembly. In CCS ’03 : Proceedings of the
10th ACM conference on Computer and communications security, pages
290–299, New York, NY, USA, 2003. ACM.
[71] Radmon Llamas, Melissa Chau, and Michael Shirer. Worldwide smartphone
market grows 28.6% year over year in the first quarter of
2014, according to idc. http://www.idc.com/getdoc.jsp?containerId=
prUS24823414, 2014.
[72] Lisa Mahapatra. Android vs. ios : What’s the most popular mobile
operating system in your country ? http://www.ibtimes.com/
android-vs-ios-whats-most-popular-mobile-operating-system-your-country-1464892,
2013.
[73] Andrew C. Myers and Barabara Liskov. Complete, safe information flow
with decentralized labels. In IEEE Symposium on Security and Privacy,
1998.
[74] Andrew C. Myers and Barbara Liskov. A decentralized model for information
flow control. SIGOPS Oper. Syst. Rev., 31(5) :129–142, 1997.154 BIBLIOGRAPHIE
[75] Andrew C. Myers and Barbara Liskov. Protecting privacy using the decentralized
label model. ACM Trans. Softw. Eng. Methodol., 9(4) :410–442,
2000.
[76] Pablo Neira-Ayuso, Rafael M Gasca, and Laurent Lefevre. Communicating
between the kernel and user-space in linux using netlink sockets.
Software : Practice and Experience, 40, 2010.
[77] Sebastian Neuner, Victor van der Veen, Martina Lindorfer, Markus Huber,
Georg Merzdovnik, Martin Mulazzani, and Edgar Weippl. Enter sandbox :
Android sandbox comparison. Proceedings of the IEEE.
[78] Jon Oberheide and Charlie Miller. Dissecting the android bouncer, 2012.
Summercon.
[79] Machigar Ongtang, Stephen McLaughlin, William Enck, and Patrick McDaniel.
Semantically rich application-centric security in android. In Annual
Computer Security Applications Conference, volume 0, pages 340–
349, Los Alamitos, CA, USA, 2009. IEEE Computer Society.
[80] Xinming Ou, Wayne F Boyer, and Miles A McQueen. A scalable approach
to attack graph generation. In Proceedings of the 13th ACM conference
on Computer and communications security, pages 336–345. ACM, 2006.
[81] PalmSource. Openbinder. http://www.angryredplanet.com/~hackbod/
openbinder/docs/html/index.html.
[82] Mila Parkour. Contagio mobile. contagiominidump.blogspot.com.
[83] Android Open Source Project. Device administration. https://
developer.android.com/guide/topics/admin/device-admin.html.
[84] Android Open Source Project. Intent. http://developer.android.com/
reference/android/content/Intent.html#setFlags%28int%29.
[85] Android Open Source Project. Introducing art. http://source.android.
com/devices/tech/dalvik/art.html.
[86] Android Open Source Project. Jni tips. http://developer.android.
com/training/articles/perf-jni.html.
[87] Android Open Source Project. Pro guard. http://developer.android.
com/tools/help/proguard.html.
[88] Alessandro Reina, Aristide Fattori, and Lorenzo Cavallaro. A system callcentric
analysis and stimulation technique to automatically reconstruct
android malware behaviors. EuroSec, April, 2013.
[89] Konrad Rieck, Thorsten Holz, Carsten Willems, Patrick D¨ussel, and Pavel
Laskov. Learning and classification of malware behavior. In Proceedings
of the 5th international conference on Detection of Intrusions and Malware,
and Vulnerability Assessment, DIMVA ’08, pages 108–125, Berlin,
Heidelberg, 2008. Springer-Verlag.
[90] Konrad Rieck, Philipp Trinius, Carsten Willems, and Thorsten Holz. Automatic
analysis of malware behavior using machine learning. J. Comput.
Secur., December 2011.155
[91] Marc Rogers. The bearer of badnews. https://blog.lookout.com/
blog/2013/04/19/the-bearer-of-badnews-malware-google-play/,
2013.
[92] Sebastian. Droid2. http://c-skills.blogspot.fr/2010/08/droid2.
html, 2010.
[93] Sebastian. Zimperlich sources. http://c-skills.blogspot.fr/2011/
02/zimperlich-sources.html, 2011.
[94] Michael Spreitzenbarth, Felix Freiling, Florian Echtler, Thomas Schreck,
and Johannes Hoffmann. Mobile-sandbox : having a deeper look into
android applications. In Proceedings of the 28th Annual ACM Symposium
on Applied Computing, pages 1808–1815. ACM, 2013.
[95] Tim Starzzere. Security alert : Legacy makes another appearance, meet
legacy native (lena). https://blog.lookout.com/blog/2011/10/20/,
2011.
[96] Tim Strazzere. June 15, 2011 security alert : Malware found targeting
custom roms (jsmshider). https://blog.lookout.com/
blog/2011/06/15/security-alert-malware-found-targeting\
discretionary{-}{}{}custom-roms-jsmshider/.
[97] Androguard team. Reverse engineering, malware and goodware analysis of
android applications ... and more (ninja !). https://code.google.com/
p/androguard/.
[98] Roman Unuchek. The most sophisticated android trojan. https:
//www.securelist.com/en/blog/8106/The_most_sophisticated_
Android_Trojan, June 2013.
[99] Marko Vitas. Art vs dalvik - introducing the new android runtime
in kitkat. http://www.infinum.co/the-capsized-eight/articles/
art-vs-dalvik-introducing-the-new-android-runtime-in-kit-kat.
[100] Lukas Weichselbaum, Matthias Neugschwandtner, Martina Lindorfer, Yanick
Fratantonio, Victor van der Veen, and Christian Platzer. Andrubis :
Android malware under the magnifying glass. Technical report, Vienna
University of Technology, 2014.
[101] Carsten Willems, Thorsten Holz, and Felix Freiling. Toward automated
dynamic malware analysis using cwsandbox. IEEE Security and Privacy,
5(2) :32–39, mar 2007.
[102] Chris Wright, Crispin Cowan, and James Morris. Linux security modules :
General security support for the linux kernel, 2002.
[103] Chris Wright, Crispin Cowan, Stephen Smalley, James Morris, and Greg
Kroah-Hartman. Linux security module framework. In OLS2002 Proceedings,
2002.
[104] Tim Wyatt. Security alert : New variants of legacy native
(lena) identified. http://blog.lookout.com/blog/2012/04/03/
security-alert-new-variants-of-legacy-native-lena-identified/,
2013.156 BIBLIOGRAPHIE
[105] Rubin Xu, Hassen Saidi, and Ross Anderson. Aurasium : Practical policy
enforcement for android applications. In USENIX Security ’12, 2012.
[106] Lok-Kwong Yan and Heng Yin. Droidscope seamlessly reconstructing
os and dalvik semantic views for dynamic android malware analysis. In
Proceedings of the 21st USENIX Security Symposium, August 2012.
[107] Jay Yarow. This chart shows google’s incredible domination of
the world’s computing platforms. http://www.businessinsider.com/
androids-share-of-the-computing-market-2014-3, 2014.
[108] Heng Yin, Dawn Song, Manuel Egele, Christopher Kruegel, and Engin
Kirda. Panorama : capturing system-wide information flow for malware
detection and analysis. In CCS ’07 : Proceedings of the 14th ACM conference
on Computer and communications security, pages 116–127, New
York, NY, USA, 2007. ACM.
[109] Nickolai Zeldovich, Silas Boyd-Wickizer, Eddie Kohler, and David
Mazi`eres. Making information flow explicit in histar. In OSDI ’06 : Proceedings
of the 7th symposium on Operating systems design and implementation,
pages 263–278, Berkeley, CA, USA, 2006. USENIX Association.
[110] Nickolai Zeldovich, Silas Boyd-Wickizer, and David Mazi`eres. Securing
distributed systems with information flow control. In NSDI’08 : Proceedings
of the 5th USENIX Symposium on Networked Systems Design and
Implementation, pages 293–308. USENIX Association, 2008.
[111] Cong Zheng, Shixiong Zhu, Shuaifu Dai, Guofei Gu, Xiaorui Gong, Xinhui
Han, and Wei Zou. Smartdroid : an automatic system for revealing uibased
trigger conditions in android applications. In Proceedings of the
second ACM workshop on Security and privacy in smartphones and mobile
devices, pages 93–104. ACM, 2012.
[112] Yajin Zhou and Xuxian Jiang. An analysis of the anserverbot trojan.
Technical report, NQ Mobile Security Research Center, 2011.
[113] Yajin Zhou and Xuxian Jiang. Dissecting android malware : Characterization
and evolution. In Proceedings of the 2012 IEEE Symposium on
Security and Privacy, SP ’12, pages 95–109, Washington, DC, USA, 2012.
IEEE Computer Society.
Interaction entre alg`ebre lin´eaire et analyse en
formalisation des math´ematiques
Guillaume Cano
To cite this version:
Guillaume Cano. Interaction entre alg`ebre lin´eaire et analyse en formalisation des
math´ematiques. Other. Universit´e Nice Sophia Antipolis, 2014. French. .
HAL Id: tel-00986283
https://tel.archives-ouvertes.fr/tel-00986283
Submitted on 2 May 2014
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of scientific
research documents, whether they are published
or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est
destin´ee au d´epˆot et `a la diffusion de documents
scientifiques de niveau recherche, publi´es ou non,
´emanant des ´etablissements d’enseignement et de
recherche fran¸cais ou ´etrangers, des laboratoires
publics ou priv´es.UNIVERSITÉ DE NICE - SOPHIA ANTIPOLIS
ÉCOLE DOCTORALE STIC
SCIENCES ET TECHNOLOGIES DE L’INFORMATION ET DE LA
COMMUNICATION
THÈSE
pour l’obtention du grade de
Docteur en Sciences
de l’Université de Nice - Sophia Antipolis
Mention : Informatique
Présentée et soutenue par
Guillaume CANO
Interaction entre algèbre linéaire
et analyse en formalisation des
mathématiques
Thèse dirigée par Yves BERTOT
soutenue le 4 avril 2014
Jury :
Micaela MAYERO - Maître de conférence, LIPN (Rapporteur)
Julio RUBIO - Professeur, Université de la Rioja (Rapporteur)
Yves BERTOT - Directeur de recherche, INRIA (Directeur)
Stephen Watt - Professeur, Université Ontario Ouest (Examinateur)
Christine PAULIN-MOHRING - Professeur, Université Paris Sud (Examinateur)
Douglas HOWE - Professeur, Université Carlton (Examinateur)Abstract
In this thesis we present the formalization of three principal results
that are the Jordan normal form of a matrices, the Bolzano-Weierstraß
theorem, and the Perron-Frobenius theorem.
To formalize the Jordan normal form, we introduce many concepts
of linear algebra like block diagonal matrices, companion matrices,
invariant factors, ...
The formalization of Bolzano-Weierstraß theorem needs to develop
some theory about topological space and metric space.
The Perron-Frobenius theorem is not completly formalized. The proof
of this theorem uses both algebraic and topological results. We will
show how we reuse the previous results.
Résumé
Dans cette thèse nous présentons la formalisation de trois résultats
principaux que sont la forme normale de Jordan d’une matrice, le
théorème de Bolzano-Weierstraß et le théorème de Perron-Frobenius.
Pour la formalisation de la forme normale de Jordan nous introduisons
différents concepts d’algèbre linéaire tel que les matrices diagonales
par blocs, les matrices compagnes, les facteurs invariants, ...
Ensuite nous définissons et développons une théorie sur les espaces topologiques
et métriques pour la formalisation du théorème de BolzanoWeierstraß.
La formalisation du théorème de Perron-Frobenius n’est pas terminé.
La preuve de ce théorème utilise des résultat d’algèbre linéaire, mais
aussi de topologie. Nous montrerons comment les précédents résultats
seront réutilisés.Remerciements
Je voudrais dans un premier temps remercier Micaela Mayero et Julio
Rubio pour avoir acceptés d’endurer l’épreuve d’être les rapporteurs
de cette thèse.
Je remercie mon directeur de thèse Yves Bertot pour m’avoir permis
de faire cette thèse, mais aussi pour les moments patisserie.
Je tiens à remercier aussi toute l’équipe Marelle pour son soutient.
Je remercie Nathalie Bellesso qui est une secrétaire merveilleuse, qui
m’a aidée dans mes tâches administratives et qui en plus écrit de bons
livres. Je remercie José Grimm pour ces conseils TEXniques, Laurent
Théry pour son soutient, ses conseils et ses casse-têtes. Et surtout
un grand merci à Laurence Rideau qui a passé beaucoup de temps à
m’apprendre SSReflect, à relire mes écrits, à corriger mes fautes
réccurentes, qui a aussi eu la patience de me supporter, et aussi qui
m’a encouragé, grondé et motivé tout au long de ma thèse. Je remercie
également ceux qui ont passés du temps à la relecture de ma thèse, et
que j’ai déjà cités.
Merci également à Ioana Paşca qi m’a beaucoup appris, en particulier
une chose absolument fondamentale : le chocolat, au bureau, c’est
important ! Merci à Tom Hutchinson dont j’ai apprécié la compagnie
et les conversations. Merci aussi à Cyril Cohen, Maxime Dénès, Érik
Martin-Dorel, Anders Mörtberg. Merci à ceux que j’ai oubliés.
Je remercie aussi ma famille pour son soutient à toute épreuve.
Et je voudrais rendre hommage à Pierre Damphousse, sans qui je
n’aurais jamais fait cette thèse.Table des matières
Introduction 1
1 Preuve formelle . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
2 Assistants de preuve . . . . . . . . . . . . . . . . . . . . . . . . . 2
3 Brève présentation de Coq . . . . . . . . . . . . . . . . . . . . . . 3
3.1 Les Types . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
4 Motivations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
4.1 Motivations générales . . . . . . . . . . . . . . . . . . . . . 5
4.2 Motivations de la thèse . . . . . . . . . . . . . . . . . . . . 6
5 Contributions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
1 Contexte 9
1.1 Les types de base . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
1.1.1 Le type produit . . . . . . . . . . . . . . . . . . . . . . . . 10
1.1.2 Les types propositionnels . . . . . . . . . . . . . . . . . . . 10
1.1.3 Le type booléen . . . . . . . . . . . . . . . . . . . . . . . . 10
1.1.4 Les entiers naturels . . . . . . . . . . . . . . . . . . . . . . 11
1.1.5 Les séquences . . . . . . . . . . . . . . . . . . . . . . . . . 11
1.2 La bibliothèque SSReflect . . . . . . . . . . . . . . . . . . . . . 12
1.2.1 La réflexion . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1.2.2 Le système de vue . . . . . . . . . . . . . . . . . . . . . . 14
1.2.3 Les types avec une égalité décidable . . . . . . . . . . . . . 15
1.2.4 Les types finis . . . . . . . . . . . . . . . . . . . . . . . . . 16
1.2.5 Les opérateurs de familles . . . . . . . . . . . . . . . . . . 16
1.2.6 Les structures algébriques . . . . . . . . . . . . . . . . . . 18
1.2.7 Les polynômes . . . . . . . . . . . . . . . . . . . . . . . . 20
1.2.8 Les matrices . . . . . . . . . . . . . . . . . . . . . . . . . . 21
1.2.9 Matrices et polynômes . . . . . . . . . . . . . . . . . . . . 22
1.2.10 Les structures ordonnées . . . . . . . . . . . . . . . . . . . 23
1.2.11 Les nombres complexes . . . . . . . . . . . . . . . . . . . . 24
1.3 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
2 Forme de Jordan d’une matrice 25
2.1 Matrices diagonales par blocs . . . . . . . . . . . . . . . . . . . . 25
2.1.1 Définition idéale . . . . . . . . . . . . . . . . . . . . . . . . 26vi Table des matières
2.1.2 Problèmes en dimension nulle . . . . . . . . . . . . . . . . 29
2.1.3 Définition finale . . . . . . . . . . . . . . . . . . . . . . . . 29
2.2 Matrices semblables et équivalentes . . . . . . . . . . . . . . . . . 31
2.2.1 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
2.2.2 Théorème fondamental . . . . . . . . . . . . . . . . . . . . 32
2.3 Forme normale de Smith . . . . . . . . . . . . . . . . . . . . . . . 33
2.3.1 Spécification . . . . . . . . . . . . . . . . . . . . . . . . . . 34
2.3.2 Unicité . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
2.3.3 Facteurs invariants . . . . . . . . . . . . . . . . . . . . . . 39
2.4 Forme normale de Frobenius . . . . . . . . . . . . . . . . . . . . . 40
2.4.1 Matrices compagnes . . . . . . . . . . . . . . . . . . . . . 40
2.4.2 De Smith à Frobenius . . . . . . . . . . . . . . . . . . . . 42
2.5 Forme normale de Jordan . . . . . . . . . . . . . . . . . . . . . . 44
2.5.1 Définitions . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
2.5.2 De Frobenius à Jordan . . . . . . . . . . . . . . . . . . . . 45
2.5.3 Diagonalisation . . . . . . . . . . . . . . . . . . . . . . . . 48
2.6 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
2.7 Travaux reliés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3 Topologie 51
3.1 Théorie des ensembles . . . . . . . . . . . . . . . . . . . . . . . . 51
3.1.1 Réécriture . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
3.1.2 Les familles d’ensembles . . . . . . . . . . . . . . . . . . . 53
3.2 Structures Topologiques . . . . . . . . . . . . . . . . . . . . . . . 55
3.2.1 Définition . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.2.2 Approche naïve . . . . . . . . . . . . . . . . . . . . . . . . 57
3.2.3 Approche SSReflect . . . . . . . . . . . . . . . . . . . . 59
3.3 Bolzano-Weierstraß . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.3.1 Topologie générale . . . . . . . . . . . . . . . . . . . . . . 62
3.3.2 Les suites . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.3.3 Le théorème . . . . . . . . . . . . . . . . . . . . . . . . . . 63
3.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
3.5 Travaux reliés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
4 Perron-Frobenius 69
4.1 Rappels et définitions . . . . . . . . . . . . . . . . . . . . . . . . . 70
4.1.1 Minimum et maximum . . . . . . . . . . . . . . . . . . . . 70
4.1.2 Éléments d’algèbre linéaire . . . . . . . . . . . . . . . . . . 71
4.2 Matrices strictement positives . . . . . . . . . . . . . . . . . . . . 73
4.2.1 Preuve du théorème principal . . . . . . . . . . . . . . . . 73
4.2.2 Instance des structures topologiques . . . . . . . . . . . . . 75
4.2.3 Preuve de l’axiome . . . . . . . . . . . . . . . . . . . . . . 77
4.3 Matrices à coefficients positifs ou nuls . . . . . . . . . . . . . . . . 80
4.3.1 La preuve . . . . . . . . . . . . . . . . . . . . . . . . . . . 81Table des matières vii
4.3.2 Convergence des rayons spectraux . . . . . . . . . . . . . . 81
4.3.3 Compacité de la boule unité . . . . . . . . . . . . . . . . . 83
4.4 Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
4.5 Travaux reliés . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Conclusion 85
Bibliographie 87Introduction
1 Preuve formelle
Formaliser un théorème, c’est difficile à définir formellement. Dans le mot “formelle”
on a le mot “forme”. Une preuve formelle, serait donc une preuve qui
manipule seulement des formes, des symboles, en faisant abstraction du sens que
peuvent avoir ces symboles.
Le mieux serait d’essayer de comprendre sur un exemple. Essayons de formaliser
le résultat suivant : “Si nous avons un ensemble, avec une loi associative
sur cet ensemble qui possède un élément neutre, et si un élément de l’ensemble
possède un inverse à droite et un inverse à gauche, alors l’inverse à droite et
l’inverse à gauche sont égaux”.
Nous commencons d’abord par mettre en forme l’énoncé, c’est-à-dire l’exprimer
à l’aide de symboles. Nous pouvons utiliser la lettre “E” pour désigner
l’ensemble, le symbole “∗” pour la loi, et “e” pour son élément neutre. Nous pouvons
formaliser le fait que la loi est associative et que e et un élément neutre par
les hypothèses suivantes :
hA : ∀xyz ∈ E,(x ∗ y) ∗ z = x ∗ (y ∗ z).
n1 : ∀x ∈ E, x ∗ e = x.
n2 : ∀x ∈ E, e ∗ x = x.
Ensuite nous pouvons utiliser par exemple la lettre “a” pour désigner un élé-
ment de E qui a un inverse à gauche et à droite que nous appellerons a1 et a2.
Formellement, nous avons les deux hypothèses suivantes :
ha1 : a ∗ a1 = e
ha2 : a2 ∗ a = e
et donc nous voulons prouver que a1 = a2.
Nous avons pour l’instant décrit formellement les hypothèses de l’énoncé, ainsi
que le but que nous voulons prouver. Nous pouvons maintenant prouver formellement
que a1 = a2 en utilisant uniquement les hypothèses que nous avons
formalisées.2 Introduction
Nous avons donc a1 = e ∗ a1 = (a2 ∗ a) ∗ a1 = a2 ∗ (a ∗ a1) = a2 ∗ e = a2, en
utilisant respectivement les hypothèses n2, ha2, hA, ha1, n1. Pour vérifier cette
preuve, nous n’avons pas besoin de connaitre le sens des symboles. La première
hypothèse utilisée est l’hypothèse n2. Si on regarde cette hypothèse, on s’aperçoit
qu’il y a un signe “=” qui indique que la forme qu’il y a d’un coté de ce signe est
équivalente à la forme qu’il y a de l’autre coté du signe, ainsi dans une expression
nous pouvons remplacer l’une par l’autre. Donc l’hypothèse n2 dit que le dessin
“a1” a la même forme que le dessin “e ∗ a1”. On n’a pas besoin de savoir à quoi
correspond ∗ ou e, on a seulement besoin de savoir que l’on peut remplacer une
expression par une autre, et donc on peut vérifier la preuve juste en comparant
des dessins1
. C’est ce qu’on appelle une preuve formelle.
Cette abstraction du sens des symboles que l’on manipule fait qu’une preuve
formelle est généralement plus longue et détaillée qu’une preuve normale. En
effet, dans une preuve mathématique, certaines choses sont considérées comme
évidentes. Mais si l’on exprime ces choses à l’aide de symboles, et que l’on oublie
le sens de ces symboles, alors en gros la seule trivialité qui reste est x = x.
D’un autre côté, le fait de pouvoir faire des preuves en manipulant des symboles
sans se préoccuper du sens fait que certaines choses peuvent se faire de
manière automatique, et donc être faites par une machine.
2 Assistants de preuve
Un assistant de preuve est un logiciel permettant de faire des preuves formelles.
Il en existe de deux sortes :
• Les assistants de preuve automatiques : ce sont des logiciels qui prouvent
automatiquement les théorèmes. L’exemple utilisé ci-dessus serait très rapidement
prouvé par un prouveur automatique. Pour prouver les théorèmes,
le logiciel regarde parmi la liste des théorèmes qu’il a à sa disposition, lesquels
il peut appliquer. Il essaye ensuite les lemmes qu’il peut appliquer.
Pour chaque théorème appliqué, les conditions du théorème deviennent de
nouveaux buts à prouver, il génère ainsi une sorte d’arbre de preuve. Si une
branche de cet arbre termine, alors il annonce que le théorème est valide,
sinon nous n’avons aucune information sur la validité du résultat que nous
voulions prouver. Si l’on donne un théorème à un prouveur automatique,
il répondra soit “c’est vrai” soit “je ne sais pas”, mais il n’indiquera pas
comment il a prouvé le théorème. On peut cependant demander une trace
de ce qu’il a fait, mais c’est rarement exploitable, on se sert géneralement
de la trace pour voir quels théorèmes intermédiaires manquent à l’assistant
de preuve pour valider la preuve.
1Enfin pas tout à fait. Dans cet exemple, il faut au moins connaître les symboles ∀, ∈, et
=. Pour avoir une preuve formelle complète, il aurait fallu donner aussi les règles d’utilisation
de ces symboles.3 Brève présentation de Coq 3
Ceci est une présentation assez grossière des assistants de preuve automatiques,
on pourra trouver dans [6] ou dans [24] plus de détails sur les mécanismes
utilisés. Les principaux prouveurs automatiques1
sont ACL2 [28, 29],
Alt-Ergo [5], E-prover [44], Gappa [31], Z3 [11], ...
• Les assistants de preuve semi-automatiques : contrairement aux assistants
de preuve automatiques, les preuves sont faites par un utilisateur humain.
L’utilisateur dit quel théorème il veut utiliser, et la machine indique si oui ou
non le théorème peut être appliqué ou pas. Donc ici l’humain fait la preuve,
et la machine la vérifie. Parmi les principaux assistants de preuve semiautomatique,
on trouve HOL [35], HOL-Light [25], Isabelle [50], Coq [13],
Mizar [33], Matita [1], PVS [45], Nuprl [10] ...
Dans cette thèse nous utiliserons l’assistant de preuve Coq.
3 Brève présentation de Coq
Le logiciel Coq est un assistant de preuve semi-automatique qui permet de faire
des preuves, mais aussi des programmes (et des preuves sur ces programmes !). La
construction de preuves se fait à l’aide d’un langage de tactiques. Une tactique
c’est ce qui permet de dire au système quel règle logique utiliser pour construire
les preuves.
La formalisation des théorèmes en Coq se fait de manière interactive avec
la machine. En général nous avons un environnement de preuve qui se présente
comme suit :
H
===================
B
où H est la partie où sont nos hypothèses, et B est la partie où il y a le(s)
but(s) que nous voulons prouver. Supposons par exemple que nous ayons l’environnement
de preuve suivant :
...
Hn0 : n = 0
H : m = n -> P
===================
P
Nous pouvons écrire dans le script de preuve que l’on veut appliquer l’hypothèse
H en écrivant :
apply: H.
Nous pouvons ensuite exécuter la commande que l’on vient d’écrire pour voir
comment notre environnement de preuve évolue. Ici il y a deux possibilités, soit
1On peut trouver une liste plus complète dans http://why3.lri.fr/.4 Introduction
le système Coq ne peut pas appliquer l’hypothèse et dans ce cas il renvoie un
message d’erreur, soit comme c’est le cas ici, le système Coq peut appliquer
l’hypothèse et dans ce cas il va alors demander de prouver les conditions de
l’hypothèse. Nous aurons donc le nouvel environnement de preuve suivant :
...
Hn0 : n = 0
===================
m = n
Là, nous savons que n = 0, nous pouvons donc remplacer n par 0 dans notre
but. Pour cela, nous pouvons écrire dans le script de preuve la ligne suivante :
rewrite Hn0.
Après l’exécution de cette ligne, nous aurons l’environnement de preuve suivant
:
...
Hn0 : n = 0
===================
m = 0
Dans cet exemple, apply et rewrite sont ce qu’on appelle des tactiques. Au
départ nous voulions prouver la proposition P, et en utilisant les deux tactiques cidessus,
nous nous somme ramenés à prouver m = 0. C’est en utilisant les tactiques
et nos hypothèses que nous allons construire progressivement la preuve formelle.
Le langage que nous utiliserons pour la formalisation des théorèmes s’appelle
SSReflect [20]. C’est une extension de Coq créée par Georges Gonthier pour
prouver le théorème des quatre couleurs [18]. Le langage de tactique est défini différemment
mais le noyau qui vérifie les preuves reste le même. Cette bibliothèque
possède déjà les outils de base pour faire de l’algèbre linéaire.
3.1 Les Types
Coq est un langage fortement typé. Un type définit un ensemble d’objets de
même nature. Par exemple dans Coq tous les entiers naturels sont de type nat,
on écrit :
3 : nat
et ça se lit “trois est de type nat”.
Le type Prop est le type des propositions, par exemple :
(forall n : nat, n + 0 = n) : Prop
Maintenant dire que le type de H est la proposition forall n : nat, n + 0 = n,
c’est dire que H est une preuve de cette proposition. Si on reprend l’exemple
ci-dessus, on a dans nos hypothèses la ligne suivante :
Hn0 : n = 04 Motivations 5
Cela signifie que parmi nos hypothèses on a une preuve (ici appelé Hn0) que n = 0.
Toutes les preuves d’une proposition ont le même type.
Le type d’une fonction est indiqué par une flèche. Le type nat -> nat, par
exemple, est le type d’une fonction qui prend en argument un entier et qui retourne
comme résultat un entier. On utilise la même flèche pour l’implication. En
effet, si P et Q sont des propositions, P -> Q est le type d’une fonction qui prend
en argument une preuve de P et qui retourne comme résultat une preuve de Q,
c’est bien une preuve de P implique Q.
Cette correspondance entre les types et les preuves s’appelle la correspondance
de Curry-Howard. Elle fait le lien entre une preuve d’une proposition P, et le type
d’un terme de λ-calcul. Donc vérifier une preuve revient à vérifier le type d’un
λ-terme. Et la vérification de type est quelque chose qui peut se faire de manière
automatique par un ordinateur. Coq est un assistant de preuve qui utilise cette
correspondance.
Coq permet également de travailler avec des types dépendants. Un type dé-
pendant est un type qui dépend de un ou plusieurs paramètres. Par exemple, le
type d’une matrice est un type qui dépend du nombre de lignes et de colonnes de
la matrice.
4 Motivations
4.1 Motivations générales
Il y a deux principales raisons pour lesquelles on voudrait faire des preuves
formelles. La première est pour vérifier des programmes. Par exemple, les programmes
utilisés dans les métros automatiques qui n’ont pas de conducteur, ou
les programmes utilisés dans des avions, etc. C’est le genre de programmes dont
on voudrait être sûr qu’ils ne feront pas d’erreurs.
La seconde, est que certaines preuves mathématiques nécessitent de longs
calculs par ordinateur. C’est le cas par exemple du théorème des quatre couleurs
ou dernièrement de la conjecture de Kepler qui est en train d’être formalisée
avec l’assistant de preuve HOL Light [21, 22]. Donc prouver formellement que les
calculs faits par l’ordinateur sont corrects permet d’avoir une meilleure certitude
sur ces preuves.
Il y a aussi le fait que les preuves mathématiques deviennent plus difficiles. Il
existe des théorèmes dont la preuve n’est compréhensible que seulement par une
poignée de mathématiciens. Ce sont des théorème difficiles à vérifier et prouver
formellement ces théorèmes permettrait de pouvoir vérifier ces preuves de manières
automatiques. C’est le cas par exemple du théorème de Feit-Thompson [19]
dont la preuve fait plusieurs centaines de pages et qui a été formalisé avec l’assistant
de preuve Coq.6 Introduction
4.2 Motivations de la thèse
Les démonstrations de certains théorèmes mathématiques parfois font intervenir
des résultats de différentes branches des mathématiques. C’est le cas par exemple
du théorème de Perron-Frobenius qui parle des propriétés du rayon spectral des
matrices à coefficients positifs.
La preuve de ce théorème utilise des résultats d’algèbre linéaire, comme la
réduction de Jordan d’une matrice, mais aussi des résultats d’analyse comme
le théorème de Bolzano-Weierstraß en topologie générale, ou des résultats de
convergence sur les matrices.
Le but de cette thèse a été d’essayer de fournir des outils d’algèbre linéaire et
d’analyse assez généraux pour qu’ils puissent être réutilisés.
Nous présenterons dans cette thèse d’abord les travaux sur la forme normale de
Jordan, ensuite ceux sur la topologie générale. Ces deux parties ont été formalisées
indépendamment l’une de l’autre. Nous verrons une réutilisation de ces résultats
dans le dernier chapitre avec le théorème de Perron-Frobenius.
Ce qui a amené en premier lieu à s’intéresser au théorème de Perron-Frobenius
est un problème de robotique qui a demandé à étudier des matrices dont les
coefficients sont des intervalles [32]. Le fait que l’on ait besoin du théorème de
Perron-Frobenius a été mis en évidence par Ioana Paşca en étudiant la régularité
de ces matrices [42].
5 Contributions
La preuve du théorème de Perron-Frobenius qui a été formalisée en partie dans
cette thèse utilise deux résultats fondamentaux en mathématiques qui sont le
théorème de Bolzano-Weierstraß en topologie générale et la forme normale de
Jordan d’une matrice en algèbre linéaire.
Jusqu’à présent les notions de topologie telles que la continuité de fonction,
ou la convergence de suite, par exemple, sont formalisées dans un cadre restreint,
c’est-à-dire la plupart du temps celui des nombres réels. Pour la formalisation du
théorème de Perron-Frobenius, nous avons besoin d’utiliser des propriétés de topologie
sur des matrices. C’est pourquoi cette thèse propose une formalisation de
résultats de topologie générale qui pourront être utilisés pour n’importe quel type,
du moment que l’on aura instancié une topologie sur ce type. Un des résultats
important de cette formalisation est le théorème de Bolzano-Weierstraß.
La formalisation de la forme normale de Jordan a, entre autre, apporté une
formalisation des matrices diagonales par blocs, d’une théorie sur les matrice
semblables et équivalentes, de la théorie des facteurs invariants, des matrices
compagnes, en formalisant au passage la forme normale de Frobenius. En collaboration
avec Maxime Dénès, nous avons pu, en utilisant les outils fournis par les
bibliothèques CoqEAL1
et SSReflect, faire une formalisation complète (sans
1http://www.maximedenes.fr/content/coqeal-coq-effective-algebra-library5 Contributions 7
axiomes) de ces résultats.
Pour la preuve du théorème de Perron-Frobenius, nous avons formalisé des
théorèmes généraux sur la convergence des suites sur des structures ordonnées
et archimédiennes, mais aussi sur la convergence des suites de matrices. En particulier
nous établissons formellement quelles sont les conditions nécessaires et
suffisantes pour que la suite des puissances d’une matrice converge vers zéro.
Nous donnons également une définition formelle du rayon spectral d’une matrice.
Pour résumer, les contributions originales de cette thèse sont :
• Une théorie générale sur la topologie.
– dont le théorème de Bolzano-Weierstraß.
• Les matrices diagonales par blocs.
• Une théorie des facteurs invariants.
• Les matrices compagnes.
• Les formes normales de Frobenius et de Jordan d’une matrice.
• Des théorèmes généraux sur la convergence des suites
– sur les structures ordonnées.
– sur les structures archimédiennes.
– sur les matrices.
• Une définition du rayon spectral d’une matrice.
• Une preuve partielle du théorème de Perron-Frobenius.Chapitre 1
Contexte
L’outil utilisé pour la formalisation de tous les résultats présentés dans cette
thèse est l’assistant de preuve Coq avec la bibliothèque SSReflect. La bibliothèque
SSReflect contient déjà des théories assez développées sur les principaux
concepts que nous utiliserons tels que les polynômes ou les matrices par
exemple. Nous présenterons donc ici comment les principaux outils que nous utiliserons
par la suite sont formalisés dans la bibliothèque SSReflect, afin de
familiariser le lecteur avec les notations et les énoncés formels qu’il rencontrera.
1.1 Les types de base
Les notions abordées dans cette section sont expliquées plus en détail dans [3].
La plupart des types en Coq sont des types inductifs. Les types inductifs sont
en général définis comme suit :
Inductive TI := C1 : e1 | C2 : e2 | ... | Ck : ek.
Ici les ei sont des expressions dans lesquelles le type TI peut apparaître. Les Ci
sont les constructeurs du type TI. C’est ce qui permet de construire des éléments
de type TI. Tous les éléments de type TI sont forcément construits à partir des
constructeurs.
Nous pouvons définir des fonctions du type inductif TI vers un type T en
faisant un traitement par cas sur toutes les formes possibles de l’élément de type
TI passé en argument de la fonction :
Definition f (x : TI) : T :=
match x with
|C1 ... => E1
|C2 ... => E2
...
|Ck ... => Ek
end.10 Contexte
où les points de suspensions horizontaux sont de possibles arguments des constructeurs
du type TI. L’expression f (Ci ...) est convertible avec l’expression Ei,
c’est-à-dire que l’expression f (Ci ...) se réduit en Ei par des règles de calculs.
On peut considérer deux expressions convertibles comme étant identiques.
Nous allons voir dans la suite les types inductifs de base dans Coq.
1.1.1 Le type produit
Le type produit de deux types A et B est défini comme suit :
Inductive prod (A B : Type) :=
pair : A -> B -> prod A B.
Ce type correspond au produit cartésien de A et de B. La notation définie dans la
bibliothèque standard de Coq pour prod A B est A * B, et celle pour pair x y
est (x,y). Donc si nous avons x : A et y : B alors nous avons (x,y) : A * B.
Si nous avons un élément p : A * B alors on peut définir les projections qui
permettent de récupérer le premier et le second élément de la paire p :
Definition fst (A B : Type) (p : A * B) :=
match p with
(x,y) => x
end.
La fonction snd qui renvoie le second élément de p est définie de la même manière.
Dans la bibliothèque SSReflect, la notation p.1 désigne fst p et p.2 désigne
snd p. Donc (x,y).1 = x et (x,y).2 = y.
1.1.2 Les types propositionnels
Soit A et B deux propositions, alors les propositions « A et B » et « A ou B »
sont exprimées formellement à l’aide de types inductifs. Elles sont notées respectivement
A /\ B et A \/ B.
Pour la conjonction de plusieurs propositions par exemple, on peut rencontrer
dans la bibliothèque SSReflect, la notation suivante :
[/\ A , B & C]
Pour la disjonction le /\ est remplacé par \/ et le & par |. On peut utiliser
cette notation jusqu’à cinq propositions pour la conjonction, et quatre pour la
disjonction.
1.1.3 Le type booléen
Les booléens sont définis simplement dans Coq de la manière suivante :
Inductive bool := true : bool | false : bool.
Les opérateurs booléens « et » et « ou » sont notés respectivement a && b et
a || b pour deux booléens a et b quelconques.1.1 Les types de base 11
1.1.4 Les entiers naturels
Les entiers naturels sont définis selon la construction de Peano :
Inductive nat :=
O : nat
| S : nat -> nat.
Le constructeur S correspond à la fonction successeur. Dans la bibliothèque
SSReflect, S n est noté n.+1, n.+2 est une notation pour S n.+1, cela va jusqu’à
n.+4.
La fonction prédécesseur d’un entier est définie dans la bibliohèque standard
de Coq :
Definition pred n := match n with 0 => 0 | S n’ => n’ end.
La bibliothèque SSReflect fourni pour pred n une notation similaire à la pré-
cedente qui est n.-1, de même nous avons aussi la notation n.-2.
1.1.5 Les séquences
Une séquence permet d’énumérer un nombre fini d’éléments de même type. On
utilise plus couramment le mot « liste », d’ailleurs dans la bibliothèque standard
de Coq ce type s’appelle list. Pour certaines raisons historiques dans la
bibliothèque SSReflect on utilise la notation seq pour list, donc bien que la
définition des séquences soit définie dans la bibliothèque standard de Coq, je vais
la présenter ici avec la notation SSReflect car c’est celle que nous utiliserons
par la suite :
Inductive seq (T : Type) :=
nil : seq T
| cons : T -> seq T -> seq T.
Les notations et les quelques définitions que nous allons voir maintenant sont
celles de la bibliothèque SSReflect.
Le constructeur nil, noté [::], correspond à la séquence vide. Le constructeur
cons permet d’ajouter un élément en tête d’une séquence. Par exemple si s est la
séquence qui contient (dans cet ordre) les éléments 2 et 3 alors cons 1 s est la
séquence qui contient (dans cet ordre) les éléments 1, 2 et 3. On note cons a s
par a :: s, par exemple la séquence ci-dessus est notée 1 :: (2 :: (3 :: nil)).
Une autre façon de noter cette séquence est la suivante [:: 1 ; 2 ; 3 ].
Voici plusieurs fonctions élémentaires sur les séquences :
• La fonction size retourne le nombre d’éléments d’une séquence.
• La fonction nth permet de retourner le n-ième élément d’une séquence.
Cette fonction prend un élément par défaut comme argument. Par exemple
nth x0 s i retourne x0 si la séquence s est vide ou si l’entier i est plus
grand que size s et retourne le i-ème élément de la séquence sinon. Si le12 Contexte
type des éléments d’une séquence s a une structure de groupe additif avec
comme élément neutre 0, alors la notation s‘_i désigne nth 0 s i.
• la fonction last retourne le dernier élément d’une séquence. Par exemple,
last x0 s retourne le dernier élément de la séquence s et x0 si la séquence
s est vide.
• La fonction cat permet de concaténer deux séquences. cat s1 s2 se note
s1 ++ s2.
• La fonction map permet à partir d’une séquence s et d’une fonction f d’obtenir
une nouvelle séquence en appliquant f à chaque élément de s. Par
exemple map f [:: 1 ; 2 ; 3] est la séquence [:: f 1 ; f 2 ; f 3]. La
notation [seq f x | x <- s] est une notation dite par compréhension pour
map f s. On peut lire cette notation comme « La séquence des f x tels que
x appartient à s »(le signe <- symbolise ∈).
• La fonction filter permet à partir d’un prédicat booléen P et d’une sé-
quence s d’obtenir une séquence qui ne contient que les éléments de la
séquence s qui vérifient le prédicat P. La notation par compréhension de
filter P s est [seq x <- s | P x].
1.2 La bibliothèque SSReflect
Dans cette section, nous allons expliquer dans un premier temps quelques mécanismes
utilisés dans la bibliothèque SSReflect. Nous présenterons ensuite les
principaux outils de SSReflect utilisés pour la formalisation.
1.2.1 La réflexion
La réflexion est une manière d’utiliser le calcul pour prouver un résultat. Imaginez
un miroir. D’un côté du miroir il y a le monde des propositions, et de l’autre
côté il y a le monde des booléens. Si certaines propositions (pas toutes) se regardent
dans le miroir, elle pourront voir une expression booléenne qui reflète
leur comportement. C’est-à-dire que l’expression booléenne aura la valeur true
si la proposition est vraie et la valeur false sinon. Prouver une proposition P
par réflexion, c’est passer de l’autre côté du miroir, pour calculer la valeur de
l’expression booléenne et ainsi en déduire la valeur de vérité de la proposition.
Dans la bibliothèque SSReflect, les lemmes qui permettent de passer d’un
côté ou de l’autre du miroir sont appelés des lemmes de réflexion. Ces lemmes
s’expriment à l’aide du type inductif suivant :
Inductive reflect (P : Prop) : bool -> Set :=
ReflectT (_ : P) : reflect P true
| ReflectF (_ : ~P) : reflect P false.1.2 La bibliothèque SSReflect 13
Le type reflect a deux constructeurs de type légèrement différent. Le premier
constructeur prend une preuve de la proposition P en argument (cette preuve
n’étant pas utilisée dans le type du constructeur, il est inutile de lui donner un
nom, d’où le _:), et son type est reflect P true. Alors que le deuxième constructeur
prend en argument une preuve de ~P et a comme type reflect P false. Nous
avons donc une correspondance entre une preuve de P avec la valeur true, et une
preuve de ~P avec la valeur false.
Si H est de type reflect P b alors nous avons deux cas. Soit H = ReflectT H’,
et dans ce cas nous avons d’une part b = true (car le type de ReflectT H’ est
reflect P true), et d’autre part la proposition P est vraie (car H’ est une preuve
de P). Soit H = ReflectF H’ et alors dans ce cas b = false et H’ est une preuve
de ~P. Ainsi H : reflect P b exprime bien le fait qu’il y a une réflexion entre la
valeur de b et la proposition P.
Un lemme de réflexion sur la proposition P permet de faire un raisonnement
classique sur cette proposition. Si nous avons l’environnement de preuve suivant :
...
H : reflect P b.
==========================
G(b)
alors nous pouvons faire un traitement par cas sur l’hypothèse H :
case: H.
Cette tactique va essayer de déstructurer l’hypothèse H. Comme le type de H
est inductif et possède deux constructeurs, cela va générer deux sous-buts (un
pour chaque constructeur). Chacun des constructeurs ayant besoin d’un argument,
chaque sous-but va être quantifié sur ces arguments ; dans le premier cas
l’argument est une preuve de P, et dans le deuxième cas c’est une preuve de ~P.
Nous allons donc avoir les deux sous-buts suivants :
subgoal 1 :
...
==============================
P -> G(true)
subgoal 2 is :
~P -> G(false)
Mis à part le remplacement du booléen b par sa valeur dans chacun des cas,
nous obtenons le même résultat que si l’on avait utilisé la tactique case: HP, où
HP est une hypothèse de type P \/ ~P.
Avec des lemmes de réflexion il est possible de passer facilement du monde
des propositions au monde booléen (et vice versa) grâce au mécanisme de « vue »
que nous allons présenter dans la section suivante.14 Contexte
1.2.2 Le système de vue
Dans la bibliothèque SSReflect, il existe un mécanisme de « vue ». Il est nommé
ainsi car il permet de faire, dans un certain sens, des changements de point de
vue.
Pour utiliser le système de vue on utilise la syntaxe suivante :
tactic/H.
où tactic peut être une tactique quelconque1
, et H une hypothèse ayant une des
trois formes suivantes :
1. P -> Q
2. P <-> Q
3. reflect P b
où P, Q sont des propositions et b un booléen.
Dans chaque cas, il y a deux exemples d’utilisation des vues. Regardons
d’abord les cas 1) et 2) :
• Le premier exemple d’utilisation est quand le but que l’on veut prouver est
Q. Alors dans ce cas là la tactique apply/H transforme le but en P.
• Le deuxième exemple d’utilisation est quand le but que l’on veut prouver
est de la forme P -> G alors la tactique move/H transforme le but en Q -> G.
La différence entre le cas 1) et le cas 2) est que dans le cas 2) les rôles des
propositions P et Q peuvent être inversés.
Nous allons expliquer maintenant le cas 3). Dans la bibliothèque SSReflect,
il y a une coercition du type des booléens vers le type des propositions :
Coercion is_true (b : bool) := b = true.
Cette coercition permet d’utiliser les booléens comme des propositions. Donc dans
le cas où H est de la forme reflect P b, le système de vues se comporte comme
si l’on avait H : P <-> b (i.e P <-> b = true).
Expliquons le principe sur un exemple. Imaginons que l’on veuille prouver
qu’un booléen b soit égal à true, et que l’on ait une hypothèse H : reflect P b.
Nous avons donc l’environnement de preuve suivant :
...
H : reflect P b
=======================
b
Si l’on exécute la tactique apply/H nous obtiendrons :
1Enfin presque, disons plutôt à quelque exceptions près. Par exemple on ne peut pas utiliser
de vue avec la tactique rewrite.1.2 La bibliothèque SSReflect 15
...
H : reflect P b
=======================
P
Pour voir ce qui s’est passé, nous pouvons exécuter la commande Show Proof, le
système affichera un terme de preuve dans lequel on verra apparaître :
. . . [eta introTF H] . . .
Donc lorsque nous avons voulu appliquer une vue avec l’hypothèse H, le système
a fait appel à un lemme appelé introTF. Le lemme introTF est défini dans
la bibliothèque SSReflect comme suit :
Lemma introTF (P : Prop) (b c : bool) : reflect P b ->
(if c then P else ~P) -> b = c.
Le but que l’on veut démontrer est b = true, donc si nous appliquons le lemme
introTF il va être instancié avec c = true, et le système va nous demander de
prouver if true then P else ~P ( c’est-à-dire P) et reflect P b, mais cette dernière
hypothèse est donnée par H. Donc finalement le nouveau but sera transformé
en P.
Le théorème introTF a été ajouté dans une base de données, que nous appelerons
la base des lemmes de vues, à l’aide de la commande Hint View. Donc lorsque
nous avons exécuté la tactique apply/H, le système a cherché s’il y a un lemme
dans la base des lemmes de vues qui pourrait être utilisé avec l’hypothèse H. Dans
notre cas il a trouvé le lemme introTF, s’il n’avait pas trouvé de lemme qu’il
aurait pu utiliser, il aurait essayé d’appliquer directement l’hypothèse H (c’est ce
qu’il fait dans le cas où H : P -> Q par exemple).
1.2.3 Les types avec une égalité décidable
L’égalité utilisée dans le système Coq est l’égalité de Leibniz. Prouver l’égalité
entre deux éléments n’est pas toujours décidable. La théorie développée dans la
bibliothèque SSReflect distingue le cadre où l’on peut décider de l’égalité.
La structure d’égalité décidable est l’une des premières structures de base
définies dans la bibliothèque SSReflect. On peut décider de l’égalité de deux
éléments de type T si on a un algorithme qui prend en argument ces deux éléments
et qui retourne le booléen true si ces éléments sont égaux, et le booléen false
sinon. La structure est donc définie ainsi1
:
Structure eqType := EqMixin {
sort : Type ;
eq_op : sort -> sort -> bool ;
_ : forall x y, reflect (x = y) (eq_op x y)
}
1Enfin presque, pour des raisons de clarté j’ai donné une définition plus simple.16 Contexte
La notation utilisée pour eq_op x y est (x == y). L’expression (x == y) repré-
sente donc une égalité booléenne. Bien sûr, l’algorithme caché derrière la notation
== dépend du type de x et de y, s’ils sont de type nat, alors le == représente l’algorithme
qui teste l’égalité de deux éléments de type nat, mais s’ils sont de type
bool, alors le == représente le test d’égalité de deux booléens. Le sytème Coq
retrouve les bonnes instances de la notation grâce à un système de structures canoniques.
Cependant dans certains cas on peut demander au système de choisir
une interprétation particulière du signe == avec la notation (x == y :> T), ici on
demande au système de voir les éléments x et y comme des éléments de type T
1
,
et donc l’algorithme de comparaison utilisé sera celui instancié sur le type T.
1.2.4 Les types finis
Les types finis sont définis dans la bibliothèque SSReflect comme les types dont
tous les éléments peuvent être énumérés dans une séquence. Ils sont définis dans
une structure appelée finType. Ici nous allons présenter dans un premier temps
le type fini appelé ordinal, car nous l’utiliserons couramment dans la suite. Nous
verrons ensuite quelques notations à propos des fonctions sur un type fini.
Les ordinaux
Si n est un entier, alors le type ordinal n contient tous les entiers strictement
plus petit que n. Il est défini dans la bibliothèque SSReflect comme suit :
Inductive ordinal (n : nat) := Ordinal m (_ : m < n).
Le type ordinal n est noté ’I_n. Ainsi, un élément x de type ’I_n est un
entier muni d’une preuve qu’il est plus petit que n. Il y a donc une coercition
naturelle du type ’I_n dans le type nat, cette coercition s’appelle nat_of_ord.
Les fonctions sur les types finis
Si nous avons une fonction f de type aT -> rT avec aT : finType et rT un type
quelconque, alors cette fonction a un nombre fini d’images, donc l’image de f peut
être représentée par une séquence. La théorie de ces fonctions est développée dans
le fichier finfun.v de la bibliothèque SSReflect. Le type de ces fonctions est
noté {ffun aT -> rT}. Pour définir une fonction qui a ce type, on peut utiliser la
notation [ffun x => expr] où expr est le corps de la fonction.
1.2.5 Les opérateurs de familles
Les opérateurs de familles sont les opérateurs que l’on utilise dans des expressions
comme :
1
Il faut donc soit que le type de x et de y soit convertible au type T, soit qu’il existe une
coercition du type de x et de y vers le type T.1.2 La bibliothèque SSReflect 17
X
p
i=n
xi
Y
i∈S
ai
[
i∈S
Ai
Le fichier bigop.v de la bibliothèque SSReflect contient des définitions et
des lemmes qui permettent d’exprimer formellement, et de manipuler ce genre
d’expression. C’est ce que nous allons présenter brièvement ici.
Supposons que nous avons un opérateur op avec la notation suivante :
Variables (T : Type) (op : T -> T -> T).
Notation "x * y" := (op x y).
Les opérateurs de familles sont un moyen d’exprimer de manière concise une
expression comme :
x1 * x2 * ... * xk
Autrement dit, on s’en sert pour appliquer, dans un certain sens, un opérateur
à une famille d’éléments en itérant plusieurs fois l’opération. Il existe une fonction
foldr définie dans la bibliothèque SSReflect, qui permet de faire cela sur les
éléments d’une séquence.
La fonction foldr est définie comme suit :
Fixpoint foldr f x0 s := if s is x :: s’ then f x (foldr s’ f) else x0.
Donc dans notre exemple, nous aurons :
• foldr op x0 [::] = x0
• foldr op x0 [:: x1] = x1 * x0
Et de manière plus générale :
• foldr op x0 [:: x1, x2, ..., xk] = x1 * (x2 * . . . * xk * x0)
L’argument x0 de la fonction foldr est l’élément par défaut retourné quand la
fonction est appelé sur la séquence vide. C’est pour cela que ci-dessus l’argument
x0 apparaît à la fin de chaque expression. Donc pour que la fonction foldr ait
le comportement attendu, il suffit que x0 soit un élément neutre à droite pour
l’opérateur op.
Dans ce qui est fait dans le fichier bigop.v, la fonction foldr n’est pas utilisée
directement sur la séquence [:: x1, ..., xk] mais sur la séquence des indices (i.e
la séquence [:: 1, 2, ... k] ; et donc au lieu d’utiliser directement la fonction op
comme premier argument, on applique d’abord la fonction fun (i : nat) => xi
avant de faire appel à l’opérateur op.
Tout ce mécanisme est caché principalement derrière la notation suivante :
\big[op/id]_(i <- s) F i
où op est l’opérateur qui est itéré, id est (en général) l’élément neutre pour
l’opérateur op, s la séquence des indices, et F i l’expression des termes auquels
on applique l’opérateur op.
Par exemple, si addn est l’addition sur les entiers, et U_ est une fonction sur
les entiers alors :18 Contexte
\big[addn/0]_(i <- [:: 2 ; 5 ; 7]) U_ i = U_ 2 + U_ 5 + U_ 7.
Il existe plusieurs variantes de cette notation qui sont présentées dans le tableau
suivant :
Contexte Notation générale
Exemple avec
l’opérateur
somme
i) \big[op/id]_(m <= i < n) F i
nX−1
i=m
Fi
ii) \big[op/id]_(i < n) F i
X
i seq R;
_ : last 1 polyseq != 0}.
Le symbole :> permet de déclarer polyseq comme une coercition du type des
polynômes vers le type des séquences. La séquence vide représentant le polynôme
nul doit vérifier la définition ci-dessus. Or lorsque la fonction last est appliquée
à la séquence vide, elle retourne un élément par défaut. Cet élément par défaut
doit être différent de 0, et le seul autre élément de l’anneau R dont on connait
l’existence est 1. Donc pour que cette définition de polynôme soit valide, il faut
que 1 != 0. C’est principalement pour cette raison que l’axiome 1 != 0 a été
rajouté comme axiome dans la structure ringType.
Nous allons voir d’abord quelques généralités sur les polynômes, ensuite nous
parlerons de la divisibilité sur les polynômes.
Généralité
Le type des polynômes est noté {poly R}, ainsi si p : {poly R} alors p est un
polynôme à coefficients dans l’anneau R.
Voici un tableau qui résume les principales notations sur les polynômes :
Notation SSReflect Description
c%:P Le polynôme constant c (avec c : R)
’X Le polynôme X (où X est l’indéterminée)
lead_coef p Le coefficient dominant du polynôme p
p \is monic Le polynôme p est unitaire
p.[a] La valeur du polynôme p évalué en a (i.e p(a))
Il n’y a pas vraiment de définition pour le degré d’un polynôme. On parle
plutôt de la taille de la séquence des coefficients. Comme il existe une coercition
des polynômes vers les séquences, on peut directement écrire size p. Donc pour
un polynôme p non nul, (size p).-1 est égal au degré de p.1.2 La bibliothèque SSReflect 21
Divisibilité et racines
Les notations liés à la divisibilité et aux racines d’un polynôme sont présentées
dans le tableau suivant :
Notation SSReflect Description
p %/ q p divisé par q
p %% q p modulo q
p %| q p divise q
p %= q p %| q et q %| p
gcdp p q pgcd(p, q)
root p x x est une racine de p
\mu_x p multiplicité de x dans p
La relation %= est une relation d’équivalence. Si p %= q alors cela veut dire
que l’on peut passer de l’un à l’autre en multipliant par un scalaire inversible. En
mode mathématique, nous noterons cette relation p ∼ q.
1.2.8 Les matrices
Dans la bibliothèque SSReflect, les matrices sont définies comme suit :
Inductive matrix := Matrix (_ : {ffun ’I_m * ’I_n -> R}).
Ce type inductif a un constructeur Matrix qui prend en argument une fonction
dont toutes les valeurs correspondent aux coefficients de la matrice. Cette fonction
peut être récupérée par la fonction mx_val définie comme suit :
Definition mx_val m n (A : matrix m n) :=
match A with Matrix g => g end.
On peut ainsi définir la coercition suivante :
Definition fun_of_matrix m n A (i : ’I_m) (j : ’I_n) := mx_val A (i,j).
Coercion fun_of_matrix : matrix -> Funclass.
Cette coercition permet de voir les matrices comme des fonctions. Ainsi, si
nous avons une matrice A, alors on peut écrire A i j le coefficient de la ligne i et de
la colonne j de A. Le type des matrices est noté de manière générale ’M[R]_(m,n)
où R est le type des coefficients de la matrice et m et n ses dimensions. Si il n’y a
pas d’ambiguïté sur le type des coefficients, alors on peut écrire ’M_(m,n). Dans
le cas des matrices carrées on notera ’M[R]_n ou ’M_n.
Si l’on connait l’expression générale des coefficients d’une matrice, alors on
peut la définir avec la notation suivante :
\matrix_(i < m , j < n) E i j22 Contexte
où E est l’expression générale des coefficients. Le type de la matrice ainsi définie
est ’M_(m,n). Dans le cas des matrices carrées, pour la taille de la matrice, on
peut juste préciser (i, j < n) ; et si il n’y a pas d’ambiguïté sur la taille de la
matrice alors on précisera simplement (i,j).
Par exemple la matrice définie comme suit :
\matrix_(i, j < 3) 2 *+ (i == j) + (i.+1 == j)
correspond à la matrice :
2 1 0
0 2 1
0 0 2
Comme il y a une coercition du type bool vers le type nat, l’expression
(i == j) sera interprétée comme 0 ou 1, et elle ne vaudra 1 que dans le cas
où i et j sont égaux ; c’est la raison pour laquelle les 2 apparaissent sur la diagonale.
En fait (i == j) est une façon d’écrire δij , le symbole de Kronecker, et
a *+ (i == j) est une façon d’écrire a.δij .
Ici nous avons montré l’exemple d’une matrice carrée où i et j ont le même
type. Mais dans le cas d’une matrice rectangulaire, i et j ont des types différents,
et donc l’expression (i == j) est mal typée. Par exemple, si nous avions écrit :
\matrix_(i < 2, j < 3) 2 *+ (i == j) + (i.+1 == j)
Nous aurions i : ’I_2 et j : ’I_3. Pour que la définition soit correcte il faut
préciser au système Coq que l’on veut que la comparaison entre i et j se fasse
sur les entiers. La définition correcte est donc :
\matrix_(i < 2, j < 3) 2 *+ (i == j :> nat) + (i.+1 == j)
Pour finir voici les notations usuelles sur les matrices :
Notation SSReflect Description
A i j Le coefficient Aij de la matrice A
a%:M La matrice qui ne contient que des a sur la diagonale
(par exemple 1%:M est la matrice identité)
A *m B A ∗ B
\det A Le déterminant de A
A \in unitmx A est inversible
1.2.9 Matrices et polynômes
Dans cette thèse nous serons amenés à évoquer les notions de polynôme caractéristique
d’une matrice et de polynôme minimal. Ces notions sont formalisées
dans la bibliothèque SSReflect dans le fichier mxpoly.v.
Soit A un anneau, p ∈ A[X] et A ∈ Mn(A). Alors p(A) est la matrice qui
correspond à l’évaluation du polynôme p en la matrice A. Par exemple, si nous1.2 La bibliothèque SSReflect 23
avons p = 2X2 − 3X + 4 alors p(A) = 2A2 − 3A + 4I. Si p est tel que p(A) = 0
alors on dit que p est un polynôme annulateur de la matrice A.
La matrice XI − A est la matrice caractéristique de A. Le déterminant de
cette matrice est un polynôme appelé polynôme caractéristique de la matrice A.
Ce polynôme est un polynôme annulateur de la matrice.
Le polynôme unitaire et annulateur de la matrice A de plus petit degré est
appelé polynôme minimal de la matrice A. Une propriété caractéristique du polynôme
minimal est que c’est un polynôme annulateur qui divise tout les autres
polynômes annulateurs de la matrice.
Le tableau ci-dessous donne le nom des fonctions définies dans la bibliothèque
SSReflect qui correspondent à ce que l’on a décrit ci-dessus :
Notation SSReflect Description
horner_mx A p p(A)
char_poly_mx A XI − A
char_poly A polynôme caractéristique de A
mxminpoly A polynôme minimal de A
1.2.10 Les structures ordonnées
Les structures telles que les corps réels clos, ou les corps archimédiens sont dé-
finis dans le fichier ssrnum.v de la bibliothèque SSReflect. La structure ordonnée
la plus générale est basée sur la structure d’anneau commutatif intègre
(idomainType), et contient en plus une comparaison booléenne large notée <=,
une comparaison booléenne stricte notée <, et une fonction valeur absolue ou module
notée ‘|.|. Cette structure est appelée numDomainType. Sur cette structure,
les fonctions maxr et minr désignent respectivement les fonctions maximum et
minimum.
Voici les structures qui sont implémentées dans le fichier ssrnum.v :
Nom de la structure Description
numDomainType c’est la structure décrite plus haut
numFieldType numDomainType, mais basé sur un corps
numClosedFieldType numDomainType basé sur un corps algébriquement clos
realDomainType numDomainType avec un ordre total
realFieldType Corps réel
archiFieldType Corps archimédien
rcfType Corps réel clos
Ces structures (ainsi que la construction de nombres complexes ci-dessous)
sont expliquées plus en détails dans la thèse de Cyril Cohen [8].24 Contexte
1.2.11 Les nombres complexes
Les nombres complexes sont définis comme étant une paire de nombres :
Inductive complex (R : Type) : Type := Complex {Re : R; Im : R}.
On utilisera en général la notation suivante :
Local Notation C := (complex R).
La notation x%:C représente un réel plongé dans les complexes, c’est une notation
pour Complex x 0.
On peut munir le type complex R des structures ordonnées numDomainType et
numFieldType si R est de type rcfType (i.e. c’est un corps réel clos). En effet,
pour définir le module d’un nombre complexe, il faut définir la fonction « racine
carrée ». Or la racine carrée d’un nombre a est définie comme une racine du
polynôme X2 − a, donc pour que cette fonction soit bien définie, il faut1 que R
soit un corps réel clos.
L’ordre partiel défini sur les complexes est le suivant :
Definition lec x y := (Im x == Im y) && (Re x <= Re y).
Definition ltc x y := (Im x == Im y) && (Re x < Re y).
La structure de numDomainType est instanciée sur le type complex avec les
deux définitions ci-dessus pour l’ordre large et l’ordre strict, et avec la fonction
“module” suivante :
Definition normc x := (Num.sqrt ((Re x)^+2 + (Im x)^+2))%:C.
Pour pouvoir déclarer les nombres complexes comme étant une instance de la
structure numDomainType, on doit plonger le module d’un nombre complexe dans
C. Car si T est le type principal sur lequel est défini la structure numDomainType,
alors le type de la fonction ‘|.| est T -> T. Or, dans notre cas, T est instancié
par C, donc la fonction module doit être de type C -> C. Ceci a pour inconvénient
que le module d’un nombre complexe est un nombre complexe.
1.3 Conclusion
Ce chapitre explique les principaux outils utilisés dans le travail de formalisation.
Il présente aussi les notations usuelles qui seront utilisées dans la suite de cette
thèse.
1Enfin pas tout à fait. Disons que la structure rcfType est la plus petite structure implé-
mentée dans la bibliothèque SSReflect telle que la fonction « racine carrée »soit bien définie.Chapitre 2
Forme de Jordan d’une matrice
Un résultat important en algèbre linéaire est le fait qu’une matrice soit semblable
à sa forme normale de Jordan. La formalisation de ce résultat passe d’abord par
la formalisation de nombreux concepts comme les matrices diagonales par blocs,
les matrices compagnes, les facteurs invariants, et les matrices semblables ou
équivalentes. Ce résultat utilise également d’autres formes normales de matrices
comme la forme normale de Smith et la forme normale de Frobenius d’une matrice.
Les travaux présentés dans ce chapitre ont été menés en commun avec Maxime
Dénès (voir [7]), et ont été inspirés de la thèse de Patrick Ozello [37] et de celle
de Isabelle Gil [16].
Nous verrons dans une première section comment les matrices diagonales par
blocs ont été formalisées. Dans la section suivante, nous parlerons de la similitude
et de l’équivalence entre deux matrices. Ensuite nous discuterons sur la forme normale
de Smith, sur ses propriétés, et montrerons quelques lemmes importants qui
seront utiles par la suite. Dans une quatrième section, nous donnerons les définitions
formelles de matrices compagnes et des facteurs invariants ; nous pourrons
ainsi définir la forme normale de Frobenius d’une matrice. Enfin nous montrerons
comment nous obtenons la forme normale de Jordan d’une matrice.
2.1 Matrices diagonales par blocs
Une matrice diagonale par blocs est une matrice de la forme :
A1 0 . . . 0
0 A2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 0
0 . . . 0 Ak
où les Ai sont des matrices carrées quelconques.
Ces matrices seront utilisées pour exprimer les formes normales de Frobenius
et de Jordan d’une matrice.26 Forme de Jordan d’une matrice
Ce qui est intéressant dans les matrices diagonales par blocs est qu’en général
si l’on veut faire des opérations (ou montrer des propriétés), on peut se ramener
à les faire (ou les montrer) sur chaque bloc ; ce qui permet dans certains cas de
se ramener à un problème plus simple.
Certains choix de formalisation dans la bibliothèque SSReflect font que la
définition formelle de matrice diagonale par blocs n’est pas aussi simple qu’on
le voudrait. Nous expliquerons donc dans un premier temps quelle définition de
matrice diagonale par blocs nous voudrions avoir, et ensuite nous verrons quels
problèmes nous avons rencontrés avec cette définition, et comment ils ont été
résolus.
2.1.1 Définition idéale
Dans la bibliothèque SSReflect, il existe une fonction qui s’appelle block_mx.
Cette fonction permet de construire une matrice à partir de blocs matriciels. Par
exemple, si A, B, C et D sont des matrices (avec des dimensions adéquates) alors
block_mx A B C D est la matrice
A B
C D!
Si B et C sont des matrices nulles, et si A et D sont des matrices carrées, alors
block_mx A 0 0 D est une matrice diagonale par blocs avec comme blocs diagonaux
les matrices A et D. L’idée de base pour construire les matrices diagonales
par blocs est d’appeler récursivement la fonction block_mx.
À chaque appel de la fonction block_mx, il faudra lui donner en arguments
successivement les blocs diagonaux de la matrice que l’on veut construire. Ces
blocs peuvent être de tailles différentes, et donc de types différents. Une première
difficulté va être d’exprimer l’ensemble de ces blocs diagonaux.
Une solution pourrait être d’utiliser le type des paires dépendantes de Coq.
Dans la bibiliothèque standard de Coq, il y a un type sigT défini comme suit :
Inductive sigT (A : Type) (P : A -> Type) : Type :=
existT : forall x : A, P x -> sigT P.
Notation "{ x : A & P }" := (sigT (fun x : A => P))
Dans notre cas, si A est le type nat et P est la fonction fun n => ’M_n, alors
{n : nat & ’M_n} est le type des paires composées d’un entier et d’une matrice.
Ces paires sont dépendantes dans le sens où le type de la matrice dépend de
l’entier. De plus, pour tout k : nat et pour toute matrice M : ’M_k l’expression
existT k M est de type {n : nat & ’M_n}. Ainsi une sequence s dont le
type est seq {n : nat & ’M_n} peut contenir des matrices de types différents
(comme deuxième élément d’une paire), nous pouvons donc nous en servir pour
parler des blocs diagonaux. Ce qui nous donnerait comme première définition :2.1 Matrices diagonales par blocs 27
Fixpoint diag_block_mx (s : seq {n : nat & ’M[R]_n}) :=
match s return ’M[R]_(size_sum s) with
| [::]=> 0
| (existT k A) :: s’=> block_mx A 0 0 (diag_block_mx s’)
end.
où size_sum s est la fonction qui donne la taille de la matrice diagonale par blocs,
elle consiste simplement à faire la somme des tailles de chaque bloc.
Cette définition est suffisante pour prouver qu’une matrice est semblable à sa
forme de Jordan, car la seule chose que l’on fait avec les matrices diagonales par
blocs est de prouver leur similitude ou leur équivalence avec d’autres matrices.
Par contre, il est difficile de définir les opérateurs usuels sur ces matrices.
Nous allons rencontrer un premier problème lorsque nous voudrons exprimer
la somme de deux matrices diagonales par blocs. La matrice diag_block_mx s1 et
la matrice diag_block_mx s2, pour des séquences s1 et s2 différentes, ont respectivement
comme taille size_sum s1 et size_sum s2 ; autrement dit elles ont des
types différents (même si l’on peut prouver que size_sum s1 = size_sum s2). En
particulier on ne pourra même pas écrire l’expression suivante :
diag_block_mx s1 + diag_block_mx s2.
Il est possible de contourner ce problème en utilisant la fonction castmx de la
bibliothèque SSReflect. Si nous avons deux matrices A et B, respectivement
de type ’M_(m1,n1) et ’M_(m2,n2), et deux preuves d’égalités eqm : m1 = m2
et eqn : n1 = n2 alors la matrice cast_mx (eqm,eqn) B a le même type que
la matrice A (i.e ’M_(m1,n1)). Donc si eq_size est une preuve d’égalité entre
size_sum s1 et size_sum s2 alors nous pouvons écrire l’addition de deux matrices
diagonales par bloc comme suit :
diag_block_mx s1 + castmx (eq_size,eq_size) diag_block_mx s2
Malgré l’utilisation de la fonction castmx, nous nous heurterons à un deuxième
problème pour exprimer qu’additionner deux matrices diagonales par blocs revient
à les additionner bloc à bloc. Pour cela, il faudrait montrer que chacun des
blocs des séquences s1 et s2 sont deux à deux de la même taille, et à partir de
cette preuve obtenir les preuves d’égalité qui permetteront à l’aide de la fonction
castmx d’écrire les sommes des blocs deux à deux. Cette définition de matrice
diagonale par blocs n’est donc pas adaptée pour exprimer ce genre de propriété.
Si nous voulons additionner deux matrices diagonales par blocs, c’est qu’elles
ont, en général, le même découpage en blocs, car cela permet de faire l’addition
bloc à bloc. Si elles n’ont pas le même découpage en blocs, alors l’information que
les matrices sont diagonales par blocs n’apporte rien, et l’on doit faire l’addition
comme sur deux matrices quelconques. Il est donc intéressant que deux matrices
diagonales par blocs, ayant le même découpage en blocs, aient le même type.
Dans la description précédente, nous avons vu que la dimension d’une matrice
diagonale par blocs est donné par la fonction size_sum. Cette fonction prend en
argument une liste de paires dépendantes tailles/matrices, en extrait les dimen-28 Forme de Jordan d’une matrice
sions des matrices et en fait la somme. Dans la nouvelle définition de matrice
diagonale par blocs, nous allons plutôt donner comme premier argument directement
une séquence d’entiers qui correspondra à la séquence des tailles des blocs ;
autrement dit cette séquence donnera le découpage en blocs de la matrice.
Maintenant, pour exprimer les blocs de la matrice, nous ne pouvons plus
utiliser une séquence de paires dépendantes. Car sinon il faudrait s’assurer que
les tailles données comme premier élément de chaque paire soient les mêmes que
ceux de la séquence de découpage des blocs, ce que l’on veut éviter. Pour exprimer
les blocs, nous allons donc utiliser une fonction. Cette fonction doit retourner
comme valeur des matrices de différentes tailles, et donc de types différents. C’est
pourquoi le premier argument de la fonction sera la taille de la matrice qu’elle
va retourner ; pour le deuxième argument nous prendrons simplement le numéro
du bloc dans la matrice diagonale par blocs. Le type de cette fonction est donc
forall n : nat, nat -> ’M_n.
Notre nouvelle définition de matrices diagonales par blocs se présente donc
ainsi :
Fixpoint diag_block_mx s (F : forall n : nat, nat -> ’M_n) :=
match s return ’M_(sumn s) with
| [::] => 0
| n :: s’ => block_mx (F n 0) 0 0
(diag_block_mx s’ (fun n i => F n i.+1))
end.
où sumn prend en argument une séquence d’entiers et retourne la somme de ces
entiers. Voyons comment cela fonctionne sur un exemple :
1 1 0 0 0 0
2 4 0 0 0 0
0 0 4 0 0 0
0 0 0 4 5 1
0 0 0 9 6 6
0 0 0 0 4 2
Le découpage en blocs de la matrice ci-dessus correspond à la séquence de
découpage [:: 2 ; 1 ; 3]1
. Le bloc numéro 0 est de taille 2, il correspond donc
au bloc F 2 0 où F est la fonction qui retourne les blocs diagonaux de la matrice
ci-dessus, c’est-à-dire n’importe quelle fonction qui vérifie les trois conditions
suivantes :
F 2 0 =
1 1
2 4!
; F 1 1 =
4
; F 3 2 =
4 5 1
9 6 6
0 4 2
1
Il y a quatre façon de découper cette matrice en blocs qui correspondent aux séquences
suivantes : [:: 6], [:: 2 ; 4], [:: 3 ; 3], [:: 2 ; 1 ; 3].2.1 Matrices diagonales par blocs 29
Comme les autres valeurs de la fonction F ne sont pas appelées par la fonction
diag_block_mx, elles n’ont pas d’importance.
Avec cette définition nous pouvons exprimer facilement que la somme de deux
matrices diagonales par blocs est la matrice diagonale par blocs où chaque bloc
est la somme des blocs des deux premières matrices :
Lemma add_diag_block s F1 F2 :
diag_block_mx s F1 + diag_block_mx s F2 =
diag_block_mx s (fun n i => F1 n i + F2 n i).
Cette deuxième définition est assez proche de la définition idéale que l’on
voudrait pour les matrices diagonales par blocs, car elle est proche de l’intuition
que l’on s’en fait (appel récursif de la fonction block_mx), et permet de manipuler
les matrices diagonales par blocs assez simplement. Cependant, à cause de certains
choix de formalisation dans la bibliothèque SSReflect, nous allons rencontrer
d’autres problèmes qui font que nous allons devoir modifier cette définition. C’est
ce que nous allons voir dans la sous-section suivante.
2.1.2 Problèmes en dimension nulle
La définition de structure d’anneaux dans la bibliothèque SSReflect demande
une preuve que 1 (l’élément neutre de la loi multiplicative) soit différent de 0
(l’élément neutre de la loi additive). Ceci a pour conséquence que l’ensemble des
matrices carrées d’une taille fixée forme un anneau (dans le sens de SSReflect)
seulement si ces matrices sont non vides, c’est-à-dire de taille non nulle (car toutes
les matrices vides sont égales). Autrement dit, l’instance canonique de la structure
d’anneau sur les matrices est implémentée seulement sur celles ayant un type de
la forme ’M_n.+1. Ainsi, sur les matrices n’ayant pas un type de cette forme, on ne
peut pas utiliser les fonctions définies à partir des opérations génériques d’anneaux
(par exempe les fonctions qui calculent la puissance, le polynôme minimal où la
valeur d’un polynôme en une matrice).
Or le type des matrices diagonales par blocs définies plus haut est de la forme
’M_(sumn s). Nous ne pourrons donc pas utiliser sur ces matrices certaines des
fonctions citées ci-dessus. En effet, si l’on essayait d’appliquer une de ces fonctions,
le système Coq attendrait comme argument une structure d’anneau sur les
matrices, comme cette structure est déclarée pour les matrices dont le type est
de la forme ’M_n.+1, le système va essayer de résoudre le problème d’unification
?n.+1 = sumn s et il va échouer. Nous allons donc voir ici comment la définition
de matrice diagonale par blocs a été modifiée pour que le type de ces matrices
soit de la bonne forme.
2.1.3 Définition finale
Une propriété intéressante des matrices diagonales par blocs est que faire certaines
opérations sur une matrice diagonale par blocs revient à faire ces opérations
sur chaque bloc. Si ces opérations utilisent des opérations génériques d’anneaux,30 Forme de Jordan d’une matrice
il faut alors que chacun des blocs ait un type de la forme ’M_n.+1. Le type
de la fonction F de la définition de matrice diagonale par blocs devient donc
forall n, nat -> ’M_n.+1.
Maintenant nous voulons trouver une fonction, appelons-la size_sum, telle
que le type d’une matrice diagonale par blocs soit ’M_(size_sum s).+1. Nous
remarquons d’abord que si la séquence donnée en premier argument de la fonction
diag_block_mx est vide, alors la matrice diagonale par blocs retournée est vide,
et donc sa taille ne peut pas être de la forme n.+1. Il va donc falloir modifier la
définition de diag_block_mx pour qu’elle ne renvoie jamais une matrice vide. Pour
cela nous allons définir une première fonction pour laquelle nous allons séparer
la séquence de découpage des blocs en deux ; c’est-à-dire qu’elle va prendre en
argument un entier qui va représenter la taille du premier bloc, et une séquence
qui contiendra la taille des autres blocs (à un près à cause du décalage dû au
n.+1) :
Fixpoint diag_block_mx_rec k s (F : forall n, nat -> ’M_n.+1) :=
match s return ’M_((size_sum_rec k s).+1) with
| [::] => F k 0
| n :: s’ => block_mx (F k 0) 0 0
(diag_block_mx_rec n s’ (fun n i => F n i.+1))
end.
où size_sum_rec est défini de telle façon que le type de diag_block_mx_rec ait la
bonne forme :
Fixpoint size_sum_rec k s :=
match s with
| [::] => k
| n :: s’ => k + (size_sum_rec n s’).+1
end.
donc si s est vide alors (size_sum_rec k s).+1 = k.+1 ce qui est bien le type de
F k 0, et si s = n :: s’ alors :
(size_sum_rec k s).+1 = (k + (size_sum_rec n s’).+1).+1
et la dimension de la matrice dans la deuxième branche de la définition de
diag_block_mx_rec est k.+1 + (size_sum_rec n s’).+1, et comme l’addition est
définie récursivement par rapport à la première variable, les deux expressions sont
convertibles.
Mais pour utiliser cette définition, il faut donner en argument un entier et une
séquence d’entiers, ce qui peut souvent amener à “couper” en deux une séquence
pour donner les deux arguments. Pour éviter cela nous définissons la fonction
diag_block_mx de façon à ce qu’elle prenne en argument seulement une séquence :
Definition size_sum s :=
match s with
| [::] => 0
| n :: s’ => size_sum_rec n s’
end.2.2 Matrices semblables et équivalentes 31
Definition diag_block_mx s (F : forall n, nat -> ’M_n.+1) :=
match s return ’M_((size_sum s).+1) with
| [::] => 0 (* de type ’M_1 *)
| n :: s’ => diag_block_mx_rec n s’ F
end.
Cette définition retourne une matrice de taille un si la séquence donnée en
argument est vide. Dans la pratique cela ne devrait pas trop poser de problèmes
car lorsque l’on parle d’une matrice diagonale par blocs, c’est rarement à propos
d’une matrice vide. Ceci a pour conséquences que dans les énoncés des théorèmes,
il faut dans certains cas rajouter l’hypothèse que la séquence des tailles des blocs
soit non vide ; et dans les preuves, il faut en général faire un traitement par cas
sur cette séquence pour éliminer le cas où elle est vide. Dans le cas où la séquence
n’est pas vide, la fonction diag_block_mx a le comportement attendu.
Pour conclure cette section, cette dernière définition de matrice diagonale par
blocs a l’inconvénient mineur de ne pas avoir le bon comportement dans le cas où
la séquence des tailles des blocs est vide. Mais maintenant le type d’une matrice
retournée par la fonction diag_block_mx est de la bonne forme pour que l’on
puisse utiliser les opérations génériques d’anneaux dessus, ainsi que sur chacun
des blocs de la matrice.
2.2 Matrices semblables et équivalentes
Rappelons que nous voulons montrer que la forme normale de Jordan d’une matrice
est semblable à celle-ci. Pour cela nous utiliserons en plus de la notion de
matrices semblables, celle de matrices équivalentes. Nous présenterons donc, dans
cette section, la formalisation de ces deux notions, et nous verrons comment elles
sont liées.
2.2.1 Définitions
Deux matrices A et B sont équivalentes s’il existe deux matrices inversibles M et
N telles que MAN = B, et elles sont semblables s’il existe une matrice inversible
P telle que P AP −1 = B. Pour la définition de matrices semblables, nous préfèrerons
la version avec P A = BP, car dans la bibiliothèque SSReflect, la notation
x^-1 est définie sur la structure appelée unitRingType1
, or cette structure est audessus
de la structure d’anneaux de SSReflect, et donc comme nous l’avons vu
dans la section précédente, nous pourrons utiliser cette notation uniquement sur
les matrices dont le type est de la forme ’M_n.+1.
Une première définition formelle que l’on pourrait donner pour la similitude
est la suivante2
:
1voir section 1.2.6
2voir 1.2.8 pour les notations.32 Forme de Jordan d’une matrice
Definition similar n (A B : ’M[R]_n) :=
(exists P : ’M_m , P \in unitmx /\ P *m A = B *m P).
Mais cette définition n’est pas assez souple pour être utilisée facilement. En effet,
pour pouvoir écrire l’expression similar A B, il faut absolument que les matrices
A et B aient le même type. Or nous avons signalé plus haut que la forme normale de
Jordan sera exprimée comme une matrice diagonale par blocs. Donc si A : ’M_n
alors sa forme normale de Jordan sera de type ’M_(size_sum s).+1 pour une
certaine séquence s. En particulier, nous ne pouvons pas écrire l’énoncé qui nous
intéresse, à savoir qu’une matrice est semblable à sa forme normale de Jordan ;
sauf si nous décidons d’utiliser la fonction castmx, mais cela alourdirait les énoncés
et compliquerait les preuves.
Pour éviter ces problèmes, nous définissons le prédicat similar pour deux
matrices quelconques (pas forcément de même type). Cela implique que le prédicat
doit vérifier l’égalité des tailles des matrices :
Definition similar m n (A : ’M[R]_m) (B : ’M[R]_n) := m = n /\
(exists P : ’M_m , P \in unitmx /\ P *m A = (conform_mx P B) *m P).
Nous voyons aussi apparaître dans la définition la fonction conform_mx. Cette
apparition est due au fait que, comme les matrices P et B n’ont pas le même type,
l’expression B *m P est mal typée.
La fonction conform_mx est définie dans la bibliothèque SSReflect. Si M
et N sont deux matrices alors conform_mx M N a le même type que la matrice
M. Si l’on peut prouver que les matrices M et N ont des tailles différentes, alors
conform_mx M N = M. Si les matrices M et N ont le même type alors nous avons
conform_mx M N = N.
Nous avons donc utilisé cette fonction pour remplacer l’expression B *m P,
qui est mal typée, par l’expression (conform_mx P B) *m P qui elle est bien typée.
Ainsi si les matrices A et B ont la même dimension alors (conform_mx P B)
représentera la matrice que l’on attend, sinon les matrices A et B n’ont aucune
chance d’être semblables, et donc la matrice retournée par (conform_mx P B) importe
peu, puisque l’égalité des tailles est vérifiée par ailleurs.
Pour les mêmes raisons, nous définissons de manière analogue l’équivalence
entre deux matrices :
Variables m1 n1 m2 n2 : nat.
Definition equivalent (A : ’M[R]_(m1,n1)) (B : ’M[R]_(m2,n2)) :=
[/\ m1 = m2, n1 = n2 & exists M, exists N,
[/\ M \in unitmx , N \in unitmx & M *m A *m N = conform_mx A B]].
2.2.2 Théorème fondamental
Le lien entre ces deux notions d’équivalence et de similitude est donné par le
théorème fondamental de similitude sur un corps :2.3 Forme normale de Smith 33
Théorème. Soit K un corps, soit A et B deux matrices de Mn(K) alors :
A et B sont semblables ⇔ (XI − A) et (XI − B) sont équivalentes
Les matrices (XI − A) et (XI − B) sont les matrices caractéristiques de
A et de B. Ce sont des matrices à coefficients dans l’anneau principal K[X].
Or sur les anneaux principaux, chaque matrice a une forme normale équivalente
appelée forme normale de Smith. Le théorème fondamental permet de donner une
procédure simple pour tester si deux matrices sont semblables. Il suffit de prendre
les matrices caractéristiques de ces matrices, de calculer leur forme normale de
Smith, et de comparer les résultats.
A =⇒ (XI − A) =⇒
B =⇒ (XI − B) =⇒
Mn(K) Mn(K[X])
Smith
−→ SA =
−→ SB =
Forme normale de
Smith de (XI − A)
Forme normale de
Smith de (XI − B)
A semblable à B ⇔ SA = SB
Ce théorème sera souvent utilisé dans la suite de cette formalisation, il permet
de montrer que deux matrices sont semblables sans avoir à donner la matrice de
passage entre ces deux matrices.
L’algorithme qui donne la forme normale de Smith d’une matrice et le théorème
fondamental ont été respectivement implémenté et prouvé formellement par
Maxime Dénès [12, 9]. Ce travail sur la forme normale de Smith a permis d’avoir
une formalisation complète (sans axiomes) des formes normales de Frobenius et
de Jordan d’une matrice.
Dans les sections suivantes nous allons d’abord présenter ce qu’est la forme
normale de Smith d’une matrice et ensuite nous verrons le cheminement pour
passer de la forme normale de Smith à celle de Jordan.
2.3 Forme normale de Smith
Nous expliquons dans cette section ce qu’est la forme normale de Smith d’une matrice.
Nous voyons ensuite comment l’algorithme qui donne cette forme normale
est spécifié formellement, et montrons quelques propriétés importantes.34 Forme de Jordan d’une matrice
2.3.1 Spécification
La forme normale de Smith d’une matrice A est une matrice équivalente à A qui
se présente de la manière suivante :
d1 0 . . . . . . . . . 0
0 d2
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
0 . . . 0 dk 0 . . . 0
avec la particularité que ∀i, 1 ≤ i < k, di
| di+1. Avoir un pgcd est suffisant
pour que la forme normale de Smith existe. Ce qui est le cas pour les polynômes
à coefficients dans un corps, qui est le contexte dans lequel nous utiliserons la
forme normale de Smith.
Pour exprimer cette matrice, nous définissons la fonction diag_mx_seq qui
prend en argument une séquence et qui retourne une matrice diagonale dont les
éléments diagonaux sont les éléments de la séquence1
:
Variable R : ringType.
Definition diag_mx_seq m n (s : seq R) : ’M[R]_(m,n) :=
\matrix_(i < m, j < n) s’_i *+ (i == j :> nat).
Les dimensions de la matrice retournée par la fonction diag_mx_seq sont ses
deux premiers arguments. Ceci permet une utilisation très souple de cette fonction.
En effet, si nous avons besoin dans une expression que la matrice retournée
par diag_mx_seq soit d’un type particulier, il suffit de donner les premiers
arguments adéquats. Mais cette souplesse implique qu’il faut ajouter certaines
contraintes dans les énoncés des propriétés de la fonction diag_mx_seq, pour établir
un lien entre les dimensions de la matrice retournée par la fonction et la
séquence donnée en argument.
Par exemple, pour la sequence s = [:: 1 ; 2 ; 3] nous avons :
diag_mx_seq 4 2 s = diag_mx_seq 5 4 s = diag_mx_seq 3 3 s =
1 0
0 2
0 0
0 0
;
1 0 0 0
0 2 0 0
0 0 3 0
0 0 0 0
0 0 0 0
;
1 0 0
0 2 0
0 0 3
Nous voyons ici que selon les valeurs de m et de n la matrice diag_mx_seq m n s
n’est pas toujours la matrice à laquelle on pense. En fait, pour que la matrice
diag_mx_seq m n s soit une matrice telle que sur sa diagonale on puisse lire toute
la séquence s, et seulement la séquence s, il faut que la taille de la séquence soit
égale au minimum de m et de n.
1voir 1.2.8 pour les notations.2.3 Forme normale de Smith 35
Une fonction Smith nous est fournie par [9] pour calculer la forme normale de
Smith d’une matrice A : ’M_(m,n). Cette fonction retourne un triplet (M,d,N),
où M et N sont des matrices et d une séquence qui vérifient les trois spécifications
suivantes :
• M *m A *m N = diag_mx_seq m n d
• sorted %| d (La séquence d est triée pour la relation de division sur l’anneau
R)
• M \in unitmx & N \in unitmx (Les matrices M et N sont inversible)
Nous pouvons fusionner le premier et le dernier point pour avoir les deux
spécifications suivantes :
• equivalent A (diag_mx_seq m n d)
• sorted %| d
Nous allons montrer dans la section suivante qu’une séquence vérifiant les
spécifications ci-dessus est unique modulo une relation que nous définirons.
2.3.2 Unicité
Le calcul de la forme normale de Smith utilise des calculs de pgcd sur les coef-
ficients de la matrice. Le pgcd de deux éléments est unique modulo la relation
d’équivalence ∼ définie de la manière suivante :
a ∼ b ⇔ a|b et b|a
La forme normale de Smith est donc unique modulo cette relation d’équivalence
sur les coefficients.
Nous allons montrer ici un résultat important sur la forme normale de Smith
d’une matrice qui permet d’en déduire l’unicité, mais qui sera aussi très utile dans
la suite de la formalisation.
Théorème 1. Soit A une matrice à coefficients dans un anneau principal. Soit
d une séquence vérifiant les spécifications suivantes :
– La séquence d est triée pour la relation de division.
– La matrice diagonale dont les éléments diagonaux sont les éléments de d est
équivalente à la matrice A.
Si l’on note ∧ le pgcd, si di désigne le ième élément de la séquence d et si
|A|
k
désigne l’ensemble des mineurs d’ordre k de la matrice A, alors nous avons
l’identité suivante :
Y
k
i=1
di ∼
^
x∈|A|k
x36 Forme de Jordan d’une matrice
Un mineur d’une matrice A est le déterminant d’une sous-matrice de A.
Avant de montrer ce résultat, nous allons voir sur un exemple comment on
utilise ce théorème pour déterminer de façon “unique” la forme normale de Smith
d’une matrice.
Exemple 1. Prenons la matrice dans M3(Z[X]) suivante :
M =
5 2X X + 3
−X + 6 X + 1 4
X + 9 4X 3X + 5
Le théorème pour k = 1 dit que d1 est égal au pgcd de tous les mineurs d’ordre
1 de la matrice M. Les mineurs d’ordre 1 de la matrice M sont les déterminants
des sous-matrices de tailles 1 de M, i.e ce sont les coefficients de la matrice M.
Ici on voit que les polynômes M11 et M23 sont premiers entre eux, donc le pgcd
des coefficients de la matrice est est 1. Nous avons donc d1 = 1.
Remarque 1. En fait nous avons plus exactement d1 ∼ 1, donc d1 peut être -1 ou
1. Si les coefficients de la matrice M avaient été dans Q[X] au lieu de Z[X] alors
d1 aurait pu être n’importe quel rationnel non nul. Quelque soit le choix de d1, la
matrice diagonale obtenue à la fin respecte les spécifications de l’algorithme de la
forme normale de Smith. Cette remarque est valable pour tous les di.
Pour k = 2, nous avons d1 ∗d2 qui est égal au pgcd de tous les mineurs d’ordre
2 de la matrice M. Dans la suite nous noterons |M|IJ le déterminant de la sous
matrice de M définie par les lignes qui sont dans I et par les colonnes qui sont
dans J. Par exemple nous avons :
|M|{1,2}{1,2} =
5 2X
−X + 6 X + 1
= 2X
2 − 7X + 5 = (X − 1)(2X − 5)
De même on a :
|M|{1,3}{1,3} =
5 3 + X
X + 9 3X + 5
= −X
2 + 3X − 2 = (X − 1)(−X + 2)
|M|{1,2}{2,3} =
2X 3 + X
X + 1 4
= −X
2 + 4X − 3 = (X − 1)(−X + 3)
.
.
.
Si on continue, on s’aperçoit que (X − 1) est le seul facteur commun à tous
les mineurs d’ordre 2 de M, donc d1 ∗ d2 = d2 = (X − 1).
Enfin pour k = 3, nous avons d1 ∗ d2 ∗ d3 qui est égal au pgcd des mineurs
d’ordre 3 de la matrice M. Or la seule sous-matrice de M d’ordre 3 est la matrice2.3 Forme normale de Smith 37
M elle même. Donc d1 ∗ d2 ∗ d3 = det M ce qui donne après calcul (X − 1) ∗ d3 =
(X − 1)2
(X − 2) soit d3 = (X − 1)(X − 2). Ainsi la forme normale de Smith de
M est la matrice :
1 0 0
0 (X − 1) 0
0 0 (X − 1)(X − 2)
Nous avons vu comment utiliser le théorème précédent pour déterminer de
manière unique (modulo la relation ∼) la forme normale de Smtih d’une matrice.
Maintenant nous allons voir comment il a été formalisé.
Le théorème peut s’exprimer formellement ainsi1
:
Lemma Smith_gcdr_spec m n (A : ’M_(m,n)) (d : seq R) k :
\prod_(i < k) d‘_i %= \big[gcdr/0]_f \big[gcdr/0]_g minor k f g A .
où le premier argument de la fonction minor est l’ordre du mineur. Les fonctions
f et g jouent le rôle des ensembles d’indices I et J dans la notation |A|IJ , plus
précisément I correspond à l’image de f et J à l’image de g.
Soit donc R un anneau principal, une matrice A : ’M[R]_(m,n), et une sé-
quence d telle que d soit triée par la relation de division et que la matrice
diag_mxseq m n d soit équivalente à A.
Le résultat se montre en deux étapes. Dans une première étape nous prouvons
le théorème pour la matrice diag_mx_seq m n d (au lieu de A). Comme c’est une
matrice diagonale, les seuls mineurs d’ordre k non nuls sont les mineurs principaux,
c’est à dire les déterminants de sous-matrices dont la diagonale principale
coïncide avec la diagonale de la matrice. Dans notre cas particulier, les mineurs
principaux sont égaux au produit de k éléments de la séquence d. Comme chaque
élément de la séquence divise le suivant, le pgcd des mineurs d’ordre k est donc
le produit des k premiers éléments de la séquence.
Nous pouvons ensuite remplacer dans l’énoncé du théorème le membre de
gauche \prod_(i < k) d‘_i par l’expression suivante :
\big[gcdr/0]_f \big[gcdr/0]_g minor k f g (diag_mx_seq m n d)
Dans la seconde étape, il nous reste donc à prouver ceci :
\big[gcdr/0]_f \big[gcdr/0]_g minor k f g (diag_mx_seq m n d)
%= \big[gcdr/0]_f \big[gcdr/0]_g minor k f g A
Cela se prouve par double divisibilité, comme les deux preuves se font de la
même manière, nous montrons ici seulement le résultat suivant :
\big[gcdr/0]_f \big[gcdr/0]_g minor k f g A
%| \big[gcdr/0]_f \big[gcdr/0]_g minor k f g (diag_mx_seq m n d)
D’après les propriétés du pgcd, il suffit de montrer que pour tout f’ et g’ nous
avons :
1voir 1.2.5, et 1.2.7 pour les notations.38 Forme de Jordan d’une matrice
\big[gcdr/0]_f \big[gcdr/0]_g minor k f g A
%| minor k f’ g’ (diag_mx_seq m n d)
Or nous savons que les matrices A et diag_mx_seq m n d sont équivalentes, il
existe donc deux matrices M et N telles que M *m A *m N = diag_mx_seq m n d.
En réécrivant cette égalité, il nous reste à prouver :
\big[gcdr/0]_f \big[gcdr/0]_g minor k f g A
%| minor k f’ g’ (M *m A *m N)
Nous avons fait apparaître ici le mineur d’un produit de matrices, nous allons
le transformer en une somme de produits de mineurs en utilisant la formule de
Binet-Cauchy. Cette formule s’énonce comme suit :
det(AB) = X
I∈P({1,...,l})
#|I|=k
det(AI ) det(BI )
où A est une matrice de taille k × l et B une matrice de taille l × k. Ici det AI =
|A|{1,...,k}I et det BI = |B|I{1,...,k}. Ce résultat a été prouvé formellement par
Vincent Siles [46]. On peut facilement ramener la formule de Binet-Cauchy à
la formule suivante :
|AB|IJ =
X
K
|A|IK|B|KJ
La formule ci-dessus s’écrirait formellement :
minor k f g (A *m B) = \sum_h (minor k f h A) * (minor k h g B)
Grâce à ce lemme nous pouvons remplacer minor k f’ g’ (M *m A *m N) par
\sum_h \sum_j (minor k f’ h M) * (minor k h j A) * (minor k j g’ N)
Or d’après les propriétés du pgcd, pour tout h et j nous avons :
\big[gcdr/0]_f \big[gcdr/0]_g minor k f g A %| minor k h j A
Donc le pgcd des mineurs d’ordre k de la matrice A divise tous les termes de
la somme ci-dessus, ce que nous voulions démontrer.
Nous avons vu que les coefficients de la forme normale de Smith peuvent être
choisis modulo la relation d’équivalence ∼. Cela implique en particulier, que, pour
les matrices carrées, nous pouvons choisir un représentant de la forme normale
de Smith d’une matrice A qui a le même déterminant. En effet, soit D la forme
normale de Smith d’une matrice A. Nous savons que D est équivalent à la matrice
A, il existe donc des matrices L et R inversibles telles que D = LAR. Le fait que
L et R soient inversibles signifie que leur déterminant est également inversible.
Donc si nous appelons D′
la matrice D dans laquelle nous avons multiplié la
première ligne par (detL ∗ det R)
−1 alors :
• Les éléments diagonaux de D′
sont triés pour la relation de division (car multiplier
certains éléments par un inversible ne change pas les classes d’équivalences).2.3
Forme normale de Smith 39
• La matrice D′
est équivalente à la matrice A (car multiplier une ligne par
un élément inversible est une opération réversible et donc conserve l’équivalence).
Formellement nous avons :
Definition Smith_seq m n (M : ’M[E]_(m,n)) :=
let: (L,d,R) := (Smith _ M) in
if d is a :: d’ then (\det L)^-1 * (\det R)^-1 * a :: d’ else nil.
Definition Smith_form m n (A : ’M[R]_(m,n)) :=
diag_mx_seq m n (Smith_seq A).
Lemma det_Smith n (A : ’M[R]_n) : \det (Smith_form A) = \det A.
Le théorème d’unicité de la forme normale de Smith d’une matrice s’énonce
formellement comme suit :
Lemma Smith_unicity m n (A : ’M[R]_(m,n)) (s : seq R) :
sorted %| s -> equivalent A (diag_mx_seq m n s) ->
forall i, i < minn m n -> s‘_i %= (Smith_seq A)‘_i.
2.3.3 Facteurs invariants
Dans la section 2.2.2, nous avons vu que nous pouvons déterminer si deux matrices
carrées A et B à coefficients dans un corps sont semblables en comparant les
formes normales de Smith de leur matrice caractéristique. Ensuite nous avons
montré dans la section précédente un théorème qui permet de montrer l’unicité
de la forme normale de Smith, mais dont nous nous servirons plus tard pour
déterminer les éléments diagonaux de la forme normale de Smith d’une matrice
par des calculs de pgcd. Nous allons présenter maintenant les facteurs invariants.
La forme normale de Smith de la matrice XI − A est une matrice diagonale
à coefficients polynômiaux. Les polynômes non-constants qui apparaissent sur la
diagonale sont les facteurs invariants de la matrice A. Le théorème fondamental
et le résultat d’unicité nous disent que les facteurs invariants sont des invariants
de similitude, c’est-à-dire que deux matrices sont semblables si et seulement si
elles ont les mêmes facteurs invariants.
Nous allons voir ici comment les facteurs invariants d’une matrice ont été
définis formellement.
Rappelons que la forme normale de Smith d’une matrice à coefficients dans
un anneau principal est unique modulo la relation d’équivalence ∼. Or dans notre
contexte, l’anneau principal sur lequel nous travaillons est l’anneau des polynômes
à coefficients dans un corps. Dans ce cas-ci, si p est un polynôme non nul alors
il existe un unique représentant unitaire de la classe d’équivalence de p qui est p
divisé par son coefficient dominant.40 Forme de Jordan d’une matrice
Nous pouvons donc définir une nouvelle séquence qui vérifie les mêmes spé-
cifications que la séquence Smith_seq mais qui ne contient que des polynômes
unitaires1
:
Definition Frobenius_seq n (A : ’M_n) :=
[seq (lead_coef p)^-1 *: p | p <- (Smith_seq (char_poly_mx A))].
Les facteurs invariants sont les polynômes non constants de cette séquence :
Definition invariant_factors n (A : ’M_n) :=
[seq p : {poly R} <- (Frobenius_seq A) | 1 < size p].
2.4 Forme normale de Frobenius
La forme normale de Frobenius d’une matrice M est la matrice diagonale par blocs
dont les blocs diagonaux sont les matrices compagnes des facteurs invariants de
M.
Nous avons déjà vu comment sont définies formellement les matrices diagonales
par blocs. Nous avons vu ensuite ce qu’était la forme normale de Smith, ce
qui nous a permis de définir les facteurs invariants d’une matrice. Il nous reste
donc à donner une définition formelle des matrices compagnes pour pouvoir dé-
finir la forme normale de Frobenius. Nous prouverons ensuite que toute matrice
carrée à coefficients dans un corps est semblable à sa forme normale de Frobenius.
2.4.1 Matrices compagnes
La matrice compagne d’un polynôme unitaire p = Xn+an−1Xn−1+. . .+a1X +a0
est la matrice suivante :
Cp =
0 . . . . . . 0 −a0
1
.
.
.
.
.
. −a1
0
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 0
.
.
.
0 . . . 0 1 −an−1
Cette matrice est intéressante car p est à la fois son polynôme caractéristique et
son polynôme minimal.
Formellement, si p est un polynôme, la taille de la matrice compagne de p est
(size p).-1. Mais ici encore, si nous voulons utiliser des opérations génériques
d’anneaux sur des matrices compagnes, il faut que leur taille soit de la forme
n.+1. Pour cela nous définissons les matrices compagnes de sorte que leur type
soit (size p).-2.+1 :
1voir 1.1.5, 1.2.6 et 1.2.9 pour les notations.2.4 Forme normale de Frobenius 41
Definition companion_mx (p : {poly R}) :=
\matrix_(i,j < (size p).-2.+1)
((i == j.+1 :> nat)%:R + p‘_i *+ ((size p).-2 == j)).
Nous avons (size p).-2.+1 = (size p).-1 si et seulement si 1 < (size p),
c’est-à-dire si p est un polynôme non constant. La définition de matrice compagne
n’est donc valide que pour les polynômes non constants. En pratique ceci
ne devrait pas être trop contraignant car les matrices compagnes de polynômes
constants sont des matrices vides et sont donc inintéressantes dans un certain
sens.
Malheureusement, avec cette définition de matrices compagnes, nous ne pouvons
pas définir de matrice diagonale par blocs dont les blocs sont des matrices
compagnes. En effet, le type de la fonction qui retourne les blocs diagonaux de
la matrice est forall n, nat -> ’M_n.+1 ; c’est donc une fonction qui prend un
entier n, un entier et qui retourne une matrice de type ’M_n.+1, mais si la matrice
retournée est une matrice compagne d’un polynôme p, alors son type sera
’M_(size p).-2.+1 et non ’M_n.+1.
Pour résoudre ce problème, nous définissons les matrices compagnes en deux
étapes. Nous définissons d’abord une fonction companion_mxn qui prend en argument
un entier n et un polynôme p, et qui retourne une matrice de type ’M_n
telle que si n = (size p).-2.+1 alors la matrice retournée correspond à la matrice
compagne du polynôme p. Nous pouvons donc ensuite définir la matrice
compagne d’un polynôme p comme étant la matrice retournée par la fonction
companion_mxn appliquée aux arguments (size p).-2.+1 et p :
Definition companion_mxn n (p : {poly R}) :=
\matrix_(i,j < n) ((i == j.+1 :>nat)%:R + p‘_i *+ ((size p).-2 == j)).
Definition companion_mx (p : {poly R}) :=
companion_mxn (size p).-2.+1 p.
Ainsi pour faire une matrice diagonale par blocs, nous pouvons utiliser la
fonction companion_mxn, car companion_mxn n.+1 a le type ’M_n.+1 qui est bien
de la bonne forme. Les lemmes sur les matrices compagnes seront exprimés, eux,
sur companion_mx.
Nous pouvons maintenant donner une définition formelle de la forme normale
de Frobenius d’une matrice. Elle se présente de la manière suivante :
Cp1
Cp2
0
0
.
.
.
Cpk
où les polynômes pi sont les facteurs invariants de la matrice. Formellement, nous
la définissons comme suit :42 Forme de Jordan d’une matrice
Definition Frobenius_form n (A : ’M_n) :=
let sizes := [seq (size p).-2 | p <- (invariant_factors A)] in
let blocks n i := companion_mxn n.+1 (invariant_factors A)‘_i in
diag_block_mx sizes blocks.
2.4.2 De Smith à Frobenius
Maintenant que nous avons défini la forme normale de Frobenius d’une matrice,
nous allons montrer ici que toute matrice sur un corps F est semblable à sa forme
normale de Frobenius :
Lemma Frobenius n (A : ’M[F]_n.+1) : similar A (Frobenius_form A).
Comme nous l’avons annoncé, pour prouver ce résultat nous utilisons le théorème
fondamental. Il nous faut donc montrer que pour toute matrice A, les matrices
caractéristiques de A et Frobenius_form A sont équivalentes.
Soit une matrice A, nous allons partir de la matrice XI − A et arriver à la
matrice caractéristique de Frobenius_form A par transitivité de l’équivalence.
Nous avons vu que la séquence Frobenius_seq A respecte les spécifications
de l’algorithme de Smith. Donc la matrice XI − A est équivalente à la matrice
diag_mx_seq n.+1 n.+1 (Frobenius_seq A), qui se présente de la façon suivante :
1
.
.
. 0
1
p1
0
.
.
.
pn
où les pi sont les facteurs invariants de la matrice A.
Ici nous allons utiliser le résultat suivant pour justifier le fait que nous pouvons
permuter les éléments diagonaux :
Lemma similar_diag_mx_seq m n s1 s2 :
m = n -> size s1 = m -> perm_eq s1 s2 ->
similar (diag_mx_seq m m s1) (diag_mx_seq n n s2).
où perm_eq s1 s2 exprime le fait que les séquence s1 et s2 ont les mêmes éléments
mais permutés.
En effet, si deux matrices diagonales ont leurs éléments diagonaux permutés,
alors la matrice de passage de l’une à l’autre est une matrice de permutation
qui est inversible ; donc les deux matrices sont semblables, et donc à fortiori
équivalentes. Nous pouvons ainsi permuter les éléments diagonaux de la matrice2.4 Forme normale de Frobenius 43
précédente :
1
.
.
.
1
p1
0
.
.
.
0
1
.
.
.
1
pn
Si pi représente le polynôme pi
, alors (size pi).-2 représente le nombre de 1
avant chaque pi
. Cette matrice peut être vue comme la matrice diagonale par
blocs suivante :
1
.
.
.
1
p1
0
0
.
.
.
1
.
.
.
1
pn
Nous voulons maintenant montrer que cette matrice est équivalente à la
matrice caractéristique de la forme normale de Frobenius de A. Nous utilisons
d’abord le fait que la matrice caractéristique d’une matrice diagonale par blocs
est la matrice diagonale par blocs des blocs caractéristiques :
Lemma char_diag_block_mx s (F : forall n, nat -> ’M[R]_n.+1) :
s != [::] ->
char_poly_mx (diag_block_mx s F) =
diag_block_mx s (fun n i => char_poly_mx (F n i)).
Il ne nous reste donc plus qu’à montrer que la matrice précédente est équivalente
à :
XI − Cp1
.
.
.
0
0
.
.
.
XI − Cpn
Nous voulons donc montrer que deux matrices diagonales par blocs sont équivalentes.
Pour cela, il nous suffit de prouver que les matrices sont équivalentes bloc44 Forme de Jordan d’une matrice
à bloc. C’est-à-dire que pour chaque indice i, la matrice XI − Cpi
est équivalente
à :
1
.
.
.
1
pi
Pour montrer ce dernier résultat, nous utilisons le lemme Smith_gcdr_spec
vu plus haut. En effet, pour tout k tel que k < (size pi).-2, on peut trouver
une sous-matrice de la matrice XI − Cpi
ci-dessous n’ayant que des −1 sur la
diagonale :
XI − Cpi =
X . . . 0 0 a0
−1
.
.
.
.
.
.
.
.
. a1
0
.
.
. X
.
.
.
.
.
.
.
.
.
.
.
. −1 X
.
.
.
0 . . . 0 −1 X + an−1
Donc si nous calculons la forme normale de Smith de la matrice ci-dessus
comme nous l’avons fait dans l’exemple 1, nous remarquons que pour tout k
strictement plus petit que (size pi).-2, il existe un mineur d’ordre k associé
à 1 (car (−1)k ∼ 1), et donc le pgcd de ces mineurs est lui-même associé à 1.
Ainsi tous les éléments diagonaux de la forme normale de Smith de la matrice
XI − Cpi
sont égaux à 1, sauf le dernier qui lui est égal au déterminant de la
matrice XI − Cpi
, c’est-à-dire à pi
. Le fait qu’une matrice est équivalente à sa
forme normale de Smith termine la démonstration.
2.5 Forme normale de Jordan
La forme normale de Jordan d’une matrice A est une matrice triangulaire supé-
rieure dont les éléments diagonaux sont les racines du polynôme caractéristique de
la matrice A (c’est-à-dire les valeurs propres de A). Pour que cette forme existe, il
suffit que le polynôme caractéristique soit scindé à racines simples. Afin d’assurer
cette condition, nous choisissons de travailler sur un corps algébriquement clos F.
Nous avons montré dans la section précédente qu’une matrice était semblable
à sa forme normale de Frobenius. Nous allons ici dans un premier temps donner
une définition formelle de la forme normale de Jordan. Nous montrerons ensuite
que la forme normale de Frobenius d’une matrice est semblable à la forme normale
de Jordan de celle-ci. Par transitivité de la similitude nous aurons donc qu’une
matrice est semblable à sa forme normale de Jordan.2.5 Forme normale de Jordan 45
2.5.1 Définitions
On appelle bloc de Jordan la matrice de dimension n suivante :
J(λ, n) =
λ 1 0 . . . 0
0
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 0
.
.
.
.
.
.
.
.
. 1
0 . . . . . . 0 λ
Formellement, cela se définit simplement de la manière suivante :
Definition Jordan_block lam n : ’M[F]_n :=
\matrix_(i,j) (lam *+ (i == j) + (i.+1 == j)%:R).
La forme normale de Jordan est une matrice diagonale par blocs composée de
blocs de Jordan1
:
Definition Jordan_form n (A : ’M[R]_n.+1) :=
let sp := root_seq_poly (invariant_factors A) in
let sizes := [seq x.1 | x <- sp] in
let blocks n i := Jordan_block (nth (0,0) sp i).2 n.+1 in
diag_block_mx sizes blocks.
où la fonction root_seq_poly prend en argument une séquence de polynômes et
retourne la concaténation des séquences des paires multiplicité/racine de chaque
polynôme de la séquence. Par exemple si on a la séquence de polynômes suivante :
[:: (’X - (sqrt 2))^+ 4, (’X - (sqrt 2))^+ 4, (’X - 1)^+3 *(’X - 2)]
alors la séquence retournée par root_seq_poly sera :
[:: (4,(sqrt 2))] ++ [:: (4,(sqrt 2))] ++ [:: (3,1), (1,2)] =
[:: (4,sqrt2), (4,sqrt2), (3,1), (1,2)]
Dans la suite nous expliquons le passage de la forme normale de Frobenius
à celle de Jordan. Cela permettra de mieux comprendre la définition donnée cidessus.
2.5.2 De Frobenius à Jordan
Soit A une matrice à coefficients dans un corps clos F. Nous avons déjà prouvé
que la matrice A est semblable à sa forme normale de Frobenius. Nous allons
maintenant montrer que la forme normale de Frobenius de A est semblable à sa
forme normale de Jordan. Ce qui nous permettra de montrer le lemme suivant :
Lemma Jordan n (A : ’M[F]_n.+1) : similar A (Jordan_form A).
La preuve de ce lemme utilise deux résultats intermédiaires. Le premier résultat
intermédiaire est le lemme suivant :
1voir 1.1.1 et 1.1.5 pour les notations.46 Forme de Jordan d’une matrice
Lemme 2. Soit q un polynôme, soit (qi)1≤i≤m une famille de polynômes unitaires
premiers entre eux deux à deux telle que q = q1 . . . qm, alors la matrice Cq est
semblable à la matrice :
Cq1
.
.
.
0
0
.
.
.
Cqm
Montrons d’abord ce lemme pour m = 2. Soit donc deux polynômes unitaires
q1 et q2 premiers entre eux, et soit q = q1q2. Nous voulons montrer que la matrice
Cq est semblable à la matrice :
Cq1 0
0 Cq2
!
Là encore nous utilisons le théorème fondamental, pour se ramener à montrer
l’équivalence entre XI − Cq et la matrice :
XI − Cq1 0
0 XI − Cq2
!
D’après ce que nous avons déjà vu cela revient à montrer que la matrice
1
.
.
.
1
q
est équivalente à la matrice
1
.
.
.
1
q1
0
0
1
.
.
.
1
q2
Autrement dit, il faut montrer que le seul facteur invariant de la matrice cidessus
est le polynôme q. Pour cela nous allons utiliser une fois de plus le lemme
Smith_gcdr_spec. En effet, pour tous les ordres k strictement plus petit que la
taille de la matrice ci-dessus, on peut trouver un mineur principal égal à q1, et un
autre égal à q2, et comme q1 et q2 sont premiers entre eux, le pgcd des mineurs
d’ordre k est égal à 1. Donc les éléments diagonaux de la forme normale de Smith2.5 Forme normale de Jordan 47
de la matrice ci-dessus sont donc tous égaux à 1, sauf le dernier qui correspond
au déterminant de la matrice ci-dessus qui est q1q2 = q. Le lemme général en
découle directement par récurrence.
Le deuxième résultat intermédiaire est celui-ci :
Lemme 3. Soit K un corps. Soit λ ∈ K et n ∈ N. alors la matrice C(X−λ)n est
semblable à la matrice J(λ, n).
Ici nous pouvons directement donner la matrice de passage P définie comme
suit :
Pij =
j − 1
n − i
!
λ
(i+j)−(n+1)
Mais la vérification formelle est assez longue. Sinon nous pouvons utiliser une
nouvelle fois le théorème fondamental, et montrer que XI−C(X−λ)n est équivalente
à la matrice XI − J(λ, n). D’après ce que nous savons déjà sur les matrices
compagnes, nous voulons montrer que la matrice :
1
.
.
.
1
(X − λ)
n
est équivalente à la matrice :
X − λ −1 0 . . . 0
0
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
.
. 0
.
.
.
.
.
.
.
.
. −1
0 . . . . . . 0 X − λ
Ici encore, nous allons utiliser le lemme Smith_gcdr_spec. En effet, pour tout
k < n, nous pouvons trouver dans la matrice ci-dessus un mineur d’ordre k égal à
(−1)k
, et donc associé à 1. Donc par les mêmes raisonnement que précédemment,
le seul facteur invariant de la matrice ci-dessus est (X − λ)
n
.
Maintenant nous pouvons passer à la preuve de la similitude entre les formes
normales de Frobenius et de Jordan d’une matrice.
Comme nous sommes sur un corps clos, alors chaque facteur invariant pi de
la matrice A peut se décomposer comme suit :
pi =
Ymi
j=1
(X − λij )
µij
où les λij sont les racines de pi et les µij leur multiplicité.48 Forme de Jordan d’une matrice
Donc d’après le lemme 2 montré ci-dessus, chaque bloc Cpi de la forme normale
de Frobenius est semblable à la matrice :
C(X−λi1)
µi1
.
.
.
0
0
.
.
.
C(X−λimi
)
µimi
et d’après le lemme 3, chacun des blocs C(X−λij )
µij de la matrice ci-dessus est
semblable au bloc de Jordan J(λij , µij ).
Les paires (λij , µij ) sont les paires qui se trouvent dans la séquence retournée
par la fonction root_seq_poly appliquée à la séquence des facteurs invariants.
Cela explique la définition de la forme normale de Jordan donnée plus haut, et
démontre aussi que la forme normale de Frobenius de A est semblable à la forme
normale de Jordan de A.
2.5.3 Diagonalisation
En plus de la forme normale de Jordan, la théorie des facteurs invariants permet de
donner également un théorème de diagonalisation. Une matrice est diagonalisable,
c’est-à-dire semblable à une matrice diagonale, si son polynôme minimal est scindé
et à racines simples. Nous allons voir ici comment nous prouvons ce résultat.
Commençons par montrer le théorème suivant :
Théorème 4. Soit A une matrice à coefficients dans un corps. Si les polynômes
p1 . . . pk sont les facteurs invariants de la matrice A tels que p1 | p2 | . . . | pk,
alors le polynôme pk est le polynôme minimal de la matrice A.
Soit donc A une matrice à coefficients dans un corps. Comme la matrice A
et la forme normale de Frobenius de A sont semblables, ces deux matrices ont
le même polynôme minimal. Donc montrer que pk est le polynôme minimal de
A revient à montrer que pk est le polynôme minimal de la forme normale de
Frobenius de A.
Pour cela, nous allons montrer d’une part que pk est un polynôme annulateur
de la forme normale de Frobenius de A, et d’autre part que pk divise n’importe
quel polynôme annulateur de la forme normale de Frobenius de A.
Un polynôme p est annulateur de la matrice A si p(A) = 0. Cela peut s’exprimer
formellement grâce à la fonction horner_mx de la bibliothèque SSReflect
comme suit :
horner_mx A p = 0
Dans cette preuve, nous utiliserons le fait qu’appliquer un polynôme à une matrice
diagonale par blocs revient à appliquer le polynôme à chacun des blocs. Ce qui
s’exprime formellement de la façon suivante.2.6 Conclusion 49
Lemma horner_mx_diag_block (p : {poly R}) s F :
s != [::] ->
horner_mx (diag_block_mx s F) p =
diag_block_mx s (fun n i => horner_mx (F n i) p).
Donc pour montrer que le polynôme pk annule la forme normale de Frobenius
de A, il faut et il suffit que pk annule chaque matrice compagne des facteurs
invariants.
Soit donc pi un facteur invarant de la matrice A. D’après les propriétés des
matrices compagnes, nous savons que pi est le polynôme minimal de la matrice
Cpi
. De plus comme les facteurs invariants se divisent successivement, nous savons
également que pi
| pk. Donc pk est un polynôme annulateur de Cpi
.
Maintenant il reste à montrer que pk divise tous les polynômes annulateurs
de la forme normale de Frobenius de A.
Soit donc Q un polynôme annulateur de la forme normale de Frobenius de A.
Alors nous savons que Q est un polynôme annulateur de chacun des blocs de la
forme normale de Frobenius de A. En particulier Q annule Cpk
, or nous savons
également que pk est le polynôme minimal de la matrice Cpk
. Donc pk | Q.
Le polynôme pk étant un polynôme annulateur de la forme normale de Frobenius
de A qui divise tous les autres polynômes annulateurs est donc le polynôme
minimal de la forme de Frobenius de A et donc de A.
Ainsi nous avons d’une part que le polynôme pk est le polynôme minimal de la
matrice A, et d’autre part que tous les facteurs invariants divisent pk. Autrement
dit tous les facteurs invariants de la matrice A divisent son polynôme minimal.
Donc si le polynôme minimal de A est scindé à racines simples, alors c’est aussi le
cas des facteurs invariants. Or la taille des blocs de la forme normale de Jordan
de A sont les multiplicités des racines des facteurs invariants. Donc dans le cas
où le polynôme minimal de A est scindé à racines simples, tous les blocs de la
forme normale de Jordan de la matrice A sont de taille 1, c’est donc une matrice
diagonale. Ce qui nous donne le théorème suivant :
Lemma ex_diagonalization n (A : ’M[R]_n.+1) :
uniq (root_seq (mxminpoly A)) ->
{s | similar A (diag_mx_seq n.+1 n.+1 s)}.
où root_seq est la fonction qui retourne la séquence des racines d’un polynôme
et uniq est un prédicat booléen qui prend la valeur true si la séquence passée en
argument n’a pas de doublons.
2.6 Conclusion
Nous avons utilisé ici les matrices de la bibliothèque SSReflect. Le type de ces
matrices dépend de leurs dimensions, et cela a posé quelques problèmes. Cependant
nous avons vu qu’il y avait des outils (comme conform_mx) qui ont permis
de résoudre certains de ces problèmes.50 Forme de Jordan d’une matrice
Au départ, pour prouver certains lemmes de similitude, nous donnions directement
les matrices de passages, et nous avions de longues preuves faites de
traitements par cas exhaustifs. L’idée d’utiliser de manière assez systématique le
théorème fondamental et le lemme Smith_gcdr_spec à grandement simplifié les
preuves.
Ce travail, en plus de la formalisation de la forme normale de Jordan d’une
matrice, a apporté une bibliothèque sur les matrices diagonales par blocs, sur les
matrices compagnes, et sur les propriétés de similitude et d’équivalence de matrices.
Ce sont des concepts importants de l’algèbre linéaire utilisés dans d’autres
contextes mathématiques que celui de ce chapitre.
Nous avons aussi montré la formalisation de la forme normale de Frobenius
d’une matrice. L’avantage de cette forme normale est que ses coefficients sont
dans le même corps que les coefficients de la matrice de départ. Contrairement à
la forme de Jordan, où l’on peut avoir des coefficients dans la clôture algébrique.
2.7 Travaux reliés
Le développement de la forme normale de Smith que nous avons utilisé dans
ce chapitre fait parti d’un projet qui s’appelle CoqEAL(Coq Efficient Algebra
Library)1
. Le but de ce projet est de faire des algorithmes effectifs d’algèbre
linéaire en utilisant l’extension SSReflect de Coq.
Dans les autres assistants de preuve, il existe d’autres travaux qui ont été
faits sur les matrices. En HOL, les matrices sont vues comme des vecteurs de
vecteurs [23]. En ACL2 elles sont représentées soit par des listes de vecteurs de
même dimensions [49] soit par des tableaux [17]. En Isabelle, ce sont des fonctions
telles que l’ensemble des images non nulles de ces fonctions soit fini [36].
À ma connaissance, seul l’assistant de preuve Mizar possède des travaux sur
les matrices diagonales par blocs et sur la forme de Jordan d’une matrice [41].
Mizar est un assistant de preuve basé sur la théorie des ensembles contrairement
à Coq qui est basé sur la théorie des types.
En Mizar, une séquence finie est une fonction dont le domaine de définition
est l’ensemble des entiers de 1 à n pour un certain n ∈ N. Une matrice M à m
lignes et n colonnes est une séquence finie de séquences finies de longueur m tel
que toute séquence finie de l’image de M soit de longueur n [27].
Une matrice diagonale par blocs est construite à partir d’une séquence finie
de matrices carrées. Elle est définie comme étant la matrice dont l’élément (i, j)
est 02
si l’on se trouve en dehors des blocs et l’éléments f(i), g(j) d’une matrice
de la séquence sinon (pour certaines fonctions f et g) [39].
1http://www.maximedenes.fr/content/coqeal-coq-effective-algebra-library
2En fait, la définition de Mizar de matrice diagonale par block permet de remplir la matrice
hors des blocs diagonaux par un élément d que l’on peut passer en paramètre.Chapitre 3
Topologie
Dans ce chapitre, nous allons présenter un résultat important de topologie géné-
rale qui est le théorème de Bolzano-Weierstraß. Ce théorème porte sur les valeurs
d’adhérence des suites dont les valeurs sont dans un ensemble compact.
Tous le travail sur la topologie et sur la théorie des ensembles est formalisé
dans un cadre fortement classique, c’est-à-dire avec l’axiome du tiers exclu et
l’axiome du choix. Nous avons besoin de ces axiomes pour prouver le théorème
de Bolzano-Weierstraß.
Il existe dans la bibliothèque standard de Coq un fichier Rtopology.v1 qui
contient déjà certaines notions que nous allons présenter dans ce chapitre. Mais
ces notions ne sont définies que pour les réels de Coq. Nous présentons ici un
travail plus général.
Nous commencerons par voir quelques points de la théorie des ensembles dont
nous aurons besoin pour la formalisation de la topologie générale. Nous verrons
ensuite comment sont définies les structures d’espaces métriques et topologiques,
et nous terminerons par une présentation du théorème.
3.1 Théorie des ensembles
Pour parler d’ensembles ouverts, fermés ou compacts, il faut d’abord définir ce
qu’est un ensemble. La notion d’ensemble utilisée dans cette formalisation est
celle que l’on peut trouver dans la bibliothèque Sets de la bibliothèque standard
de Coq2
, à savoir qu’un ensemble d’éléments de type T est identifié à un prédicat
de type T -> Prop. Cependant nous n’utiliserons pas la théorie des ensembles
ainsi développée dans Coq, car par exemple les définitions d’union, d’intersection,
ou de complémentaire sur les ensembles sont intoduites explicitement à
l’aide de types inductifs, alors que ces notions peuvent être définies comme une
réinterprétation des opérateurs ”et”, ”ou”, ”non” de la logique propositionnelle.
L’égalité utilisée entre les ensembles est l’égalité par inclusion mutuelle, mais
1http://coq.inria.fr/distrib/current/stdlib/Coq.Reals.Rtopology.html
2http://coq.inria.fr/distrib/current/stdlib/52 Topologie
nous avons tout de même besoin de la propriété d’extensionnalité. Plutôt que
d’ajouter cette propriété comme axiome, nous allons voir comment faire en sorte
d’utiliser l’égalité ensembliste comme l’égalité de Leibniz. Nous nous attarderons
ensuite sur la définition de famille d’ensembles car nous en aurons besoin pour
définir ce qu’est un ensemble compact.
3.1.1 Réécriture
La tactique rewrite en Coq permet à partir d’une hypothèse de type x = y
(où = représente l’égalité de Leibniz) de changer des occurences de x par des
occurences de y et vice versa.
Si on remplace l’égalité de Leibniz par une relation d’équivalence, on peut
aussi utiliser la tactique rewrite si x et y apparaissent dans une fonction dont
on a montré qu’elle était compatible avec la relation d’équivalence, c’est-à-dire
que sa valeur ne dépend pas du représentant choisi dans la classe d’équivalence.
C’est ce que nous allons voir ici avec comme relation d’équivalence l’égalité entre
ensembles.
L’égalité entre ensembles est définie comme suit :
Variable T : Type.
Definition eqset (A B : T -> Prop) :=
forall x, x ’in A <-> x ’in B.
Notation "A =s B" := (eqset A B).
où x ’in A est une notation pour A x.
C’est une relation d’équivalence. Pour que le système Coq puisse la reconnaître
comme telle, il faut la déclarer de la manière suivante :
Add Relation _ eqset
reflexivity proved by eqset_refl
symmetry proved by eqset_sym
transitivity proved by eqset_trans
as eqset_rel.
où eqset_refl,eqset_sym, et eqset_trans sont respectivement les lemmes de re-
flexivité, symétrie et de transitivité de la relation eqset.
Puis il faut indiquer à Coq quelles sont les fonctions sous lesquelles on peut
réécrire avec la relation eqset, c’est-à-dire les fonctions qui sont compatibles avec
la relation eqset. Pour cela on utilise les mots clefs Add Morphism. Prenons comme
exemple l’inclusion. L’inclusion est définie comme suit :
Definition include (A B : T -> Prop) :=
forall x, x ’in A -> x ’in B.
Notation "A eqset ==> iff
as include_mor.
Proof.
...
Qed.
Une manière de lire la signature est que si deux ensembles vérifient la relation
eqset, et que deux autres ensembles vérifient également la relation eqset, alors
nous avons deux propositions d’inclusions qui vérifient la relation iff, autrement
dit qui sont équivalentes. Le système nous demande donc de prouver l’énoncé
suivant :
forall x y : T -> Prop,
x =s y -> forall x0 y0 : T -> Prop, x0 =s y0 -> (x y Prop;
F :> Ti -> T -> Prop
}.
Dans cette définition, il n’y a pas de dépendance entre la fonction F et l’ensemble
d’indices ind. Donc dans certaines définitions et certains lemmes, il faudra
préciser que l’on ne s’intéresse qu’aux indices appartenant à l’ensemble d’indices54 Topologie
de la famille. En effet, si nous avons un indice i : Ti qui n’appartient pas à l’ensemble
ind, alors F i est un ensemble qui n’appartient pas à la famille, et donc
on ne voudrait pas que cet ensemble soit pris en compte dans certaines preuves
ou définitions.
Les autres définitions dont nous aurons besoin pour la définition d’ensemble
compact sont celles de sous-famille, de famille finie et de recouvrement d’un ensemble
par une famille.
Une sous-famille est définie comme un prédicat qui prend deux familles, et qui
vérifie que l’ensemble d’indices de l’une est bien un sous-ensemble de l’ensemble
d’indices de l’autre, et que sur ce sous-ensemble d’indices commun, les ensembles
des deux familles sont les mêmes :
Definition sub_family f g :=
ind g f i =s g i.
Pour les familles finies, nous avons le choix entre définir un prédicat comme
pour les sous-familles, ou définir un type “famille finie”. Dans le premier cas, à
chaque usage d’une définition sur les familles finies, nous devrons fournir une
preuve que la famille passée en argument est finie. Alors que dans le second cas,
l’information qu’une famille est finie est donnée par le typage. Cette dernière
option permet d’avoir des définitions qui ne dépendent pas d’un terme de preuve.
Une famille est finie si son ensemble d’indices est un ensemble fini :
Definition finite_set (T1 : eqType) (A : T1 -> Prop) :=
exists s : seq T1, A =s (fun x => x \in s).
Structure finite_family := Ff {
fam :> family;
_ : finite_set (ind fam)
}.
Une fois que nous avons défini les familles, nous pouvons appliquer des opé-
rations dessus, comme l’union ou l’intersection des éléments d’une famille. Nous
donnons ici uniquement l’opération qui nous intéresse pour la définition de recouvrement
:
Definition union_fam (f : family) (x : T) :=
exists i, i ’in (ind f) /\ x ’in (f i).
Definition cover (A : T -> Prop) (f : family) := A Prop) -> Prop. L’union de tous les ensembles d’un
ensemble d’ensembles est définie comme suit :
Definition union_s (E : (T -> Prop) -> Prop)
(f : (T-> Prop) -> (T -> Prop)) (x : T) :=
exists A, A ’in E /\ x ’in (f A).
Par exemple, si E est un ensemble d’ensembles et f une fonction sur les
ensembles, alors union_s E f représente l’ensemble suivant :
[
A∈E
f(A)
Donc pour faire l’union des ensembles de E nous utiliserons la fonction identité
pour f.
On peut maintenant définir la structure d’espace topologique simplement
comme suit :56 Topologie
Structure Topologicalspace : Type := mkTS {
T_Space : Type;
open : (T_Space -> Prop) -> Prop;
_ : open {ø : T_Space};
_ : open {full : T_Space};
_ : forall (E : (T_Space -> Prop) -> Prop), E
open (union_s E id);
_ : forall A B, open A -> open B -> open (inter A B);
_ : forall A B, A =s B -> (open A <-> open B)
}.
Le dernier champ de la structure est la propriété d’extensionnalité pour les
ouverts. Les ouverts étant définis axiomatiquement, cette propriété utile ne peut
être démontrée, et a donc dû être ajoutée à la définition d’espace topologique.
Espace Métrique
Un espace métrique est un ensemble de points muni d’une distance. Il existe
déjà une définition de cette structure dans le fichier Rlimit.v de la bibliothèque
standard de Coq1
. Dans cette définition le type de retour de la fonction distance
est le type des réels de Coq. Ici on s’autorise à ce que ce soit une structure
ordonnée plus générale :
Structure Metricspace (Rn : numDomainType) := mkMS {
T_metric : Type.
dist : T_metric -> T_metric -> Rn;
_ : forall x y, 0 <= dist x y ;
_ : forall x y, dist x y = dist y x;
_ : forall x y, reflect (x = y) (dist x y == 0);
_ : forall x y z, dist x y <= dist x z + dist z y
}.
L’espace métrique prend en paramètre le type de retour de la distance dist.
Ce type de retour doit être une structure ordonnée. Au début ce paramètre n’existait
pas. Le type de retour de la fonction distance était directement le type des
réels de Coq. Le problème était que l’on ne pouvait pas déclarer la structure
numDomainType par exemple comme une instance de la structure d’espace mé-
trique. Car la fontion de distance que l’on définit pour cela utilise la fonction ‘|.|
dont le type de retour est une instance abstraite de la structure numDomainType
et non le type concret des réels de Coq. Mettre le type de retour de la fonction
distance en paramètre de la structure d’espace métrique permet d’implémenter la
structure d’espace métrique sur des types plus abstraits comme le type des corps
réels clos, des corps archimédiens, ou des complexes.
Pour un ensemble E de type Metricspace, on utilisera la notation suivante :
Notation d := (dist E).
1http://coq.inria.fr/distrib/current/stdlib/Coq.Reals.Rlimit.html3.2 Structures Topologiques 57
La principale notion utilisée pour étudier les propriétés métriques et topologiques
d’un espace métrique est la notion de boule. Une boule est un ensemble
défini à partir d’un élément de l’espace métrique qui sera appelé centre, et d’un
rayon représenté par un nombre strictement positif. Pour éviter d’avoir dans la
définition de boule une preuve que le rayon est strictement positif, on peut définir
un type des nombres strictement positifs comme suit :
Structure posDomain (T: numDomainType) :=
PosD { sort :> T ; _ : 0 < sort }.
Notation "{ ’posD’ T }" := (posDomain T).
Ceci permet de définir les boules comme suit :
Variable Rn : numDomainType.
Variable E : (MetricSpace Rn).
Definition open_ball (x: E) (r : {posD Rn}) (y : E) := d x y < r.
Notation "’’B’ ( x , r )" := (open_ball x r).
Nous allons voir maintenant comment inférer les instances de structures canoniques
avec les définitions ci-dessus. Les structures que nous définirons ensuite
contiendrons les mêmes axiomes. Ce qui changera sera seulement la façon d’implémenter
les structures.
3.2.2 Approche naïve
Pour déclarer dans le système Coq qu’un espace métrique possède canoniquement
une structure d’espace topologique il faut d’abord définir ce qu’est un ensemble
ouvert dans un espace métrique :
Variable Rn : numDomainType.
Variable E : (Metricspace Rn).
Definition open_met (A : E -> Prop) :=
forall x, x ’in A -> exists r, ’B(x,r) Prop) -> Prop;
_ : open . . .
_ : . . .
...
}.
Cette structure ne suffit pas, car comme le type de base n’est plus un champ
de la structure, lors de la déclaration de structure canonique, la projection vers
le type de base n’existera pas. Les projections enregistrées correspondent seulement
aux champs de la structure qui sont nommés. Nous allons donc définir une
deuxième structure qui va correspondre à notre type final d’espace topologique
(ou métrique) :
Notation class_of := mixin_of
Structure type := Pack {sort : Type; _ : class_of sort}.
Coercion sort : type >-> Sortclass.
La structure class_of est habituellement utilisée pour assurer l’héridité dans
les structures héréditaires. Comme ici nous n’avons pas d’hérédité, class_of est
seulement une notation utilisée pour des raisons d’uniformité des définitions.
Ces structures sont définies dans un module, par exemple ici dans le module
Topology. Ce qui fait qu’en dehors du module les noms des structures seront de
la forme Topology.type ce qui permet d’avoir des noms uniformes. Chacune de
ces nouvelles définitions sera utilisée avec les notations suivantes :
Notation topologyType := type.
Notation TopologyMixin := Mixin.
Notation TopologyType T m := (@Pack T m).
Nous avons donc séparé le type de base et les axiomes de la structure que nous
avons mis dans une boîte que nous avons appelée mixin_of. Cette boîte a été mise
dans une deuxième structure appelée type qui contient comme premier champ le
type sur lequel nous voulons déclarer l’instance, et comme deuxième champ la
boîte qui contient toutes les propriétés que doit vérifier le type en question.
Pour revenir au problème qui nous intéresse, avec ces nouvelles structures nous
allons déclarer l’instance canonique d’espace topologique à partir d’un espace
métrique :3.3 Bolzano-Weierstraß 61
Variable Rn : numDomainType.
Variable E : (espMetType Rn).
Definition EspMet_TopMixin := Eval hnf in
TopologyMixin empty_in_open_met full_in_open_met . . .
Definition EspMet_TopType := Eval hnf in
TopologyType E EspMet_TopMixin.
Canonical EspMet_TopMixin.
Canonical EspMet_TopType.
Nous déclarons ensuite de la même manière que l’ensemble des nombres réels de
Coq (représenté par R) a une structure d’espace métrique :
Definition EspMet_RMixin := EspMetMixin R_dist_pos . . .
Definition EspMet_R :=
Eval hnf in EspMetType R R EspMet_RMixin.
...
Et maintenant pour dire que le type R des réels de Coq a une structure d’espace
topologique, nous allons utiliser la fonction TopologyType. Comme nous voulons
que la projection se fasse directement sur R, nous allons donner comme premier
argument R. Le deuxième argument doit être la structure mixin_of, la notation
EspMet_TopMixin permet justement de construire cette structure. Nous pouvons
donc déclarer la structure d’espace topologique sur R directement comme ceci :
Definition EspTop_R := TopologyType R (EspMet_TopMixin EspMet_R).
Canonical EspTop_R.
Bien que dans cette sous-section nous mentionnons les espaces normés et euclidiens
(avec un produit scalaire), seules les structures d’espaces métriques et topologiques
sont implémentées. La formalisation des espaces normés et euclidiens
pourra faire l’objet de travaux futurs. Nous allons maintenant nous intéresser à la
formalisation de certains concepts de topologie générale qui ont permis d’énoncer
et de prouver formellement le théorème de Bolzano-Weierstraß.
3.3 Bolzano-Weierstraß
Le théorème de Bolzano-Weierstraß est un résultat de topologie générale dont la
forme la plus utilisée est la suivante :
Bolzano-Weierstraß (dans un espace métrique). Toute suite à valeurs dans un
compact admet une sous-suite convergente.
La version du théorème formalisée est sa forme plus générale qui est vraie
pour un espace topologique quelconque :
Bolzano-Weierstraß (dans un espace topologique). Toute suite à valeurs dans
un compact admet une valeur d’adhérence.62 Topologie
En effet, dans un espace métrique les valeurs d’adhérence sont les limites de
sous-suites.
Nous donnons dans un premier temps quelques définitions de topologie gé-
nérale, principalement celles dont nous aurons besoin (comme la compacité par
exemple). Nous verrons ensuite quelques notions sur les suites, et enfin nous parlerons
de la formalisation du théorème.
3.3.1 Topologie générale
Nous faisons ici quelques rappels des notions utilisées par la suite.
Une première notion que nous utiliserons est celle de voisinage. Soit x un point
d’un espace topologique T , alors un ensemble V est un voisinage du point x si
V contient un ouvert qui contient x, autrement dit s’il existe un ensemble ouvert
qui contient x et qui est inclus dans V :
Definition neighbourhood (V : T -> Prop) (x : T) :=
exists A, [/\ x ’in A, open A & A y -> exists V1, exists V2,
[/\ neighbourhood V1 x, neighbourhood V2 y & (inter V1 V2) Prop) :=
forall Ti (f : family T Ti),
open_family f -> cover K f ->
exists g : finite_family T Ti, sub_family f g /\ cover K g.
Definition compact (K : T -> Prop) := separated /\ quasi_compact K.
Nous allons maintenant définir les suites.
3.3.2 Les suites
Nous parlerons ici de sous-suites et nous rappellerons en donnant les définitions
formelles ce qu’est une valeur d’adhérence et la convergence d’une suite.
Une suite d’éléments de type T est représentée par un élément dont le type est
nat -> T. Soit u = (un)n∈N une suite, alors toutes les sous-suites de u peuvent3.3 Bolzano-Weierstraß 63
s’exprimer sous la forme (uϕ(n))n∈N où ϕ est une fonction strictement croissante
de N → N. Donc une sous-suite est principalement la donnée d’une fonction ϕ
qui vérifie les bonnes propriétés :
Structure sub_seq : Type := mkss
{
phi :> nat -> nat;
grow : forall m n, (m < n)%N -> (phi m < phi n)%N
}.
Formellement, étant donné g : sub_seq et une suite Un : nat -> T, alors Un \o g
(où \o est la composition) désigne une sous-suite de Un.
La formalisation des définitions de convergence et de valeur d’adhérence est
une retranscription directe des définitions mathématiques. Une suite (un)n∈N
converge vers une limite l si pour tout voisinage V de l on peut trouver un
rang à partir duquel tous les éléments de la suite sont dans V . Et l est une valeur
d’adhérence si pour tout voisinage V de l, pour chaque rang N on peut trouver
un élément de la suite dans V au-delà du rang N :
Definition Un_cvg (Un : nat -> T) (l : T) :=
forall V, neighbourhood V l ->
exists N : nat, forall n, N <= n -> (Un n) ’in V.
Notation "Un >->> l" := (Un_cvg Un l).
Definition cluster_point (Un : nat -> T) (l : T) :=
forall V, neighbourhood V l ->
forall N : nat, exists n, N <= n /\ (Un n) ’in V.
À ce point, nous avons toutes les définitions utiles à l’énoncé et à la preuve
du théorème de Bolzano-Weierstraß, dont nous décrivons la formalisation dans la
section suivante.
3.3.3 Le théorème
Le théorème de Bolzano-Weierstraß s’énonce formellement sur un espace topologique
quelconque de la manière suivante :
Lemma Bolzano_Weierstrass : forall (Un : nat -> T) K, compact K ->
(forall n, (Un n) ’in K) -> exists l, l ’in (cluster_point Un).
Nous allons dans un premier temps voir les grandes lignes de la preuve de ce
théorème.
Pour utiliser le théorème sous sa forme plus usuelle dans un espace métrique,
nous montrerons ensuite que dans un espace métrique, les valeurs d’adhérence
d’une suite sont des limites de ses sous-suites.
Preuve dans un espace topologique
La preuve formelle du théorème suit les mêmes étapes que la démonstration
mathématique, et sa formalisation n’a pas posé de problème majeur. Les grands64 Topologie
points de la démonstration du théorème sont les suivants :
Soit K un ensemble compact et u = (un)n∈N une suite dont tous les termes
sont dans l’ensemble K. Supposons par l’absurde que la suite u n’ait aucune valeur
d’adhérence. Cela signifie que pour n’importe quel point x ∈ K on peut trouver
un voisinage (ouvert) Vx de x qui à partir d’un certain rang nx ne contient aucun
élément de la suite. La famille (Vx)x∈K recouvre l’ensemble K, comme K est
compact, alors on peut extraire une sous-famille finie (Wi)i∈{0...k} avec Wi = Vxi
qui recouvre K. Pour chaque Wi on a un rang nxi
au-delà duquel la suite u n’a
aucun terme qui appartient à l’ensemble Wi
. Donc si l’on note N le maximum
de tous les nxi
, uN n’appartient à aucun ensemble de la famille W. Ce qui est
absurde car uN est dans l’ensemble K et que la famille W forme un recouvrement
de K.
Preuve dans un espace métrique
Pour montrer la version métrique du théorème de Bolzano-Weierstraß, nous montrons
que dans les epaces métriques, les valeurs d’adhérence d’une suite sont les
limites de ses sous-suites.
Dans un espace métrique, nous avons une distance, et cela nous permet de
définir pour un point x et un réel positif r donnés, la boule de centre x et de
rayon r, notée généralement B(x, r), dont nous rappelons la définition formelle :
Definition open_ball (x : E) (r : {posD Rn}) (y : E) := d x y < r.
Notation "’’B’ ( x , r )" := (open_ball x r).
où d est la distance de l’espace métrique.
Ainsi, pour la plupart des définitions comme la convergence ou les valeurs
d’adhérence d’une suite, on peut remplacer de manière équivalente les voisinages
par des boules.
Comme nous l’avons vu précédemment, les définitions formelles sont principalement
de simples retranscriptions des définitions mathématiques. Donc dans
la suite, nous utiliserons pour plus de lisibilité les notations mathématiques.
Soit donc u = (un)n∈N une suite, et l une valeur d’adhérence de u. Le fait
d’enlever le premier terme d’une suite ne change pas les valeurs d’adhérence,
donc l est aussi une valeur d’adhérence de la suite (un+1)n∈N, autrement dit :
∀V ∈ Vois(l), ∀N, ∃n, N ≤ n et un+1 ∈ V
où Vois(l) désigne l’ensemble des voisinages de l. Comme nous l’avons dit plus
haut, ceci est équivalent à :
∀k ∈ N
∗
, ∀N, ∃n, N ≤ n et un+1 ∈ B(l, 1
k
) (1)
Nous voulons maintenant montrer que la suite u a une sous-suite qui converge
vers l, autrement dit nous voulons trouver une fonction ϕ : N → N strictement
croissante telle que la suite (uϕ(n))n∈N converge vers l. Nous allons donc dans un
premier temps “construire” la fonction ϕ.3.3 Bolzano-Weierstraß 65
Pour construire la fonction, nous allons utiliser le lemme functional_choice
que l’on trouve dans la bibliothèque standard de Coq1
. Ce lemme s’énonce ainsi :
(∀x ∈ A, ∃y ∈ B, P(x, y)) ⇔ (∃f : A → B, ∀x ∈ A, P(x, f(x)))
Si nous appliquons ce lemme une première fois dans l’expression (1) nous
obtenons :
∀k ∈ N
∗
, ∃f, ∀N, N ≤ f(N) et uf(N)+1 ∈ B(l, 1
k
)
Nous pouvons utiliser le lemme functional_choice une seconde fois pour obtenir :
∃G, ∀k ∈ N
∗
, ∀N ∈ N, N ≤ Gk(N) et uGk(N)+1 ∈ B(l, 1
k
)
où Gk(N) est une notation pour (G(k))(N).
Nous avons donc une fonction G du type nat->nat->nat qui vérifie :
∀k ∈ N
∗
, ∀N ∈ N, N ≤ Gk(N) et uGk(N)+1 ∈ B(l, 1
k
)
ou de manière équivalente :
∀k ∈ N
∗
, ∀N ∈ N, N < Gk(N) + 1 et uGk(N)+1 ∈ B(l, 1
k
) (2)
Ici nous avons fait apparaître deux choses. La première est l’inégalité N <
Gk(N) + 1 et la deuxième est uGk(N)+1 qui est un bon candidat pour définir une
sous-suite. Le problème c’est que l’expression Gk(N) + 1 dépend de deux entiers
k et N. Mais l’expression (2) est vraie quelque soit N, donc en particulier elle
est vraie pour tous les N de la forme ϕ(k) pour une certaine fonction ϕ. Ainsi en
remplaçant dans l’inégalité les occurences de N par ϕ(k), où ϕ est une fonction
que l’on cherche à définir, nous obtenons d’une part :
∀k, ϕ(k) < Gk(ϕ(k)) + 1
Donc en définissant récursivement la fonction ϕ de manière à ce que ϕ(k + 1) =
Gk(ϕ(k)) + 1, nous avons ∀k, ϕ(k) < ϕ(k + 1) et donc ϕ est une fonction strictement
croissante. Et d’autre part, d’après (2) la fonction ϕ vérifie :
∀k ∈ N
∗
, uϕ(k+1) ∈ B(l, 1
k
) (3)
On peut définir la fonction ϕ formellement comme suit :
Fixpoint phi (m : nat) : nat :=
match m with
| 0 => G 0 0
| m’.+1 => (G m’ (phi m’)).+1
end.
1http://coq.inria.fr/distrib/current/stdlib/Coq.Logic.IndefiniteDescription.html66 Topologie
Nous avons donc construit une fonction ϕ strictement croissante. Maintenant,
il ne nous reste plus qu’à prouver que la suite uϕ(n) converge vers l, ainsi nous
aurons montré que l est une limite d’une sous-suite de u.
Comme nous l’avons déjà dit précédemment, on peut remplacer les voisinages
par des boules de manière équivalente dans la définition de convergence dans un
espace métrique. Nous voulons donc montrer que :
∀t ∈ N
∗
, ∃N ∈ N, ∀n, N ≤ n ⇒ uϕ(n) ∈ B(l, 1
t
)
Soit t ∈ N
∗
, alors montrons que N = t + 1 convient. Soit n ∈ N tel que
t + 1 ≤ n, il nous reste à montrer que uϕ(n) ∈ B(l, 1
t
).
Comme t+1 ≤ n et que t ∈ N
∗ alors n−1 ∈ N
∗
, donc d’après (3) nous avons :
uϕ(n) ∈ B(l, 1
n−1
)
Comme t + 1 ≤ n alors t ≤ n − 1, ce qui implique que 1
n−1 ≤
1
t
, et donc
B(l, 1
n−1
) ⊂ B(l, 1
t
), autrement dit :
uϕ(n) ∈ B(l, 1
t
)
Nous avons donc montré que dans un espace métrique, les valeurs d’adhérences
d’une suite sont les limites de ses sous-suites. La preuve du résultat précédent
permet d’utiliser la version de Bolzano-Weierstraß dans un espace métrique.
En fait, dans un cadre plus général, pour montrer ce résultat il suffit d’avoir
pour chaque point l de l’espace topologique une base dénombrable de voisinages
(dans les espaces métriques ce sont les boules de centre l et de rayon 1
k
).
3.4 Conclusion
La topologie générale se formalise plutôt bien. Comme nous l’avons vu, la plupart
des définitions sont naïves, et les preuves suivent le même schéma que les
preuves mathématiques. La logique utilisée est la logique classique. D’une part
cela permet d’avoir une théorie des ensembles avec les bonnes propriétés (comme
le fait qu’un ensemble soit égal au complémentaire de son complémentaire par
exemple), d’autre part le théorème de Bolzano-Weierstraß est un résultat de logique
classique.
La formalisation de la topologie a permis de prouver le théorème de BolzanoWeierstraß,
mais aussi de munir les structures ordonnées de la bibliothèque SSReflect
d’une topologie, et de montrer des résultats dessus dont nous aurons
également besoin par la suite.
Il existe déjà un théorème de Bolzano-Weierstraß dans la bibliothèque standard
de Coq, mais prouvé uniquement sur les nombres réels. Puisque nous l’avons
prouvé dans un cadre plus général, cela fait que l’on pourra l’utiliser sur n’importe
quel type que l’on aura muni d’une topologie. En particulier, par la suite,
nous aurons besoins de l’utiliser sur l’espace des matrices.3.5 Travaux reliés 67
Cependant, pour utiliser ce théorème il faut d’abord montrer qu’un certain
ensemble est compact. L’argument souvent utilisé pour prouver la compacité d’un
ensemble est de montrer qu’il est fermé et borné. Mais pour prouver ce résultat
il faut être dans un espace vectoriel normé de dimension finie ou dans un espace
euclidien. Comme nous l’avons vu, pour l’instant seules les structures d’espaces
métriques et topologiques sont implémentées, il serait donc intéressant par la
suite d’implémenter également les structures d’espaces normés et euclidiens.
3.5 Travaux reliés
Les travaux de formalisation de topologie générale sont nombreux et ont été faits
dans de nombreux assistants de preuve comme Mizar [38], Isabelle [26], PVS [30],
etc. Plus particulièrmeent dans l’assistant de preuve HOL Light on trouve une
preuve du théorème de Bolzano-Weierstraß dans le cas particulier des espaces
métriques [23].
Il existe également un début de formalisation de topologie générale en Coq,
dans un projet qui s’appelle Coqtail1
.
Il existe aussi des travaux de formalisation qui ont une approche constructive
de la topologie. Cela la s’appelle la topologie formelle, ou la topologie sans points.
On pourra par exemple cité les travaux de Giovanni Sambin [43] dont une partie
des travaux a été formalisée avec l’assistant de preuve Matita [2].
1http://coqtail.sourceforge.netChapitre 4
Perron-Frobenius
Le théorème de Perron-Frobenius est un théorème d’algèbre linéaire à propos du
rayon spectral d’une matrice réelle dont les coefficients sont positifs. Les principales
applications de ce théorème sont en théorie des graphes, ou en probabilité
avec les chaînes de Markov. Le théorème est utilisé sur les matrices d’adjacence
d’un graphe ou sur des matrices stochastiques, ce sont des matrices à coefficients
positifs [48]. On utilise également le théorème de Perron-Frobenius dans l’étude
des matrices dont les coefficients sont des intervalles [32, 42].
La partie du théorème de Perron-Frobenius à laquelle on s’intéresse est celle
qui dit que le rayon spectral d’une matrice à coefficients positifs est une valeur
propre de la matrice, et que cette valeur propre a un vecteur propre associé dont
les coefficients sont positifs.
Cette preuve se fait en deux étapes. Dans une première étape on démontre le
théorème pour les matrices à coefficients strictement positifs. Dans une deuxième
étape on utilise un argument de densité pour prouver le résultat sur les matrices
à coefficients positifs ou nuls. Pour prouver ce théorème nous devrons utiliser les
notions de topologie, et la forme normale de Jordan d’une matrice vues dans les
deux chapitres précédents.
Dans un premier temps, nous allons voir dans ce chapitre la formalisation
de la première étape de la preuve. Nous verrons d’abord les définitions de base
dont nous aurons besoin par la suite. Ensuite nous présenterons une preuve du
théorème pour le cas des matrices strictements positives pour mettre en évidence
les résultats intermédiaires dont nous aurons besoin et dont nous montrerons la
formalisation ensuite.
Dans un second temps, nous expliquerons le chemin qu’il reste à faire pour la
formalisation de la deuxième partie de la preuve.70 Perron-Frobenius
4.1 Rappels et définitions
4.1.1 Minimum et maximum
Nous aurons besoin de définir le maximum d’une famille d’éléments pour la définition
du rayon spectral d’une matrice et du minimum pour la preuve du théorème.
C’est pourquoi nous commençons par définir ces deux notions dans cette section.
Minimum
Pour exprimer le minimum d’une famille d’éléments, on pourrait essayer d’utiliser
les opérateurs de familles de la façon suivante1
:
\big[minr/id]_(i <- s) F i
Le problème avec cette façon de faire c’est que id doit être un élément neutre
pour le minimum. En effet, nous avons vu que, par exemple, pour une séquence
[:: a, b, c] l’expression ci-dessus est équivalente à :
minr a (minr b (minr c id))
et donc si a, b et c sont tous plus grand que l’élément id alors la valeur retournée
sera id et non le plus petit des trois éléments a, b et c. C’est la raison pour
laquelle id doit être un élément neutre, or dans notre cas la fonction minimum
n’a pas d’élément neutre.
Pour les besoins de la preuve, nous avons seulement besoin d’une fonction
qui retourne un élément de la famille qui soit plus petit que tous les autres. Le
minimum est donc simplement défini comme suit :
Fixpoint min_seq s :=
match s with
| [::] => 0
| [:: x] => x
| x :: s’ => minr x (min_seq s’)
end.
On traite à part le cas où la séquence ne contient qu’un seul élément pour que
l’appel récursif de la fonction ne se fasse jamais sur une séquence vide. À partir
de cette définition, nous pouvons définir une fonction minimum plus proche de
ce qui est fait dans la bibliothèque SSReflect sur les opérateurs de familles :
Definition min_fT (I : finType) (F : I -> R) :=
min_seq [seq F i | i <- index_enum I].
Cette définition respecte les deux propriétés dont nous avons besoin, à savoir :
Lemma min_fT_le (I : finType) F (i : I) : min_fT F <= F i.
Lemma ex_min_fT (I : finType) F (_ : I) : {k | min_fT F = F k}.
1voir 1.2.5 et 1.2.10 pour les notations.4.1 Rappels et définitions 71
Maximum
Pour définir le maximum d’une famille d’éléments, nous pouvons contourner le
problème de l’élément neutre du fait que dans notre contexte, nous prenons toujours
le maximum d’une famille d’éléments positifs. Nous pouvons donc choisir
zéro comme élément neutre et utiliser les opérateurs de familles :
\big[(@maxr R)/0%R]_i F i
L’expression ci-dessus sera cachée derrière la notation :
\maxr_i F i
4.1.2 Éléments d’algèbre linéaire
Soit A une matrice carrée de dimension n à coefficients dans un corps. Le noyau de
la matrice A, noté ker A, est l’ensemble des vecteurs tels que Ax = 0 c’est-à-dire :
x ∈ ker A ⇔ Ax = 0
Le noyau d’une matrice est fourni par une fonction de la bibliothèque SSReflect,
noté kermx A.
Si x est un vecteur non nul qui appartient au noyau de la matrice A, alors A
n’est pas inversible. En effet, si A était inversible nous aurions :
x = I ∗ x = (A
−1
∗ A)x = A
−1
(Ax) = A
−1
∗ 0 = 0
ce qui contredit le fait que x soit non nul. La matrice A n’étant pas inversible,
comme nous sommes sur des matrices à coefficients dans un corps, nous avons
det A = 0.
Soit maintenant x et λ respectivement un vecteur colonne non nul et un
scalaire tels que l’on ait la relation :
Ax = λx
Alors on dit que λ est une valeur propre de la matrice A et que x est un vecteur
propre associé à la valeur propre λ.
La relation ci-dessus peut être réécrite comme suit :
(A − λI)x = 0 (1)
Donc si λ est une valeur propre de la matrice A alors x est un vecteur non nul
appartenant au noyau de la matrice (A−λI). C’est ainsi qu’est définie le prédicat
booléen qui caractérise les valeurs propres dans la biblothèque SSReflect :
Variables (T : fieldType) (n : nat) (A : ’M[T]_n).
Definition eigenvalue lam := kermx (A - lam%:M) != 0.72 Perron-Frobenius
Remarque 2. Le prédicat eigenvalue ne représente que l’ensemble des valeurs
propres qui sont de type T. Donc par exemple si T est le corps des réels, alors
les seules valeurs qui vérifieront le prédicat seront les valeurs propres réelles de
la matrice A, et si lam est une valeur propre complexe de la matrice A alors
eigenvalue A lam sera mal typé.
L’égalité (1) indique également que si λ est une valeur propre de la matrice
A alors det(A − λI) = 0 d’après ce que l’on a vu juste avant. C’est-à-dire que λ
est une racine du polynôme caractéristique de la matrice A. Nous pouvons donc,
dans un corps algébriquement clos, définir la séquence des valeurs propres d’une
matrice :
Variable F : closedFieldType.
Definition eigen_seq n (A : ’M[F]_n) := root_seq (char_poly A).
où la fonction root_seq retourne la séquence des racines d’un polynôme. Par
exemple, si p est le polynôme (’X-1)^+2 * (’X-2) alors root_seq p sera la sé-
quence [:: 1, 1, 2] (ou une de ses permutations).
Le lemme suivant montre que, sur un corps algébriquement clos, les deux
définitions ci-dessus expriment bien la même chose :
Lemma eigenE n (A : ’M[F]_n) lam :
(lam \in (eigenvalue A)) = (lam \in (eigen_seq A)).
Le rayon spectral d’une matrice est le plus grand des modules des valeurs
propres d’une matrice. Donc pour définir le rayon spectral, il faut une fonction
module. Comme la séquence des valeurs propres est définie pour les matrices à
coefficients dans un corps clos, alors le rayon spectral est défini pour les matrices
à coefficients complexes1
:
Variable R : rcfType.
Notation C := (complex R).
Definition spectral_radius n (A : ’M[C]_n) :=
\maxr_(lam <- eigen_seq A) Re ‘|lam|.
Notation "\rho A" := (spectral_radius A).
où Re désigne la fonction partie réelle, car bien que le module d’un nombre complexe
ait une partie imaginaire nulle, son type est le type des nombres complexes,
donc la fonction partie réelle est utilisée ici pour que le résultat obtenu soit réel.
Donc pour parler du rayon spectral d’une matrice à coefficients réels, il faudra
d’abord plonger la matrice dans l’espace des matrices à coefficients complexes.
Dans la suite, nous parlerons également de comparaison entre matrices. Si A et
B sont deux matrices de même dimensions, alors on dira que A ≤ B (resp. A < B)
si tous les coefficients de B sont supérieurs ou égaux (resp. strictement supérieurs)
aux coefficients de A. Dans le code formel, nous utiliserons les définitions et les
notations suivantes :
1voir 1.2.10 et 1.2.11 pour les notations.4.2 Matrices strictement positives 73
Definition Mle A B := forall i j, A i j <= B i j.
Definition Mlt A B := forall i j, A i j < B i j.
Notation "A <=m: B" := (Mle A B).
Notation "A
exists x, 0 <=m: x /\ A *m x = (\rho A^%:C) *: x.
La notation A^%:C signifie que chaque coefficient réel de la matrice A est plongé
dans le corps des nombres complexes
4.2 Matrices strictement positives
Nous allons voir maintenant dans une première partie la formalisation de la preuve
du théorème de Perron-Frobenius pour les matrices strictement positives. Dans
une seconde partie, nous verrons la formalisation d’un résultat important dont
nous aurons besoin pour la première partie.
4.2.1 Preuve du théorème principal
Le théorème que nous allons montrer ici est le suivant :
Perron-Frobenius[cas strictement positif] Soit A ∈ Mn(R) telle que 0 < A,
alors ρ(A) est une valeur propre de la matrice A et possède un vecteur propre
associé dont tous les coefficients sont strictement positifs.
La preuve du théorème repose sur l’axiome suivant :
Axiome. Soit A ∈ Mn(R). La suite définit par (Ak
)k∈N converge vers 0 si et
seulement si ρ(A) < 1.
Nous utiliserons également dans la preuve le résultat suivant :
Resultat 1. Soit A ∈ Mn(R) telle que 0 < A, soit x un vecteur non nul tel que
0 ≤ x, alors 0 < Ax.74 Perron-Frobenius
En effet, le i-ème coefficient du vecteur Ax est P
k aikxi et comme x est nonnul
alors il existe un terme de la somme qui est non-nul, donc tous les coefficients
du vecteur Ax sont strictement positifs.
Pour la preuve du théorème de Perron-Frobeniuspour les matrices strictement
positives nous avons besoins du lemme suivant :
Lemme 5. Soit A ∈ Mn(R) telle que 0 < A. Soit λ une valeur propre de A telle
que |λ| = ρ(A), et soit x un vecteur non nul tel que Ax = λx. Alors nous avons
A|x| = ρ(A)|x|, 0 < ρ(A) et 0 < |x|.
Pour montrer ce lemme, on fait un traitement par cas sur l’égalité A|x| =
ρ(A)|x| :
Posons z = A|x|, alors d’après le résultat 1 nous avons 0 < z.
• Supposons que A|x| = ρ(A)|x|, dans ce cas il ne reste plus qu’à montrer
que 0 < ρ(A) et 0 < |x|. On sait que 0 ≤ ρ(A), si ρ(A) = 0 alors on aurait
A|x| = 0 ∗ |x| = 0, autrement dit on aurait z = 0 ce qui contredit le fait
que 0 < z, donc 0 < ρ(A). De plus, comme 0 < z et que z = ρ(A)|x|, on a
0 < ρ(A)|x| et donc 0 < |x|.
• Maintenant supposons que A|x| 6= ρ(A)|x|. Nous allons montrer que cette
hypothèse est absurde. Posons y = A|x| − ρ(A)|x|, alors d’après l’inégalité
précédente nous avons y 6= 0, de plus 0 ≤ y en effet, nous avons :
ρ(A)|x| = |λ||x| = |λx| = |Ax| ≤ |A||x| = A|x|
et donc
ρ(A)|x| ≤ A|x| ⇔ 0 ≤ A|x| − ρ(A)|x| = y
Donc d’après le résultat 1 nous avons 0 < Ay = Az − ρ(A)z.
Comme 0 < z et 0 < Az − ρ(A)z alors il existe un ε > 0 tel que l’on ait
Az − ρ(A)z > εz. Autrement dit, nous avons :
Az > (ρ(A) + ε)z ⇔
A
ρ(A) + ε
z > z
Donc en posant B = A/(ρ(A) + ε) nous avons Bz > z, et par récurrence
nous obtenons que ∀k, Bk
z > z. De plus ρ(B) = ρ(A)/(ρ(A) + ε) < 1 donc
d’après l’axiome, la suite des Bk
converge vers 0 ce qui donne que 0 ≥ z > 0
ce qui est absurde.
Le théorème découle directement du lemme 5 et des deux lemmes ci-dessous :
Lemma ex_eigen_rho n (A : ’M[C]_n.+1) :
{lam | eigenvalue A lam & ‘|lam| = \rho(A)%:C}.
Lemma eigenvalueP a :
reflect (exists2 v : ’rV_n, v *m g = a *: v & v != 0) (eigenvalue a).4.2 Matrices strictement positives 75
Le premier est une conséquence du fait que le maximum d’un nombre fini de
valeurs est atteint et le deuxième est un résultat donné par la bibliothèque SSReflect.
Dans la preuve du lemme 5, nous avons utilisé quatre résultats qui ne sont
pas seulement des manipulations algébriques :
• Le premier dit que si u et v sont des vecteurs strictement positifs, alors il
existe ε > 0 tel que εv < u. Pour montrer ce résultat, on peut prendre
ε = min
i
ui
2vi
. L’énoncé prouvé formellement est celui-ci :
Lemma Mle_eps m (u v : ’cV[R]_m.+1) :
let F i := ((u i 0) / 2%:R)/ (v i 0) in
let eps := min_fT F in
0 0 eps *: v B, et si la suite des Ak
converge vers C alors on a C ≥ B. Son énoncé formel est le suivant :
Lemma ltmx_cvg_lemx m n (A B :’M[R]_(m,n)) (U : nat -> ’M_(m,n)) :
(forall k, A (U >->> B) -> A <=m: B.
Nous remarquons que certaines propriétés utilisent la notion de convergence
d’une suite de matrices. Donc pour pouvoir les exprimer, il faut d’abord munir
le type des matrices d’une topologie. Nous allons donc voir maintenant comment
est implémentée la structure d’espace topologique sur les matrices, mais aussi sur
les structures ordonnées car nous en aurons besoin par la suite.
4.2.2 Instance des structures topologiques
Nous avons déjà vu au chapitre 3 comment sont implémentées les structures
d’espace métrique et topologique. Nous avons aussi vu sur l’exemple des réels de
Coq comment instancier ces structures. Aussi nous indiquerons ici seulement la
métrique qui sera utilisée pour ces instanciations.76 Perron-Frobenius
Les structures ordonnées
Toutes la hiérarchie des structures ordonnées est basée sur la structure appelée
numDomainType. Nous avons vu que cette structure possède une fonction valeur
absolue, ou module notée ‘|.|. La métrique utilisée sur les structures ordonnées
est donc la suivante :
Definition dist_real x y := ‘|x - y|.
Les nombres complexes
Nous avons vu aussi que dans la définition d’espace métrique le type de retour
de la fonction distance était en paramètre. Ainsi si nous avons E : metricType R
alors plus R sera “haut” dans la hiérarchie des structures ordonnées, plus nous
pourrons démontrer de propriétés sur les espaces métriques. Les nombres complexes
sont une instance de la structure numFieldType. Or nous aurons besoin
dans le développement formel que le type de retour de la fonction distance sur les
nombres complexes soit au moins de type realDomainType. C’est pourquoi nous
utilisons la fontion partie réelle dans la définition de la distance sur les nombres
complexes :
Definition dist_C x y := Re ‘|x - y|.
Les matrices
Avant de définir une distance sur les matrices, nous définissons d’abord un type
pour les normes de matrices :
Section normDef.
Variable R : numDomainType.
Structure can_norm : Type := MNorm {
anorm : forall p q, ’M[R]_(p,q) -> R;
pos_norm : forall p q (A : ’M_(p, q)), 0 <= anorm A;
hom_pos_norm : forall p q (A : ’M_(p, q)) (r : R),
anorm (r *: A) = ‘|r| * anorm A;
trin_ineq_norm : forall p q (A B : ’M_(p, q)),
anorm (A + B) <= anorm A + anorm B;
prod_ineq_norm : forall p q r (A : ’M_(p, q)) (B : matrix _ q r),
anorm (A *m B) <= anorm A * anorm B;
canonical_norm : forall p q (A : ’M_(p, q) ) i j,
‘|A i j| <= anorm A;
canonical_norm2 : forall p q (A B: ’M_(p, q)),
(forall i j, ‘|A i j| <= ‘|B i j|) -> anorm A <= anorm B
}.
End normDef.4.2 Matrices strictement positives 77
Notation "|| A : N |" := (anorm N A).
Ici nous avons simplement repris la définition de norme formalisée par Ioana
Paşca dans [42]. La définition a été actualisée avec les nouvelles définitions et
notations de SSReflect.
La norme que nous utiliserons par la suite est la norme infini définie commme
suit1
:
Definition norm8 (m n : nat) (A : ’M[R]_(m,n)) :=
\maxr_i \sum_j ‘|A i j|.
Cette norme vérifie tous les axiomes de la structure can_norm définie ci-dessus.
Donc après avoir démontré ces propriétés, nous pouvons déclarer la norme infini
comme une instance de la structure :
Canonical Structure can_norm8 := MNorm norm8_pos norm8_hom ...
La distance sur les matrices est définie à partir de cette norme :
Variable R : numDomainType.
Let N8 := can_norm8 R.
Definition dist_mat m n (A B : ’M[R]_(m,n)) :=
||(A - B) : N8 |.
4.2.3 Preuve de l’axiome
Nous allons montrer ici le théorème que nous avons posé en axiome dans la
première partie de la preuve du théorème de Perron-Frobenius :
Théorème 6. Soit A ∈ Mn(K) (K étant R ou C). La suite définit par (Ak
)k∈N
converge vers 0 si et seulement si ρ(A) < 1.
Nous verrons également quelques points de la formalisation de cette preuve.
La Preuve
Commençons d’abord par montrer le sens facile : Si la suite (Ak
)k∈N converge vers
0 alors ρ(A) < 1. Soit λ une valeur propre de la matrice A et x un vecteur propre
associé à λ. Comme Ax = λx alors Akx = λ
kx. Supposons que (Ak
)k∈N converge
vers 0, alors la suite (λ
kx)k∈N = (Akx)k∈N converge vers 0 et comme x est non nul
cela signifie que la suite (λ
k
)k∈N converge vers 0 et donc que |λ| < 1. Nous avons
donc montré que pour toute valeur propre λ de la matrice A nous avons |λ| < 1
et donc en particulier nous avons ρ(A) < 1.
Maintenant supposons que ρ(A) < 1 et montrons que la suite (Ak
)k∈N converge
vers 0. Notons J (A) la forme normale de Jordan de la matrice A. D’après ce que
1Le “8” représente un infini debout.78 Perron-Frobenius
nous avons vu dans le chapitre 2, la matrice A est semblable à J (A). C’est-à-dire
qu’il existe une matrice inversible P telle que A = P
−1J (A)P, autrement dit
telle que Ak = P
−1J (A)
kP. Donc prouver que la suite (Ak
)k∈N converge vers 0
revient à prouver que la suite (J (A)
k
)k∈N converge vers 0.
Nous savons que la forme normale de Jordan de A est une matrice diagonale
par blocs dont chaque bloc est un bloc de Jordan J(λ, n) où λ est une valeur
propre de A. Donc la matrice J (A)
k
est une matrice diagonale par blocs dont
chaque bloc est de la forme J(λ, n)
k
.
Ainsi pour montrer que la suite (J (A)
k
)k∈N converge vers 0, il suffit de montrer
que pour chaque bloc la suite des (J(λ, n)
k
)k∈N converge vers 0.
Voyons donc quelle est la forme générale de la matrice J(λ, n)
k
. Sur la figure
ci-dessous on peut voir ce qui se passe sur un exemple pour les quatre premières
puissances avec n = 4 :
J(λ, 4) =
λ 1 0 0
0 λ 1 0
0 0 λ 1
0 0 0 λ
J(λ, 4)2 =
λ
2 2λ 1 0
0 λ
2 2λ 1
0 0 λ
2 2λ
0 0 0 λ
2
J(λ, 4)3 =
λ
3 3λ
2 3λ 1
0 λ
3 3λ
2 3λ
0 0 λ
3 3λ
2
0 0 0 λ
3
J(λ, 4)4 =
λ
4 4λ
3 6λ
2 4λ
0 λ
4 4λ
3 6λ
2
0 0 λ
4 4λ
3
0 0 0 λ
4
On remarque que sur chaque ligne les puissances de λ décroissent et que des
coefficients binomiaux apparaissent. De manière générale nous avons :
(J(λ, n)
k
)ij =
k
j − i
!
λ
k−(j−i)
avec la convention que
k
j−i
= 0 si j − i > k ou si i > j.
Rappelons que nous avons ρ(A) < 1 et donc pour toute valeur propre λ de A
nous avons |λ| < 1. Nous allons montrer que si |λ| < 1 alors la suite (J(λ, n)
k
)k∈N
converge vers 0, pour cela nous allons montrer que les coefficients de la matrice
J(λ, n)
k
convergent vers 0 quand k tend vers l’infini.
Nous avons pour tout l :
k
l
!
=
k!
(k − l)! l!
=
(k − (l − 1)) ∗ · · · ∗ k
l!
≤
k ∗ · · · ∗ k
l!
=
k
l
l!
avec comme convention que a − b = 0 si a < b.
Cela signifie que pour un l fixé,
k
l
est borné par le polynôme k
l/l! et donc
dans l’expression suivante :
k
j − i
!
λ
k−(j−i)4.2 Matrices strictement positives 79
comme |λ| < 1 nous avons le terme λ
k−(j−i) qui converge vers 0 de façon exponentielle
alors que le terme
k
j−i
croit vers l’infini de façon polynômiale. Donc
finalement chaque coefficient du bloc J(λ, n)
k
converge vers 0. Ceci fini de montrer
le théorème.
Quelques points de formalisation
Matrice et convergence Nous allons d’abord parler de lemmes généraux sur la
convergence des suites de matrices. Un premier lemme important que nous avons
utilisé est celui qui fait le lien entre la convergence des matrices et la convergence
coefficient par coefficient. Ce lemme s’énonce formellement ainsi :
Variable R : numFieldType.
Lemma mx_cvgP m n (U : nat -> ’M_(m,n)) (A :’M[R]_(m,n)) :
U >->> A <-> (forall i j, (fun n => (U n) i j) >->> (A i j)).
Nous nous en sommes servi pour montrer que la suite des puissances des blocs
de Jordan convergeait vers 0.
Le second résultat sur la convergence des matrices que nous allons voir est
celui qui fait le lien entre la convergence des matrices diagonales par blocs et
la convergence bloc à bloc. Rappelons qu’une matrice diagonale par blocs est
définie formellement à l’aide d’une fonction F : forall n, nat -> ’M_n.+1 qui
donne les blocs diagonaux (voir 2.1), et d’une séquence qui correspond à peu de
choses près à la taille des blocs. Une suite U1, U2, . . . de matrices diagonales par
blocs correspondra formellement à une suite :
diag_block_mx s (UF 1), diag_block_mx s (UF 2), ...
où UF est la suite des fonctions qui donnent les blocs diagonaux. Nous avons donc
UF qui est de type nat -> forall n, nat -> ’M_n.+1. Le lemme s’énonce ainsi :
Lemma diag_block_mx_cvg s (UF : nat -> forall n, nat -> ’M[R]_n.+1)
(F : forall n, nat -> ’M[R]_n.+1) :
(forall i, (i < size s)%N ->
(fun k => UF k (nth 0%N s i) i) >->> (F (nth 0%N s i) i)) ->
(fun k => diag_block_mx s (UF k)) >->> (diag_block_mx s F).
Nous l’utilisons pour montrer que la forme normale de Jordan de la matrice A
converge vers 0.
Convergence sur les nombres réels ou complexes Nous avons également
utilisé le fait qu’il y a équivalence entre |λ| < 1 et la convergence de la suite
(λ
k
)k∈N vers zéro. La preuve de ce résultat utilise la propriété archimédienne
des nombres réels. Or dans notre cas nous utilisons ces lemmes sur les nombres
complexes qui n’est pas archimédien.
La structure archifieldType de la bibliothèque SSReflect est une structure
realFieldType qui vérifie l’axiome suivant :80 Perron-Frobenius
Definition archimedean_axiom (R : numDomainType) :=
forall (x : R), exists ub : nat, ‘|x| < ub%:R.
La preuve de ce résultat n’utilise pas le fait que la structure de base est de
type realFieldType, mais seulement le fait que l’axiome ci-dessus est vérifié. Or il
se trouve que l’ensemble des nombres complexes vérifie cet axiome (car le module
d’un nombre complexe est réel).
Pour éviter d’avoir à dupliquer les lemmes sur les nombres réels et sur les
nombres complexes, nous allons définir une nouvelle structure plus faible que la
structure archiFieldType dont le type de base sera la structure numFieldType :
Structure class_of (R : Type) := Class
{ base : NumField.class_of R;
_ : archimedean_axiom (@NumDomain.Pack R base) }.
Coercion base : class_of >-> NumField.class_of.
Structure type := Pack {sort; _ : class_of sort}.
Coercion sort : type >-> Sortclass.
Notation archiDomainType := type.
Nous avons déjà rencontré ce genre de définition dans le chapitre 3 sur la
présentation des structures topologiques. La structure class_of est la structure
d’hérédité. Elle contient un champ base qui correspond à la structure d’hérédité
du type de base, et un preuve que ce type de base vérifie les propriétés supplé-
mentaires qui se trouve dans la structure mixin_of qui ici est seulement réduite
à l’axiome archimedean_axiom. Ce genre de structure est expliquée plus en détail
dans [15, 14].
Cette structure étant basée sur la structure numFieldType hérite des propriétés
de cette dernière, et aussi de la topologie (et de la métrique) que nous avons
instanciée pour la structure numDomainType.
L’ensemble des nombres réels et l’ensemble des nombres complexes étant tous
les deux des instances de la structure ci-dessus, nous pouvons utiliser dans les
deux cas les deux lemmes suivants qui nous intéressent :
Variable R : archiDomainType.
Lemma cvg_lt1 (x : R) :
reflect ((fun k => x ^+ k) >->> 0) (‘|x| < 1).
Lemma polyM_exp_cvg0 i (a : R) :
‘|a| < 1 -> (fun k => k%:R ^+ i * a ^+ k) >->> 0.
4.3 Matrices à coefficients positifs ou nuls
Nous avons montré que pour toute matrice A ∈ Mn(R) telle que 0 < A, il existe
un vecteur propre x de A tel que 0 < x et que Ax = ρ(A)x. Nous allons voir4.3 Matrices à coefficients positifs ou nuls 81
maintenant comment l’on généralise ce résultat pour le cas où 0 ≤ A. Ce que
nous allons voir dans cette section n’est pas formalisé. Nous discuterons ici du
travail qu’il reste à faire.
4.3.1 La preuve
Le théorème que nous allons étudier maintenant est donc le suivant :
Perron-Frobenius Soit A ∈ Mn(R) telle que 0 ≤ A, alors ρ(A) est une valeur
propre de la matrice A et possède un vecteur propre associé dont tous les
coefficients sont positifs.
Prenons donc une matrice A telle que 0 ≤ A. Posons Ak = (aij +
1
k
)1≤i,j≤n.
Les matrices Ak sont des matrices strictement positives. Donc d’après le théorème
que nous venons de montrer dans la section 4.2.1, nous avons ρ(Ak) qui est une
valeur propre de Ak et qui possède un vecteur propre associé xk strictement positif.
Quitte à normaliser, nous pouvons choisir le vecteur xk de norme 1. Comme la
suite des matrices Ak converge vers A, alors la suite des ρ(Ak) converge vers ρ(A).
De plus, comme les vecteurs de la suite xk sont dans un ensemble compact, alors
d’après le théorème de Bolzano-Weierstraß (chapitre 3) il existe une sous-suite
xϕ(k) qui converge vers un vecteur x positif. Pour tout entier k nous avons donc
Aϕ(k)xϕ(k) = ρ(Aϕ(k))xϕ(k)
, donc d’après ce qui précède, en passant à la limite
nous obtenons Ax = ρ(A)x. Ainsi ρ(A) est une valeur propre de A et possède un
vecteur propre associé à coefficients positifs ou nuls.
Les deux principaux résultats de cette preuve qui demanderont le plus de
travail de formalisation sont :
• Si (An)n∈N est une suite de matrice qui converge vers A alors la suite des
ρ(An) converge vers ρ(A).
• L’ensemble des vecteurs de norme 1 est un ensemble compact.
4.3.2 Convergence des rayons spectraux
Nous avons deux façons de montrer que la suite (ρ(Ak))k∈N∗ décrite plus haut
converge vers ρ(A). La première utilise un argument de convergence des suites
réelles décroissantes et minorées, et la deuxième utilise un argument de continuité.
Argument de convergence
Pour montrer que la suite des rayons spectraux est décroissante, nous utilisons le
lemme suivant :
Lemme 7. Si A, B ∈ Mn(K) (avec K = R ou C) sont des matrices telles que
|A| ≤ B alors ρ(A) ≤ ρ(B).82 Perron-Frobenius
Démonstration. Soit ε > 0. Définissons les matrices suivantes :
Aε =
A
ρ(B) + ε
et Bε =
B
ρ(B) + ε
Comme |A| ≤ B, nous avons |Aε| ≤ Bε et donc |Aε|
k ≤ Bk
ε
.
D’une part ρ(Bε) = ρ(B)/(ρ(B) + ε) < 1. D’après ce que nous avons vu dans
la section 4.2.3, cela signifie que la suite (Bk
ε
)k∈N converge vers 0.
D’autre part pour tout entier k nous avons |Ak
ε
| ≤ |Aε|
k ≤ Bk
ε
. D’après ce
qui précède, cela signifie que la suite (Ak
ε
)k∈N converge aussi vers 0, et donc cela
implique que ρ(Aε) < 1.
Donc finalement :
ρ(Aε) = ρ(A)
ρ(B) + ε
< 1 ⇔ ρ(A) < ρ(B) + ε
et ce pour tout ε > 0 donc ρ(A) ≤ ρ(B).
Grâce à ce lemme nous pouvons montrer que la suite (ρ(Ak))k∈N∗ est une suite
décroissante et minorée par ρ(A) donc cette suite converge vers un réel ρ tel que
ρ ≥ ρ(A).
De plus nous avons vu que en passant à la limite, nous avons l’égalité Ax = ρx.
Cela nous donne que ρ ≤ ρ(A) et donc par double inégalité ρ = ρ(A).
Le développement sur la topologie est assez développé pour faire ce genre de
preuve.
Argument de continuité
Une autre façon de faire est de montrer que la fonction A → ρ(A) est continue.
Ainsi comme la suite (Ak)k∈N converge vers A alors la suite (ρ(Ak))k∈N∗ converge
vers ρ(A).
L’argument le plus souvent utilisé pour montrer la continuité du rayon spectral
est le suivant :
• Les coefficients du polynôme caractéristique d’une matrice varient continuement
en fonction des coefficients de la matrice.
• Les racines d’un polynôme varient continuement en fonction des coefficients
du polynôme.
• Le rayon spectral est continu en tant que composée d’applications continues.
Le polynôme caractéristique d’une matrice est le déterminant de sa matrice
caractéristique. Donc une manière de prouver le premier point est d’instancier
une métrique sur l’ensemble des polynômes et de prouver que l’application déterminant
est continue.4.4 Conclusion 83
On peut trouver une preuve du second point dans [34]. C’est une preuve qui
demanderait encore du travail de formalisation, mais qui je pense reste abordable
avec les outils que nous avons déjà formalisés.
Le troisème point est un résultat général sur la continuité qui est déjà formalisé
dans le développement sur la topologie.
4.3.3 Compacité de la boule unité
Pour pouvoir utiliser le théorème de Bolzano-Weierstraß que nous avons vu au
chapitre 3, il nous faut montrer que l’ensemble des vecteurs de norme 1 est un
ensemble compact. Pour montrer ce résultat, on montre d’abord que les intervalles
fermés sur R sont compacts.
Ensuite on montre que la boule unité est incluse dans un pavé qui est le
produit cartésien d’intervalles de R. Comme le produit cartésien fini d’ensembles
compacts est compact, nous avons la boule unité qui est un ensemble fermé inclus
dans un compact et est donc compact.
Une première étape serait de définir le produit cartésien de deux ensembles.
Nous avons vu qu’il existe déjà dans Coq un type produit pour le produit carté-
sien de deux types (voir 1.1.1). Nous pourrions réutiliser ce produit cartésien sur
les types pour avoir une définition du produit cartésien sur les ensembles :
Variables (T1 T2 : Type).
Definition cartesian_product (A : T1 -> Prop) (B : T2 -> Prop) :=
fun x : (T1 * T2) => (x.1 ’in A) /\ (x.2 ’in B).
Mais je n’ai aucune idée si cette définition est praticable.
Un second problème va apparaître lorsque nous voudrons utiliser ce résultat
sur l’ensemble des nombres complexes. Ici l’argument est que l’on peut voir l’ensemble
C comme le produit cartésien R × R. Il faudrait alors expliquer que la
topologie obtenue à partir de la topologie produit sur R × R est équivalente à la
topologie que nous avons instanciée sur l’ensemble des nombres complexes. Pour
l’instant, telle qu’est définie la structure d’espace topologique, c’est quelque chose
de difficile à exprimer.
Le fait qu’un ensemble fermé inclus dans un compact est compact est déjà
formalisé dans le développement sur la topologie générale.
4.4 Conclusion
Le théorème de Perron-Frobenius est un exemple de théorème d’algèbre linéaire
qui fait intervenir des arguments d’analyse et de topologie. Bien que la formalisation
de ce théorème ait motivé la formalisation de la forme normale de Jordan et
des espaces topologiques et métriques, ces développements ont été fait de manière
indépendantes.
La premère partie du théorème a permis de montrer que ces développements
étaient réutilisables. Nous avons pu ainsi avoir une formalisation complète du84 Perron-Frobenius
théorème de Perron-Frobeniuspour les matrices strictements positives.
Toutefois pour montrer le théorème dans le cas générale, il reste encore à
prouver des résultats comme la continuité du rayon spectrale ou la compacité de
l’ensemble des vecteurs de norme 1.
4.5 Travaux reliés
A ma connaissance, il n’existe pas de travaux de formalisation à propos du théorème
du théorème de Perron-Frobenius. Un des rares papiers que j’ai trouvé sur
la formalisation de sujet semblable est celui de Karol Pąk où le concept de valeur
propre est formalisé en Mizar [40].Conclusion
La formalisation du théorème de Perron-Frobenius a permis de formaliser des
résultats plus généraux d’algèbre linéaire, mais aussi de topologie générale. C’est
ce théorème qui a principalement motivé cette thèse.
La bibliothèque SSReflect contient déjà une formalisation assez avancée
sur les matrices, les polynômes et les propriétés algébriques. Ceci nous a fourni
une bonne base pour développer les travaux de cette thèse.
La formalisation des formes normales de Frobenius et de Jordan vue au chapitre
2, outre le fait d’avoir une preuve formelle de ces résultats, a occasionné
le développement de théories sur les matrices diagonales par blocs, et sur les
matrices semblales ou équivalentes. Ce sont des théories qui sont utilisées dans
d’autres contextes mathématiques et donc nous espérons que ces outils pourront
être réutilisés pour la formalisation d’autres résultats mathématiques.
Dans le chapitre 3 nous avons formalisé les structures d’espace métrique et topologique.
Il existe déjà une topologie dans la bibliothèque standard de Coq sur
les nombre réels. Ici nous avons défini une structure générale de topologie pour
avoir des résultats qui puissent être utilisés aussi bien sur des réels que sur des matrices
ou sur des nombres complexes. Le résultat important de ce développement
sur la topologie est le théorème de Bolzano-Weierstraß. Pour l’utilisation de ce
théorème, il serait intéressant par la suite d’implémenter les structures d’espace
normé et euclidien, ainsi que les propriétés de compacité des produits cartésiens
d’ensembles. Cela permettrait d’avoir des théorèmes généraux supplémentaires
pour montrer la compacité d’un ensemble.
Les développements sur les formes normales de matrices et sur la topologie ont
été formalisés de manière indépendante et dans le but de pouvoir être réutilisés.
Le théorème de Perron-Frobenius est une première application de l’utilisation de
ces développements formels. En effet, nous avons réussi à instancier une métrique
et une topologie sur les matrices et les nombres réels ou complexes. Ensuite nous
avons pu prouver des résultats sur la convergence de certaines suites. Et la forme
normale de Jordan a permis de montrer un résultat important sur la convergence
des suites des puissances de matrices.
Cependant la partie du théorème de Perron-Frobenius utilisant le théorème
de Bolzano-Weierstraß n’a pu être encore formalisée. Pour finir cette partie de
la preuve, il reste à montrer quelques résultats comme la continuité du rayon
spectral, et d’autres résultats de topologie pour pouvoir montrer la compacité
d’un ensemble, et utiliser Bolzano-Weierstraß.Bibliographie
[1] Andrea Asperti, Claudio Sacerdoti Coen, Ferruccio Guidi, Enrico
Tassi et Stefano Zacchiroli : Matita v0.99.1 : User manual, 2006.
http://matita.cs.unibo.it/. 3
[2] Andrea Asperti, Maria Emilia Maietti, Claudio Sacerdoti Coen, Giovanni
Sambin et Silvio Valentini : Formalization of formal topology
by means of the interactive theorem prover matita. In Proceedings of the
18th Calculemus and 10th International Conference on Intelligent Computer
Mathematics, MKM’11, pages 278–280, Berlin, Heidelberg, 2011. SpringerVerlag.
67
[3] Yves Bertot et Pierre Castéran : Interactive Theorem Proving and Program
Development – Coq’Art : The Calculus of Inductive Constructions.
Texts in Theoretical Computer Science. An EATCS Series. Springer Verlag,
2004. 9
[4] Yves Bertot, Georges Gonthier, Sidi Ould Biha et Ioana Paşca : Canonical
big operators. In Theorem Proving in Higher Order Logics, 21st
International Conference, TPHOLs 2008, Montreal, Canada, volume 5170
de Lecture Notes in Computer Science, pages 86–101. Springer, 2008. 18
[5] François Bobot, Sylvain Conchon, Évelyne Contejean, Mohamed
Iguernelala, Stéphane Lescuyer et Alain Mebsout : The Alt-Ergo
automated theorem prover, 2008. http://alt-ergo.lri.fr/. 3
[6] Robert Stephen Boyer et J Strother Moore : A Computational Logic
Handbook. Academic Press, Inc, 1988. 3
[7] Guillaume Cano et Maxime Dénès : Matrices à blocs et en forme canonique.
In JFLA - Journées francophones des langages applicatifs, Aussois, France,
2013. 25
[8] Cyril Cohen : Formalized algebraic numbers : construction and first-order
theory. Thèse de doctorat, École Polytechnique, 2012. 23
[9] Cyril Cohen, Maxime Dénès, Anders Mörtberg et Vincent
Siles : Smith Normal form and executable rank for matrices, 2012.88 Bibliographie
http://wiki.portal.chalmers.se/cse/pmwiki.php/ForMath/ProofExamples.
33, 35
[10] Robert L. Constable, Stuart F. Allen, H. M. Bromley, W. R. Cleaveland,
J. F. Cremer, R. W. Harper, Douglas J. Howe, T. B. Knoblock,
N. P. Mendler, P. Panangaden, James T. Sasaki et Scott F. Smith :
Implementing mathematics with the nuprl proof development system, 1986.
3
[11] Leonardo de Moura et Nikolaj Bjørner : Z3 : An efficient SMT solver.
In Conference on Tools and Algorithms for the Construction and Analysis of
Systems (TACAS), Budapest, Hungary, 2008. http://z3.codeplex.com/.
3
[12] Maxime Dénès : Étude formelle d’algorithmes efficaces en algèbre linéaire.
Thèse de doctorat, Université de Nice - Sophia Antipolis, 2013. 33
[13] The Coq development team : The Coq proof assistant : Reference manual,
2013. http://coq.inria.fr/. 3
[14] François Garillot : Outils génériques de preuve et théorie des groupes finis.
These, Ecole Polytechnique X, décembre 2011. 59, 80
[15] François Garillot, Georges Gonthier, Assia Mahboubi et Laurence Rideau
: Packaging Mathematical Structures. In Tobias Nipkow et Christian
Urban, éditeurs : Theorem Proving in Higher Order Logics, volume 5674 de
Lecture Notes in Computer Science, Munich, Germany, 2009. Springer. 80
[16] Isabelle Gil : Contribution à l’algèbre linéaire formelle. Thèse de doctorat,
Institut Nationale Polytechnique de Grenoble, 1993. 25
[17] Ruben Gomboa, John Cowles et Jeff Van Baalen : Using ACL2 arrays
to formalize matrix algebra. ACL2 Workshop 2003, Boulder, 2003. 50
[18] Georges Gonthier : The four colour theorem : Engineering of a formal
proof. In Computer Mathematics, 8th Asian Symposium, ASCM 2007, volume
5081 de Lecture Notes in Computer Science, page 333. Springer, 2007.
4
[19] Georges Gonthier, Andrea Asperti, Jeremy Avigad, Yves Bertot, Cyril
Cohen, François Garillot, Stéphane Le Roux, Assia Mahboubi, Russell
O’Connor, Sidi Ould Biha, Ioana Paşca, Laurence Rideau, Alexey
Solovyev, Enrico Tassi et Laurent Théry : A machine-checked proof of
the odd order theorem. In Interactive Theorem Proving - 4th International
Conference, ITP 2013, Rennes, France. Proceedings, volume 7998 de Lecture
Notes in Computer Science, pages 163–179. Springer, 2013. 5Bibliographie 89
[20] Georges Gonthier et Assia Mahboubi : A Small Scale Reflection Extension
for the Coq system. Research Report RR-6455, INRIA, 2008. 4
[21] Thomas Callister Hales : Introduction to the flyspeck project. In Mathematics,
Algorithms, Proofs, volume 05021 de Dagstuhl Seminar Proceedings.
Internationales Begegnungs- und Forschungszentrum für Informatik (IBFI),
Schloss Dagstuhl, Germany, 2005. 5
[22] Thomas Callister Hales, John Harrison, Sean McLaughlin, Tobias Nipkow,
Steven Obua et Roland Zumkeller : A revision of the proof of the
kepler conjecture. Discrete & Computational Geometry, 44(1):1–34, 2010. 5
[23] John Harrison : A HOL theory of Euclidean space. In Joe Hurd et
Tom Melham, éditeurs : Theorem Proving in Higher Order Logics, 18th
International Conference, TPHOLs 2005, volume 3603 de Lecture Notes in
Computer Science, Oxford, UK, 2005. Springer-Verlag. 50, 67
[24] John Harrison : Handbook of Practical Logic and Automated Reasoning.
Cambridge University Press, New York, NY, USA, 1st édition, 2009. 3
[25] John Harrison : The HOL-Light system reference. University of Cambridge,
2013. http://www.cl.cam.ac.uk/~jrh13/hol-light/. 3
[26] Johannes Hölzl, Fabian Immler et Brian Huffman : Type classes and
filters for mathematical analysis in Isabelle/HOL. In Proceedings of the
4th International Conference on Interactive Theorem Proving, ITP’13, pages
279–294, Berlin, Heidelberg, 2013. Springer-Verlag. 67
[27] Katarzyna Jankowska : Matrices. Abelian group of matrices. Formalized
Mathematics, 2(4):475–480, 1991. 50
[28] Matt Kaufmann et J Strother Moore : ACL2, 2013.
http://www.cs.utexas.edu/~moore/acl2/. 3
[29] Matt Kaufmann, J. Strother Moore et Panagiotis Manolios : ComputerAided
Reasoning : An Approach. Kluwer Academic Publishers, Norwell, MA,
USA, 2000. 3
[30] David R. Lester : Topology in PVS : Continuous mathematics with applications.
In Proceedings of the Second Workshop on Automated Formal
Methods, AFM ’07, pages 11–20, New York, NY, USA, 2007. ACM. 67
[31] Guillaume Melquiond : User’s guide for gappa, 2013.
http://gappa.gforge.inria.fr/. 3
[32] Jean-Pierre Merlet : Interval Analysis and Reliability in Robotics, mars
2006. 6, 6990 Bibliographie
[33] Michał Muzalewski : An outline of PC Mizar. Fondation Philippe le
Hodey, 1993. http://mizar.uwb.edu.pl/. 3
[34] Raúl Naulin et Carlos Pabst : The roots of a polynomial depend continuously
on its coefficients. Revista Colombiana de Matemáticas, 28(1):35–37,
1994. 83
[35] Michael Norrish, Konrad Slind et al. : The HOL system reference. Automated
Reasoning Group, University of Cambridge, Computer Laboratory,
2013. http://hol.sourceforge.net/. 3
[36] Steven Obua : Proving bounds for real linear programs in Isabelle/HOL.
In Joe Hurd et Thomas F. Melham, éditeurs : TPHOLs, volume 3603 de
Lecture Notes in Computer Science, pages 227–244. Springer, 2005. 50
[37] Patrick Ozello : Calcul exact des formes de Jordan et de Frobenius d’une
matrice. Thèse de doctorat, Université Scientifique Technologique et Médicale
de Grenoble, 1987. 25
[38] Beata Padlewska et Agata Darmochwał : Topological spaces and continuous
functions. Formalized Mathematics, 1(1):223–230, 1990. 67
[39] Karol Pąk : Block diagonal matrices. Formalized Mathematics, 16(3):259–
267, 2008. 50
[40] Karol Pąk : Eigenvalues of a linear transformation. Formalized Mathematics,
16(4):289–295, 2008. 84
[41] Karol Pąk : Jordan matrix decomposition. Formalized Mathematics, 16(4):
297–303, 2008. 50
[42] Ioana Paşca : Vérification formelle pour les méthodes numériques. Thèse
de doctorat, Université Nice-Sophia Antipolis, 2010. 6, 69, 73, 77
[43] Giovanni Sambin : The basic picture, a structure for topology (the basic
picture, i). Rapport technique, 2001. 67
[44] Stephan Schulz : E 1.8 : User manual, 2013.
http://www4.informatik.tu-muenchen.de/~schulz/E/. 3
[45] Natarajan Shankar, Sam Owre, John M. Rushby et David William John
Stringer-Calvert : PVS prover guide, 2001. http://pvs.csl.sri.com/.
3
[46] Vincent Siles : A formal proof of the Cauchy-Binet formula, 2012.
http://wiki.portal.chalmers.se/cse/pmwiki.php/ForMath/ProofExamples.
38Bibliographie 91
[47] Matthieu Sozeau et Nicolas Oury : First-Class Type Classes. In Otmame
Aït-Mohamed, César Muñoz et Sofiène Tahar, éditeurs : 21th International
Conference on Theorem Proving in Higher Order Logics, volume 5170
de Lecture Notes in Computer Science. Springer, août 2008. 53
[48] Shlomo Sternberg : Dynamical Systems. Dover Publications, 2010. Chapitre
9. 69
[49] Joe Hendrix University et Joe Hendrix : Matrices in ACL2, 2003. 50
[50] Makarius Wenzel et al. : The Isabelle/Isar reference manual, 2013.
http://www.cl.cam.ac.uk/research/hvg/Isabelle/. 3
M´ethodes num´eriques pour la spatialisation sonore, de
la simulation `a la synth`ese binaurale
Matthieu Aussal
To cite this version:
Matthieu Aussal. M´ethodes num´eriques pour la spatialisation sonore, de la simulation `a la
synth`ese binaurale. Mathematics. Ecole Polytechnique X, 2014. French.
HAL Id: tel-01095801
https://pastel.archives-ouvertes.fr/tel-01095801
Submitted on 16 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 titre de
Docteur de l’École Polytechnique
Spécialité : Mathématiques appliquées
par Matthieu Aussal
Méthodes numériques pour
la spatialisation sonore,
de la simulation à la
synthèse binaurale.
Soutenue le 02 octobre 2014
Rapporteurs et membres du jury
Directeur de thèse : François Alouges (École Polytechnique)
Rapporteurs : Leslie Greengard (New York University)
Jean-Marc Jot (DTS inc.)
Séraphin Mefire (Université de Lorraine)
Examinateurs : Toufic Abboud (École Polytechnique)
Joël Bensoam (IRCAM)
Marc Bonnet (ENSTA)
Directeurs Industriels : Vincent Mouret (Digital Media Solutions)
Hervé Roux (Digital Media Solutions)Remerciements
Mes premiers remerciements vont tout naturellement à Hervé Roux, initiateur
de ces recherches à travers la société Digital Media Solutions et
Vincent Mouret, qui a repris le flambeau avec la même ferveur. Merci de
m’avoir fait confiance, et ce dès le début, en me laissant toute la liberté
d’agir sans autre contrainte que celle d’imaginer l’avenir. En m’impliquant
doucement mais sûrement dans les rouages de la société, vous m’avez transmis
le goût de l’entrepreneuriat.
Je remercie mes rapporteurs, MM. Leslie Greengard, Jean-Marc Jot et
Séraphin Mefire d’avoir accepté de consacrer une partie de leurs vacances
à relire mon manuscrit. J’ai été très honoré qu’ils acceptent cette charge et
particulièrement touché par les compliments de leurs rapports respectifs.
Je tiens aussi à remercier MM. Toufic Abboud, Joël Bensoam et Marc
Bonnet d’avoir accepté de faire partie de mon jury. Merci à Toufic de nous
avoir proposé son aide lorsque nous en avions besoin. Merci à Joël de m’avoir
donné le goût des équations intégrales pour l’acoustique. Merci à Marc pour
les nombreux échanges passés et à venir.
Par ailleurs, je remercie les doctorants et personnels du Centre de Mathématiques
Appliquées de l’École Polytechnique qui se sont prêtés de nombreuses
fois à des expériences sonores diverses et variées, et toujours avec le
sourire. Un grand merci aussi à l’École Polytechnique, et plus spécifiquement
au CMAP et Antonin Chambolle, pour m’avoir accueilli pendant ce doctorat,
et pour m’accueillir encore pendant quelques temps.
Une pensée toute particulière accompagne l’équipe Audio 3D de DMS,
qui a réussie à supporter mon encadrement sans (trop) broncher ! ;-) Encore
Bravo à Mathieu Coïc pour la quantité/qualité colossale de travail abattu et
merci pour cette ambiance si chaleureuse. Merci à Alexandre Dazzoni pour ses
conseils et sa grande disponibilité. Je souhaiterais aussi féliciter et remercier
les nombreux stagiaires que j’ai eu le plaisir d’encadrer : Ivan Alouges, Louis
Anglionin, Martin Averseng, Pierre Bézard, Timothée Chevalier, Marie-Julie
Dhaou, Louis Faucon (et merci à l’ADO !), Valentin Labourette, Hanna Ma-tahri, Lasse Munk, François Salmon, Adel Chelghoum et Augustin Deprez.
J’en profite pour remercier tout le personel de DMS et tout particulièrement
Nathalie, Alix, Mika, Walid, Ludo, Pascal C., Eric, Matthieu D., PatrickGilles,
Guillaume E., Lucas et Alberto.
En vrac, encore merci à Sylvie Tonda-Goldstein pour son aide précieuse
en démêlage de sac de nœuds, à Hervé Le Meur pour ses nombreux coups
de pouce, à Timothée Chevalier pour ses maillages de tête à trous, à Sylvain
Faure et Pascal Frey pour leurs maillages de tête sans trou, à Jean-Christophe
Messonnier pour les nombreuses conversations, à Hervé Déjardin pour ses
riches conseils, aux membres du consortium BiLi, à Sophie-Anaïs pour son
expertise, à Isabelle et Jean pour la transmission de savoirs, à Manou et
So pour leurs coups de main, à Grany, à The Mathworks d’avoir inventé
Matlab, au bâtiment 334, aux d’Yvette d’en face pour leurs superbes voix et
à Vincent, l’ami éternel.
Enfin, il faudrait bien plus qu’un merci à ma famille, ma belle-famille et
mes amis pour leur soutien sans faille.
Et puisqu’il est coutume de garder le meilleur pour la fin, je tiens à
adresser mes plus sincères et chaleureux remerciements à François Alouges.
Au-delà d’un encadrement scientifique d’une rare qualité, tu as été d’une
extrême bienveillance pendant ces trois années qui, grâce à toi, furent d’une
richesse inouïe. Je te dois cette thèse, alors vraiment, merci.à Caroline
et à nos enfants
Crédits : Bob de Groot et Turk, Léonard est un génie, ed. Le Lombard, 1977.Résumé
Les recherches effectuées lors de ce doctorat ont été initiées par un besoin
industriel identifié par la société Digital Media Solutions, à savoir la
réalisation d’un outil de spatialisation sonore au casque destiné aux nonvoyants.
Malgré les nombreux dispositifs déjà existants, les techniques de
synthèse binaurale butent, depuis leur apparition, sur un obstacle majeur,
qui empêche la réalisation de produits de haute qualité. En effet, pour rendre
l’illusion d’un espace sonore perceptible, les déformations temporelles et spectrales
issues de la propagation d’une onde sonore jusqu’aux tympans doivent
être restituées le plus fidèlement possible. En plus des difficultés classiques
rencontrées en traitement du signal audio, ceci entraîne, de facto, la nécessité
d’individualiser les fonctions de transfert HRTF, traduisant pour chacun
l’empreinte spatiale d’une source sonore. Pour réaliser cette personnalisation,
une première approche consiste à mesurer en laboratoire les HRTF de
chaque individu. Bien qu’offrant des résultats convaincants, cette technique
n’est pas encore applicable au grand public, car le processus est long, pé-
nible et relativement coûteux. C’est pourquoi la modélisation mathématique
a été envisagée. Sous réserve d’un maillage représentatif de la morphologie
de l’auditeur, la résolution numérique des équations de propagation des
ondes pourrait avantageusement remplacer la mesure. Aujourd’hui, des outils
grand public (e.g. Kinect de Microsoft) permettent la réalisation de maillages
satisfaisants, qui peuvent être perfectionnés, voire couplés, à des formes élé-
mentaires analytiques (Sphères, Ellipses, Cônes, etc.). La thèse se concentre
alors sur deux axes principaux et complémentaires.
D’une part, nous avons développé (conjointement avec F. Alouges) un
nouveau moteur de calcul intégral par éléments finis de frontières (MyBEM),
réalisé sous Matlab. Ce dernier est appliqué à la résolution des équations de
l’acoustique. Pour pouvoir calculer les fonctions de transfert HRTF sur l’ensemble
des fréquences audibles, une nouvelle méthode rapide de convolution a
été conçue, implémentée, puis validée analytiquement. À partir d’une quadrature
monodimensionnelle performante d’un noyau de Green quelconque (Laplace,
Helmholtz, Stokes, Maxwell, etc), une séparation des variables permet
1le calcul rapide d’un produit de convolution dans l’espace. Dénommée "Dé-
composition Creuse en Sinus Cardinal" (SCSD), cette méthode est confrontée
à la "Méthode Multipolaire Rapide" (FMM), référence reconnue en la matière.
D’autre part, une fois les HRTF mesurées ou calculées sur une grille sphé-
rique discrète, une résolution de quelques degrés angulaires est indispensable
pour pouvoir effectuer un rendu spatial de grande qualité. Il faut donc procéder
à des interpolations de filtres, qui nuisent à la qualité du rendu audio
et à l’impression d’externalisation. Cependant, une nouvelle compréhension
des HRTF initiée avant la thèse a permis un sous-échantillonnage spatial des
bases de données, sans produire d’artefacts audibles, mais aussi une personnalisation
par filtrage inverse. Mise en œuvre au sein d’un moteur de rendu
audio spatialisé sous Matlab (PifPaf3D), cette technique appelée "Décomposition
par Modèle Morphologique" a montré des qualités reconnues par validations
subjectives. Par ailleurs, de nombreux outils connexes ont été intégrés
à ce moteur, pour améliorer encore le rendu spatial, comme des acoustiques
de salles ou la compensation du casque audio.
Ces deux étapes, abouties et maîtrisées, doivent désormais être couplées
en vue de réaliser une chaîne complète de synthèse binaurale numérique.
2Abstract
Research conducted during this PhD were initiated by an industrial need
identified by Digital Media Solutions, namely the creation of a tool for spatial
sound rendering through headphones for blind people. Despite the many existing
devices, techniques for binaural synthesis face, since their appearance,
a major obstacle that prevents to realize high quality products. Indeed, to
make the illusion of a perceptible sound space, temporal and spectral distortions
resulting from the propagation of a sound wave to the ears must be
reproduced as accurately as possible. In addition to traditional difficulties in
audio signal processing, this enlightens the need to individualize the Head
Related Transfer Functions (HRTF), that encode the spatial impression of a
sound source. To achieve this individualization, a first approach consists in
measuring in the laboratory the HRTF of each individual. Although offering
convincing results, this technique is not yet applicable to the general public,
because the process is long, painful, and relatively expensive. This is why
mathematical modeling has been considered. Subject to a mesh representing
the morphology of the listener, the numerical solution of the wave propagation
equations could advantageously replace the measure. Today, large public
tools (e.g. Microsoft Kinect) allow the construction of satisfactory meshes,
which can be refined, when coupled with analytical basic shapes (spheres, Ellipse,
cones, etc..). The thesis then focuses on two main and complementary
axes.
On the one hand, we have developed (jointly with F. Alouges) a new
boundary element method software (MyBEM). Realized in Matlab, we apply
it to solve the equations of acoustics. For the calculation of the HRTF across
all audible frequencies, a new fast convolution method has been designed,
implemented and validated analytically. From the efficient one dimensional
quadrature of any Green kernel (Laplace, Helmholtz, Stokes, Maxwell, etc.), a
separation of variables allows a fast convolution in space calculation. Called
"Sparse Cardinal Sine Decomposition" (SCSD), this method is confronted
with the Fast Multipole Method (FMM) renowned as the state-of-the-art in
the domain.
3Moreover, once the HRTF are measured or calculated on a discrete spherical
grid, a resolution of a few angular degrees is essential to perform a high
quality spatial rendering. It is therefore necessary to interpolate the filters,
and that affects the quality of the audio rendering. However, a new understanding
initiated before the PhD allows an undersampling of the databases,
without producing audible artifacts, and providing with a possibility of individualization
by inverse filtering. Implemented in a spatial audio rendering
engine (PifPaf3D), this technique called "Morphological Model Decomposition"
has been validated by subjective tests. Moreover, many related tools
have been integrated into the engine, to further improve the spatial rendering,
such as acoustic rooms or headphones compensation.
These two stages, accomplished and mastered must now be coupled in
order to achieve a complete chain of digital binaural synthesis.
4Table des matières
Résumé/Abstract 1
1 Synthèse binaurale et HRTF 7
1.1 Introduction à l’écoute spatialisée . . . . . . . . . . . . . . . . 7
1.1.1 Espace sonore . . . . . . . . . . . . . . . . . . . . . . . 7
1.1.2 Théorie du Duplex . . . . . . . . . . . . . . . . . . . . 9
1.1.3 Head-Related Transfer Function . . . . . . . . . . . . . 11
1.2 Exemples de systèmes de spatialisation sonore . . . . . . . . . 14
1.2.1 Panning d’Amplitude, de la stéréo au VBAP . . . . . . 14
1.2.2 High Order Ambisonics, captation et restitution . . . . 17
1.2.3 Technologies binaurales, enregistrement et synthèse . . 21
1.3 Head-Related Transfer Function, what else ? . . . . . . . . . . 24
1.3.1 Modèle de HRTF, la sphère rigide . . . . . . . . . . . . 25
1.3.2 Mesures de HRTF, Acoustics Research Institute . . . . 31
1.3.3 Interpolation linéaire . . . . . . . . . . . . . . . . . . . 34
1.3.4 Interpolation par harmoniques sphériques . . . . . . . . 43
1.4 Décomposition par Modèle Morphologique . . . . . . . . . . . 48
1.4.1 Principe et résultats . . . . . . . . . . . . . . . . . . . 48
1.4.2 Interpolation optimisée . . . . . . . . . . . . . . . . . . 54
1.4.3 Variations de position . . . . . . . . . . . . . . . . . . 57
1.4.4 Déraffinement spatial d’une base de données . . . . . . 59
1.4.5 Vers une méthode d’individualisation . . . . . . . . . . 62
2 Moteur binaural PifPaf3D 67
2.1 Introduction et configuration . . . . . . . . . . . . . . . . . . . 67
2.2 Transport et contrôle . . . . . . . . . . . . . . . . . . . . . . . 70
2.3 Traitement Binaural . . . . . . . . . . . . . . . . . . . . . . . 72
2.4 Acoustique de salle et Ambisonics . . . . . . . . . . . . . . . . 77
2.5 Compensation du casque et égalisation . . . . . . . . . . . . . 81
2.6 SpherAudio Headphones . . . . . . . . . . . . . . . . . . . . . 83
53 Formulations intégrales rapides pour l’acoustique 89
3.1 Représentation et équations intégrales . . . . . . . . . . . . . . 91
3.1.1 Diffraction dans l’espace libre . . . . . . . . . . . . . . 91
3.1.2 Diffraction en présence d’un obstacle . . . . . . . . . . 93
3.1.3 Équations intégrales . . . . . . . . . . . . . . . . . . . 96
3.1.4 Formulations discrètes . . . . . . . . . . . . . . . . . . 99
3.2 Introduction aux méthodes multipolaires rapides . . . . . . . . 101
3.3 Nouvelle méthode rapide - SCSD . . . . . . . . . . . . . . . . 104
3.3.1 Vers un problème mono-dimensionnel . . . . . . . . . . 105
3.3.2 Résolution du problème . . . . . . . . . . . . . . . . . 106
3.3.3 Formalisme final pour l’équation de Helmholtz . . . . . 116
3.3.4 Extension vers Laplace (et plus si affinités...) . . . . . . 120
3.4 Comparaisons et performances . . . . . . . . . . . . . . . . . . 123
3.4.1 Méthodologie . . . . . . . . . . . . . . . . . . . . . . . 123
3.4.2 Résultats . . . . . . . . . . . . . . . . . . . . . . . . . 124
4 Moteur intégral MyBEM 131
4.1 Présentation . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
4.2 Validations . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
4.3 Applications au calcul de HRTF . . . . . . . . . . . . . . . . . 142
Conclusion 153
Bibliographie 155
Articles 163
6Chapitre 1
Synthèse binaurale et HRTF
Ce premier chapitre a pour but de poser le cadre théorique des recherches
en spatialisation sonore effectuées avant, puis pendant la thèse, notamment
en synthèse binaurale. En effet, il est important de préciser que les travaux
de recherche exposés ici s’inscrivent dans la continuité de travaux effectués
au préalable et par le même auteur au sein de la société Digital Media Solutions.
Ces travaux ont donné naissance à un spatialisateur innovant, appelé
PifPaf3D, écrit exclusivement en langage Matlab, dont le développement s’est
poursuivi au cours de ces trois années de thèse. Aussi, certains aspects pré-
sentés dans ce chapitre sortent du sujet de thèse initial, mais ont néanmoins
motivé des axes de développement non négligeables.
1.1 Introduction à l’écoute spatialisée
De par sa grande complexité et ses multiples domaines d’étude (physiologie,
neurologie, psycho-acoustique, physique ondulatoire, etc.), seuls les
principes généraux de la perception spatiale liée au système auditif humain
sont présentés ici, en guise d’introduction ou de rappel. Le lecteur curieux
est invité à se documenter sur les ouvrages de références [10], [15] et [68], ou
encore les manuscrits de thèse [20] et [70]. Pour une courte introduction, [14]
et [17] présentent un excellent résumé, avec une bibliographie détaillée.
1.1.1 Espace sonore
La perception sonore de l’espace, bien que souvent négligée au profit
de la perception visuelle, n’en est pas moins fondamentale puisqu’elle est
l’unique indicateur environnemental qui ne souffre d’aucune restriction spatiale.
À titre comparatif, le système visuel (vision fovéale + périphérique)
7Figure 1.1 – Vue subjective du célèbre jeu de tir à la première personne
Counter Strike.
ne délivre d’informations que sur une faible portion de l’espace, alors que
le système auditif est effectif pour toutes les directions, avec une précision
angulaire (Just Noticeable Difference) de l’ordre de quelques degrés. De plus,
le système auditif effectue une analyse permanente et souvent inconsciente de
l’environnement, tandis que le système visuel est de plus en plus requis pour
effectuer des tâches quotidiennes, nécessitant une attention particulière.
La capture d’écran présentée en figure 1.1 est un exemple issu du monde
des jeux vidéos. Cette vision subjective du célèbre jeu de tir à la première
personne (FPS) Counter Strike présente un certain nombre d’objets, comme
les mains du joueur, des caisses, une terrasse, des murs, etc. Bref, aucun
danger n’est visuellement apparent. Si le joueur ne dispose pas d’un système
de rendu sonore, il n’aura aucune information relative à son environnement
autre que celles fournies par la vision, ce qui est restrictif. Si, au contraire, le
joueur dispose d’un rendu stéréo classique, il aura accès à d’autres données
non visibles. Cependant, privé d’une perception sonore en rendu spatialisé, le
joueur devra balayer visuellement l’ensemble de la scène à la moindre alerte
auditive, pour identifier la position de la source sonore (tirs, bruits de pas,
explosion, etc.). Ce temps perdu peut lui être dommageable. Aussi, pour
que le joueur puisse pleinement et rapidement appréhender tout danger non
visible à l’écran, un rendu spatial de la scène sonore serait souhaitable. Les
mêmes principes s’appliquent au quotidien, à savoir que le système auditif
fournit l’ensemble des informations nécessaires à une perception spatiale de
l’environnent, dynamique et analytique.
La spatialisation sonore est une branche de l’Acoustique dont on peut défi-
8Figure 1.2 – Système auditif humain. (source www.alynsimardaudio.com)
nir l’objectif général comme étant "la (re)création d’un espace sonore subjectif
au niveau de l’auditeur" [20]. D’un point de vue physiologique, l’étude de la
spatialisation sonore part d’une hypothèse fondatrice, à savoir que l’oreille
interne et l’oreille moyenne n’interviennent pas dans la création des indices
de localisation tridimensionnels. La figure 1.2 fournit un embryon d’explication
par une représentation en coupe du système auditif humain. Lorsqu’une
onde sonore (une variation de pression dans l’air) atteint le tympan, celle-ci
est ensuite transmise mécaniquement par les osselets vers la cochlée. Cette
dernière encode alors le signal sonore en impulsions électriques, acheminées
au cerveau par le nerf auditif. Dans ce schéma simpliste, une fois que l’onde
sonore a fait vibrer le tympan, ce dernier transmet un signal qui se propage de
l’oreille moyenne jusqu’au cerveau, sans aucun ajout possible d’informations
spatiales. Aussi, la compression des informations de localisation encodées
dans ce signal ne peut être faite qu’avant.
1.1.2 Théorie du Duplex
Des indices dits de localisation sont inhérents à l’analyse discriminatoire
de l’espace sonore, effectuée par notre système cognitif. Dans ce sens, deux
contributions principales ont été mises en évidence par Lord Rayleigh en 1907,
formant ainsi la théorie du Duplex [74]. Cette dernière fut ainsi nommée car
elle met en lumière l’analyse des indices acoustiques interauraux, c’est-à-dire
issus des signaux perçus conjointement par les deux oreilles. Sur le schéma
9Figure 1.3 – Représentation graphique de l’ITD et de l’ILD. (source
www.kfs.oeaw.ac.at)
de la figure 1.3, l’onde sonore incidente est supposée provenir de l’infini.
De ce fait, les isovaleurs de pression acoustique sont orthogonales au sens
de propagation. Ainsi, de par l’orientation de l’onde dans le plan horizontal,
l’oreille gauche percevra l’information plus tôt et plus fort que l’oreille droite.
Ces écarts de temps et d’intensité sont caractérisés respectivement par l’ITD
et l’ILD :
– Interaural Time Difference, ITD : La différence interaurale de temps
est la différence de temps d’arrivée d’une onde sonore entre les deux
oreilles. Cet indice de localisation joue un rôle fondamental pour la
localisation dans le plan horizontal, notamment en basse fréquence ;
– Interaural Level/Intensity Difference, ILD ou IID : La différence interaurale
de niveau est la différence d’intensité de l’onde sonore entre
les deux oreilles. Cet indice de localisation joue de même un rôle fondamental
pour la localisation azimutale, notamment en moyenne et haute
fréquence.
En revanche, cette théorie est incomplète pour les sources sonores qui seraient,
par exemple, dans le plan médian. En effet, l’ITD et l’ILD sont grossièrement
identiques pour une source sonore devant, dessus ou encore derrière
un auditeur. Pourtant, l’être humain est capable de discriminer ces directions,
avec une précision exemplaire. Le fait est que la théorie du Duplex ne tient
pas compte des dissymétries de la tête et du pavillon.
10Figure 1.4 – Cônes de confusion, représentant les isovaleurs de l’ITD et
de l’ILD pour une approximation de tête sphérique sans pavillon. (source
www.humansystems.arc.nasa.gov)
1.1.3 Head-Related Transfer Function
Avec l’approximation de tête sphérique [85], l’ILD et l’ITD de la théorie
du Duplex n’apportent pas d’informations discriminatoires dans le plan median,
ni dans des cônes communément appelés "cônes de confusion" (fig. 1.4).
Il manque donc un indice de localisation pour compléter cette théorie. Ce dernier
indice est principalement lié à la morphologie de l’auditeur, notamment
la géométrie du pavillon et du conduit auditif de l’oreille externe (fig. 1.2)
qui modifient singulièrement l’onde sonore incidente. En effet, des ondes ré-
fléchies peuvent être engendrées selon l’incidence, ainsi que des déformations
spectrales liées à des modes de résonance (fig. 1.5). Le timbre du signal émis
par la source sonore est alors modifié et ce, en fonction de sa position dans
l’espace. Il en résulte des filtres spatio-fréquentiels relativement complexes,
encore appelés Direction-Dependent Filters (fig. 1.6).
Ces trois indices (ITD, ILD et DDF) sont inclus dans un modèle plus
général de filtres fréquentiels communément appelés Head-Related Transfert
Functions (HRTF). Par Transformée de Fourier, ces filtres s’expriment aussi
bien en domaine fréquentiel qu’en domaine temporel, sous forme de HeadRelated
Impulse Responses (HRIR), et peuvent être définis comme suit :
HRTF : R
3 × R
+ → C
(r, θ, φ) × f → HRT F
HRIR : R
3 × R
+ → R
(r, θ, φ) × t → HRIR
11Figure 1.5 – Modes de résonance de l’oreille externe. (source
www.dtmblabber.blogspot.fr, d’après [78])
Figure 1.6 – Représentation directionelle des Directions Depending Filters
de l’oreille gauche du sujet 003 de la base CIPIC. Visualisation de l’amplitude
spectrale (dB) pour des sources sonores situées sur la sphère unité (croix
noire), à fréquence fixe, dans le repère de la figure 1.4. De gauche à droite,
la fréquence vaut respectivement 2 kHz, 8 kHz et 15 kHz.
12Figure 1.7 – Amplitude spectrale (dB) des HRTF de l’oreille gauche du
sujet 003 de la base CIPIC, dans le plan médian.
L’amplitude spectrale (dB) pour quelques positions de ces filtres est représentée
sur la figure 1.7. L’azimut est fixé à 0˚, pour une élévation croissante de 0˚
à 80˚ (plan median). Comme le montre cette figure, il existe une forte variabilité
entre chacun de ces filtres, induisant une grande complexité dans leur
étude. Ces fonctions de transfert HRTF établissent donc une cartographie
spatiale minutieuse du système auditif humain et sont, de par leur nature
même, propres à chaque individu. Enfin, il est intéressant de souligner que
ces filtres peuvent être :
– Mesurés par réponse impulsionnelle sous forme de HRIR (e.g. [3], [62],
[6]) ;
– Modélisés de manière analytique (e.g. [85], [57], [25]) ou par simulation
numérique (e.g. [50], [51], [39]) ;
– Échangés sous forme de bases de données (e.g. [65], [9]) ;
– Individualisés, par divers et nommbreux procédés.
La compréhension et l’exploitation de ces HRTF représente un enjeu majeur
pour la recherche en spatialisation sonore, mais aussi pour les industriels
soucieux d’innovations technologiques. En effet, la perception d’un espace sonore
réaliste devient possible dès lors que les trois indices formant les HRTF
sont correctement restitués, ou dans une moindre mesure au moins l’un des
trois. Aussi, tout système de restitution sonore en exploite certaines proprié-
tés, directement sur casque audio ou indirectement sur enceintes.
13Figure 1.8 – Principe de la stéréophonie et notion de "Sweet Spot".
1.2 Exemples de systèmes de spatialisation
sonore
Il existe de nombreux systèmes de spatialisation sonore, chacun exploitant
de savants mélanges au sein des dimensions perceptives et physiques.
Dans cette section, trois de ces techniques sont détaillées, à savoir le panning
d’amplitude et sa généralisation au Vector Base Amplitude Panning (VBAP),
l’approche Ambisonics et son extension en High Order Ambisonics et pour
terminer la synthèse binaurale. Ce choix est principalement motivé par le fait
qu’elles ont toutes trois été intégrées dans le spatialisateur PifPaf3D, moteur
de rendu audio 3D Matlab détaillé dans le chapitre suivant.
1.2.1 Panning d’Amplitude, de la stéréo au VBAP
Le panning d’amplitude est apparu avec les premiers supports utilisant
plus d’un canal de diffusion et fait partie des plus anciennes techniques de
spatialisation sonore [83]. Le principe théorique est relativement simple, à
savoir la création d’une image sonore virtuelle dite "Fantôme", en jouant
sur la différence d’intensité de sources sonores réelles ( haut-parleurs). Tout
l’art de l’ingénieur du son consiste en l’obtention d’une image sonore robuste
et réaliste, répartissant judicieusement l’ensemble des objets virtuels
sur des segments reliant les sources réelles. La restitution stéréophonique,
encore très largement dominante aujourd’hui, est fondée sur ce principe. En
disposant l’auditeur et deux haut-parleurs (gauche et droit) sur les sommets
d’un triangle équilatéral, ce système permet une restitution spatialisée sur
une dimension d’espace. Il est important de noter qu’une contrainte forte af-
14Figure 1.9 – Disposition fixée de haut-parleurs en 5.1 (en traits pleins), 9.1
(en tirets) et 22.2 (en pointillés). (source Wikipedia)
fecte l’ensemble des systèmes de spatialisation sonore sur enceintes, à savoir
le positionnement des sources sonores par rapport à l’auditeur (notion de
Sweet Spot). Celle-ci est déjà présente sur un système à deux canaux, tel que
le montre la figure 1.8.
Dans la lignée de la stéréophonie, plusieurs systèmes de restitution en
audio spatialisé sont progressivement apparus, comme la quadriphonie, le
5.1, le 7.1, le 9.1, ou plus récemment le 22.2 de la NHK (fig. 1.9, [42]).
Tous utilisent des maillages de haut-parleurs répartis sur des positions préalablement
fixées dans l’espace autour de l’auditeur. Ces systèmes permettent
d’étendre les principes fondateurs de la stéréophonie sur des maillages plus
denses de haut-parleurs, sur un cercle entourant l’auditeur (1D), voire sur
une sphère (2D). En appliquant des lois de panning prédéfinies, des sources
sonores fantômes peuvent ainsi être créées. Il est intéressant de remarquer
qu’aucun de ces systèmes n’est réellement 3D en terme de répartition de
haut-parleurs. Ceci est notamment lié à la faible précision de la localisation
en distance, qui est préférentiellement rendue dans sa dimension perceptive
plutôt que physique [48].
Enfin, de récents travaux ont donné naissance aux techniques de Vector
15Figure 1.10 – Principe du Vector Base Amplitude Panning : la source virtuelle,
symbolisée par sa pression acoustique p, est générée par panning d’intensité
de coefficients Ij appliqués aux trois sources sonores adjacentes j.
(source www.ausim3d.com/products/Vectsonic)
Base Amplitude Panning (VBAP), autorisant une répartition quelconque des
haut-parleurs sur une sphère entourant l’auditeur [73]. Cette approche est une
extension de la stéréo vers un système à multiples sources sonores réelles,
ce qui permet de définir un support quelconque pour les sources fantômes
(triangle, quadrangle, etc.). Une loi d’interpolation est alors appliquée aux
canaux pour déterminer leurs gains, en utilisant notamment les cordonnées
barycentriques de la source virtuelle dans la base formée par les sources réelles
(fig. 1.10). Un maillage quelconque de haut-parleurs peut être envisagé, ce
qui permet de s’affranchir des contraintes liées aux systèmes fixes précédents.
Cette méthode a été implémentée dans le spatialisateur PifPaf3D, en marge
des travaux de thèse, et testée sur un maillage de 16 haut-parleurs répartis
dans une pièce de type bureau. Le script réalisé permet notamment de générer
le maillage triangulaire selon la position absolue des haut-parleurs, et de
naviguer en temps réel dans ses éléments pour créer les sources fantômes.
Les résultats de cette étude feront éventuellement l’objet d’une publication
ultérieure.
Face au développement de ces nouveaux systèmes de restitution, toujours
plus complexes et précis, la notion d’objet sonore ponctuel devient dès
lors incontournable pour que les techniques de spatialisation soient humaine-
16Figure 1.11 – (Gauche) Schéma du microphone Soundfield tel que breveté
[19]. Quatre capsules cardioïdes sont placées sur les faces d’un tétraèdre
régulier, dont les signaux (RF,LF,RB,LB) constituent le A-Format, ou format
ambisonique brut. (Droite) Les composantes directionnelles du B-Format
(W,X,Y,Z) ou format encodé. (source [20]).
ment réalisables. En effet, le mixage stéréo ne nécessite qu’un potentiomètre
pour répartir l’intensité sonore de la source virtuelle entre les deux canaux
de diffusion. Dans le cas d’un maillage triangulaire dense, il est nécessaire
de manipuler des objets sur des surfaces, ce qui complique singulièrement
l’interface homme-machine. C’est pourquoi l’ensemble de la chaîne de traitement
audio, de la captation à la restitution en passant par le mixage, subit
aujourd’hui de grands bouleversements.
1.2.2 High Order Ambisonics, captation et restitution
Parmi les nombreuses techniques émergentes de spatialisation sonore,
l’approche Ambisonics et son extension High Order Ambisonics (HOA) fournissent
une gamme d’outils complète sur l’ensemble de la chaîne de production
(e.g. [19], [20], [21], [33]). Originellement, elles sont issues des techniques
de prise de son par couple MS. Le principe général est de capter simultanément
et ponctuellement un champ sonore à l’aide d’un micro bidirectif
et d’un micro omnidirectionnel. Des informations directionnelles de la scène
sonore sont alors nativement incluses dans les signaux de sortie des microphones,
qui peuvent-être stockés ou échangés comme tels. Pour que l’image
sonore soit directement rendue, dans une dimension d’espace, il suffit ensuite
de restituer ce champ sur un système stéréophonique, par une sommation
17des signaux sur un haut-parleur et une opposition de phase sur l’autre. Cette
technique de prise de son fut généralisée aux trois dimensions d’espace par
Gerzon et donna naissance au fameux encodage B-Format du microphone
Soundfield (fig. 1.11). À la restitution, le B- Format est décodé pour s’adapter
au système de haut-parleurs, par exemple disposés sur les sommets d’un
cube. Ce processus d’encodage-décodage d’une scène sonore spatialisée est
une caractéristique propre des méthodes Ambisonics.
Cependant, cette approche souffre d’une faible précision spatiale de par la
nature même de la captation, à savoir cardioïde. Aussi, de nombreux travaux,
notamment ceux de J. Daniel [20], ont permis de créer un cadre robuste
pour étendre Ambisonics vers une précision supérieure, appelée High order
Ambisonics (HOA). Cette extension peut s’introduire de façon théorique en
considérant le problème de propagation des ondes dans un espace Ω homogène
et isotrope, dénué de sources, en régime harmonique. Sous ces hypothèses,
l’équation de Helmholtz formalise mathématiquement ce type de problème
et s’écrit comme suit :
−(∆ + k
2
)u = 0 avec u ∈ Ω. (1.1)
Cette équation peut être résolue en introduisant les harmoniques sphériques
(Y
m
l
), qui sont des fonctions propres de l’opérateur Laplace Beltrami sur la
sphère S
2
, associées aux valeurs propres l(l + 1) (e.g. [69], [82] et fig. 1.12).
Elles forment une base orthonormée pour le produit scalaire L
2
(S
2
) et sont
définies comme la trace sur la sphère unité S
2 des polynômes homogènes
harmoniques de degré l (i.e. à Laplacien nul sur R
3
). Cette base orthonormée
(Y
m
l
) peut être considérée comme un équivalent pour la sphère dans R
3 de
la base (e
inθ) pour le cercle dans le plan R
2
. D’un point de vue plus formel,
les fonctions de Legendre :
P
m
l
(x) = (−1)m(1 − x
2
)
m/2
d
m
dxm
Pl(x) avec m ≥ 0,
définies pour tout l dans N, −l ≤ m ≤ l et −1 < x < 1, construisent la
famille (Y
m
l
), définie par :
Y
m
l
(θ, φ) =
vuut
2l + 1
4π
(l − m)!
(l + m)!P
m
l
(cos(φ))e
imθ
. (1.2)
En fixant Ω comme l’intérieur ou l’extérieur de la sphère unité S
2
, toute
fonction u solution de l’équation de Helmholtz (1.1) peut se décomposer en
harmoniques sphériques comme suit :
u(k, r, θ, φ) = X
l,m
α
m
l
(k)Ul(kr)Y
m
l
(θ, φ). (1.3)
18Figure 1.12 – Représentation spatiale des cinq premières harmoniques sphé-
rique Y
m
l
, telles que r = |Y
m
l
(θ, φ)|.
En pratique, selon les conditions aux limites du problème considéré (Dirichlet,
Neumann, Fourier, etc.), la fonction radiale Ul(kr) est construite par
des combinaisons linéaires dans C de fonctions de Bessel sphériques, Hankel
sphériques et de leurs dérivées.
D’un point de vue strictement mathématique, le formalisme HOA est
pleinement contenu dans l’équation (1.3) et la propriété d’orthonormalité des
harmoniques sphériques pour le produit L
2
(S
2
) [20]. En effet, la captation
puis l’encodage HOA consiste en la création des signaux de projection α
m
l
sur
les harmoniques sphériques. Ces signaux peuvent être stockés, échangés et
utilisés en l’état pour effectuer des opérations simples, comme des zooms ou
des rotations spatiales. Par exemple, le B-Format est l’équivalent du signal
α
m
l pour l ≤ 1. Enfin, s’ensuit l’étape de décodage pour la restitution sur un
système de haut-parleurs en calculant cette fois les canaux u correspondants
aux signaux α
m
l
. Le protocole suivant, non exhaustif, résume les grandes
étapes d’un encodage-décodage HOA dans le cas d’une captation-restitution
d’une scène sonore spatialisée.
Encodage :
1. Suite à la captation d’une scène sonore par une sphère de microphones,
le problème aux limites correspondant est formalisé en domaine de Fou-
19rier pour expliciter les fonctions Ul(kr) sous forme de filtres fréquentiels
;
2. En considérant les valeurs du champ u aux positions des microphones
par rapport au centre de la sphère, la série en (1.3) peut alors être
tronquée ;
3. En projetant la série (1.3) tronquée sur la base orthonormée des harmoniques
sphériques par intégration sur S
2
, un système linéaire est
formé ;
4. Puis, ce système est résolu, fréquence par fréquence, pour déterminer
les coefficients α
m
l
(k) de la décomposition.
Cette étape d’encodage HOA permet de créer les signaux fréquentiels α
m
l
(k),
ou encore temporels α
m
l
(t) par transformée de Fourier inverse. Ces derniers
définissent un format d’échange évolutif et modulable (rotation, zoom, etc.),
indépendant de la sphère de microphones utilisée pour la captation. Le BFormat
Ambisonics est la version à l’ordre l = 1 du format HOA et le couple
MS en est la version d’ordre l = 1 avec m = 0 uniquement.
Décodage :
1. Un nouveau problème aux limites est formalisé pour la diffusion en
champ libre par une sphère de haut-parleurs, explicitant notamment
un nouveau filtre fréquentiel et une nouvelle matrice de décodage liés
aux positions des haut-parleurs dans l’espace centré sur l’auditeur ;
2. Par intégration sur S
2
, un nouveau système linéaire est formé ayant
pour inconnues les signaux ui discrets ;
3. Ce système est cette fois inversé, délivrant ainsi le signal à diffuser par
les haut-parleurs pour recréer un champ sonore identique à la captation.
Une version améliorée de ce protocole a été implémentée durant la thèse dans
le moteur PifPaf3D, notamment pour effectuer un rendu binaural d’une captation
par microphone Soundfield en A-Format (fig. 1.11). De nombreux dé-
tails soulèvent de grandes difficultés, non présentées dans ce manuscrit, mais
bien connues de l’homme de l’art. Peuvent être citées en exemple la troncature
de la série harmonique dans l’équation (1.3), les phénomènes d’aliasing
fréquentiel liés aux diverses discrétisations, la pseudo inversion de la matrice
rectangulaire des harmoniques sphériques, ou encore la régularisation
des filtres fréquentiels faisant appels aux fonctions de Bessel et Hankel sphé-
riques. Néanmoins, le module Matlab d’encodage-décodage HOA a donné
des résultats encourageants pour des captations par microphone Soundfield.
Il fera sans doute l’objet de recherches ultérieures, par exemple sur le rendu
20de microphones d’ordres plus élevés, ou non sphériques, ou encore pour de la
localisation spatiale de sources sonores.
Pour conclure, comme toute technique audio, HOA présente des avantages
et des inconvénients, à la fois sur les plans perceptif, physique et technique.
Ce manuscrit n’ayant pas pour vocation d’en faire une étude détaillée, mais
plutôt d’en expliciter les grandes lignes pour comprendre et exploiter l’outil,
le lecteur curieux pourra se documenter sur une littérature abondante
(e.g. [11], [20], [21], [59], [71]).
1.2.3 Technologies binaurales, enregistrement et synthèse
Binaural, binaurale, binauraux (adj. du latin bini/paire et auris/oreille)
se dit des perceptions auditives engendrées par une stimulation simultanée
des deux oreilles. (Larousse 2013 )
Cette définition introductive a pour but de fixer le vocabulaire employé
dans ce manuscrit. En effet, le terme binaural tend à se démocratiser ces
dernières années, en devenant un nom commun synonyme d’une écoute spatialisée
sur casque audio. En accord avec la définition précédente, il doit en
réalité être employé comme adjectif caractérisant une stimulation simultanée
des deux oreilles, ce qui induit une certaine prudence d’utilisation 1
... Ceci
étant, les technologies binaurales peuvent être introduites en distinguant
deux grandes techniques, ayant comme point commun leur mode de restitution
essentiellement sur casque audio, voire sur haut-parleur par Cross-Talk
Cancellation.
Tout d’abord, l’enregistrement binaural (fig. 1.13) consiste à effectuer une
prise de son par l’intermédiaire de deux microphones placés au niveau des
tympans d’un être humain, ou d’un objet reprenant tout ou partie des caractéristiques
de l’oreille externe (mannequin Gras Kemar, tête artificielle Neumann
KU100, oreilles Otokinoko, sphère The Audio BS3D, etc.). Cette technique
contient nativement des informations perceptives relatives à la scène
sonore originale, ce qui lui confère (en général) un rendu plutôt réaliste, à
la fois en direction et en distance. Cependant, elle souffre des contraintes
suivantes, liées à la "compression" des informations spatiales dans un signal
stéréo :
1. En effet, la quasi-totalité du monde de l’audio est basé sur une stimulation simultanée
des deux oreilles... Au même titre, les HRTF sont bien souvent associées au "binaural",
alors que tout système de restitution audio exploite de manière directe ou indirecte tout
ou partie des informations de localisation contenues dans ces filtres.
21Figure 1.13 – (Gauche) Enregistrement binaural par microphones DPA,
situés à l’embouchure du conduit auditif d’un joueur de violoncelle. (Droite)
Tête artificielle Neumann KU100, avec microphones intégrés au creux de
chaque "oreille". (source www.neumann.com)
1. Les divers objets de la scène sonore forment un tout difficilement dissociable
;
2. Il est difficile de construire manuellement une scène sonore ;
3. Les retouches par égaliseurs, compresseurs, limiteurs, réverbérateurs et
autres effets risquent d’altérer fortement la spatialisation, native à la
captation ;
4. A posteriori, les filtres HRTF liés à la prise de son ne peuvent pas être
individualisés à la morphologie de l’auditeur.
Aussi, même si cette approche est connue depuis la fin des années 60, ces
difficultés ont sans doute fait obstacle à sa popularisation, à la fois chez les
professionnels et les particuliers.
La seconde technique, appelée synthèse binaurale (fig. 1.14), réside en
l’application d’algorithmes de traitement du signal audio pour recréer artifi-
ciellement la perception spatialisée d’une scène sonore. Le principe de base
consiste à mesurer par réponse impulsionnelle les filtres HRIR gauches et
droits d’un auditeur, pour une position donnée dans l’espace. Puis, après
convolution d’une source audio mono par ces deux filtres, le fichier stéréo
issu de cette manipulation peut être écouté sur n’importe quel casque audio
(de facture honorable !). Dès lors, la source mono sera perçue dans la
direction de la position mesurée. En pratique, les HRIR sont mesurées en
plusieurs positions de l’espace et une interpolation spatiale de ces filtres est
effectuée pour convoluer n’importe quelle source audio dans n’importe quelle
22Figure 1.14 – (Gauche) Principe de base de la synthèse binaurale : x˜(t) correspond
au signal mono xA(t), perçu à la position (r, θ, φ) et délivré par les signaux
binauraux xL(t) et xR(t). Pour ce faire, xA(t) est convolué par les filtres
HRIR gauches h˜
L(t) et droit h˜
R(t) de la position (r, θ, φ), généralement obtenus
par interpolation sur une base de données de HRIR. (source Wikipedia)
(Droite) Système de mesure de HRTF de l’ARI. (source www.kfs.oeaw.ac.at)
23direction. Sous réserve d’un workflow draconien, la synthèse binaurale peut
s’affranchir des contraintes précédentes liées à l’enregistrement binaural, à
savoir :
1. Les sources sonores peuvent être des objets dissociés, issus de prises de
son séparées ou non ;
2. Une scène sonore se construit manuellement, par positionnement des
sources dans l’espace ;
3. Toutes les retouches nécessaires peuvent être faites avant le rendu par
synthèse binaurale, préférentiellement effectué en dernier dans la chaîne
de production sonore ;
4. Les bases de données HRIR utilisées pour les convolutions peuvent être
différentes selon l’utilisateur, voire même individualisées.
Ce sont toutes ces possibilités offertes par la synthèse binaurale qui ont motivé
l’ensemble de ce travail de recherche appliquée, en particulier le dernier point
sur l’individualisation des filtres HRIR/HRTF par des méthodes numériques
non intrusives. Aussi, même si cette technique est beaucoup plus difficile à
mettre en œuvre, les progrès matériels et logiciels de ces dix dernières années
appliqués au traitement du signal offrent aujourd’hui de nouvelles perspectives.
Le contexte CIFRE de cette thèse n’est d’ailleurs pas sans rappeler
que de nombreux industriels suivent de très (très) près les récentes avancées
faites en synthèse binaurale, toujours plus prometteuses.
1.3 Head-Related Transfer Function, what else ?
Pour mieux saisir les difficultés liées à l’utilisation des filtres HRTF en
synthèse binaurale, une analyse systémique de ces filtres est présentée dans
cette section. Cette analyse est effectuée dans la dimension physique des fonctions
de transfert, sans se soucier des questions perceptives. La méthodologie
est discutable au regard de la psycho-acoustique, mais facilite l’appréhension
des résultats de mesures, ainsi que leur couplage avec des résultats issus de
modélisations analytiques ou de simulations numériques. Par ailleurs, cette
approche rigoureuse a donné naissance à une décomposition fonctionnelle
des HRTF en éléments modélisables et résiduels, détaillée dans la section
suivante. Aussi, dans toute la suite, les HRTF seront avant tout considérées
comme des solutions de radiation sphérique d’un problème de diffraction des
ondes sonores par un objet essentiellement rigide, à savoir l’être humain.
24Figure 1.15 – Repère en coordonnées sphériques, convention en rayonlongitude-latitude
correspondant respectivement à la distance (ρ), l’azimut
(θ) et l’élévation (φ). (source Wikipedia)
1.3.1 Modèle de HRTF, la sphère rigide
Avant de s’intéresser aux HRTF réelles issues de mesures en laboratoire,
certaines bases méritent d’être posées en étudiant un modèle simplifié, comme
les HRTF d’une sphère rigide sans pavillon. Ceci permet notamment d’introduire
différents modes de représentations, ainsi que des résultats utiles pour
la suite. Pour ce faire, il existe deux principaux modèles associés au problème
de diffraction d’une onde sonore par un objet sphérique.
Le premier modèle fournit une solution dans le domaine temporel, à savoir
une évaluation analytique du retard interaural (ITD) pour une sphère rigide
(e.g. [57], [85]). Ce retard correspond à la différence de temps de propagation
d’une onde sonore à l’infini entre deux points diamétralement opposés sur
la sphère. En considérant que la direction d’une source sonore à l’infini est
caractérisée par un angle d’azimut θ et d’élévation φ dans un repère sphérique
(fig. 1.15), le retard interaural τ s’exprime par :
τ =
a
c
× (arcsin(cos φ sin θ) + cos φ sin θ), (1.4)
avec a le rayon de la tête sphérique considérée et c la célérité des ondes sonores
dans l’air. La figure (fig. 1.16) donne une représentation du retard τ calculé
par le modèle d’ITD (1.4), en fonction de l’azimut θ, pour trois élévations φ
significatives. Le rayon de tête choisi pour les calculs correspond au rayon de
tête sphérique moyen (a = 8.74 cm [58]) et la vitesse du son dans l’air est
25Figure 1.16 – Représentation de l’ITD τ calculé par le modèle de Larcher
(1.4), en fonction de l’azimut θ, pour trois élévations φ significatives.
prise à 15˚C (c = 340 m/s). En pratique, ce modèle peut simplement être mis
en œuvre en approchant les HRTF comme une combinaison de déformations
spectrales en amplitude et d’un retard pur :
HRT F(θ, φ) = |HRT F(θ, φ)|e
iτ(θ,φ)
.
Cette décomposition est surtout valable en basse fréquence, lorsque l’approximation
de tête sphérique est légitime. Cette technique a été implémentée dès
la toute première version du logiciel PifPaf3D, notamment pour faciliter les
interpolations de filtres et autoriser une personnalisation de la synthèse binaurale
au diamètre de la tête de l’auditeur. Cependant, malgré des résultats
perceptifs encourageants, cette approche est trop grossière en haute fréquence
pour être raisonnablement suffisante.
Le second modèle sphérique a été introduit par Duda [25] et exploite les
solutions analytiques du problème de diffraction d’onde par une sphère rigide
de rayon a, en régime harmonique de nombre d’onde k. La source sonore est
cette fois ponctuelle et localisée dans l’espace. Comme ce problème possède
une symétrie de révolution, la position de cette source sera entièrement dé-
terminée par sa distance r et son angle d’incidence θ. La fonction de transfert
HS issue de cette modélisation est analytique et donnée par :
HS(k, a, r, θ) = −
r
ka2
e
−ikr X∞
m=0
(2m + 1)Pm(cos θ)
hm(kr)
h
0
m(ka)
, r > a, (1.5)
où Pm est le polynôme de Legendre de degré m et hm la fonction de Hankel
sphérique de degré m. De plus, Duda propose un algorithme récursif
pour évaluer les fonctions de Hankel et leurs dérivées, ce qui permet un calcul
rapide et facilite l’étude. Les deux premières représentations graphiques
26Figure 1.17 – Représentations des HRTF du modèle sphérique de Duda,
dans le plan azimutal. (Haut) Amplitude spectrale. (Milieu) Portrait de
phase. (Bas) Amplitude signal HRIR.
27de la figure 1.17 montrent l’amplitude spectrale et le portrait de phase des
HRTF sphériques de Duda, évalués à partir de l’équation (1.5). Dans le repère
sphérique de la figure 1.15, ces deux grandeurs sont données pour "l’oreille
gauche", située en (0, a, 0). La discrétisation angulaire du plan d’incidence
(azimutal) est de l’ordre du degré et la discrétisation fréquentielle compte 129
échantillons répartis régulièrement entre 0 et 24 kHz. Les valeurs d’amplitude
spectrale sont données en dB sur un intervalle audible fixe ([−60, 0] dB) et
la phase est exprimée en radian ([−π, π] rad). Sur la figure 1.17, les amplitudes
spectrales des sources ipsilatérales sont relativement monotones,
alors qu’apparaissent des interférences constructives et destructives pour les
sources contralatérales. De plus, pour les sources diamétralement opposées
au point de mesure sur la sphère (θ = 270˚), les interférences constructives
amènent un gain jusque 20 dB supérieur aux sources juxtaposées. Enfin, le
portrait de phase est relativement uniforme, avec des isovaleurs caractéristiques
d’un problème à géométrie sphérique, excepté pour ces mêmes sources
diamétralement opposées, qui présentent un saut de phase. La dernière repré-
sentation graphique de la figure 1.17 montre la transformée de Fourier inverse
des HRTF sphériques, soit les HRIR du modèle sphérique de Duda dans le
plan d’incidence. La discrétisation temporelle compte 256 échantillons sur
un intervalle de l’ordre de quelques millisecondes. Les valeurs d’amplitude
du signal sont données en dB sur un intervalle audible fixe ([−60, 0] dB). Le
modèle d’ITD de Larcher (1.4) en élévation nulle (fig. 1.16) est clairement
visible sur la représentation temporelle des HRIR sphériques. Il est néanmoins
intéressant de noter un lissage pour l’azimut θ = 90˚, correspondant
à une source ipsilatérale. Ceci peut s’expliquer par l’approximation d’onde
incidente à l’infini dans le modèle de Larcher, qui diffère de l’approximation
en sources ponctuelles dans le modèle de Duda. Par ailleurs, un second front
d’ondes d’amplitude non négligeable apparaît pour les sources contralaté-
rales, retardé par rapport au front d’onde caractérisant l’ITD. Ce résidu est
généré par les ondes contournant la sphère par le chemin diamétralement
opposé au plus court trajet, dans le plan d’incidence.
La figure 1.17 donne une première forme de représentation graphique des
HRTF sphériques, à la fois en fréquence, en temps et en espace. Cependant,
autant où les représentations strictement azimutales s’avèrent consistantes
pour les HRTF sphériques, autant où elles sont incomplètes pour les HRTF
réelles. En effet, ces dernières sont des données directionnelles n’ayant a priori
pas de symétries particulières. Or, l’ajout d’une dimension pour l’élévation
complique grandement l’analyse, qui nécessite des supports clairs et intuitifs
pour être rigoureuse et efficace. Aussi, en fixant la fréquence, une représentation
aplatie en azimut θ et élévation φ de l’amplitude spectrale (fig. 1.18) et
du portrait de phase (fig. 1.19), est un bon complément des représentations
28Figure 1.18 – Amplitude spectrale (dB) des HRTF gauches du modèle
sphérique de Duda (eq. 1.5). Représentation en azimut θ et élévation φ, à
fréquence fixe f.
29Figure 1.19 – Portrait de phase (radian) des HRTF gauches du modèle
sphérique de Duda (eq. 1.5). Représentation en azimut θ et élévation φ, à
fréquence fixe f.
30Figure 1.20 – Répartition spatiale des positions de mesures pour la base de
données ARI. (source [6])
exclusivement fréquence-azimut précédentes. Sur ces figures, les discrétisations
en azimut θ et élévation φ pour le modèle analytique de Duda sont
de l’ordre du degré dans chaque dimension. Cette nouvelle représentation
offre l’avantage d’afficher toutes les données spatiales sans idées reçues et de
mesurer pleinement la nature ondulatoire des HRTF. En effet, l’amplitude
spectrale et la phase des HRTF sphériques de Duda (fig. 1.18 et 1.19) ne
sont pas sans rappeler les figures d’interférences classiques des problèmes de
diffraction d’onde. Enfin, la symétrie axiale d’axe de rotation interaural Oy
est parfaitement visible.
Tous les outils de représentation graphique étant désormais établis avec
un modèle analytique, le problème réel des HRTF mesurées peut maintenant
être abordé.
1.3.2 Mesures de HRTF, Acoustics Research Institute
La base de données récemment mesurée à l’Acoustics Research Institute
de l’Austrian Academy of Science a été utilisée dans cette section à des fins
de recherche, sous licence Creative Commons (cc). Ces mesures présentent
l’avantage de compter 1550 positions, quasi-uniformément espacées sur plus
d’une demi-sphère (fig. 1.20), avec un écart angulaire de 2.5˚ frontalement
et de 5˚ sinon. Au vu des schémas de diffraction précédents pour le modèle
sphérique analytique (fig. 1.18 et 1.19), ce faible écart angulaire semble
31indispensable pour représenter le plus fidèlement possible les variations en
hautes fréquences. Pour réaliser ces mesures, le dispositif expérimental mis
en place consiste en une batterie de haut-parleurs disposés en arc de cercle
autour d’une chaise rotative où s’assoit le sujet, dans une chambre semianechoïque
(fig. 1.14). Les HRIR sont mesurées par sweep multiples [64] de
50 Hz à 20 kHz, puis post-traitées par filtrage inverse en minimum de phase
de l’amplitude spectrale de la Common Transfer Function (CTF), afin de
compenser l’impact de l’équipement sur la mesure. Pour finir, elles ont été
filtrées par coupe-haut à 18 kHz (ce qui rend les données non valables au-delà
de cette limite), puis fenêtrées en temps sur 256 échantillons (Tukey asymé-
trique). Pour plus d’informations sur le protocole expérimental, un extrait
est disponible sur le site de l’ARI [6]. Enfin, il n’est pas inutile de préciser
que cette base de données est disponible au format Matlab, ce qui en facilite
grandement l’usage.
La figure 1.21 donne les représentations de l’amplitude spectrale, de la
phase et de l’amplitude signal des HRTF du sujet NH5 de la base ARI, en
azimut-fréquence. La discrétisation azimutale θ est semi-régulière, avec un
pas de 2.5˚ autour de θ = 0˚ et un pas de 5˚ sinon. Les valeurs d’amplitude
spectrale ont été normalisées et sont données en dB sur l’intervalle audible
fixe [−60, 0] dB, pour faciliter les comparaisons avec le modèle sphérique
de Duda (fig. 1.17). La discrétisation fréquentielle compte 129 échantillons
répartis régulièrement entre 0 et 24 kHz et l’équivalent temporel présente
256 échantillons sur un intervalle de l’ordre de quelques millisecondes. D’une
part, sur la représentation temporelle, le modèle d’ITD de Larcher (fig. 1.16)
est parfaitement visible, avec le même décrochement à θ = 90˚ que pour la
modélisation analytique de Duda (fig. 1.17). De plus, un certain nombre de
réflexions supplémentaires, engendrées par le pavillon de l’oreille, mais aussi
les épaules et le torse, se dessinent en suivant les mêmes courbes d’ITD.
Ces réflexions sont à l’origine des importantes déformations spectrales en
amplitude et en phase, caractéristiques des HRTF. D’autre part, certaines
remarques peuvent se dégager de l’analyse comparative des représentations
fréquentielles des HRTF modélisées (fig. 1.17) et mesurées (fig. 1.21) :
– Les HRTF des sources contralatérales (θ proche de 270˚) sont beaucoup
plus complexes que celles ipsilatérales (θ proche de 90˚) ;
– L’amplitude spectrale des HRTF mesurées est relativement lisse, dans
le sens où ses variations présentent peu de sauts critiques, excepté en
faible amplitude ;
– Le portrait de phase présente quant à lui de fortes variations et de
nombreux sauts ;
– Le modèle de Duda est visible sur l’amplitude spectrale, notamment
en basse fréquence pour l’oreille contralatérale et se retrouve aussi sur
32Figure 1.21 – Représentations des HRTF du sujet NH5 de la base de données
ARI, dans le plan azimutal. (Haut) Amplitude spectrale, avec filtrage coupehaut
d’origine. (Milieu) Portrait de phase. (Bas) Amplitude signal HRIR.
33toute la bande fréquentielle du portrait de phase.
Ce dernier point, parfaitement empirique, est fondamental puisqu’il a donné
naissance au principe de Décomposition par Modèle Morphologique des HRTF,
présenté dans la suite de ce manuscrit.
En complément des représentations azimutales précédentes, les figures 1.22
et 1.23 donnent les représentations en azimut-élévation à fréquence fixe des
HRTF mesurées du sujet NH5 de la base ARI. La discrétisation spatiale de
cette base oscillant entre 2.5˚ et 5˚, ces figures présentent une discrétisation
tous les degrés d’espace en considérant la valeur du plus proche voisin mesuré,
ce qui correspond aux diagrammes de Voronoï. Ceci permet d’afficher
les résultats de mesures bruts, sans interpolations graphiques éventuellement
préjudiciables à l’analyse des données. Les positions spatiales des données mesurées
sont représentées par des points noirs. Les propriétés précédemment
observées se retrouvent dans la représentation spatiale des HRTF. En effet,
l’amplitude spectrale (fig. 1.22) est relativement lisse, y compris en haute
fréquence. Certains décrochements sont néanmoins visibles pour les sources
contralatérales (en bleu foncé). Mais ces valeurs sont relativisées par leur
faible amplitude en échelle logarithmique. Cette représentation laisse penser
que la discrétisation spatiale de la base ARI semble surdéterminée, au regard
des faibles variations entre chaque point de mesure. Une interpolation,
linéaire ou d’ordre supérieur, pourrait donc être envisagée. En revanche, le
portrait de phase est quant à lui bien plus oscillant (fig. 1.23). La discrétisation
spatiale est suffisante pour une représentation à 0.5 kHz, mais commence
à pêcher pour les sources contralatérales à 8 kHz et devient manifestement
insuffisante pour ces mêmes positions à 16 kHz. Une interpolation de ces
données en l’état est donc relativement difficile à haute fréquence, mais reste
envisageable (cf. section suivante). Il est néanmoins intéressant de remarquer
une certaine symétrie axiale par rotation autour de l’axe interaural, qui
n’est pas sans rappeler le portrait de phase sphérique du modèle de Duda
(fig. 1.19).
Toutes les représentations brutes des HRTF et des HRIR équivalentes
étant établies, celles-ci vont désormais servir de référence dans toute la suite
de ce chapitre.
1.3.3 Interpolation linéaire
Les représentations précédentes des diagrammes de Voronoï en azimut-
élévation (fig. 1.22 et 1.23) amènent naturellement la question de l’interpolation
spatiale des filtres HRTF, à savoir :
Comment construire des données pertinentes entre les positions
discrètes des mesures ?
34Figure 1.22 – Amplitude spectrale (dB) des HRTF gauches du sujet NH5
de la base de données ARI. Représentation en azimut θ et élévation φ, à
fréquence fixe. Les positions des mesures sont données par les points noirs.
35Figure 1.23 – Portrait de phase (radian) des HRTF gauches du sujet NH5
de la base de données ARI. Représentation en azimut θ et élévation φ, à
fréquence fixe. Les positions des mesures sont données par les points noirs.
36Cette question est fondamentale pour la compréhension de ces fonctions de
transfert, ainsi que pour leur exploitation industrielle (e.g. [17], [45], [57]).
Par exemple, une interpolation spatiale de haute qualité permet notamment :
– Un rendu dynamique de la spatialisation sonore en minimisant les artefacts
audibles ;
– L’ajout d’un head-tracking transparent ;
– Une minimisation de la densité spatiale des mesures, ce qui diminue
leur durée, simplifie les appareillages nécessaires et décroit la taille des
bases de données de façon quadratique.
Pour ce faire, une interpolation linéaire par triangularisation sphérique de la
sphère de mesures a été préférentiellement choisie. Tant que la discrétisation
des fonctions à interpoler est suffisante pour appliquer une hypothèse de
linéarité locale, ce type d’interpolation est un bon compromis entre précision
et coûts de calcul. L’algorithme exploité pour produire les représentations
ci-après peut se résumer comme suit :
1. Considérer le nuage de points de mesures en coordonnées sphériques ;
2. Subdiviser la surface sphérique en triangles plans, ayant pour sommets
les points des mesures ;
3. Construire une grille régulière plus fine, par exemple, tous les degrés
en azimut θ et élévation φ ;
4. Interpoler linéairement triangle par triangle les données aux nœuds sur
cette nouvelle grille.
Au vu des variations des HRTF brutes (fig. 1.22 et 1.23), le module et
la phase des HRTF ont été traités séparément. Les figures (fig. 1.24 et 1.25)
représentent respectivement en azimut-élévation les interpolations linéaires
de l’amplitude spectrale et de la phase des HRTF mesurées du sujet NH5
de la base ARI. L’interpolation linéaire de l’amplitude spectrale (fig. 1.24)
donne d’excellents résultats puisque, comparativement aux mesures originales
(fig. 1.22), les variations semblent entièrement décrites avec la discrétisation
spatiale de la base ARI et ce, quelle que soit la fréquence. Autour de l’oreille
contralatérale, seuls quelques "trous" de faible amplitude mériteraient une
étude plus approfondie, mais leur importance est moindre au regard de la
faible amplitude de la zone avoisinante. D’autre part, à 8 kHz, des stries
horizontales apparaissent pour l’oreille ipsilatérale et semblent fonctions de
l’élévation. Selon le protocole expérimental, à savoir une rangée de hautparleurs
distincts en élévation, il est possible que l’égalisation du dispositif
impacte la mesure. Cette problématique limite les mesures d’erreurs possibles
et peut justifier qu’une interprétation purement graphique des résultats soit
suffisante en première approche. En revanche, l’interpolation linéaire de la
37Figure 1.24 – Interpolation linéaire de l’amplitude spectrale (dB) des HRTF
gauches du sujet NH5 de la base de données ARI. Représentation en azimut
θ et élévation φ, à fréquence f fixe. Les positions des mesures sont données
par les points noirs. 38Figure 1.25 – Interpolation linéaire du portrait de phase (radian) des HRTF
gauches du sujet NH5 de la base de données ARI. Représentation en azimut
θ et élévation φ, à fréquence f fixe. Les positions des mesures sont données
par les points noirs. 39phase (fig. 1.25), peut quant à elle être considérée comme un échec. En effet,
même si le portrait de phase original (fig. 1.25) est relativement consistant
pour les fréquences 1 kHz, voire 8 kHz, la discrétisation spatiale de la base
ARI est clairement insuffisante pour ce type d’interpolation à 15 kHz. En
effet, étant donné que les données spatiales brutes présentent de nombreux
sauts de π vers −π, une interpolation linéaire entre ces sauts génère des artefacts
visibles et audibles. À titre comparatif, le portrait de phase théorique
des HRTF sphériques de Duda (fig. 1.19) peut être mis en regard du portrait
de phase interpolé (fig. 1.25).
Comme les oscillations observées résultent en grande partie de la repré-
sentation modulo 2π, une approche classique consiste à "dérouler" la phase
pour retirer les sauts de π vers −π, obtenant ainsi une phase continue sur un
intervalle élargi [10]. Mais, comme le montrent les mesures brutes (fig. 1.23),
la question de la direction du déroulement est loin d’être triviale. En effet,
celui-ci doit respecter la causalité, qui est difficile à évaluer directement pour
des fonctions de transfert définies sur deux dimensions d’espace (azimut et
élévation). Des travaux de recherches ont précédemment été entrepris pour
tenter de résoudre cette problématique, donnant lieu à des méthodes comme :
– Soustraire la portion de phase linéaire liée au retard de propagation ;
– Soustraire la portion de phase minimale déduite du spectre d’amplitude
et représenter l’excès de phase déroulé ("unwrapped").
La seconde approche est considérée notamment dans la thèse de Véronique
Larcher et propose de mesurer le retard de propagation par une approximation
linéaire de l’excès de phase (e.g. [57]).
Une autre méthode, utilisée ici, consiste à interpoler directement les HRTF
dans le domaine complexe, en séparant la partie imaginaire et la partie réelle.
Étant donné que la transformée de Fourier et la méthode d’interpolation sont
toutes deux linéaires, cela revient à effectuer une interpolation linéaire en domaine
temporel, soit directement sur les HRIR [45]. L’amplitude spectrale
(dB) et la phase (rad) peuvent alors être extraites du résultat et représentées
en azimut-élévation à fréquence fixe. Suivant cette technique, le portrait de
phase (fig. 1.27) semble cette fois plus cohérent que précédemment (fig. 1.25),
notamment à 1 kHz, voire 8 kHz. Cependant, les variations à 16 kHz étant
toujours trop fortes pour être interpolées correctement, de nouveaux artefacts
apparaissent, comme des phases spatialement constantes (visibles aussi
à 8 kHz pour les sources contralatérales). D’autre part, l’amplitude spectrale
de cette méthode (fig. 1.27) est quant à elle plutôt médiocre à 8 kHz et
16 kHz, car un aliasing spectral perturbe la reconstruction. Même si la répartition
générale est respectée (fig. 1.22), ces oscillations locales de l’amplitude
spectrale sont du domaine de l’audible. Ceci modifie de manière conséquente
le timbre de la source sonore restituée et peut affecter la localisation spa-
40Figure 1.26 – Amplitude spectrale (dB) de l’interpolation linéaire complexe
des HRTF gauches du sujet NH5 de la base de données ARI (équivalent
de l’interpolation des HRIR). Représentation en azimut θ et élévation φ, à
fréquence fixe. 41Figure 1.27 – Phase (radian) de l’interpolation linéaire complexe des HRTF
gauches du sujet NH5 de la base de données ARI (équivalent de l’interpolation
des HRIR). Représentation en azimut θ et élévation φ, à fréquence fixe.
42tiale. Cet aliasing est majoritairement dû à la sous-discrétisation spatiale de
la phase, qui vient perturber l’interpolation linéaire en domaine temporel.
En effet, l’interpolation linéaire des HRTF fait appel à des combinaisons de
filtres, qui peuvent générer des erreurs lorsque les interpolants présentent une
trop grande variabilité, ou un mauvais alignement temporel.
À partir de ces résultats, une première intuition pour interpoler les HRTF
serait de combiner une interpolation linéaire de l’amplitude spectrale (fig. 1.24)
avec la phase d’une interpolation temporelle (fig. 1.27). Mais cette phase
étant reliée à une amplitude spectrale avec fort aliasing (fig. 1.26), rien ne
garantit la validité du résultat. Une nouvelle méthode, dite de "Décomposition
par Modèle Morphologique", a été mise au point pour répondre à cette
problématique.
1.3.4 Interpolation par harmoniques sphériques
En complément de l’interpolation linéaire précédente, un autre type d’interpolation
a été étudié, issu des travaux de R. Duraiswami et N. Gumerov
(e.g. [27], [28], [53]). Le principe général de la méthode consiste à projeter
sur les harmoniques sphériques Y
m
l
(eq. 1.2, fig. 1.12) des fonctions u défi-
nies sur la sphère S
2
, afin de les interpoler en n’importe quel point. Comme
les harmoniques sphériques forment une base orthonormée de L
2
(S
2
), toute
fonction u ∈ L
2
(S
2
) peut se décomposer selon la série (1.3), indépendamment
de r :
u(θ, φ) = X∞
l=0
X
+l
m=−l
α
m
l Y
m
l
(θ, φ), (1.6)
avec α
m
l
les coefficients de cette décomposition. Cette écriture autorise la
formation de systèmes matriciels, qui peuvent être résolus ou inversés selon
le changement de base souhaité. Pour ce faire, la série précédente doit être
tronquée à une valeur fixe l ≤ L, ce qui donne (L + 1)2
termes. Puis, en
considérant N données discrètes ui évaluées aux points (θi
, φi) sur la sphère
S
2
, la série (1.6) peut être réécrite sous la forme matricielle :
U = Aα, (1.7)
avec A une matrice rectangulaire formée par les harmoniques sphériques tronquées,
évaluées aux points de mesures (θi
, φi). Cette matrice peut être mal
conditionnée, notamment par une répartition parfois incomplète des N mesures
sur la sphère. Aussi, lorsque les coefficients α
m
l
sont obtenus par inversion
du système linéaire (1.7), une régularisation de type Tikhonov peut-être
mise en place [27] :
A
TU = (A
TA + D)α. (1.8)
43Dans l’équation (1.8), D = diag(1 + l(l + 1)) est une matrice diagonale
favorisant les harmoniques sphériques d’ordre peu élevé, pour minimiser les
perturbations générées par des "trous" spatiaux présents dans les données
originales. D’autre part, est introduit comme constante de pondération
de cette régularisation. Après de nombreux essais, un algorithme empirique,
relativement simpliste, a été conçu pour calculer automatiquement . En
effet, les grandes valeurs de favorisent le lissage, dont l’excès engendre une
perte de précision importante dans les informations spatiales. Par ailleurs, les
petites valeurs de peuvent rendre la régularisation parfaitement inopérante.
Par conséquent, ce paramètre doit être judicieusement choisi pour obtenir de
bons résultats, notamment selon le conditionnement du système à résoudre
(M = ATA + D). Pour cela, un estimateur normalisé du conditionnement
est calculé par le produit ||M||2 × ||M−1
||2, avec une donnée initiale 0 fixée
à 10−6
. Tant que la valeur de l’estimateur est plus grande que 104
, ce qui
correspond traditionnellement à un système mal conditionné, est multiplié
par 10 et l’estimateur est recalculé. Cette régularisation semble relativement
efficace pour pallier les nombreuses erreurs numériques engendrées par les
troncatures, ou les répartitions de données incomplètes. Pour résumer, une
interpolation par harmoniques sphériques d’une fonction u ∈ L
2
(S
2
) peut
être effectuée par l’algorithme suivant :
1. Considérer N valeurs connues de la fonction u sur la sphère, pour former
le vecteur second membre U de l’équation régularisée (1.8) ;
2. Tronquer la série (1.6) à un ordre L en fonction de la précision de
l’interpolation voulue, pour construire la matrice A aux N positions
connues de la fonction u ;
3. Appliquer la régularisation de Tikhonov, ce qui permet a priori de
prendre L relativement quelconque ;
4. Résoudre l’équation (1.8) par inversion matricielle pour calculer le vecteur
α des coefficients de décomposition α
m
l
;
5. Construire une nouvelle matrice B d’harmoniques sphériques, évaluées
aux M positions (θ, φ) à interpoler ;
6. Calculer le produit matrice-vecteur Bα pour obtenir le vecteur des
valeurs de la fonction u aux positions interpolées.
Cet algorithme, parfaitement générique, peut être appliqué à toute fonction
u ∈ L
2
(S
2
), à valeurs dans R ou C.
Or, en décomposant les HRTF fréquence par fréquence, les données ré-
sultantes sont typiquement des fonctions de L
2
(S
2
) à valeurs dans C. Par
ailleurs, leurs module, phase et transformée de Fourier (HRIR) sont aussi des
44fonctions de L
2
(S
2
), à valeurs dans R. L’interpolation par harmoniques sphé-
riques peut donc être appliquée à tous ces objets, pour estimer des données
spatiales non mesurées. Ce type d’interpolation présente l’avantage d’être
global, contrairement à l’interpolation linéaire qui est un algorithme local.
De plus, la régularisation de Tikhonov induit un certain lissage, qui peut
avantageusement compenser les erreurs ponctuelles inhérentes aux mesures.
Enfin, les coefficients α
m
l ne sont rien d’autres que les signaux utilisés par
les technologies HOA présentées dans la section précédente. Aussi, cet algorithme
peut-être utilisé pour assurer la conversion des mesures discrètes
aux signaux ambisonics. Néanmoins, la répartition non uniforme des données
issues de systèmes de mesures mécaniques peut générer des erreurs difficilement
maîtrisables, notamment à haute fréquence pour des bases de HRTF
non suffisamment denses.
Pour limiter le nombre de figures, cet algorithme a uniquement été appliqué
à l’amplitude spectrale des HRTF du sujet NH5 de la base ARI (fig. 1.28
et 1.29). Ces données sont donc à valeurs dans R, avec N = 1550 mesures
sur une calotte sphérique d’élévation comprise entre −30˚< φ < 80˚ (points
noirs). Dans un premier temps, la troncature a été arbitrairement fixée à
L = b
√
Nc = 39 (fig. 1.28) et la constante de régularisation calculée vaut
= 1, significative d’un système assez mal conditionné. Au vu des données
manquantes pour compléter la sphère, cette valeur n’est pas vraiment surprenante.
La comparaison de ces résultats aux mesures brutes (fig. 1.22), ainsi
qu’à l’interpolation linéaire (fig. 1.24), semble montrer que ce type d’algorithme
est bien adapté à l’interpolation de ces HRTF, et ce, quelque soit la
fréquence. Ceci est principalement dû à la grande densité spatiale des mesures
originales, autorisant un ordre élevé d’harmoniques sphériques. Cette
approche avec L grand conduit à une interpolation fidèle des données, qui
ressemble finalement beaucoup à une interpolation linéaire (fig. 1.24). En
effet, un des intérêts de cet algorithme réside dans sa considération globale
de l’information spatiale, ce qui est assez peu visible sur la figure (fig. 1.28)
tant l’ordre de troncature est élevé. Aussi, un ordre de troncature arbitraire
a été fixé à L = 15, tout en conservant les autres paramètres à l’identique.
Le coefficient calculé vaut cette fois 0.1, la matrice étant mieux conditionnée.
Un système extrêmement surdéterminé est donc résolu, engendrant un
moyennage spatial de l’ensemble des données disponibles. Les résultats de
cette approximation sont représentés sur la figure 1.29. Quelle que soit la
fréquence, un lissage est clairement visible, tout en conservant les principales
variations des HRTF originales (fig. 1.22). Ceci a pour conséquence d’égaliser
sphériquement les mesures entre elles, pour en dégager l’essentiel. En faisant
l’hypothèse (raisonnable) que le système auditif est limité en précision, donc
en ordre de troncature d’harmoniques sphériques, cette méthode permet de
45Figure 1.28 – Interpolation par harmoniques sphériques (L = 39) de l’Amplitude
spectrale (dB) des HRTF gauches du sujet NH5 de la base de données
ARI. Représentation en azimut θ et élévation φ, à fréquence fixe.
46Figure 1.29 – Interpolation par harmoniques sphériques (L = 15) de l’Amplitude
spectrale (dB) des HRTF gauches du sujet NH5 de la base de donnée
ARI. Représentation en azimut θ et élévation φ, à fréquence fixe.
47générer des bases de données HRTF particulièrement adaptées à la synthèse
binaurale. Il reste néanmoins à trouver par des tests subjectifs l’ordre de
troncature optimal minimisant les erreurs de localisation.
Que ce soit pour la conversion des HRTF en format HOA, pour l’égalisation
sphérique de l’information, ou encore pour l’interpolation globale
et automatique des mesures, une attention particulière a été portée à cette
méthode durant cette recherche doctorale. Ces études ont conduit à la publication
de deux articles de conférence [8] et [9]. Le premier de ces articles
concerne l’interpolation harmonique de l’ITD, qui est une fonction de L
2
(S
2
)
dans R. Le second propose une analyse approfondie de la précision de cet
algorithme, en mesurant l’erreur d’une interpolation des HRTF sur une grille
de mesure dense déraffinée.
1.4 Décomposition par Modèle Morphologique
La Décomposition par Modèle Morphologique est issue du constat classique
que les modèles sphériques de Larcher [57] et Duda [25] (fig. 1.16 et
1.17) se retrouvent nettement dans les représentations temporelles des HRIR
mesurées (fig. 1.21). Aussi, de nombreuses recherches ont été faites et sont
actuellement en cours, pour affiner ces modélisations en construisant analytiquement
et/ou numériquement des HRTF s’approchant de mesures réelles,
en phase comme en amplitude spectrale (e.g. [4], [26], [37], [52], [72], [81]).
Toutes ces méthodes ont comme point commun de s’inscrire dans une logique
de "construction" de modèles de HRTF, se voulant de plus en plus
proches de mesures expérimentales. La simulation numérique par Boundary
Element Method accélérés en Fast Multipole sur des maillages de tête individuels
haute-résolution en est un aboutissement des plus complexes (e.g. [30],
[39], [56]). La Décomposition par Modèle Morphologique suit une démarche
inverse, qui consiste cette fois à "retirer" des mesures originales les solutions
exactes ou approchées issues de modélisations élémentaires. Les HRTF
deviennent dès lors le résultat d’un couplage astucieux entre modèle(s) et
mesures, ayant vocation à exploiter les avantages de chacun. Cette distinction
de cheminement est le point fondamental de cette nouvelle approche,
dont le formalisme, ainsi que trois applications, sont détaillés dans la suite
de ce chapitre.
1.4.1 Principe et résultats
La Décomposition par Modèle Morphologique s’effectue en trois étapes,
dans un contexte de traitement du signal en régime harmonique. Tout d’abord,
48des fonctions de transfert HRTF originales H(Xi), mesurées en N points de
l’espace Xi = (ri
, θi
, φi), sont décomposées en une série de filtres élémentaires
paramétriques Hm(p
m, Xi). Ces filtres sont des solutions analytiques ou numériques
de modèle m, paramétrées par un jeu de données p
m en lien avec la
morphologie. La fonction de transfert résiduelle issue de cette décomposition
sera notée Hr
(Xi) et est, a priori, parfaitement inconnue. La Décomposition
par Modèle Morphologique s’écrit alors :
H(Xi) = H
r
(Xi) ·
Y
m
H
m(p
m, Xi), ∀i ∈ [1, N]. (1.9)
Cette décomposition est équivalente a une décomposition additive de l’amplitude
en dB et de la phase en radians. La seconde étape consiste en la
réécriture de cette décomposition (1.9) par filtrage inverse, afin d’en expliciter
le résidu :
H
r
(Xi) = H(Xi)
Q
m Hm(pm, Xi)
, ∀i ∈ [1, N]. (1.10)
Ce filtre résiduel Hr
(Xi) peut alors être étudié pour valider, invalider, ou
affiner la décomposition. En effet, le résidu est directement équivalent a des
erreurs de modélisation, calculées par soustraction. Par exemple, dans le cas
idéal où le modèle coïnciderait exactement avec les données mesurées, le
résidu serait uniformément nul pour l’amplitude spectrale et la phase, et égal
en temps à une impulsion de Dirac. En pratique, si le module ou la phase du
résidu présente une plus grande régularité (des variations plus petites) que la
fonction de transfert originale H(Xi), alors la décomposition peut être jugée
satisfaisante. Dans le cas contraire, il faudra retravailler la modélisation d’un
ou plusieurs éléments, séparément ou non. Enfin, la dernière étape réside en
la recomposition des HRTF, en exploitant notamment les solutions issues des
modèles et connues en tous points de l’espace. Des propriétés propres aux
modèles, ainsi que les paramètres p
m peuvent aussi être exploités pendant
cette étape, en fonction du but recherché.
À titre d’exemple d’utilisation de cette méthode, trois applications sont
détaillées dans la suite de cette section, à savoir l’interpolation optimisée
des HRTF, la sous-discrétisation spatiale et l’individualisation. Pour ce faire,
la Décomposition par Modèle Morphologique (1.9) a été appliquée au modèle
sphérique de Duda [25], dont la fonction de transfert (1.5) sera notée
Hsp(a, Xi). Ce choix est guidé par un confort d’utilisation, puisque ce modèle
est un modèle analytique abouti, aisément calculable. Les solutions sont
donc connues en tous points de l’espace, avec en outre un rayon de tête
paramétrique a. Cette décomposition s’écrit alors :
H(Xi) = H
r
(Xi) · H
sp(a, Xi). (1.11)
49Figure 1.30 – Représentations fréquentielles et temporelle dans le plan azimutal
du résidu Hr de la décomposition sphérique des HRTF gauches du
sujet NH5 de la base ARI. (Haut) Amplitude spectrale. (Milieu) Portrait de
phase. (Bas) Amplitude signal HRIR.50La figure 1.30 donne les représentations azimut-fréquence de l’amplitude
spectrale et de la phase du résidu Hr
(Xi), aux points de mesures Xi
. Ces
valeurs sont calculées par filtrage inverse de Hsp(a, Xi) (eq. 1.10), avec un
rayon de tête sphérique a = 8.74 cm, correspondant au rayon de tête moyen
[58]. Il en ressort de prime abord que le portrait de phase de ce résidu est
beaucoup plus droit que celui des HRTF originales (fig. 1.21) et présente,
dans l’ensemble, moins de variations, en fréquence comme en azimut. Cependant,
les sources contralatérales ont toujours des irrégularités locales assez
fortes. Une des conséquences de ce résultat réside dans l’alignement temporel
des HRIR résiduelles, clairement visible sur la représentation en temps
azimut-fréquence du résidu (fig. 1.30). Par ailleurs, en comparaison avec
les HRTF originales (fig. 1.21), l’amplitude spectrale du résidu semble avoir
été globalement égalisée, notamment certains creux en amplitude de l’oreille
contralatérale. En revanche, des stries apparaissent, similaires au portrait
d’amplitude des HRTF sphériques (fig. 1.17). Ces stries sont la conséquence
d’une modélisation trop grossière, ou mal adaptée, qui vient surcompenser
les HRTF originales. Ceci montre les limitations d’un modèle de HRTF sphé-
rique, notamment pour l’oreille contralatérale. Il faudrait donc l’affiner, en
conservant certaines propriétés visiblement bénéfiques pour la phase.
Les figures 1.31 et 1.32 viennent compléter les représentations azimutales
précédentes, en donnant l’amplitude spectrale (dB) et le portrait de phase
(radian) en azimut-élévation du résidu Hr de la décomposition sphérique de
rayon a = 8.74 cm, pour les HRTF gauches du sujet NH5 (base ARI). Au
même titre que pour les représentations azimut-fréquence (fig. 1.30), l’amplitude
spectrale et la phase sont globalement lissées et ce, quelle que soit la
fréquence. D’une part, le portrait de phase présente particulièrement peu de
variations, comparé à l’original avant décomposition (fig. 1.23), d’autre part
l’amplitude spectrale semble avoir été partiellement "rebouchée", notamment
dans la zone contralatérale. Cependant, cette même zone présente encore des
irrégularités importantes, en amplitude et en phase. De plus, des sauts de
phase verticaux sont à noter en haute fréquence, caractérisés par des stries
horizontales à 8 et 16 kHz (fig. 1.32). Celles-ci peuvent être causées par le
dispositif expérimental, qui compte un haut-parleur différent par élévation et
dont les variations résiduelles sont faibles au regard de la fréquence élevée.
Pour conclure, il semblerait que la décomposition de HRTF par un modèle
sphérique de Duda soit plutôt pertinente, surtout pour la phase. L’analyse
du résidu Hr montre une bonne concordance du modèle, surtout en basse
fréquence. De plus, même si par construction Hr n’a pas de sens physique
véritable, les résultats de la décomposition précédente donnent l’impression
que ce résidu pourrait caractériser des HRTF "privées" d’une tête sphérique.
Mais cette hypothèse reste encore à démontrer... En revanche, cette modé-
51Figure 1.31 – Amplitude spectrale (dB) du résidu Hr de la décomposition
sphérique des HRTF gauches du sujet NH5 de la base ARI. Représentation
en azimut θ et élévation φ, à fréquence fixe. Les positions des mesures sont
données par les points noirs. 52Figure 1.32 – Portrait de phase (rad) du résidu Hr de la décomposition
sphérique des HRTF gauches du sujet NH5 de la base ARI. Représentation
en azimut θ et élévation φ, à fréquence fixe. Les positions des mesures sont
données par les points noirs. 53lisation montre des limites importantes pour les sources contralatérales qui
semblent assez mal prises en compte, surtout en haute fréquence. Ceci peut
s’expliquer par la sphéricité du modèle qui tend à exagérer la reconstruction
des ondes contralatérales par des oreilles diamétralement opposées, induisant
une mise en phase contraire à la réalité. Une première amélioration de cette
décomposition consisterait par exemple en une modélisation ovoïdale de la
tête, avec des oreilles non diamétralement opposées [26]. Mais il n’existe pas
de solutions analytiques simples à ce problème, qui nécessite dès lors des outils
de simulation numérique. Aussi, malgré ce défaut, trois applications de
la décomposition sphérique sont présentées.
1.4.2 Interpolation optimisée
Comme expliqué précedemment, la question de l’interpolation des HRTF
n’est pas triviale de par la grande variabilité de ces filtres, en temps comme
en espace [45]. Une première application de la Décomposition par Modèle
Morphologique consiste à optimiser l’interpolation spatiale en tenant compte
de solutions modélisées, connues en tous points de l’espace.
Plus exactement, les figures 1.31 et 1.32 montrent que le résidu Hr
(Xi),
issu du filtrage inverse d’une HRTF mesurée H(Xi) par sa décomposition
sphérique Hsp(a, Xi), est plus régulier que la fonction de transfert originale
(fig. 1.22 et 1.23), notamment en phase. En complément, la représentation
temporelle de ce résidu (fig. 1.30) montre un alignement azimutal des filtres.
Fort de ces deux constats, une idée naturelle consiste à interpoler linéairement
en espace le résidu Hr
(Xi) sous sa forme temporelle, ce qui revient par
transformée de Fourier à une interpolation du résidu sous sa forme complexe.
Ceci fait, des HRTF peuvent être recomposées, calculées avec les valeurs des
HRTF sphériques de Duda aux points interpolés. Une grille quelconque peut
alors être générée, en tout point de l’espace. Par ailleurs, si les modèles de
décomposition et de recomposition sont identiques et que l’interpolation n’est
pas régularisante, alors les HRTF aux points de mesure originaux reste inchangées
par cette opération. Les figures 1.33 et 1.34 représentent respectivement
l’amplitude spectrale et le portrait de phase des HRTF gauches du
sujet NH5 de la base ARI, après interpolation optimisée par décomposition
morphologique. La nouvelle grille possède un pas constant de 1˚ en azimut
et élévation, au même titre que les représentations précédentes (fig. 1.22 à
1.27). La symétrie sphérique du portrait de phase semble cette fois plutôt bien
reconstituée, y compris à 16 kHz. Le résultat est lisse sans aberrations flagrantes,
avec une causalité respectée, même pour les sources contralatérales.
En revanche, même si l’interpolation de l’amplitude spectrale semble réussie
à 1 et 8 kHz, un aliasing spectral est toujours visible à 16 kHz (fig. 1.33).
54Figure 1.33 – Amplitude spectrale (dB) de l’interpolation linéaire par dé-
composition sphérique, des HRTF gauches du sujet NH5 de la base ARI.
Représentation en azimut θ et élévation φ, à fréquence fixe.
55Figure 1.34 – Portrait de phase (radian) de l’interpolation linéaire après
décomposition par modèle sphérique, HRTF gauches du sujet NH5 de la
base ARI. Représentation en azimut θ et élévation φ, à fréquence fixe.
56Bien que plus faible qu’en interpolation linéaire directe (fig. 1.26), cette erreur
montre néanmoins les limites du modèle, qui mériterait donc d’être affiné.
Pour conclure, cette interpolation par décomposition morphologique est
suffisamment robuste pour être mise en pratique et les résultats de test
d’écoute à la volée sont plutôt satisfaisants. Il reste cependant des artefacts
d’interpolation audibles pour les sources situées proches de l’axe interaural,
dues aux erreurs visibles dans les représentations du résidu Hr
(Xi) (fig. 1.31
et 1.32). Enfin, d’autres méthodes d’interpolation (quadratiques, cubiques,
harmoniques sphériques, etc.) peuvent être appliquées sur le résidu Hr
(Xi)
et ce, indépendamment de la décomposition morphologique choisie.
1.4.3 Variations de position
Une des principales applications de l’interpolation optimisée des HRTF
concerne le Head-Tracking, qui consiste à corriger en temps réel la direction
spatiale (θ, φ) des sources sonores, en fonction des rotations de la tête. L’utilisation
d’un tel dispositif augmente singulièrement la qualité d’expérience
binaurale, grâce à un rendu dynamique de l’espace, contrôlé consciemment
(ou inconsciemment) par l’utilisateur (e.g. [10], [12]). Par exemple, l’image
sonore est plus stable, la localisation des directions spatiales des sources sonores
est facilitée et l’externalisation est, elle aussi, bien meilleure. Pour ce
faire, l’ensemble des directions de l’espace doit être synthétisable par rendu
binaural, ce qui implique une définition continue des HRTF. Comme les mesures
sont discrètes par nature, il est nécessaire de recourir à des algorithmes
d’interpolations à la fois rapides et transparents.
Cependant, l’accès à un Head-Tracker n’était pas possible lors de la réalisation
du spatialisateur PifPaf3D, c’est pourquoi une méthode de rendu dynamique
sans Head-Tracking a été imaginée. La démarche consiste à rendre
mobiles les sources sonores pour profiter d’indices de localisation dynamiques
(e.g. [47], [84]), sans pour autant détériorer le rendu binaural par un détimbrage
permanent. Des trajectoires spatiales autour des positions fixes ont
donc été mises en place, d’amplitude angulaire de l’ordre de la Just Noticeable
Difference (1˚ à 4˚ selon l’azimut θ), afin de s’adresser à la partie
inconsciente de la localisation spatiale.
Une trajectoire de micro-variations est représentée par des ronds noirs
sur la figure 1.35, en azimut-élévation. Elle est tout d’abord superposée aux
HRTF brutes du sujet NH5 de la base ARI, à 16 kHz, autour de la position
θ = 180˚ et φ = 0˚ (en haut). Comme la JND est de l’ordre du degré, l’amplitude
maximale du mouvement doit être du même ordre, arbitrairement
fixé à 2˚. Il apparaît clairement que sans interpolation spatiale des HRTF,
les micro-variations sont proprement inutiles, puisque le même filtre HRTF
57Figure 1.35 – Représentation en azimut θ et élévation φ à 16 kHz des HRTF
gauches du sujet NH5 de la base ARI, centrées sur la position θ = 180˚ et
φ = 0˚. Les positions successives des micros-variations sont représentées par
les ronds noirs. (Haut) Amplitude spectrale (dB) des mesures brutes. (Milieu)
Amplitude spectrale (dB) après interpolation optimisée par décomposition
sphérique. (Bas) Phase (rad) après interpolation optimisée par décomposition
sphérique.
58est toujours utilisé, quelle que soit la position de la source sonore dans l’espace.
Les deux représentations suivantes montrent en revanche l’intérêt d’une
interpolation optimisée des HRTF, ici par décomposition sphérique. Sur la
trajectoire du milieu, des variations en amplitude spectrale sont cette fois
bien présentes, principalement en élévation (entre −12 et −2 dB). Sur la
trajectoire du bas, les isovaleurs de phase (agissant notamment sur l’ITD)
sont plutôt verticales, ce qui conduit à des variations principalement azimutales.
Ces deux constats peuvent s’expliquer par la géométrie de la tête et
du pavillon. En effet, il est coutumier de dire que les variations d’ITD sont
principalement azimutales, car reliées à la forme plutôt sphérique de la tête.
D’autre part, les fortes variations spectrales sont surtout causées par la géométrie
du pavillon, qui génère de plus grandes variations dans les HRTF en
élévation qu’en azimut (e.g. [15], [12]). Fort de ces deux remarques, la trajectoire
des micro-variations représentée sur la figure 1.35 a donc été choisie
de manière à exciter à la fois la phase et l’amplitude spectrale, sans a priori.
Par ailleurs, ces résultats se retrouvent bien entendu pour des fréquences plus
basses que 16 kHz, mais avec des variations moins intenses.
Un stage a été encadré durant cette thèse pour évaluer subjectivement
l’impact des micro-variations, mais ces travaux n’ont pas abouti à une conclusion
probante. De plus, de nouvelles recherches pourraient être menées sur
ce thème, notamment pour générer des trajectoires optimales, trouver des
amplitudes et des périodes d’oscillations adaptées, ou encore comparer des
trajectoires continues contre des apparitions stochastiques localisées. Enfin,
le traitement du signal audio se faisant par blocs de données, la question du
nombre de blocs nécessaires pour construire proprement une trajectoire est
encore à déterminer.
1.4.4 Déraffinement spatial d’une base de données
Les résultats de l’interpolation par décomposition morphologique ouvrent
une perspective intéressante sur la discrétisation spatiale des HRTF. En effet,
une interpolation de haute fidélité permet notamment de réduire le nombre
d’interpolants nécessaires à la reconstruction spatiale des données. Or, la
représentation en azimut-élévation à fréquence fixe de l’amplitude spectrale
de la HRTF brute du sujet NH5 de la base ARI (fig. 1.22) laisse supposer une
sur-discrétisation du problème. En effet, moyennant une égalisation visible
des haut-parleurs entre eux (stries horizontales), les variations en module
semblent plutôt faibles au regard de l’échantillonnage spatial des mesures,
compris entre 2.5˚et 5˚en azimut et élévation.
Aussi, un déraffinement arbitraire a été envisagé, de l’ordre de 15˚ en
moyenne en azimut et élévation. De plus, une grille uniforme est préférentiel-
59Figure 1.36 – Représentation en azimut θ et élévation φ à 8 kHz de l’amplitude
spectrale (dB) des HRTF gauches du sujet NH5 de la base ARI. Les positions
des mesures sont données par les points noirs. (Haut) Mesures brutes
uniformément déraffinées tous les 15˚. (Milieu) Interpolation par décomposition
sphérique sur la grille déraffinée. (Bas) Mesures brutes originales.
60Figure 1.37 – Représentation en azimut θ et élévation φ à 8 kHz du portrait
de phase (rad) des HRTF gauches du sujet NH5 de la base ARI. Les positions
des mesures sont données par les points noirs. (Haut) Mesures brutes uniformément
déraffinées tous les 15˚. (Milieu) Interpolation par décomposition
sphérique sur la grille déraffinée. (Bas) Mesures brutes originales.
61lement extraite de la grille originale, notamment pour limiter les redondances
locales. Ce faisant, le nombre de mesures utiles passe de 1550 positions à environ
220, puisque diviser par 3 le nombre de mesures sur chaque dimension
revient à diviser par 8 le nombre de mesures total sur la sphère. Cette division
est résolument excessive, l’idée étant simplement de montrer une application
de la Décomposition par Modèle Morphologique, qui mériterait d’être approfondie
par la recherche de grilles optimales en fonction du modèle choisi.
La figure 1.36 (haut) donne une représentation en azimut-élévation de l’amplitude
spectrale brute de la HRTF du sujet NH5 de la base ARI, sur la
grille déraffinée. La fréquence a été fixée à 8 kHz, puisqu’un aliasing spectral
apparaissait déjà à 16 kHz, lorsque l’ensemble des mesures était pris en
compte (fig. 1.33). Après interpolation par décomposition sphérique (fig. 1.36,
milieu), l’amplitude spectrale résultante semble consistante avec l’originale
(fig. 1.36, bas), excepté pour l’oreille contralatérale. Apparaît dans cette zone
la diffraction de la sphère par surcompensation, ce qui démontre que le modèle
n’est pas suffisamment fin pour être directement exploité. En revanche, le
portrait de phase semble plutôt convaincant, comme le montre la figure 1.37,
et ce, malgré le peu de mesures originales exploitées. En effet, il n’y a pas
d’artefacts visibles, la causalité est respectée et la phase semble se dérouler
correctement.
Au vu de ces représentations, la Décomposition par Modèle Morphologique
semble une technique tout à fait prometteuse pour le déraffinement
spatial des HRTF. Malgré la simplicité apparente du modèle utilisé, les ré-
sultats pour la phase sont plutôt bons et ceux pour l’amplitude spectrale ne
sont pas dénués d’intérêt. Par ailleurs, il n’est pas inutile de rappeler que la
fréquence choisie est assez élevée et le déraffinement plutôt fort. Aussi, comme
spécifié plus haut, une piste pour améliorer cet algorithme sans changer de
modèle serait de chercher une répartition optimale des données sur la sphère,
minimisant les erreurs d’interpolation spectrale sur l’amplitude. Enfin, pour
définitivement valider cette approche, des tests subjectifs complémentaires
sont encore à réaliser.
1.4.5 Vers une méthode d’individualisation
Selon l’équation (1.9), la Décomposition par Modèle Morphologique fait
intervenir des paramètres propres aux modèles, notés p
m. Ces paramètres
peuvent être purement abstraits, ou en lien avec des éléments de la morphologie
individuelle, à l’origine des HRTF. Auquel cas, les deux applications
précédentes pourraient voir leurs performances améliorées, en individualisant
les étapes de décompositions et recompositions par un modèle correctement
ajusté aux HRTF considérées. En outre, les étapes de décomposition et de
62recomposition étant indépendantes, il serait même envisageable de décomposer
des HRTF par un modèle adapté, puis de les recomposer en utilisant
cette fois une nouvelle paramétrisation dudit modèle, propre à l’auditeur.
Sous réserve que le résidu obtenu par décomposition soit bien indépendant
des paramètres utilisés, cette approche autoriserait une réelle individualisation
des fonctions de transfert HRTF. Par exemple, des mesures de haute
qualité, dont les paramètres morphologiques seraient connus, pourraient être
couplées à des modèles analytiques ou numériques en vue d’une individualisation
sur un ou plusieurs critères morphologiques. Afin d’estimer la faisabilité
d’une telle approche, une paramétrisation individualisée a été appliquée à
une décomposition par modèle sphérique de Duda (eq. 1.11, [25]). Comme
la représentation temporelle du résidu (fig. 1.30) issue de cette décomposition
laisse penser que les HRTF décomposées par une sphère ne possède plus
d’ITD, ce dernier a préférentiellement été choisi pour valider le concept. De
plus, le rayon de la sphère peut être choisi en lien avec le périmètre crânien
de l’auditeur, ce qui offre un premier pas vers l’individualisation des HRTF.
Pour ce faire, la première étape consiste à mesurer sur le plan azimutal
l’ITD de HRIR originales, ici celles du sujet NH5 de la base ARI (fig. 1.38,
haut). Cet ITD a été mesuré en recherchant pour chaque azimut les premiers
échantillons temporels où le niveau de l’amplitude signal franchit un certain
seuil. Aussi, pour compenser la perte de niveau en distance imputable au
décentrage de l’oreille, les HRIR ont préalablement été multipliées par un
facteur (t × c)
2
, où t correspond au temps de propagation (en seconde) et c
correspond à la célérité des ondes dans l’air à 15˚ (soit 340 m/s). Enfin, afin
de limiter les erreurs dues aux imperfections de mesures, chaque échantillon
temporel compensé en niveau a été moyenné par un fenêtrage de Hann sur
ses plus proches voisins. Le résultat de ces deux traitements, après normalisation,
est représenté sur la figure (fig. 1.38, milieu). En accord avec cette
représentation, le seuil de recherche a été fixé à −15 dB. L’ITD ainsi mesuré
est représenté par un liserai marron sur les HRIR originales (fig. 1.38, haut)
et semble suffisamment satisfaisant pour continuer.
La seconde étape consiste en l’ajustement du rayon a d’un modèle de tête
sphérique, pour coller par essai-erreur un ITD sphérique analytique sur l’ITD
mesuré précedemment. Cet ITD sphérique est calculé pour chaque azimut en
considérant le maximum des HRIR sphériques analytiques. Ces deux ITD
sont représentés en bleu sur la figure (fig. 1.39). Les deux courbes coïncident
plutôt bien pour les azimuts situés à l’arrière, voire sur les côtés, mais plus
difficilement sur le plan frontal. Ce résultat est probablement causé par la
géométrie de la tête, qui tend vers une sphère à l’arrière, mais qui s’en éloigne
assez fortement vers l’avant. C’est la raison pour laquelle le "zéro" de l’ITD
a été placé à θ = 180˚, sans tenir compte de θ = 0˚. Le rayon de la sphère
63Figure 1.38 – (Haut) Représentation temporelle dans le plan azimutal des
HRIR du sujet NH5 de la base de données ARI, amplitude signal avant
décomposition sphérique (ITD en marron). (Milieu) Représentation temporelle
de ces mêmes HRIR compensées en distance et lissées par fenêtrage
afin de mesurer l’ITD par seuil de l’amplitude signal, fixé à −15 dB. (Bas)
Représentation temporelle de ces mêmes HRIR après individualisation par
décomposition sphérique de rayon inférieur (ITD en marron).
64Figure 1.39 – Représentation de l’ITD (ms) en fonction de l’azimut θ (˚),
pour les HRTF originales, sphériques et individualisées avec Décomposition
par Modèle Morphologique.
des HRTF azimutales du sujet NH5 a ainsi été estimé à a = 9.7 cm.
Une fois ce paramètre de la décomposition sphérique établi, l’étape suivante
consiste à établir un nouveau jeu de paramètres pour le modèle considéré.
Dans cette étude, un rayon b = 8.0 cm a été choisi arbitrairement, afin
de générer une tête sphérique de circonférence inférieure à celle du sujet NH5.
Dès lors, les HRTF originales peuvent être décomposées par le modèle sphé-
rique de paramètre correspondant a, avant d’être recomposées par le même
modèle reparamétré par b. Si l’hypothèse d’indépendance est bien vérifiée,
les HRTF ainsi générées deviennent individualisées.
La dernière étape permettant de valider le concept consiste alors à mesurer
l’ITD des HRTF recomposées par le même protocole de mesures que
pour les HRTF originales. Le résultat ainsi obtenu est représenté par un liseré
marron et superposé aux HRIR individualisées (fig. 1.38, bas). Une bonne
coïncidence entre l’ITD mesuré et le front d’onde est de nouveau obtenu
par cette méthode. De plus, la HRIR individualisée ne semble pas présenter
d’aberration flagrante faisant suite au traitement subi, ce qui donne du cré-
dit au résultat obtenu pour l’ITD. Aussi, ce dernier a été tracé en rouge sur
la figure 1.39, au même titre que la mesure de l’ITD du modèle sphérique
équivalent. Comme le montrent ces deux dernières courbes, l’ITD individualisé
semble coller à son modèle et ce dernier est bien représentatif d’une tête
65sphérique singulièrement plus petite que l’originale (en bleu). Donc, mises à
part les aberrations frontales déjà présentes pour le modèle sphérique original,
il semble bien que l’ITD soit indépendant du résidu de la décomposition
sphérique, ce qui en autorise la personnalisation.
Pour poursuivre cette étude, il faudrait désormais valider l’individualisation
de la phase et de l’amplitude spectrale. Cette étape, bien plus complexe,
n’a pas été abordée durant cette thèse et fera très probablement l’objet de
recherches ultérieures. Par ailleurs, des modèles numériques peuvent désormais
être utilisés pour affiner l’individualisation, comme des têtes ellipsoïdes,
des "snowman model", ou encore des maillages de têtes.
66Chapitre 2
Moteur binaural PifPaf3D
Une grande partie des travaux de thèse a porté sur la conception et la
réalisation d’un moteur de synthèse binaurale innovant, nommé PifPaf3D
(fig. 2.1). Ce moteur intègre de nombreuses fonctionnalités pour chaque étape
de la chaîne de production sonore, de la captation à la restitution. Il a été entièrement
programmé et optimisé en langage Matlab, bénéficiant ainsi d’une
grande souplesse de programmation pour en faire un outil de prototypage
efficace (≈ 2000 lignes de code). De plus, aucune librairie externe n’a été
utilisée, ceci afin d’assurer un contrôle total sur l’ensemble des traitements
effectués. Aussi, l’essentiel des recherches effectuées en spatialisation sonore,
présentées ou non dans ce manuscrit, ont été implémentées dans ce moteur,
testées et validées de manière analytique et/ou subjective. Par ailleurs, ce
spatialisateur ayant été développé dans le contexte industriel de la thèse
CIFRE, pour des raisons évidentes de protection de la propriété industrielle,
seule une revue générale des différents modules est présentée dans ce chapitre.
Les détails de conception et de programmation de ce moteur ne seront
donc pas explicités.
2.1 Introduction et configuration
Le spatialisateur PifPaf3D est un logiciel exclusivement écrit en langage
Matlab, interfacé avec une interface graphique (GUI) faisant appel aux différentes
parties de la librairie, selon le traitement audio souhaité (fig. 2.1).
Il se décompose en différents modules, indépendants et autonomes, ce qui
permet de réaliser n’importe quel traitement audio dans un ordre déterminé
par l’utilisateur. Les passerelles pour assurer la communication entre chaque
module ont été implémentées sous forme de pipe-line et tous les traitements
ont été programmés sous forme de fonctions callback. Cette logique de pro-
67Figure 2.1 – PifPaf3D, prototype Matlab pour la spatialisation sonore en temps réel.
68Figure 2.2 – PifPaf3D - Module de Configuration.
grammation rend ce code suffisamment flexible pour s’adapter au traitement
audio temps réel. À titre informatif, sur un ordinateur portable standard dont
le processeur est cadencé à 1.6Ghz, il est possible de spatialiser et contrôler
en temps réel au moins seize sources sonores dynamiques simultanément. En
mode offline, un nombre illimité de sources peut être joué puisque le temps
de calcul est simplement proportionnel au nombre de canaux traités.
Au démarrage de PifPaf3D, la première étape consiste à configurer le
moteur avec l’interface graphique (fig. 2.2), qui permet d’accéder aux principaux
paramètres. Tout d’abord, l’utilisateur fait le choix dans une liste de
fichiers audio multicanaux, présents dans un dossier ’wav/input/’ à la racine
du script de lancement du logiciel. Ces fichiers doivent être au format .wav,
préférentiellement échantillonnés à 44.1 kHz et de nombre de canaux fixe
(mono, stéréo, 5.1, 7.1, n.m, etc.). Ensuite, l’utilisateur peut choisir son routing
dans une batterie de fichiers .txt, disponibles par défaut dans un dossier
’data/speakers’. Ces fichiers contiennent à la fois des positions statiques de
sources audio et des trajectoires pré-établies en fonction du temps et de l’espace.
L’utilisateur peut ainsi utiliser les routing présents, ou créer son propre
fichier. Voici, par exemple, un script pour effectuer une trajectoire dynamique
sur deux canaux. Ici, le premier canal se déplace pendant 30 secondes derrière
l’auditeur, tandis que le second passe au-dessus sur la même durée :
% Source 1
sources.azimuth{1} = [90,270]; % Azimut (deg)
sources.elevation{1} = [0,0]; % Elevation (deg)
sources.range{1} = [2,2]; % Distance à l’auditeur (m)
sources.time{1} = [0,30]; % Durée entre les 2 positions (s)
% Source 2
sources.azimuth{2} = [270,270];
sources.elevation{2} = [0,180];
69sources.range{2} = [2,2];
sources.time{2} = [0,30];
Cette étape effectuée, l’intervalle de lecture du fichier audio est défini, avec
pour unité la seconde. Enfin, la latence du rendu temps réel peut être modi-
fiée, ainsi que la taille des blocs de traitement du signal. Ces deux paramètres
agissent essentiellement sur la fluidité de la lecture en rendu temps réel, qui
est fonction de la puissance de calcul disponible sur la machine. Une fois tous
ces choix établis, le spatialisateur peut être lancé en cliquant sur le bouton
"GO !", ce qui affichera l’interface complète (fig. 2.1) et bloquera définitivement
le module de configuration (fig. 2.2). PifPaf3D devra donc être relancé
pour tout changement ultérieur dans ces données.
Pour les utilisateurs plus avancés, il est possible de choisir d’autres paramètres
directement dans le code source. À titre d’exemple, peuvent être
cités la forme des fenêtres de traitement audio (Hann, Porte, Sine, Linear,
etc.), le répertoire de sortie des fichiers audio après traitement (par défaut
’wav/output/’) ou la taille des filtres utilisés.
2.2 Transport et contrôle
Le module de transport (fig. 2.3) se décompose en deux parties. La première
partie (onglet "Play") propose les principales fonctionnalités de lecture
et de navigation dans un fichier audio, à savoir un curseur de lecture, un curseur
de volume pour le monitoring, un bouton play/pause, ainsi qu’un bouton
de répétition. Par ailleurs, il est possible de désactiver la lecture temps réel
pour traiter des fichiers audio plus rapidement en mode offline. Tous les algorithmes
de traitement du signal sont routés sur ce module, qui réalise une
transformée de Fourier en overlap-add [7] sur des blocs fenêtrés, typiquement
par des fenêtres de Hann. Ce fenêtrage est nécessaire pour limiter l’impact
d’éventuels changements brutaux dans des fonctions de transfert utilisées
lors d’un filtrage, qui peuvent introduire des claquements audibles perturbant
l’écoute. Par exemple, des sauts de filtres interviennent en continu lors
du traitement binaural de sources en mouvement. Aussi, cette combinaison
entre overlap-add et fenêtrage a été optimisée pour le cas particulier du filtrage
binaural, dont les fonctions de transfert HRTF ont des caractéristiques
propres. Cette optimisation a conduit au développement d’un algorithme
type overlap performant, qui fera l’objet d’une publication ultérieure.
La seconde partie de ce module (onglet "Sources", fig. 2.3) permet de visualiser
séparément des informations relatives aux canaux audio, préalablement
définis dans le routing, dans un esprit de mixage objet. C’est pourquoi
70Figure 2.3 – PifPaf3D - Module de transport.
chaque tranche donne la couleur et les coordonnées sphériques de la source
associée, représentée dans le module de contrôle détaillé ci-après (fig. 2.4).
De plus, il est possible d’activer ou de désactiver une source sonore par des
boutons "Mute/Solo" interconnectés, ainsi que de modifier le gain d’entrée de
chaque tranche de +/- 3 dB.
Au même titre que le module de transport, le module de contrôle (fig. 2.4)
se décompose en deux parties. La première partie (fig. 2.4, gauche) donne
une représentation de l’espace péri-personnel, avec un auditeur représenté
en trois dimensions entouré de sources sonores ponctuelles. Pour faciliter la
visualisation, les axes cartésiens ont été rajoutés, ainsi que trois cercles de
positionnement inclus dans une sphère de rayon unité, le tout complété par
un plan sur lequel repose l’auditeur. De plus, des rotations de la camera et
de l’éclairage sont autorisées, notamment pour lever d’éventuelles indéterminations
de positionnement en naviguant au sein de la scène sonore. Enfin,
un onglet situé en haut à gauche de l’interface graphique permet de choisir
le mode de déplacement des sources sonores pour les contrôler en temps
réel. Les sources à mouvoir sont sélectionnées dans le module de transport
(fig. 2.3) par un clic sur le bouton donnant les coordonnées sphériques de
leur position, puis déplacées par le pavé numérique du clavier, la souris, ou
encore une manette de type Microsoft XBox 360. Le clavier et la manette
71Figure 2.4 – PifPaf3D - Module de contrôle.
font bouger les sources relativement à leurs positions respectives, tandis que
la souris fixe une position absolue. Dans ce dernier cas, la position de la croix
rouge sur la grille du module de contrôle (fig. 2.4, droite) détermine les coordonnées
azimutales des sources sonores sélectionnées, tandis qu’un curseur
sur le côté permet d’en modifier l’élévation. Toutes ces fonctionnalités faisant
appel à un rafraîchissement graphique récurent (plutôt gourmand en CPU),
le ratio entre la charge de calcul disponible et le coût de la mise à jour est
vérifié en permanence, notamment pour que ces dernières ne soient pas faites
au détriment des traitements audio.
Il est important de souligner que ces outils ont avant tout été conçus pour
naviguer et contrôler des sources sonores en temps réel sous Matlab, afin de
tester et valider les différents traitements audio. Ils n’ont donc pas vocation
à former une véritable plate-forme de mixage professionnel.
2.3 Traitement Binaural
Le module de traitement binaural (fig. 2.5) s’appuie essentiellement sur les
recherches présentées dans le premier chapitre de ce manuscrit. Tout d’abord,
les bases de données de fonctions HRTF utilisées pour le filtrage (onglet
"HRIR" de la figure 2.5) sont issues des bases publiques suivantes :
– CIPIC, Université de Californie [3] ;
– ARI, Institut de Recherche en Acoustique de l’Académie des sciences
d’Autriche [6] ;
– LISTEN, Institut de Recherche et Coordination en Acoustique et
Musique [62].
72Figure 2.5 – PifPaf3D - Module de traitement binaural.
Ces bases ont comme points communs d’être disponibles au format Matlab
et d’être livrées avec des filtres sous forme HRIR, des coordonnées des points
de mesures, ainsi que des données morphologiques associées à chaque sujet.
Ces trois informations sont nécessaires et suffisantes pour le bon fonctionnement
du filtrage binaural dispensé par PifPaf3D. En effet, la convolution
en domaine de Fourier entre un signal monophonique et les filtres gauches
et droits d’une HRTF à une position donnée est réalisée par interpolation
linéaire locale quadrangle sur des grilles régularisées de filtres. Pour ce type
de support, la recherche des filtres voisins à la position souhaitée est instantanée
: les parties entières de l’azimut et de l’élévation donnent directement
les indices des filtres à interpoler, tandis que les parties décimales fournissent
les coefficients de pondération de la sommation. Il n’y a donc pas de parcours
d’arbre, ce qui diminue d’autant les charges de calcul pour chaque position
à évaluer. Aussi, une attention particulière a été portée sur l’interpolation
globale des HRTF brutes, notamment pour minimiser les erreurs générées au
cours de la formation des grilles régulières, à l’origine d’artefacts audibles.
Les recherches sur cette problématique ont conduit à la Décomposition par
Modèle Morphologique (1.9), présentée dans le chapitre précédent. Ainsi,
dans un premier temps, des bases de données fidèles aux mesures brutes ont
été créées en vue de pratiquer une interpolation locale inaudible (fig. 1.33
et 1.34). Le modèle sphérique de Duda [25] a été utilisé et paramétré par le
rayon de la tête dont sont issues les HRTF mesurées. Lorsque celui-ci n’est
pas disponible, le rayon de tête moyen (8.74 cm) sert de référence [58]. Pour
effectuer des comparaisons subjectives, trois raffinements sont prévus dans
l’onglet "Database" de la figure 2.5, à savoir "Low", "Medium" et "High density",
correspondant respectivement à 15, 10 et 5 degrés de discrétisation en
azimut et élévation. D’autre part, il est important de souligner que les bases
de données [3], [6] et [62] ne sont pas les seules exploitables par PifPaf3D,
puisque l’algorithme d’interpolation globale est applicable dès lors que les
73filtres et les positions des mesures sont fournis.
Par la suite, il est apparu après quelques optimisations que la Décomposition
par Modèle Morphologique était peu coûteuse en calcul, ce qui rendait
le processus adapté pour du traitement en temps réel. Aussi fut-elle inté-
grée directement dans PifPaf3D pour pratiquer les interpolations locales sur
des grilles de filtres régulières et déraffinées (exemple fig. 1.36 et 1.37), plus
rapides d’accès puisque plus légères en mémoire. De plus, le peu d’espace
nécessaire au stockage de ces données favorise le traitement embarqué sur
processeurs dédiés de type DSP, qui disposent de plus de ressources de calcul
que de mémoire vive. En pratique, PifPaf3D exploite désormais les grilles
échantillonnées tous les 15 degrés par défaut, sans artefact d’interpolation
audible. Le choix de la densité des grilles est toujours proposé à titre comparatif,
mais inusité en pratique. Enfin, l’espace mémoire requis pour de telles
grilles est d’environ 2 Mo, ce qui constitue un format d’échange exploitable.
Par ailleurs, un bouton "on/off " est disponible sur l’interface graphique
(fig. 2.5) pour comparer en temps réel l’activation du binaural contre un
downmix stéréo du contenu multicanal original. Afin d’estimer le gain à fournir
aux canaux gauches et droits, le downmix utilise la norme Root Mean
Square (moyenne quadratique) normalisée des filtres HRTF aux positions
des sources sonores. Ainsi, le downmix est bien rendu en stéréophonie, il
tient compte de la position des sources sonores et conserve la norme RMS du
signal "downmixé" constante par rapport au traitement binaural. Ce faisant,
les écoutes comparées permettent d’apprécier à sa juste valeur la spatialisation,
sans autres biais que le Loudness.
Pour les utilisateurs avertis, PifPaf3D propose quatre paramètres avancés
disponibles dans l’onglet "Advanced" de la figure 2.5 :
1. Le premier de ces paramètres ("D") offre une première étape d’individualisation.
Le principe est fondé sur la Décomposition par Modèle
Morphologique pour l’individualisation, telle que présentée dans le chapitre
précédent. L’utilisateur rentre le diamètre de sa tête en cm, qui
sera utilisé pendant l’étape de recomposition par modèle sphérique.
Les réponses fréquentielles présentes dans les HRTF finales se trouve
dès lors plus proches de celles de l’utilisateur que de celles des HRTF
originales, notamment pour l’ITD (fig. 1.39).
2. Les deux paramètres suivants ("A","T") règlent respectivement l’amplitude
(degré) et la période (seconde) des oscillations des micro-variations
de sources, détaillées dans le chapitre précédent (fig. 1.35). Par défaut,
ces paramètres sont fixés en deçà du seuil de perception. Des recherches
par tests perceptifs ont été effectuées par un stagiaire pour analyser
l’impact de ces paramètres sur la localisation. Ces travaux n’ayant pas
74Figure 2.6 – Schématisation des premières réflexions intervenant lors
de la propagation d’une onde sonore dans un espace clos. (source
www.audacity.sourceforge.net)
donné de résultats significatifs, des études restent encore à mener pour
évaluer les micro-variations et trouver des paramètres rigoureux.
3. La dernière option permet d’activer ou de désactiver un modèle dynamique
de premières réflexions (early reflexions, fig 2.6), fruit d’une
discussion avec J.-C. Messonnier du Conservatoire National Supérieur
de Musique et de Danse de Paris [66]. Ce modèle est fondé sur une
méthode source-image temps réel [2], indépendante pour chaque source
sonore, ayant vocation à simuler la présence de panneaux réflecteurs
autour de la source pour favoriser la création d’énergie précoce [63].
Pour ce faire, deux HRTF sont superposées à l’originale, choisies symétriquement
de part et d’autre et de la source. Chacune est retardée
manuellement, relativement à la distance entre l’auditeur et la source
fantôme ainsi créée. Cet outil offre des perspectives intéressantes, en
rajoutant des indices de localisation pour lever l’indétermination de positionnement
des sources sonores. Une analyse plus approfondie, ainsi
qu’une validation subjective fera l’objet de travaux ultérieurs.
Pour terminer, plusieurs effets de distance ont été rajoutés, afin d’imiter
artificiellement l’éloignement entre la source sonore et l’auditeur (fig. 2.5). Le
premier effet, simple et efficace, consiste à jouer sur le volume de la source
sonore en fonction de son éloignement. Une loi en 1
rα a été employée, avec α
contrôlé par l’utilisateur pour adapter le gain en fonction du contenu audio.
75Figure 2.7 – Cross-ear selection pour la correction des HRTF gauches et
droites, en champ proche [75]. Sur ce schéma, la sphère verte représente une
tête, le maillage quadrangle appartient à la sphère de mesure des HRTF, la
flèche bleu indique l’avant (axe Ox), la flèche verte indique la gauche (axe Oy)
et la flèche rouge le dessus (axe Oz). Pour une source proche de l’auditeur
(trait plein noir), le filtre HRTF sans traitement spécifique est celui donné
par la direction en pointillés, invariant selon la distance. Après cross-ear
selection, les filtres gauches et droits sont donnés par les directions en tirets.
Le deuxième effet intervient lors de la Décomposition par Modèle Morphologique,
en recomposant le résidu sphérique par les HRTF sphériques évaluées
cette fois à la distance souhaitée. Le troisième effet consiste à filtrer
le signal d’entrée par un coupe-haut modélisant l’absorption de l’air selon
la distance parcourue par l’onde sonore. Cet effet intervient principalement
pour les sources en champ lointain. Pour le champ proche, un quatrième et
dernier effet nommé cross-ear selection vient compléter cette panoplie [53]
[75]. Les HRTF utilisées pour le traitement binaural sont sélectionnées sur
la sphère de mesure originale, en calculant géométriquement les coordonnées
des HRTF réellement mises en jeu lorsqu’une source se rapproche de l’auditeur
(fig. 2.7). Mathématiquement, cela revient à résoudre une équation du
second degré pour chaque oreille, puisque la position cherchée est solution de
l’intersection entre une droite et une sphère. Pour l’ensemble de ces effets, il
est important de préciser que, faute de base de données de HRTF en distance
aisément disponible, aucun procédé n’a été validé analytiquement. Seule une
évaluation perceptive a été pratiquée, donnant des résultats encourageants.
Une analyse approfondie de ces effets doit désormais être faite pour s’assurer
que les HRTF ainsi modifiées respectent bien la physique du problème.
76Figure 2.8 – Microphone Soundfield SPS200 et enceinte KH pour la mesure
impulsionelle en B-Format du studio de répétition de l’École Polytechnique.
(Atelier des Ondes, www.atelierdesondes.net)
2.4 Acoustique de salle et Ambisonics
Comme les HRTF sont classiquement mesurées en chambre anéchoïque, le
traitement binaural issu de la convolution avec de tels filtres souffre bien souvent
d’un manque d’espace, minimisant la sensation d’externalisation. C’est
pourquoi, un module d’acoustique de salle vient avantageusement compléter
le module binaural précédent, en apportant l’illusion de la diffusion au sein
d’une pièce. Le principe consiste en l’ajout d’une réverbération directionnelle
pour chaque source sonore, captée en trois dimensions en High Order
Ambisonics (HOA) et restituée en binaural par un système de haut-parleurs
virtuels fixes. La thèse de J. Daniel [20] en explicite toute la théorie, qui ne
sera donc pas reprise ici, mais survolée d’un point de vue pratique en accord
avec la courte introduction du premier chapitre.
La première étape pour réaliser ce traitement consiste à construire une
base de données de réponse impulsionnelle d’une salle (Room Impulse Responses)
en format HOA. Pour ce faire, il existe principalement deux mé-
thodes :
– Virtuellement en simulant numériquement la mesure avec des logiciels
adaptés, tels que Catt-Acoustique 1
. Cette approche permet d’obtenir
un ordre HOA flexible, de considérer n’importe quelle pièce et de disposer
les points de mesures à n’importe quelle position de l’espace. En
1. Un résultat de simulation numérique d’un studio de type LEDE, effectuée au
LIMSI/CNRS, a été utilisé dans cette étude.
77Figure 2.9 – Projection sur les harmoniques sphériques de la norme RMS
des quatre signaux du B-Format, représentation spatiale d’une mesure par
microphone SoundField.
revanche, certaines simulations peuvent générer des artefacts audibles,
notamment en haute fréquence, qui nuisent au rendu.
– Réellement en mesurant des réponses impulsionnelles avec une sphère
de microphones. Cette technique demande à la fois du matériel de haute
qualité (microphones HOA, carte son, haut-parleurs, salle mesurable,
etc.), ainsi que des logiciels de traitement du type encodeur/décodeur
HOA. Cette technique est plus difficile à mettre en œuvre, mais offre
souvent des résultats plus convaincants à l’écoute.
Ces deux approches ont été testées durant la thèse et les résultats intégrés
dans PifPaf3D. Ainsi, un outil Matlab a été spécifiquement programmé pour
réaliser des mesures de réponses impulsionnelles par microphone HOA. Cependant,
comme le seul microphone 3D à disposition pendant la thèse était
un Soundfield SPS200 (à gauche sur la figure 2.8), toutes les prises de son
ont été faites à l’ordre 1 (équivalent du B-Format). Ce logiciel doit donc encore
être éprouvé pour les ordres supérieurs. Cela étant, trois pièces ont été
mesurées, à savoir la salle à manger de la société Digital Media Solutions, le
bureau de l’équipe Audio 3D de DMS et le studio de répétition des étudiants
de l’École Polytechnique (fig. 2.8). Dans le cas du studio, un haut-parleur a
été placé tous les 30 degrés en azimut, à élévation nulle, pour générer une
base de données sur douze positions. Le signal de mesure utilisé est une
combinaison entre codes de Golay [32], bruit blanc et sweep-sine fréquentiel
[80]. À titre d’exemple issu d’une de ces mesures, la projection sur les har-
78Figure 2.10 – Méthode des haut-parleurs virtuels pour le rendu ambisonique
en binaural. (source [20])
moniques sphériques de la norme RMS des quatre signaux du B-Format est
représentée dans l’espace sur la figure 2.9. Cette enveloppe prend la forme
d’un champignon, dont le maximum est symbolisé par l’étoile noire, tandis
que le cercle noir donne la position théorique du haut- parleur comme réfé-
rence. La mesure est validée dès lors que ces deux objets sont suffisamment
proches, preuve que l’onde directe est captée à la bonne incidence. Avec ce
type de représentation, cet outil peut aussi servir à la localisation de sources
sonores. En complément de ces données, les RIR effectuées par A. Farina en
B-format dans une salle de classe, une bibliothèque et une salle de concert
(www.isophonics.net, [29]) ont aussi été intégrées dans PifPaf3D.
La deuxième étape consiste à filtrer les sources sonores ponctuelles par les
fonctions de transfert tridimensionnelles de la pièce, obtenues pendant l’étape
précédente. Tout d’abord, chaque position est associée à la plus proche RIR
mesurée et le contenu audio de la source est filtré en domaine ambisonique
pour obtenir la projection du signal original sur les harmoniques sphériques.
Suivant cette étape d’encodage, un filtrage supplémentaire peut éventuellement
être ajouté pour corriger la proximité des haut-parleurs, ou encore la
sphéricité du microphone dans le cas d’une mesure réelle. Une fois toutes
les sources audio traitées par leurs réponses respectives, celles-ci sont sommées,
toujours en domaine ambisonique. Un décodage associe alors le signal
à diffuser sur chaque haut-parleur virtuel, qui sont in fine rendus par filtrage
binaural comme résumé figure 2.10.
En pratique, le module d’acoustique de salle de PifPaf3D (gauche, fig. 2.11)
est capable de traiter jusqu’à huit sources sonores en temps réel avec un dé-
codage HOA d’ordre 3, diffusé sur un système à vingt canaux disposés aux
79Figure 2.11 – PifPaf3D - (Gauche) Module de traitement acoustique de
salle. (Droite) Module de traitement High Order Ambisonics.
sommets d’un dodécaèdre. Pour ce faire, l’algorithme d’overlap-add optimisé
pour le traitement binaural a été adapté à l’ajout d’acoustique de salle par
convolution, ce qui diminue considérablement les coûts de calculs effectués
par Matlab. De plus, l’interface graphique offre la possibilité de comparer
l’ajout d’acoustique de salle au signal original par un bouton "on/off ", qui
active/désactive l’effet en temps réel. Pour respecter les niveaux lors d’écoutes
comparées, un contrôle des gains à la volée a été ajouté pour que la norme
RMS du signal de sortie soit proche de celle du signal d’entrée. Cette option
est disponible par simple clic sur le bouton "Volume" de l’interface. Par
ailleurs, comme expliqué précédemment, plusieurs salles sont présentes par
défaut, comme le studio de l’école Polytechnique, et l’utilisateur averti peut
aisément rentrer ses propres mesures dans le code source. Un ordre ambisonique
variable est proposé, entre 0 (réverbération classique) et 3 (réverbération
directionelle), scalable au besoin selon la théorie HOA. Un curseur
permet en outre de jouer sur le rapport "Dry-Wet", couramment utilisé par
les ingénieurs du son utilisant ce type d’effet. Pour finir, un filtre additionnel
permet de compenser la proximité des haut-parleurs (bouton "Near LS") et
l’utilisateur peut activer une interpolation linéaire des RIR, à la place d’une
recherche de la RIR la plus proche (bouton "Interp").
Suite aux développements effectués pour les mesures réelles de réponses
impulsionelles de salle en High Order Ambisonics, un module autonome de
traitement HOA a été ajouté à PifPaf3D (droite, fig. 2.11). Ce dernier pratique
un encodage/décodage des signaux bruts issus de microphones sphé-
riques, couplé à des filtres correctifs. En pratique, seul le Soundfield SPS200
a été éprouvé, faute de microphones d’ordre plus élevé disponibles. Les signaux
de sortie sont donc directement projetés sur les harmoniques sphé-
riques, relativement aux positions des capsules, avant d’être filtrés en domaine
ambisonique pour compenser notamment la répartition sphérique et
la directivité des capsules. Enfin, le décodage HOA est effectué sur le sys-
80Figure 2.12 – Représentation fréquentielle du module des filtres associés au
casque Sennheiser HD25.
tème de haut-parleurs choisi lors de la première étape de configuration de
PifPaf3D. Comme le montre l’interface graphique, un choix de microphones
est néanmoins possible et les filtres spatiaux associés sont activables (bouton
"Spatial filter"). De plus, il est possible de visualiser en trois dimensions le
microphone utilisé en cliquant sur le bouton "Visu Mic", notamment pour
s’assurer du routing entre les canaux de sortie du microphone et les entrées
fixées dans ce module. Enfin, le contenu encodé en HOA peut être sauvé pour
une éventuelle utilisation extérieure des signaux bruts encodés en domaine
ambisonique (bouton "Save Content").
2.5 Compensation du casque et égalisation
Le dernier module présenté dans ce chapitre concerne la compensation
du casque et l’égalisation tri-bande du signal de sortie. La compensation
du casque consiste en la suppression de la fonction de transfert issue à la
fois des transducteurs utilisés, de la forme et des matériaux de la structure
du casque, ainsi que de la cavité formée par le système {Oreille Externe ;
Casque} dans le cas d’une écoute fermée. Pour ce faire, plusieurs séries de
mesures ont été pratiquées en plaçant différents casques sur la tête artifi-
cielle Neumann KU100, isolée phoniquement par des panneaux absorbants.
Le signal utilisé pour l’obtention des fonctions de transfert est une combinaison
entre code de Golay, bruit blanc et sweep-sine, au même titre que
pour les mesures de réponses impulsionnelles de salle. Entre chaque excitation,
le casque est retiré puis remis, ceci afin de moyenner intrinsèquement
les différents positionnements possibles sur les oreilles. Un code Matlab a été
81Figure 2.13 – PifPaf3D - Module de compensation de casque et d’égalisation
tri-bandes.
spécifiquement développé pour traiter les données ainsi obtenues et livrer un
filtre brut utilisable par PifPaf3D. Un exemple de module fréquentiel d’une
fonction de transfert mesurée avec un casque type Sennheiser HD25 est représenté
en bleu sur la figure 2.12. Sur cette même figure, apparaissent les
différents étapes de traitement avec, en premier lieu, le filtre brut tronqué
(en rouge) par un gabarit (en noir), dont la bande fréquentielle est définie par
l’utilisateur. Étant donné que la mesure par tête artificielle nécessite l’utilisation
d’un filtre coupe-bas pour limiter le bruit, la valeur minimale du gabarit
a été fixée à 400 Hz. La valeur maximale est déterminée par une estimation
empirique de la zone de linéarité des transducteurs au delà de laquelle les
mesures ne sont plus considérées comme tangibles (ici 4000 Hz). Le module
de la fonction de transfert ainsi obtenue est alors inversé pour servir de réfé-
rence à la création d’un filtre à minimum de phase par modélisation du type
Yulewalk (en vert sur la figure 2.12). Ce filtre compensatoire est alors utilisé
par convolution en domaine de Fourier sur les signaux gauches et droits.
L’interface graphique associée au module de compensation du casque
(fig. 2.13) propose ainsi un ensemble de corrections de casques, mesurés au
sein de la société DMS et obtenu d’après le protocole précédent. Le module
du filtre fréquentiel associé est affiché en noir sur cette figure et le résultat du
filtrage des canaux gauche et droit est donné en temps réel par les courbes
bleu (canal gauche) et rouge (canal droit). Un bouton "on/off " permet d’activer
ou désactiver le traitement en temps réel, notamment pour les écoutes
comparées. Par ailleurs, en utilisant cette fonctionnalité, un bruit blanc a été
compensé par PifPaf3D pour chaque casque mesuré. Le fichier audio obtenu
a été diffusé et enregistré sur le même dispositif que celui utilisé pour les mesures,
à savoir le casque positionné sur la tête artificielle Neumann KU100.
Ce résultat a été comparé en domaine fréquentiel à la diffusion du bruit blanc
de référence, où la fonction de transfert est non compensée. Ainsi, pour la
82plupart des casques, le module fréquentiel obtenu après compensation est
bien plus aplati, ce qui valide expérimentalement le procédé et les résultats.
Enfin, en complément de cet outil, un égaliseur tri-bande du second ordre
est proposé, notamment pour compenser d’éventuelles détériorations fréquentielles
du signal original traité par les différents modules composant PifPaf3D.
Ce dernier est accessible en temps réel par trois curseurs modifiant les gains
par bande de fréquence ("Low", "Medium" et "High", fig. 2.12). Un bouton
"Reset" a été ajouté pour remettre rapidement l’ensemble de ces gains à leur
valeur par défaut.
2.6 SpherAudio Headphones
Dès ses premières versions, PifPaf3D a démontré des performances étonnantes
d’un point de vue qualitatif, validées par de nombreux ingénieurs du
son, ainsi que d’importants industriels du monde de l’audio. La société DMS
a donc rapidement monté une équipe de développement pour créer une librairie
C/C++ industrialisable, dont l’équivalence au code Matlab est certifiée
par une batterie de tests de non régression. Afin d’assurer une retranscription
inaudible sur l’ensemble des traitements effectués, ces tests adoptent tous une
précision relative fixée à 10−6
sur les signaux de sortie. PifPaf3D reste donc
l’unique référence, limitant les conflits éventuels entre les différents codes.
Par ailleurs, la librairie C/C+ a été popularisée sous la marque SpherAudio
Headphones (fig. 2.14 et 2.15), et interfacée avec :
– un plug’in VST sous Reaper (SpherAudioVST) ;
– un processeur dédié (BP84 ) ;
– une tablette Samsung Galaxy Tab (SpherAudioDroid) ;
– une web audio API en HTML5 (SpherAudioAPI) ;
– un serveur audio (SpherAudio@Home).
Mis à part le BP84, tous ces développements ont été réalisés par M. Mathieu
Coïc, que j’ai eu le plaisir d’encadrer en parallèle des travaux de recherche
doctorale présentés dans ce manuscrit. Par ailleurs, de nombreux stagiaires
ont contribué à la réalisation de ces outils. Dès lors, il est agréable de préciser
que le plug’in VST et le processeur dédié ont été utilisés par de nombreux
organismes, publics ou privés (CNSMDP, Radio France, France Télévision,
INA, Technicolor, etc.). De plus, Radio France a mis en ligne un site internet
pour diffuser des contenus spatialisés, utilisant la gamme SpherAudio
pour l’encodage binaural (fig. 2.16). Je profites donc de ce court aparté pour
renouveler à tous et à toutes mes sincères félicitations et remerciements.
83Figure 2.14 – Outils et logiciels dérivés de PifPaf3D, développés en parallèle de la thèse par la société Digital
Media Solutions. (Haut, gauche) Spatialisateur SpherAudioAPI pour les plate-formes web compatibles HTML5,
comme Google Chrome. (Haut, droite) Spatialisateur SpherAudioDroid pour les tablettes Androïd du type Samsung
Galaxy et les terminaux mobiles compatibles. (Bas, gauche) Plug’in VST SpherAudioVST pour le logiciel de Musique
Assisté par Ordinateur Reaper. (Bas, droite) Processeur Binaural BP84 pour le traitement professionnel sur système
embarqué, proposant huit entrées mono et quatre sorties binaurales.
84Figure 2.15 – Outils et logiciels dérivés de PifPaf3D, développés en parallèle
de la thèse par les ingénieurs de la société Digital Media Solutions. (Gauche)
Interface "télécommande" pour serveur d’Audio spatialisé sous tablette Androïd.
(Droite) Interface "télécommande" pour serveur d’Audio-description
spatialisée sous tablette Androïd, en vue d’améliorer l’accessibilité au cinéma
des personnes non-voyantes.
85Figure 2.16 – Visuels extraits de nouvoson.radiofrance.fr, plate-forme de
contenus multicanaux mis en ligne par Radio France, utilisant les outils dé-
rivés de PifPaf3D pour l’encodage binaural (BP84 et SpherAudioVST).
868788Chapitre 3
Formulations intégrales rapides
pour l’acoustique
Une fois que le spatialisateur PifPaf3D eut atteint un stade de développement
suffisant pour être exploité dans la suite des recherches, la seconde
partie de la thèse porta sur la génération numérique des fonctions de transfert
HRTF, notamment pour leurs individualisations. En effet, comme expliqué
dans les chapitres précédents, une des difficultés majeures que rencontrent
aujourd’hui les technologies binaurales concerne la personnalisation de ces
filtres, propres à chacun. De nombreuses études ont démontré qu’un filtrage
générique est insuffisant pour un rendu de l’espace réellement convaincant
(e.g. [12], [67], [86]). C’est pourquoi le but original de l’ensemble du projet
de thèse consiste en l’obtention et l’exploitation de HRTF individualisées
pour le grand public, obtenues par une reproduction numérique des mesures
physiques (e.g. [39], [49], [50], [51], [52]). Le protocole alors envisagé (fig. 3.1)
est découpé en trois grandes étapes :
1. Création et adaptation de maillages de tête/corps individuels, obtenus
par traitement d’images et fusionnés ou non avec des maillages paramétriques
de formes élémentaires (sphères, ovoïdes, cônes, etc.). Cette
étape, détaillée dans le chapitre suivant, a notamment été réalisée en
Matlab à partir de données issues d’une Kinect Microsoft.
2. Réalisation d’un moteur de calcul intégral pour résoudre rapidement les
équations de propagation des ondes sur lesdits maillages. Cette étape
a donné naissance à la librairie MyBEM, entièrement programmée en
Matlab et optimisée par vectorisation. De plus, une nouvelle méthode
rapide intitulée "Décomposition Creuse en Sinus Cardinal" ("Sparse
Cardinal Sine Decomposition") a été implémentée en lieu et place des
classiques méthodes multipolaires FMM (e.g. [31], [34], [35], [38], [82]).
89Figure 3.1 – Résumé de la méthodologie envisagée pour la création de HRTF
numériques individualisées. Diagramme issu du projet de thèse initial, entre
mathématiques appliquées et acoustique.
903. Validation par tests perceptifs des HRTF issues des simulations numériques
sur les maillages individuels, en utilisant le moteur binaural
PifPaf3D pour le rendu audio. Cette étape n’a pas été réalisée pendant
la thèse et fera l’objet de recherches ultérieures. 1
Une revue théorique des équations intégrales fait donc l’objet de la première
partie de ce chapitre, adjointe à l’introduction de la méthode multipolaire rapide
(Fast Multipole Method). Dans une seconde partie, la nouvelle méthode
rapide SCSD est présentée, non pas de façon théorique, mais en suivant les
différentes étapes du raisonnement qui ont menées vers le formalisme final.
Une présentation moins empirique, établie en parallèle de la rédaction de
ce manuscrit, est disponible dans l’article [5] joint en annexe. La réalisation
pratique au sein de la librairie MyBEM, développée conjointement avec
F. Alouges, est quant à elle présentée dans le chapitre suivant.
3.1 Représentation et équations intégrales
Il existe différentes méthodes pour la modélisation numérique des phé-
nomènes de propagation d’ondes, classés parmi les problèmes hyperboliques
linéaires. En effet, la linéarité permet un traitement de la variable temps par
transformée de Fourier, ce qui autorise une formulation en temps comme en
fréquence. Dans le cas de l’acoustique fréquentielle, le problème de diffraction
résultant peut être écrit sous une forme intégrale, puis discrétisé par éléments
finis de frontière. Cette section introduit donc quelques rappels classiques des
équations intégrales sous forme variationnelle. Pour plus de précisions, le lecteur
curieux peut se documenter sur les ouvrages suivants : [13], [16], [55],
[69] et [82].
3.1.1 Diffraction dans l’espace libre
Les équations de l’acoustique s’obtiennent par linéarisation des équations
d’Euler, caractérisant les fluides :
– Conservation de la masse ;
– Conservation de la quantité de mouvement ;
– Conservation de l’entropie pour les fluides parfaits.
1. En complément, des itérations sur l’ensemble de ce processus sont envisagées pour
obtenir une personnalisation optimale. En effet, il doit être possible d’exploiter les données
issues des tests perceptifs pour guider la création des maillages de calcul, ainsi que pour
définir les conditions aux limites du problème à résoudre. Cette piste fera très probablement
l’objet de travaux futurs.
91En fixant c la vitesse du son dans un fluide au repos, la pression acoustique
p vérifie l’équation des ondes scalaire :
1
c
2
∂
2
t
p − ∆p = 0. (3.1)
Pour que ce modèle conduise à un problème bien posé, il est nécessaire d’ajouter
des conditions initiales à t = 0.
Par ailleurs, comme l’équation des ondes scalaire (3.1) est linéaire, la
transformée de Fourier en convention temporelle e
iωt conduit à l’équation de
Helmholtz scalaire :
−∆u −
ω
2
c
2
u = −∆u − k
2u = 0, (3.2)
où k représente le nombre d’onde (rad.m−1
) et u(ω) = p(ω), ω étant la
pulsation (rad.s−1
). Il existe certaines solutions non triviales à cette équation,
mentionnées à toutes fins utiles :
– Les ondes planes, dont le vecteur d’onde k, de module k, fixe la direction
de propagation :
u(x) = u0e
−ik·x ∀x ∈ Ω, (3.3)
– Les ondes sphériques :
u(x) = u0
e
±ik|x|
|x|
∀x ∈ Ω
∗
. (3.4)
Enfin, pour que le problème fréquentiel (3.2) équivalent à la formulation
temporelle (3.1) soit bien posé, il faut rajouter des conditions aux limites
pour fixer le sens du temps et fermer le système. La condition de radiation
de Sommerfeld (3.5), introduite à partir de considérations énergétiques, joue
ce rôle en assurant l’unicité d’une solution :
r (∂ru + iku) → 0 quand r = |x| → +∞. (3.5)
Il est d’ores et déjà possible de constater que certaines solutions de l’équation
de Helmholtz (3.2) ne respectent pas cette condition, à l’instar des ondes
planes (3.3), dites non causales (ou non physiques). Pour résumer, un problème
bien posé de diffraction dans l’espace libre s’écrit dans le cas général :
−∆u − k
2u = f,
r (∂ru + iku) → 0 quand r → +∞.
92Figure 3.2 – Notations associées à la modélisation des phénomènes de propagation
d’ondes. (source [82])
Pour f ≡ δy, ce système possède une solution élémentaire E ∈ D0
(R
3
),
au sens des distributions. Dans le cas tridimensionnel, le noyau (ou fonction)
de Green G(x, y) est introduit à partir de E :
G(x, y) = E(x − y) = e
−ik|x−y|
4π|x − y|
∀(x, y) ∈ R
3
, (3.6)
et permet d’établir l’expression de la solution générale u du problème, issue
du produit de convolution ? suivant :
u(x) = (E ? f)(x) = Z
R3
G(x, y)f(y)dy =
Z
R3
e
−ik|x−y|
4π|x − y|
f(y)dy. (3.7)
Pour que cette expression ait un sens, des restrictions sur f doivent être
imposées avec, par exemple, f ∈ L
2
(R
3
).
3.1.2 Diffraction en présence d’un obstacle
Une surface fermée régulière et orientable Γ découpe désormais l’espace Ω
en un ouvert borné Ω
i
et un ouvert non borné Ω
e
(fig. 3.2). La présence d’une
telle frontière permet de définir deux distributions surfaciques, utilisées pour
établir les résultats fondamentaux de ce chapitre :
– Pour toute fonction λ régulière définie sur une surface Γ, la distribution
de simple couche de densité λ sur Γ correspond à la mesure de Radon
s(λ) = λ(x)dΓx telle que :
hs(λ), φi =
Z
Γ
λ(x)φ(x)dΓx ∀φ ∈ D(R
3
). (3.8)
93– La distribution de double couche de densité µ, notée d(µ), est quant à
elle définie par :
hd(µ), φi =
Z
Γ
µ(x)∂nφ(x)dΓx ∀φ ∈ D(R
3
). (3.9)
Ainsi, dans le cas particulier du rayonnement de sources réparties sur la
surface Γ, le potentiel de simple couche Sλ peut être établi comme la solution
u du problème de diffraction dans l’espace libre pour une distribution de
simple couche s(λ) (3.8) :
−∆u − k
2u = s(λ),
r (∂ru + iku) → 0 quand r → +∞.
D’après la formulation générale des solutions de ce problème (3.7), Sλ s’écrit
donc comme le produit de convolution :
Sλ(x) = (E ? s(λ))(x) = Z
Γ
G(x, y)λ(y)dΓy ∀x ∈ R
3
, (3.10)
et possède les propriétés suivantes :
– Continuité dans R
3
;
– C
∞ en dehors de Γ ;
– Solution de l’équation de Helmholtz homogène (3.2) en dehors de Γ ;
– Vérifie la condition de radiation à l’infini de Sommerfeld.
L’opérateur S associé est appelé "opérateur de simple couche" et sa restriction
à la frontière Γ sera notée S. Au même titre, un opérateur dit de "double
couche" D peut être appliqué à toute fonction régulière µ, définie sur Γ, pour
former le potentiel de double couche suivant :
Dµ(x) = (E ? d(µ))(x) = Z
Γ
∂nyG(x, y)µ(y)dΓy ∀x ∈ R
3
, (3.11)
où d(µ) est la distribution de double couche (3.9). Le potentiel de double
couche Dµ possède les mêmes propriétés que celui de simple couche Sλ, mais
présente une discontinuité sur R
3 par un saut de −µ à la traversée de Γ. La
restriction de l’opérateur double couche D à la frontière Γ sera notée D.
Les solutions u
tot du problème de diffraction en présence d’un obstacle
peuvent désormais être explicitées à partir de ces potentiels de rayonnement.
En posant le champ diffracté u = u
tot − u
in comme la différence entre le
champ total u
tot et le champ incident u
in
, u est solution de l’équation de
Helmholtz homogène (3.2), pour laquelle le théorème de représentation inté-
grale s’applique.
94Théorème 1 (de représentation intégrale) Soit u une fonction régulière dé-
finie de part et d’autre d’une frontière Γ régulière orientée. La restriction de
u à Ω
i
est notée u
i
et la restriction à Ω
e
est notée u
e
. Les sauts de u et de
sa dérivée normale ∂nu sont notés µ et λ :
µ = [u] = u
i − u
e
et λ = [∂nu] = ∂nu
i − ∂nu
e
sur Γ.
D’après la formule des sauts appliquée à la distribution {u}, définie par u en
dehors de Γ :
∆{u} = {∆u} − s([∂nu]) + d([u]),
si les hypothèses suivantes sont satisfaites :
−(∆u
i + k
2u
i
) = 0 dans D0
(Ωi
),
−(∆u
e + k
2u
e
) = 0 dans D0
(Ωe
),
r (∂ru
e + ikue
) → 0 quand r → +∞,
alors la fonction u vérifie :
−(∆ + k
2
)u = s(λ) − d(µ) dans D
0
(R
3
),
ainsi que la condition de radiation à l’infini. u est donc la somme d’un potentiel
de simple couche et d’un potentiel de double couche :
u = E ? s(λ) − E ? d(µ),
u = Sλ − Dµ dans D
0
(R
3
).
Plus précisément, les formulations de représentation intégrale suivantes peuvent
être explicitées :
u(x) = Sλ(x) − Dµ(x) ∀x ∈ Ω
i ∪ Ω
e
,
1
2
(u
i
(x) + u
e
(x)) = Sλ(x) − Dµ(x) ∀x ∈ Γ,
1
2
(∂nu
i
(x) + ∂nu
e
(x)) = D
∗λ(x) − Hµ(x) ∀x ∈ Γ,
où les opérateurs S, D, S et D sont tels qu’introduits dans (3.10) et (3.11).
Les opérateurs D∗
et H (hypersingulier), sont respectivement obtenus par
dérivation normale des opérateurs de simple et double couches S et D. Par
ailleurs, dans le cas de singularités géométriques présentes sur une surface Γ
lipschitzienne, les facteurs 1
2
doivent être remplacés par les rapports à 4π des
limites des angles solides intérieurs et extérieurs.
953.1.3 Équations intégrales
Le théorème de représentation intégrale 1 est la pierre angulaire des mé-
thodes intégrales. Il peut élégamment s’écrire sous la forme d’opérateurs matriciels,
appelés projecteurs de Calderón intérieur Ci et extérieur Ce.
Théorème 2 (Projecteurs de Calderón) Soient λ et µ deux fonctions régulières
quelconques définies sur Γ, alors la fonction u définie par u = Sλ−Dµ
dans D0
(R
3
) est solution de l’équation de Helmholtz dans Ω
i ∪ Ω
e
et vérifie la
condition de radiation à l’infini. De plus, les traces intérieures et extérieures
de u et de sa dérivée normale sur Γ sont données par :
u
i
∂nu
i
= (Id
2
+ C)
µ
λ
= Ci
µ
λ
,
u
e
∂nu
e
= (−
Id
2
+ C)
µ
λ
= Ce
µ
λ
,
où C est l’opérateur
−D S
−H D∗
.
De plus, les projecteurs Ce et Ci satisfont les relations suivantes :
C
2
i = Ci
, C2
e = Ce, Ci − Ce = Id,
qui peuvent se réécrire à partir des opérateurs surfaciques usuels :
DS = SD∗
, HD = D
∗H, D2 − SH = D
∗2 − HS =
Id
4
. (3.12)
Ces projecteurs confirment que les potentiels de simple et double couches
sont définis partout et vérifient l’équation de Helmholtz en dehors de Γ, ainsi
que la condition de radiation de Sommerfeld à l’infini.
Cependant, afin de calculer explicitement la solution du problème de diffraction
en présence d’un obstacle, il reste encore à déterminer les sauts µ
et λ. Pour cela, des prolongements sur les traces intérieures et extérieures
de u permettent d’établir des équations intégrales, définies sur la frontière Γ.
Pour former un système bien posé, ces équations sont alors couplées à des
conditions de bord, fixées par la modélisation physique de la structure diffractante.
Trois types de condition de bord sont utilisés en pratique :
96– La condition de Dirichlet, pour les obstacles dits mous (ou soft) :
u = uD régulière sur Γ; (3.13)
– La condition de Neumann, pour les obstacles dits rigides (ou hard) :
∂nu = grad(u) · n = uN régulière sur Γ; (3.14)
– La condition de Robin (ou Fourier), pour les obstacles d’impédance β :
∂nu − ikβu = uR régulière sur Γ. (3.15)
Selon la modélisation physique souhaitée, il existe de nombreuses équations
intégrales liées aux conditions de bord et au choix du prolongement des traces
intérieures ou extérieures. Aussi, pour ne pas surcharger le manuscrit par de
nombreuses formules, seuls les problèmes extérieurs de Dirichlet et Neumann
sont détaillés.
Dans le cas d’un problème de Dirichlet extérieur (3.13), la formulation
bien posée est la suivante :
−(∆u
e + k
2u
e
) = 0 dans Ω
e
,
u
e = uD régulière sur Γ,
r (∂ru
e + ikue
) → 0 quand r → +∞,
et selon le prolongement choisi pour la trace intérieure, cinq équations inté-
grales peuvent être formulées en saut :
Prolongement µ λ
Dirichlet 0 Sλ = uD
Neumann −(0.5Id + D)µ = uD 0
Zéro −uD Sλ = (0.5Id − D)uD
Zéro (∂n) −uD (0.5Id + D∗
)λ = −HuD
Robin, β ∈ C (ikβS − (0.5Id + D))µ = uD ikβµ
Pour les quatre premières équations, le prolongement n’est pas unique si k
2
est une valeur propre du problème de Dirichlet intérieur relatif à l’opérateur
−∆. L’opérateur associé à l’équation intégrale ne sera donc pas inversible
pour ces fréquences propres.
97Dans le cas d’un problème de Neumann extérieur (3.14), la formulation
bien posée s’écrit cette fois :
−(∆u
e + k
2u
e
) = 0 dans Ω
e
,
∂nu
e = uN régulière sur Γ,
r (∂ru
e + ikue
) → 0 quand r → +∞,
avec les équations intégrales associées :
Prolongement µ λ
Dirichlet 0 (−0.5Id + D∗
)λ = uN
Neumann −Hµ = uN 0
Zéro −Hµ = (0.5Id + D∗
)uN −uN
Zéro (trace) (0.5Id − D)µ = SuN −uN
Robin, β ∈ C −(H + ikβ(0.5Id − D∗
))µ = uN ikβµ
Au même titre que pour le problème de Dirichlet, seule la dernière équation
assure l’existence et l’unicité d’une solution pour toutes les fréquences.
Une fois ces équations établies, il ne reste plus qu’à les résoudre numé-
riquement pour obtenir les sauts µ et λ. En accord avec le théorème de
représentation intégrale, la solution générale u pourra dès lors être calculée
en tous points de l’espace, par rayonnement des potentiels de simple et
double couches Sλ et Dµ. Pour mémoire, les opérateurs intégraux mis en jeu
s’écrivent dans l’espace tridimensionnel :
Sλ(x) = Z
Γ
G(x, y)λ(y)dΓy pour x ∈ R
3
\ Γ, (3.16)
Dµ(x) = Z
Γ
∂nyG(x, y)µ(y)dΓy pour x ∈ R
3
\ Γ, (3.17)
Sλ(x) = Z
Γ
G(x, y)λ(y)dΓy pour x ∈ Γ, (3.18)
Dµ(x) = Z
Γ
∂nyG(x, y)µ(y)dΓy pour x ∈ Γ, (3.19)
D
∗λ(x) = Z
Γ
∂nxG(x, y)λ(y)dΓy pour x ∈ Γ, (3.20)
Hµ(x) = Z
Γ
∂
2
nxyG(x, y)µ(y)dΓy pour x ∈ Γ, (3.21)
où G(x, y) est le noyau de Green introduit en (3.6). De plus, en posant
x = |x|ν = rν dans R
3
, à ces relations s’ajoutent les potentiels de champ
98lointain, obtenus par développement limité du noyau de Green pour |x| |y| :
Sλ(x) = e
−ikr
4πr
S
∞λ(ν) + O(
1
r
2
)
avec S
∞λ(ν) = Z
Γ
e
ikν·yλ(y)dΓy, (3.22)
et Dµ(x) = e
−ikr
4πr
D
∞µ(ν) + O(
1
r
2
)
avec D
∞µ(ν) = ik Z
Γ
(ny · ν)e
ikν·yµ(y)dΓy. (3.23)
Les opérateurs S
∞ et D∞ sont appelés "opérateurs de rayonnement à l’infini"
et sont couramment utilisés pour représenter la radiation en champ lointain,
sans tenir compte de la décroissance 1
r
.
3.1.4 Formulations discrètes
Le problème de Dirichlet extérieur prolongé par un problème de Dirichlet
intérieur a été choisi pour établir une formulation discrète des équations inté-
grales. À partir de cet exemple, la méthodologie peut aisément être reproduite
pour obtenir les formulations d’autres problèmes. Aussi, pour toute fonction
régulière f, l’équation intégrale à résoudre s’écrit :
Sλ = f,
Sλ(x) = Z
Γ
G(x, y)λ(y)dΓy = f(x) pour x ∈ Γ.
Ce problème peut alors être formulé sous la forme variationnelle :
trouver λ ∈ V = H− 1
2 (Γ) tel que
hSλ, λt
i = hf, λt
i ∀λ
t ∈ V.
Les méthodes par éléments finis de frontière consistent, en premier lieu,
à approcher la surface Γ par un maillage élémentaire Th de taille h, composé
par exemples de triangles Ti
formant une discrétisation Γh de Γ. Ce maillage
doit vérifier les propriétés classiques sur l’intersection de deux éléments, la
qualité des éléments, etc. Dès lors, l’espace variationnel V peut être approché
par un espace :
Vh = {λh = λi sur le triangle Ti
, Ti ∈ Th},
et la formulation variationnelle devient :
trouver λh ∈ Vh tel que
hSλh, λt
h
i = hf, λt
h
i ∀λ
t
h ∈ Vh.
99Cette approximation, dite P
0
, est conforme et permet d’approcher λ par λh,
constante par morceau. De plus, Vh est de dimension N égale au nombre de
triangles de Th et sa base {φi
, i = 1, · · · , N} s’exprime relativement simplement
par :
φi(x) =
1 sur le triangle Ti
,
0 ailleurs.
Une fois ce cadre formel établi, en posant Λ
h
les coordonnées de λh ∈ Vh
dans la base {φi
, i = 1, .., N} telles que :
λh(x) = X
N
i=1
Λ
h
i φi(x),
le problème discret équivalent à la formulation variationnelle approchée consiste
en la résolution du système linéaire S
hΛ
h = F
h
. Chaque coefficient de la matrice
S
h
est défini par :
S
h
i,j =
Z
Ti
Z
Tj
G(x, y)dTj (y)dTi(x) pour (i, j) ∈ {1, · · · , N}
2
,
et le vecteur F
h a pour coordonnées :
F
h
i =
Z
Ti
f(x)dTi(x).
En supposant, d’une part, que k
2 n’est pas une valeur propre du problème de
Dirichlet intérieur pour −∆, d’autre part, que le maillage est suffisamment
fin pour que la base choisie puisse représenter correctement le problème, le
système linéaire ainsi formé admet une unique solution Λ
h
.
Dès lors, le champ approché uh de la solution du problème de diffraction
u peut être calculé dans tout l’espace, par représentation intégrale des
potentiels de simple et double couches approchés S
hλh et Dhµh. Dans le cas
d’un problème de Dirichlet extérieur prolongé par Dirichlet intérieur, µ = 0
et la représentation discrète s’écrit :
uh(x) = Z
Γh
G(x, y)λh(y)dΓh(y)
=
X
N
j=1
Λ
h
j
Z
Tj
G(x, y)dTj (y).
Heuristiquement, pour obtenir des résultats raisonnables en approximation
P
0
, il faut que la taille h des éléments soit au minimum inférieure au
dixième de la longueur d’onde (donnée empirique). Un espace variationnel
100discret P
1 permet d’estimer λh par des fonctions de bases plus précises, linéaires
par morceaux (fonctions chapeaux). Auquel cas, au prix d’une inté-
gration locale plus fine, la taille h des éléments peut être seulement inférieure
au sixième, voire au quart de la longueur d’onde. In fine, quelle que soit la dimension
de l’espace d’approximation variationnelle, l’assemblage du système
linéaire à résoudre est principalement fonction des interactions élémentaires
dans Th, estimées numériquement par intégration de Gauss. En omettant les
problèmes liés aux singularités des intégrales, ceci revient donc à calculer
l’ensemble des interactions au sein d’un nuage de points, évaluées avec une
complexité quadratique. C’est pourquoi le calcul rapide de ces interactions
est un enjeu majeur pour la compétitivité des méthodes intégrales.
3.2 Introduction aux méthodes multipolaires
rapides
La méthode des multipoles rapides (Fast Multipole Method) a été introduite
par L. Greengard et V. Rokhlin à la fin du XXe
siècle [34], pour ramener
la complexité des méthodes intégrales de quadratique (N2
) à quasi-linéaire
(N log N). Cet algorithme a littéralement bousculé les ordres de grandeurs
des problèmes jusqu’alors résolus, et, pour cela, a été classé parmi les dix
algorithmes majeurs du siècle dernier (source Wikipedia). Pour réaliser cette
compression, le principe de base consiste à calculer des produits matricesvecteurs
de manière économique, à la fois en mémoire vive et en charge de
calcul. Seule une brève introduction est présentée dans ce manuscrit, essentiellement
pour illustrer les concepts principaux mis en jeu. Pour de plus
amples détails, de nombreux ouvrages de référence expliquent les fondements
théoriques et pratiques de cette méthode (e.g. [35], [38], [82]).
En méthodes intégrales, quelle que soit la formulation variationnelle et
l’équation intégrale considérée, le produit matrice vecteur calculé dans la
résolution d’un problème de diffraction se ramène toujours à la forme :
Z
Γh
Z
Γh
G(x, y)f(x)g(y)dΓh(x)dΓh(y),
avec f et g des fonctions scalaires. Hors singularités, les quadratures utilisées
pour l’évaluation numérique des intégrales font généralement appel à des
points de Gauss xg et yg, répartis sur la surface Γh. La formulation précédente
peut donc être approchée par la discrétisation :
X
xg∈Γh
X
yg∈Γh
G(xg, yg)f(xg)g(yg), (3.24)
101Figure 3.3 – Configuration type d’une répartition spatiale pour l’application
du théorème d’addition de Gegenbauer. (source [82])
où les fonctions f et g incluent aussi les poids d’intégration des quadratures.
L’idée générale de la FMM consiste à séparer les variables spatiales xg et
yg, pour calculer indépendamment, donc rapidement, les deux sommes de la
formulation (3.24) :
X
xg∈Γh
X
yg∈Γh
G(xg, yg)g(yg)
f(xg). (3.25)
Pour cela, le noyau de Green est décomposé à l’aide du théorème suivant :
Théorème 3 (d’addition de Gegenbauer) Soient x, y, M1 et M2 quatre
points de l’espace, avec x "proche" de M1 et y "proche" de M2 (fig. 3.3). s
est un point de la sphère unité S
2 dans R
3
, Pl
le polynôme de Legendre de
rang l et hl
la fonction de Hankel sphérique du premier type de rang l. En
posant le vecteur xy = xM1 + M1M2 + M2y, le noyau de Green G(x, y)
peut se décomposer en :
G(x, y) = ik
16π
2
lim
L→+∞
Z
s∈S2
e
iks·xM1T
L
M1M2
(s)e
iks·M2y
ds, (3.26)
avec
T
L
M1M2
(s) = X
L
l=0
(2l + 1)i
lhl(k|M1M2|)Pl(cos(s,M1M2)).
Dans (3.26), les variables x et y sont bien séparées et les trois termes de
l’intégrale sphérique peuvent s’interpréter comme suit :
– e
iks·xM1 transporte l’information du point source x au centre M1 ;
– T
L
M1M2
(s) transfère l’information du centre M1 au centre M2 ;
– e
iks·M2y
envoie l’information du centre M2 au point de destination y.
102Figure 3.4 – (Gauche) Traitement des interactions sans regroupement multipolaire.
(Droite) Traitement des interactions en FMM. (source [82])
Ainsi, de par la centralisation des informations sur M1 et M2 due au théorème
d’addition de Gegenbauer (3.26), le nombre d’interactions à calculer
entre le nuage de points en x et celui en y diminue grandement entre la
méthode classique et la méthode multipolaire (fig. 3.4). Il reste néanmoins
à choisir une valeur de troncature pour L, ainsi qu’une quadrature sur la
sphère unité S
2
, en fonction de la précision souhaitée pour l’évaluation des
interactions ponctuelles entre les deux groupes de points. Cette étape, particulièrement
délicate, est grandement liée à la "proximité" des objets mis en
jeu dans la configuration type (fig. 3.3). Le domaine de calcul original Ω doit
donc être découpé en sous-domaines, où la séparation des variables est valable
lorsque les deux sous-domaines en interaction ne sont pas voisins. Si tel
est le cas, le calcul de la double somme (3.24) sera traité classiquement, sans
regroupement multipolaire. Dans l’exemple de gauche de la figure 3.5, les interactions
entre C et C
0 peuvent être calculées par séparation des variables,
centrées respectivement sur M et M0
. Ce découpage conduit à la formulation
FMM mono-niveau du produit matrice-vecteur discret (3.24), entre C et C
0
:
ik
16π
2
X
xg∈C0
Z
s∈S2
X
yg∈C
e
iks·ygMf(yg)
T
L
MM0(s)e
iks·M0xgds
g(xg).
En considérant l’ensemble des interactions entre chaque sous-domaines,
la complexité finale de l’algorithme mono-niveau est de l’ordre de N3/2
. Pour
atteindre la limite N log N, les interactions multipolaires doivent être effectuées
suivant un algorithme du type Divide and Conquer. Pour ce faire, des
sous-domaines hiérarchiques sont construits à l’aide d’un octree (fig. 3.5 à
droite), en vue de former par bloc le produit matrice vecteur associé au problème.
Les interactions très lointaines seront, dès lors, traitées différemment
des interactions lointaines, banlieues, proches, etc. Cette méthode, bien que
robuste et bien maîtrisée, est relativement complexe, notamment dans sa
programmation, et de nombreux détails soulèvent toujours de grandes diffi-
cultés. Par ailleurs, bien que la complexité théorique de l’algorithme FMM
103Figure 3.5 – (Gauche) Découpage mono-niveau du domaine original Ω et de
la frontière Γ en sous-domaines de calcul. (Droite) Découpage multi-niveaux.
(source [82])
multi-niveaux ait pour limite N log N, la constante de cette complexité peut
être assez lourde si l’algorithme n’est pas correctement réglé pour le problème
à résoudre. Ces deux raisons ont poussé les recherches effectuées lors
de cette thèse vers une solution alternative, la Décomposition Creuse en Sinus
Cardinal (SCSD).
3.3 Nouvelle méthode rapide - SCSD
La séparation des variables d’espace (3.25) conduit au calcul rapide des
produits matrices-vecteurs (3.24), issus des équations intégrales. Dans le cas
de l’acoustique tridimensionnelle, cet assemblage se résume à évaluer le produit
de convolution (Gf )(xp), défini pour toute fonction régulière f par :
(Gf )(xp) = X
Ny
q=1
G(xp, yq)f(yq) = X
Ny
q=1
e
−ik|xp−yq|
4π|xp − yq|
f(yq). (3.27)
Ce résultat n’est pas sans rappeler la forme des solutions générales d’un
problème de diffraction (3.7), construites par le produit de convolution ?.
1043.3.1 Vers un problème mono-dimensionnel
Le fondement de la Décomposition Creuse en Sinus Cardinal (SCSD)
réside dans la représentation intégrale de la fonction sinus cardinal [69] et
[82]. Pour tout z dans R
3
:
sin(k|z|)
|z|
=
k
4π
Z
S2
e
iks·z
ds, (3.28)
avec S
2
est la sphère unité de R
3
et k le nombre d’onde (positif). En posant
|z| = |x − y|, la partie imaginaire du noyau de Green (3.6) peut s’écrire en
variables séparées :
sin(k|x − y|)
4π|x − y|
=
k
(4π)
2
Z
S2
e
iks·(x−y)
ds (3.29)
=
k
(4π)
2
Z
S2
e
iks·x
e
−iks·y
ds.
Sous réserve d’une quadrature efficace pour la sphère unité S
2
, cette séparation
des variables peut se substituer au théorème d’addition de Gegenbauer
(3.26), dont dérivent la FMM. Par ailleurs, une intégration sur S
2
apparaît aussi dans (3.26), mais le couplage avec les fonctions de transfert
T
L
M1M2
(s) complexifie grandement la tâche. Dans (3.29), ces fonctions de
transfert ont disparu.
Une transformée de Fourier en espace F[.] est appliquée sur l’équation
élémentaire de Helmholtz, pour obtenir une représentation intégrale de la
partie réelle du noyau de Green (3.6) :
F
h
(−∆ − k
2
)G(x, y)
i
= F[δy].
En posant y = 0 dans l’égalité précédente, celle-ci devient :
(|ξ|
2 − k
2
) F[G(x, 0)] = 1,
ce qui permet d’écrire la transformée de Fourier du cosinus cardinal :
F
"
cos(k|x|)
|x|
#
=
4π
|ξ|
2 − k
2
.
Une représentation intégrale de la partie réelle du noyau de Green est alors
obtenue par transformée de Fourier inverse sur l’équation précédente :
cos(k|x − y|)
4π|x − y|
=
1
(2π)
3
Z
R3
1
|ξ|
2 − k
2
e
iξ·(x−y)
dξ,
105amenant de nouveau la séparation des variables d’espace :
cos(k|x − y|)
4π|x − y|
=
1
(2π)
3
Z
R3
1
|ξ|
2 − k
2
e
iξ·x
e
−iξ·y
dξ. (3.30)
La singularité du cosinus cardinal présente en 0 lui confère une forte irré-
gularité. Celle-ci est traduite en domaine de Fourier par une représentation
intégrale sur tout l’espace R
3
, alors que la partie sinus s’intègre sur uniquement
sur S
2
(eq. 3.29). À cela s’ajoute une singularité en |ξ| = k, ce qui peut
sembler rédhibitoire.
Néanmoins, après réécriture de l’équation (3.30) en coordonnées sphé-
riques, la représentation intégrale du sinus cardinal (3.28) permet d’établir
l’égalité suivante :
cos(k|x − y|)
4π|x − y|
=
1
(2π)
3
Z +∞
ρ=0
ρ
2
ρ
2 − k
2
Z
S2
e
iρs·(x−y)
ds
dρ,
=
2
π
Z +∞
ρ=0
ρ
ρ
2 − k
2
sin(ρ|x − y|)
4π|x − y|
dρ. (3.31)
Si l’intégrale sur ρ converge bien dans (3.31), alors une séparation des variables
de la partie réelle pourrait découler de celle obtenue pour la partie
imaginaire (3.29). De plus, pour éviter de retomber sur les difficultés de
programmation de la FMM, il est nécessaire qu’une même quadrature, la
plus précise possible, puisse être utilisée pour R dans un grand intervalle
[Rmin, Rmax]. Pour étudier ce problème, l’intégrale (3.31) est réécrite sous la
forme :
cos(R) = 2
π
Z +∞
ρ=0
ρ
ρ
2 − 1
sin(ρR)dρ, (3.32)
avec R = k|x − y|.
3.3.2 Résolution du problème
Le problème d’intégration mono-dimensionnel à résoudre est le suivant :
Existe-il une quadrature vérifiant l’égalité (3.32) pour tout R dans
un intervalle [Rmin, Rmax] le plus grand possible, avec peu de points
d’intégration ρ dans un intervalle [0, A] petit ?
En première approche, des méthodes classiques de quadrature du type
Trapèze, Simpson, ou encore Fourier ont été appliquées sur une formulation
106Figure 3.6 – Calcul du cosinus par intégration de Simpson, pour R dans
[0, 15]. 71 points d’intégrations en ρ, espacés régulièrement sur [0, 7], ont été
utilisés pour approcher l’intégrale (3.33). L’erreur relative est inférieure au
seuil de 5% pour R > 3.
tronquée en A et régularisée avec une solution analytique :
cos(R) ≈
2
π
Z A
ρ=0
ρ
ρ
2 − 1
(sin(ρR) − sin(R))dρ!
+
2 sin(R)
π
Z A
ρ=0
ρ
ρ
2 − 1
dρ. (3.33)
Dans cette approximation, le membre de gauche est bien régulier pour ρ autour
de 1 et le membre de droite s’intègre exactement au sens des valeurs
principales. Les résultats présentés sur la figure 3.6 sont peu satisfaisants et
dépendent beaucoup de l’intervalle dans lequel évolue R. Pour R petit, A est
grand avec des points d’intégration relativement espacés, tandis que pour R
grand, A est petit mais il faut de nombreuses valeurs pour discrétiser l’intervalle
[0, A]. Ces résultats sont, bien entendu, liés à la singularité du cosinus,
quand R tend vers 0. Une quadrature classique pour l’évaluation de cos(R)
sur un intervalle [Rmin, Rmax] grand n’est donc pas raisonnable.
Une quadrature entièrement numérique pour la résolution de ce problème
a donc été envisagée. Pour ce faire, l’équation (3.32) est réécrite sous la
formulation discrète suivante, tronquée en N ∈ N :
cos(R) ≈
X
N
n=0
αn sin(ρnR). (3.34)
Le problème d’intégration approchée à résoudre devient :
107Figure 3.7 – Calcul du cosinus par quadrature numérique issue d’une minimisation
sous contrainte (3.35), pour R dans [0, 15]. 5 points d’intégrations
en ρ, espacés régulièrement sur [0, 1.2], ont été trouvés pour évaluer l’approximation
(3.34). L’erreur relative est inférieure au seuil de 5% pour R > 3.
Pour N le plus petit possible, existe-il un vecteur (ρn)n∈[0,N] de petites
valeurs, associées à un vecteur (αn)n∈[0,N], tels que la relation
(3.34) soit vérifiée pour tout R dans un intervalle [Rmin, Rmax] le plus
grand possible ?
Comme il n’est pas évident de résoudre analytiquement cette question, une
minimisation sous contrainte a d’abord été programmée pour tenter d’obtenir
des éléments de réponses. Une discrétisation (Ri)i∈[0,M] de R dans
[Rmin, Rmax] est utilisée pour former un système matriciel, dont chaque ligne
i est définie par :
(cos(Ri))i∈[0,M] =
X
N
n=0
αn sin(ρnRi)
!
i∈[0,M]
. (3.35)
Dans ce système linéaire, (αn)n∈[0,N] est le vecteur inconnu, recherché au sens
des moindres carrés. Les contraintes sont fixées sur le calcul de (ρn)n∈[0,N]
,
discrétisé par pas régulier sur [0, A], avec A exigé le plus petit possible. De
plus, à chaque itération de la minimisation, le rang du système linéaire est
estimé avec une précision donnée. Si ce rang n’est pas plein, l’ordre de
troncature N est diminué pour assurer un nombre de termes minimal dans la
quadrature. Ce procédé permet de tenir compte du défaut de rang constaté
dans les opérateurs intégraux issus du noyau de Green (3.6) et exploité dans
d’autres méthodes de compression comme H-matrix [43], GGQ [18], Skeletonization,
ACA, etc. Cet algorithme a été développé en langage Matlab
108et la structure "optimset" a été utilisée pour établir la minimisation sous
contraintes du système matriciel. La figure 3.7 donne un résultat issu de
cette approche empirique, avec une configuration identique à l’intégration
de Simpson précédente (fig. 3.6). Après convergence, 5 points en ρ ont été
trouvés, compris entre 0 et 1.2. Ces valeurs apportent cette fois une solution
tangible au problème mono- dimensionnel et le calcul d’un produit matricevecteur
rapide peut être envisagé, pour toutes les interactions entre x et y
telles que Rmin < k|x − y| < Rmax.
Cependant, malgré une certaine robustesse éprouvée à l’usage, l’algorithme
de minimisation sous contrainte ne permet pas de comprendre les
mécanismes mis en jeu, ce qui a poussé les recherches vers une quadrature
analytique. Celle-ci peut être introduite à partir de la quadrature de l’unité
suivante :
1 ≈
X
N
n=0
βn sin(ρnR). (3.36)
En effet, il existe une formule exacte similaire à l’approximation (3.36), définie
pour tout t dans (0, π) :
X∞
n=0
4
π(2n + 1) sin((2n + 1)t) = 1.
Cette série, couramment utilisée en traitement du signal pour définir la fonction
créneau, est issue de la décomposition en série de Fourier de la fonction
2π-périodique égale à −1 sur (−π, 0) et 1 sur (0, π). En posant le changement
de variable t =
R
b
π pour tout R dans (0, b), l’égalité précédente devient :
X∞
n=0
4
π(2n + 1) sin
π
b
(2n + 1)R
= 1.
La convergence de cette série est assez lente et dépend fortement des valeurs
de R. Aussi, une troncature avec N petit conduit à de fortes oscillations aux
extrémités de l’intervalle de R, dues à la discontinuité en zéro de la fonction
créneau (phénomène de Gibbs). Cet artefact est classiquement lissé par l’introduction
d’un facteur correctif de Lanczos, encore appelé σ-approximation
(e.g. [1], [44]), qui consiste à pondérer la série précédente par une puissance
de sinus cardinal :
N
X−1
n=0
4
π(2n + 1)
sinc
2n + 1
2N
π
q
sin
π
b
(2n + 1)R
≈ 1,
avec q entier (typiquement q = 1 ou 2). En fixant dans (3.36) :
βn =
4
π(2n + 1)
sinc
2n + 1
2N
π
q
et ρn =
π
b
(2n + 1), (3.37)
109Figure 3.8 – Calcul du cosinus par quadrature analytique issue des coeffi-
cients exacts (3.37) de la quadrature de l’unité (3.36), avec q = 1 pour R
dans [0, 15]. 6 points d’intégration en ρ, espacés régulièrement sur [0, 1.4],
sont nécessaires pour une erreur relative inférieure à 5%.
une quadrature analytique de l’unité avec une bonne convergence est ainsi
établie.
Une quadrature analytique du cosinus (3.34) peut être déduite en multipliant
(3.36) par cos(R), puis en appliquant la formule trigonométrique
sin(A) cos(B) = 0.5(sin(A + B) + sin(A − B)) :
cos(R) ≈
X
N
n=0
0.5βn (sin((1 + ρn)R) − sin((1 − ρn)R)), (3.38)
où les ρn sont donnés par (3.37). Enfin, lorsque b = 2πL avec L ∈ N
∗
, la
variante (3.38) se décompose sous la forme :
cos(R) ≈
X
N
n=0
0.5βn (sin((1 + ρn)R))
−
L
X−1
n=0
0.5βn (sin((1 − ρn)R))
+
X
N
n=L−1
0.5βn (sin((ρn − 1)R)),
où tous les facteurs devant R appartiennent à la même discrétisation de
ρ dans l’intervalle [ρ0; 1 + ρN ]. Ainsi, après réagencement et unification des
termes de cette nouvelle série, la quadrature analytique du cosinus (3.34) peut
être obtenue à partir de celle de l’unité (3.36). En pratique, pour tout R dans
[Rmin, Rmax] ⊂ [Rmin, b], il suffit de rechercher N tel que l’erreur relative
de cette quadrature soit inférieure à une précision fixée. Par ailleurs, pour
110limiter l’impact du phénomène de Gibbs et minimiser N, il est avantageux
de symétriser l’erreur commise en posant b ≥ (Rmax+Rmin), multiple de 2π.
La figure 3.8 offre une comparaison de la quadrature analytique avec les deux
quadratures précédentes (fig. 3.6 et 3.7). Même si ce résultat est du même
ordre de grandeur que celui de la figure 3.7, les valeurs de ρn et N sont
légèrement supérieures à celles obtenues par l’algorithme de minimisation
sous contraintes. Cette remarque est d’autant plus vraie pour b plus grand,
non représenté ici.
Aussi, une quadrature hybride a été développée à partir des deux quadratures
précédentes. Comme les valeurs analytiques de ρn sont connues pour
tout n ≤ N (eq. 3.37), celles-ci peuvent directement être utilisées dans la
quadrature du cosinus (3.34) pour former le système matriciel (3.35), utilisé
par l’algorithme de minimisation sous contrainte. Après résolution, les valeurs
calculées de αn lissent au sens des moindres carrés l’erreur relative , pour
tout R sur l’intervalle de quadrature [Rmin, Rmax]. En itérant ce processus sur
N pour atteindre une précision donnée, cette approche permet d’estimer αn
pour que l’erreur commise soit plus uniforme. Par ailleurs, suivant le même
principe, il est possible d’estimer βn par une quadrature hybride de l’unité
et d’obtenir une nouvelle quadrature du cosinus en utilisant la formule de
passage (3.38). Trois méthodes peuvent donc être confrontées (fig. 3.9) :
1. Quadrature analytique du cosinus, d’après une quadrature analytique
de l’unité lissée par σ-approximation avec q = 2 ("Analytique", courbe
bleue) ;
2. Quadrature analytique du cosinus, d’après une quadrature hybride de
l’unité lissée au sens des moindres carrés ("Hybride Un", ronds verts) ;
3. Quadrature numérique du cosinus lissée au sens des moindres carrés.
("Hybride Cos", croix rouges).
cos(R) Rmin Rmax N ρN erreur L
2
erreur L
∞
1. Analytique 3 15 14 4.5 2.26e
−4 7.83e
−4
2. Hybride Un 3 15 14 4.5 1.83e
−6 5.27e
−6
3. Hybride Cos 3 15 14 4.5 7.91e
−8 1.91e
−7
Pour R dans [Rmin, Rmax] et ρ dans [ρ0, ρN ] avec N fixé, il apparaît très nettement
sur ces valeurs numériques et sur la figure 3.9 que l’évaluation de αn par
ces trois méthodes fournit des erreurs relatives et uniformes singulièrement
différentes. En effet, plus d’un facteur 1000 sépare la quadrature analytique
de la quadrature hybride en cosinus. Aussi, en fixant un seuil d’erreur relative
∞ à 10−3
(norme L
∞) pour R ∈ [Rmin, Rmax], puis en minimisant le
111Figure 3.9 – Quadratures de l’unité et du cosinus pour R dans [3, 15], avec
respectivement 11 et 14 points d’intégrations fixés, inclus dans [0, 3.5] et
[0, 4.5]. L’erreur relative (∞ en norme L
∞) en fonction de R est donnée en
échelle logarithmique pour une meilleure lisibilité.
112Figure 3.10 – Quadratures de l’unité et du cosinus pour R dans [3, 15], avec
un seuil d’erreur relative ∞ fixée à 1e−3. Le nombre de points d’intégration
N varie en fonction de la quadrature.
113nombre N de points d’intégrations nécessaires pour atteindre cette précision,
les résultats suivants sont obtenus (fig. 3.10) :
cos(R) Rmin Rmax N ρN erreur L
2
erreur L
∞
1. Analytique 3 15 14 4.5 2.26e
−4 7.83e
−4
2. Hybride Un 3 15 10 3.17 1.95e
−4 5.62e
−4
3. Hybride Cos 3 15 8 2.5 1.40e
−4 3.47e
−4
Pour une précision fixée, les valeurs de N et ρN sont fortement liées à la quadrature
considérée, ce qui est particulièrement intéressant dans le contexte
de cette étude. Par exemple, la quadrature hybride en cosinus semble tout à
fait adaptée pour répondre au problème mono-dimensionnel posé dans cette
section.
Au vu de ces résultats, l’intervalle [Rmin, Rmax] et la précision relative en
norme L
∞ ont donc été modifiés, pour éprouver la robustesse des quadratures
(fig. 3.11) :
Cosinus Rmin Rmax N ρN erreur L
2
erreur L
∞
1. Analytique 3 150 115 4.58 7.05e
−5 9.65e
−4
2. Hybride Un 3 150 80 3.18 1.11e
−4 9.41e
−4
3. Hybride Cos 3 150 61 2.42 1.13e
−4 9.98e
−4
1. Analytique 3 1000 734 4.58 2.81e
−5 9.97e
−4
2. Hybride Un 3 1000 510 3.18 4.68e
−5 9.97e
−4
3. Hybride Cos 3 1000 392 2.45 5.02e
−5 9.95e
−4
1. Analytique 0.5 150 436 4.58 5.92e
−5 8.85e
−4
2. Hybride Un 0.5 150 281 3.18 6.06e
−5 6.89e
−4
3. Hybride Cos 0.5 150 259 2.45 9.09e
−5 9.93e
−4
1. Analytique 3 150 - - - -
2. Hybride Un 3 150 213 8.5 1.16e
−13 7.96e
−13
3. Hybride Cos 3 150 189 4.4 1.62e
−13 9.21e
−13
Pour les quadratures hybrides de l’unité et du cosinus, la linéarité apparente
114Figure 3.11 – Représentation du nombre N de termes nécessaires à chaque
quadrature. (Haut) Rmin dans [1, 3] et Rmax = 150, pour une précision relative
fixée à 10−3
. (Milieu) Rmin = 3 et Rmax dans [10, 1000], pour une
précision relative fixée à 10−3
. (Bas) [Rmin, Rmax] = [3, 150], pour une précision
relative dans [10−13
, 10−2
].
115de l’ensemble des courbes de la figure 3.11 permet de conjecturer la relation :
N ∝
Rmax + Rmin
Rmin
| log()|. (3.39)
Une dépendance logarithmique en erreur relative est donc empiriquement
établie, ainsi qu’une dépendance linéaire pour l’intervalle de R. Ce résultat
est fondamental pour les applications visées. Il ne reste plus qu’à savoir si
la linéarité de la conjecture (3.39) sur N va permettre d’atteindre une complexité
finale raisonnable pour le calcul rapide du noyau de Green.
Pour terminer, non seulement il apparaît que l’efficacité d’une quadrature
ne dépende que de αn, mais aussi N diminue lorsque le rapport entre l’erreur
L
2
et l’erreur L
∞ tend vers 1. Les trois méthodes proposées ne seraient donc
peut-être pas les seules et de nouveaux algorithmes pourraient être recherchés
en vue de diminuer N, ce qui aurait un impact très fort sur l’efficacité globale
de la méthode SCSD.
3.3.3 Formalisme final pour l’équation de Helmholtz
Pour une précision donnée, la section précédente a mis numériquement
en lumière qu’il existe deux suites (αn)n∈[0,N] et (ρn)n∈[0,N] telles que, pour
tout R dans [Rmin, Rmax] :
cos(R) ≈
X
N
n=0
αnsin(ρnR) avec N ∝
Rmax + Rmin
Rmin
| log()|.
Le retour vers le problème tri-dimensionnel original s’effectue simplement à
travers la définition de R, à savoir R = k|x − y| pour tous points x et y de
l’espace R
3
. En divisant la relation précédente par 4π|x − y|, la partie réelle
du noyau de Green (3.6) peut être approchée par la quadrature suivante :
cos(k|x − y|)
4π|x − y|
≈
X
N
n=0
αn
sin(ρnk|x − y|)
4π|x − y|
,
équivalent discret de (3.31). En ajoutant à cette relation la partie imaginaire
du noyau de Green, la quadrature complète du noyau peut être établie, sous
la forme d’une somme pondérée de sinus cardinaux :
G(x, y) ≈
N
X
+1
n=0
αn
sin(ρnk|x − y|)
4π|x − y|
,
où αN+1 = −i et ρN+1 = 1. En appliquant la représentation intégrale du
sinus cardinal (3.28) sur ce résultat fondamental, la séparation des variables
116de la SCSD peut être formulée comme une somme pondérée d’intégrales
surfaciques sur N + 2 sphères unités :
G(x, y) ≈
k
(4π)
2
N
X
+1
n=0
αnρn
Z
S2
e
ikρns·x
e
−ikρns·y
ds, (3.40)
ou encore sur des sphères emboîtées de rayon kρn :
G(x, y) ≈
1
(4π)
2
N
X
+1
n=0
αn
Z
kρnS2
e
is·x
e
−is·y
ds.
Pour obtenir une version totalement discrète de la séparation des variables
du noyau de Green (3.40), il reste à choisir une dernière quadrature pour
l’intégration sphérique. De nombreux travaux traitent de ce sujet récurrent
et certaines solutions sont couramment utilisées dans divers domaines des
mathématiques appliquées [46]. Pour la SCSD, les quadratures de GaussLegendre
ont été préférées aux grilles de Fibonacci [41], ou encore aux sphères
de Lebedev [60].
Quadrature de Gauss-Legendre sur la sphère unité S
2
:
Pour un entier Na donné, les angles azimutaux (θi)i∈[1,2Na] sont choisis dans
{0,
π
Na
, ..., 2π −
π
Na
}, tandis que les angles d’élévations (φj )j∈[1,Na] sont tels
que cos(φj ) appartient aux zéros du Nième
a polynôme de Legendre PNa
. Une
grille sphérique (si,j )i×j∈[1,Ns] de dimension Ns = 2N2
a peut alors être générée
en (θ, φ), associée aux poids d’intégrations ωs.
Cette quadrature intègre exactement toutes les harmoniques sphériques Y
m
l
(1.2) de degré inférieur ou égal à 2Na − 1, mais discrétise la sphère par pas
régulier en azimut, ce qui créé une concentration de points élevée aux pôles.
En pratique, la quadrature de Gauss-Legendre dans l’approximation (3.40)
est telle que Na doit être au moins proportionnel à la plus grande distance
évaluée sous l’intégrale, c’est-à-dire :
Na ∝ kρn max(|x − y|) ⇒ Ns ∝ (ρnRmax)
2
. (3.41)
L’approximation (3.40) conduit alors à :
G(x, y) ≈
k
(4π)
2
N
X
+1
n=0
αnρn
X
Ns
s
ωse
ikρns·x
e
−ikρns·y
.
Puis, pour tout l dans [1, Nξ] tel que Nξ =
PN+1
n=0 Ns, en posant :
ξl = kρns dans R
3
et ωl =
kαnρnωs
(4π)
2
dans R, (3.42)
117Figure 3.12 – Représentation du nombre total de points Nξ d’une quadrature
SCSD, pour le noyau de Helmholtz (3.43). (Haut) Rmin dans [2, 3] et
Rmax = 150, pour une précision relative fixée à 10−3
. (Milieu) Rmin = 3
et Rmax dans [10, 250], pour une précision relative fixée à 10−3
. (Bas)
[Rmin, Rmax] = [3, 50] pour une précision relative dans [10−12
, 10−2
].
118la version discrète de la séparation des variables SCSD peut être établie :
G(x, y) ≈
X
Nξ
l=1
ωle
iξl
·x
e
−iξl
·y
. (3.43)
De plus, d’après les relations (3.37) et (3.41) :
Ns ∝
Rmax
Rmin + Rmax
(2n + 1)2
.
Dès lors, à partir de la conjecture (3.39) sur N, Nξ peut être estimé par une
majoration de la somme des carrés impairs pour Rmax Rmin :
Nξ =
N
X
+1
n=0
Ns ∝
Rmax
Rmin
| log()|
3
. (3.44)
La figure 3.12 vient confirmer ce résultat, par l’apparente linéarité des fonctions
représentées. La séparation des variables de la SCSD est donc logarithmique
en erreur et le nombre de points total est simplement fonction du
rapport des extremums Rmax sur Rmin, élevé au cube.
Pour terminer, la quadrature en ξ (3.43) est directement injectée dans le
produit de convolution initial (3.27) :
Gf (xp) ≈
X
Ny
q=1
f(yq)
X
Nξ
l=1
ωle
iξl
·xp e
−iξl
·yq
,
pour aboutir au calcul rapide par SCSD :
Gf (xp) ≈
X
Nξ
l=1
e
iξl
·xp
X
Ny
q=1
e
−iξl
·yq f(yq)
ωl
. (3.45)
Ce résultat, fondateur de la méthode de Décomposition Creuse en Sinus Cardinal,
est le pendant discret du théorème d’addition de Gegenbauer (3.26),
qui conduit à la séparation des variables en FMM. En comparaison, cette
formulation est bien moins complexe et le calcul des sommes du type :
Xn
q=0
e
±iap·bq h(bq) avec (ap, bq) ∈ R
3
,
peut être réalisé par transformée de Fourier 3D rapide, non uniforme en espace/fréquence.
Cet algorithme, plus connu sous le nom de Type-III Non
Uniform Fast Fourier Transform (NUFFT), est notamment utilisé en traitement
d’image et propose une complexité quasi-linéaire N log N (e.g. [24],
[36], [61]). Un calcul de produit matrice-vecteur en SCSD (3.45) se résume
donc à :
1191. Passer du domaine spatial (en y) vers le domaine de Fourier (en ξ), par
NUFFT directe de type-III ;
2. Multiplier le résultat obtenu par les poids ωl
, liés aux quadratures de
la SCSD ;
3. Retourner dans l’espace (en x) par NUFFT inverse de type-III.
In fine, comme le produit matrice-vecteur (3.27) est issu d’une convolution
spatiale entre le noyau de Green G(x, y) et la fonction régulière f(y) (eq. 3.7),
la SCSD reflète simplement l’idée qu’une telle convolution se traduit en
domaine de Fourier par un produit. Toute l’originalité de la méthode ré-
side finalement dans l’efficacité et la robustesse de la quadrature monodimensionnelle
(3.34).
3.3.4 Extension vers Laplace (et plus si affinités...)
Avant de poursuivre vers des résultats applicatifs, une légère digression
mérite d’être faite pour les problèmes de Laplace, qui interviennent dans
de nombreux domaines de la physique (Électrostatique, Magnétostatique,
Gravitation, etc.). Introduite par l’équation :
−∆u = f, avec f régulière sur R
3
,
la solution générale d’un problème de Laplace est formée par interactions
Coulombiennes :
u(x) = ELap ? f(x) = Z
R3
f(y)
4π|x − y|
dy,
dont la version discrète s’écrit :
u(xp) = X
Ny
q=1
1
4π|xp − yq|
f(yq). (3.46)
Sensiblement proche des interactions helmholtziennes (3.27), seules les oscillations
liées à l’exponentielle complexe n’apparaissent plus dans ce nouveau
noyau de Green.
Or, le problème mono-dimensionnel a été résolu à la fois pour la quadrature
du cosinus (3.34) et pour celle de l’unité (3.36). En effet, les résultats
précédents montrent bien que l’unité peut être approchée comme une somme
pondérée de sinus, pour une précision donnée sur un intervalle [Rmin, Rmax].
Par conséquent, suivant le même raisonnement, les grandes étapes de la Dé-
composition Creuse en Sinus Cardinal du noyau de Laplace sont données
120Figure 3.13 – Représentation du nombre total de points N0
ξ d’une quadrature
CSD, pour le noyau de Laplace (3.48). (Haut) Rmin dans [2, 3] et
Rmax = 150, pour une précision relative fixée à 10−3
. (Milieu) Rmin = 3
et Rmax dans [10, 250], pour une précision relative fixée à 10−3
. (Bas)
[Rmin, Rmax] = [3, 50] pour une précision relative dans [10−12
, 10−2
].
121par :
1
4π|xp − yq|
≈
X
N
n=0
βn
sin(ρn|xp − yq|)
4π|xp − yq|
,
≈
1
(4π)
2
X
N
n=0
βnρn
Z
S2
e
iρns·xp e
−iρns·yq ds,
≈
1
(4π)
2
Nξ
X0
l=1
ω
0
l
e
iξ0
l
·xp e
−iξ0
l
·yq
,
avec ξ
0
l
et ω
0
l
similaires à ξl et ωl dans (3.42) :
ξ
0
l = ρns dans R
3
et ω
0
l =
βnρnωs
(4π)
2
dans R. (3.47)
Ce résultat offre donc une séparation des variables identique à l’équation
(3.45) :
u(xp) ≈
N0 X
ξ
l=1
e
iξ0
l
·xp
X
Ny
q=1
e
−iξ0
l
·yq f(yq)
ω
0
l
, (3.48)
où chaque somme peut être calculée rapidement par NUFFT de type III.
L’étude détaillée des quadratures du noyau de Laplace n’est pas présentée
ici, mais la figure 3.13 montre bien que la loi sur Nξ, établie pour Helmholtz
(eq. 3.44), semble toujours vérifiée pour Laplace. De plus, l’article [5] disponible
en annexe propose une revue théorique de la SCSD pour Laplace,
étendue ensuite sur Helmholtz. Cet article fait donc office de référence en la
matière et n’est donc pas repris dans ce manuscrit.
Il est donc fondamental de remarquer qu’une même méthode générique
peut-être appliquée à deux noyaux distincts, en vue de calculer rapidement
des interactions ponctuelles, oscillantes ou non. Cette constatation s’étend
aux noyaux de Stokes ou Maxwell, respectivement dérivés des noyaux de Laplace
et d’Helmholtz, ou plus largement encore à tous noyaux de Green exprimés
en domaine de Fourier. Par conséquent, la SCSD est intrinsèquement
multi-physique, contrairement à la FMM, qui nécessite des développements
propres à chaque noyau. À elle seule, cette remarque peut justifier l’intérêt
des recherches effectuées sur cette nouvelle méthode.
1223.4 Comparaisons et performances
Comme les produits de convolution par les noyaux de Green pour Helmholtz
(3.27) et Laplace (3.46) sont tous deux définis par :
Gp =
X
N
q=1
G(xp, xq)fq ∀p ∈ [1, N], (3.49)
un nuage de N points x est défini dans R
3
, associé à un vecteur (fq)q∈[1,N]
de valeurs aléatoires complexes. Une routine Matlab a été programmée pour
comparer l’évaluation du produit Gp (3.49) par différentes méthodes, dont
la SCSD. Ce code n’est pas un solveur d’équations intégrales, mais un outil
de validation analytique. La machine utilisée pour l’ensemble des tests de
cette section est un PC portable disposant de 8 GO de mémoire vive et d’un
processeur à 8 cœurs cadencés à 1.6 GHz.
3.4.1 Méthodologie
En premier lieu, le nuage de N points x dans R
3
est créé suivant trois
répartitions :
– Aléatoire dans une boule ;
– Aléatoire dans un cube ;
– Uniforme sur une sphère.
Chacune de ces répartitions est centrée en zéro, de sorte à maximiser par
symétrie l’efficacité de la méthode SCSD. Pour assurer un régime fréquentiel
adapté aux méthodes approchées, une normalisation sur la position des points
x est effectuée : la plus grande distance au sein du nuage est imposée telle
que Rmax =
√3 N et le nombre d’onde k, intervenant dans le noyau de Green
de Helmholtz (3.6), est fixé à 1.
Une fois le domaine de calcul établi, la SCSD a été programmée en neuf
grandes étapes, tirées des formulations du produit de convolution (3.49) pour
Helmholtz (3.45) et Laplace (3.48) :
1. Quadrature hybride de l’unité ou du cosinus pour les interactions lointaines
dans [Rmin, Rmax] ;
2. Quadrature des sphères d’intégrations et construction du domaine de
Fourier en (ξl)l∈[1,Nξ] associé aux poids (ωl)l∈[1,Nξ]
;
3. NUFFT type-III directe de l’espace (xq)q∈[1,N] vers les fréquences (ξl)l∈[1,Nξ]
,
appliquée sur (fq)q∈[1,N]
;
4. Pondération du résultat précédent par les poids de quadrature (ωl)l∈[1,Nξ]
;
1235. NUFFT type-III inverse des fréquences (ξl)l∈[1,Nξ] vers l’espace (xp)p∈[1,N]
,
appliquée sur le résultat pondéré ;
6. Recherche des interactions proches, définies par |xp − xq| ≤ Rmin ;
7. Calcul du noyau de Green pour les interactions proches ;
8. Calcul de la partie réelle de la quadrature SCSD pour les interactions
proches, inexacte, mais régulière sur [0, Rmin] ;
9. Addition des résultats issus des interactions proches et lointaines, puis
soustraction des évaluations inexactes SCSD.
Cet algorithme permet une implémentation vectorielle relativement simple.
Aussi, toutes les routines ont été écrites nativement en Matlab, à l’exception
de la NUFFT qui dispose de nombreuses versions .mex en accès libre sur
internet (e.g. [93], [94], [95], [96], etc.). Après quelques tests comparatifs, celle
proposée par L. Greengard [95] a été choisie, notamment pour sa rapidité, sa
précision et sa simplicité d’utilisation.
Pour valider les résultats issus de la SCSD, deux autres méthodes ont
servi de référence au calcul du produit de convolution (3.49) :
– La méthode directe, notée DM (exacte, complexité quadratique) ;
– La méthode multipolaire rapide FMM (approchée, complexité quasilinéaire).
Les deux routines utilisées sont issues d’une autre librairie Fortran écrite par
L. Greengard, toujours interfacée Matlab, mais dédiée cette fois au calcul
intégral [88]. Étant donné que L. Greengard est un pionnier de la FMM, les
comparaisons avec cette librairie ont semblé toutes naturelles. Pour s’assurer
du bon réglage de ces outils, la précision machine a été vérifiée sur des petits
cas (N < 10000), en comparant les méthodes directe et rapide proposées par
L. Greengard, avec un produit de convolution écrit nativement en Matlab.
Afin d’être le plus objectif possible, le multi-threading a été désactivé pour
les exécutions Matlab (options ’-singleCompThread’ au démarrage) et pour
les bibliothèques externes (re-compilées sans OpenMP). Seul le parallélisme
du calcul direct de la méthode exacte en Fortran a été conservé, afin de
minimiser l’impact de la complexité quadratique sur les temps de calcul.
3.4.2 Résultats
La figure 3.14 compare les temps de calcul de la convolution avec le noyau
de Laplace, en fonction du nombre N de points dans l’espace. La précision
des méthodes relatives est fixée à 10−3
et Rmin est fixé à 1. Tout d’abord, il
apparaît que la méthode directe présente bien des temps de calcul supérieurs,
ce qui est attendu. Ensuite, les temps d’assemblage FMM et SCSD sont
124Figure 3.14 – Temps totaux comparatifs pour la convolution (3.49) du noyau
de Laplace, en fonction du nombre N de points x en interactions dans R
3
.
La précision relative des méthodes approchées est fixée à 10−3
et Rmin = 1
pour la SCSD. 125comparables sur une boule, alors que la FMM est légèrement plus rapide
pour le cube et bien plus rapide pour la sphère. Ceci peut s’expliquer par les
fondements même de chaque méthode :
– La SCSD est optimale pour les répartitions volumiques dans une boule.
En effet, sa complexité est fonction de la quadrature en domaine de
Fourier, dont le nombre de points Nξ est, dans ce cas, très proche de N
(eq. 3.44 avec Rmin = 1 et Rmax =
√3 N) ;
– La FMM est plus adaptée aux répartitions volumiques dans un cube,
de par le découpage de l’espace en octree. De plus, quelle que soit la
répartition spatiale, sa complexité reste N log N. C’est pourquoi le cas
sphérique n’est pas plus difficile en FMM.
Par ailleurs, toutes les erreurs relatives finales obtenues entre méthode directe,
FMM et SCSD sont de l’ordre de grandeur de la précision souhaitée
(dans ce cas ≈ 10−3
). Enfin, autant la pente de la méthode directe montre
bien une complexité plus grande que les méthodes approchées, autant la
SCSD et la FMM présentent la même linéarité, malgré quelques accrocs numériques
inexpliqués. Ceci laisse penser que la complexité empirique de la
SCSD pourrait être du même ordre que celle de la FMM, de mille à un million
de points en interactions (soit mille milliards d’interactions calculées).
De plus, en pré-calculant les interactions proches lors de calculs itératifs, le
produit matrice-vecteur résultant (SCSD - MV, fig. 3.14) est quant à lui tout
à fait compétitif avec la FMM.
La figure 3.15 présente les mêmes courbes que la figure 3.14, mais pour une
convolution avec le noyau oscillant de Helmholtz. La précision des méthodes
relatives est toujours fixée à 10−3
, et Rmin à 1. Quelle que soit la répartition
spatiale de x dans R
3
, il apparaît cette fois que la méthode SCSD est la plus
rapide. De plus, les pentes des courbes des méthodes approchées montrent
toujours une complexité empirique équivalente. Enfin, le pré-calcul des parties
proches lors de résolutions itératives offre un produit matrice-vecteur
particulièrement rapide.
Pour terminer, la figure 3.16 donne les temps de calculs pour les convolutions
de Laplace et Helmholtz sur une sphère, avec une précision fixée à 10−6
.
Pour réaliser des calculs SCSD en accord avec la loi (3.44), Rmin a été augmenté
et fixé arbitrairement à 3. Il apparaît de nouveau une grande similitude
pour les divers temps de résolution, malgré une précision relative mille fois
supérieure. Par conséquent, la SCSD montre en outre une certaine robustesse
à la précision, comparable à celle de la FMM.
En conclusion, la SCSD semble tout à fait comparable à la FMM, tant en
terme de complexité que de précision. La plupart des résultats présentés a
d’ailleurs été démontrée dans un article rédigé en parallèle de ce manuscrit,
ce qui a permis de valider et maîtriser pleinement cette approche [5]. De plus,
126Figure 3.15 – Temps totaux comparatifs pour la convolution (3.49) du noyau
de Helmholtz, en fonction du nombre N de points x en interactions dans R
3
.
La précision relative des méthodes approchées est fixée à 10−3
et Rmin = 1
pour la SCSD.
127Figure 3.16 – Temps totaux comparatifs pour la convolution (3.49) des
noyaux de Laplace (Haut) et Helmholtz (Bas), en fonction du nombre N de
points x en interactions dans R
3
. La précision relative des méthodes approchées
est fixée à 10−6
et Rmin = 3 pour la SCSD.
128de nombreuses optimisations mathématiques et algorithmiques sont encore
envisageables (et envisagées) pour chacune des étapes de cette méthode (pré-
calculs, parallélismes, amélioration des quadratures, etc.), ouvrant un large
pan de recherche pour de futurs travaux. Par ailleurs, comme le même code
Matlab a été utilisé pour calculer les produits de convolution (3.49) pour Laplace
(3.48) et Helmholtz (3.45), ces optimisations impacteront directement
toutes les physiques compatibles (gravitation, acoustique, électromagnétisme,
mécanique des fluides, etc). C’est pourquoi cette méthode a d’ores et déjà
été implémentée avec succès dans un moteur de calcul d’équations intégrales
pour l’acoustique, présenté dans le dernier chapitre de ce manuscrit.
129130Chapitre 4
Moteur intégral MyBEM
Une fois la SCSD validée pour le calcul des interactions au sein d’un nuage
de points, elle fut aussitôt implémentée dans une nouvelle routine Matlab, qui
assemble par collocation les opérateurs sphériques de simple couche (3.18) et
de double couche (3.19). En estimant les interactions lointaines par le produit
matrice-vecteur (3.45), des solutions tirées d’une résolution itérative sont obtenues,
pour des problèmes de diffraction de 1 000 à 50 000 inconnues. Ces
résultats furent alors confrontés aux solutions analytiques du rayonnement
sphérique, avec succès. Ce principe montra de bonnes performances, mais il
n’était pas possible d’aller plus loin sans une approximation de Galerkin bien
établie. Il fut donc décidé d’implémenter la SCSD dans un vrai moteur de
calcul intégral en éléments finis P
1
(MyBEM), dont le prototype est présenté
dans ce dernier chapitre. Ce moteur a été développé en collaboration avec
François Alouges à partir d’une librairie Matlab dont il est l’auteur, initialement
conçue pour l’enseignement des éléments finis 2D. Ce co-développement
a permis d’en étendre rapidement et très significativement la portée.
4.1 Présentation
MyBEM est une librairie de calcul intégral par éléments finis de frontières,
appliquée à l’acoustique tri-dimensionnelle et nativement écrite en
langage Matlab. De nombreux services connexes y ont été associés, comme
la gestion de maillage, le pré/post-traitement de données et la visualisation
de résultats. De prime abord, le choix d’une implémentation Matlab peut
surprendre au regard des performances exigibles en calcul numérique, mais
cette plateforme fut initialement adoptée pour assurer un prototypage rapide
et efficace. Au final, il aura fallu moins d’une année pour aboutir à la version
présentée dans ce manuscrit. Par ailleurs, une vectorisation drastique de
131Figure 4.1 – MyUI, interface graphique de MyBEM, prototype Matlab pour le calcul intégral en acoustique tridimensionelle.
132l’ensemble des opérations a été effectuée, ceci afin d’assurer des performances
comparables à celles obtenues par des langages de plus bas niveau. Enfin, la
Parallel Computing Toolbox proposée par Mathwork a définitivement scellé
ce choix, puisque les calculs les plus gourmands ont pu bénéficier d’un multithreading
efficace, au prix d’un effort de développement réellement modique
(remplacer les boucles "for" par "parfor"). En pratique, les temps de calcul
sont en moyenne divisés par cinq sur une machine comptant huit cœurs.
MyBEM est programmé dans une logique objet et les fonctions membres
comme les attributs sont accessibles par appels directs, ou par interface graphique
dédiée à l’utilisateur (MyUI, fig. 4.1). L’ensemble des données et des
traitements est inclu dans six objets distincts, relatifs aux différentes étapes
intervenant dans la résolution d’une formulation intégrale :
1. Mesh : Contient l’ensemble des données sur maillages, ainsi que les
routines de lecture de fichiers .vtk, .ply, .mat, .mesh, etc. Toutes les
données utiles (arêtes, normales, tangentes, surfaces, etc.) sont calculées
par MyBEM, à partir des nœuds et des éléments.
2. Mef : Contient l’ensemble des données relatives à l’espace d’éléments
finis des méthodes de Galerkin (degrés de liberté, fonctions de bases,
formules d’intégrations, matrices d’intégrations de Gauss, etc.). Ces
données sont automatiquement générées à partir des maillages et ne
nécessitent, a priori, aucune intervention de la part de l’utilisateur.
Dans sa version actuelle, MyBEM se limite aux formulations P
1
, avec
les inconnues aux nœuds de mailles triangulaires. Des travaux sont en
cours pour ajouter d’autres éléments finis.
3. Opr : Contient l’ensemble des données relatives aux opérateurs inté-
graux usuels (eq. 3.16 à 3.23), ainsi que les différentes méthodes pour les
assembler. En effet, MyBEM propose non seulement une construction
matricielle classique par évaluation exacte des noyaux de Green, mais
aussi des assemblages FMM et SCSD de produits matrices-vecteurs approchés
(3.27). Dans tous les cas, les opérateurs sont construits à partir
des interactions entre les points de Gauss des éléments finis, puis intégrés
pour former le système final aux degrés de liberté. Par ailleurs,
pour limiter les erreurs dues aux singularités, les intégrations proches
sont régularisées analytiquement [77].
4. Sol : Contient l’ensemble des données relatives à la modélisation mathé-
matique du problème de diffraction, ainsi qu’à sa résolution. Les fonctions
membres permettent à l’utilisateur de définir les sources [ondes
planes (3.3) ou ondes sphériques (3.4)], les conditions de bord [Dirichlet
(3.13) ou Neumann (3.14)] et le prolongement de la trace. Le
système linéaire correspondant est ensuite établi, puis résolu de ma-
133nière directe ou itérative selon la méthode d’assemblage choisie pour
former les opérateurs. De plus, pour accélérer les résolutions itératives,
des préconditionneurs issus des identités de Calderón (3.12) sont couplés
à la décomposition LU des interactions proches (e.g. [54], [79]). Les
solutions alors obtenues sont rendues en saut, pour conserver le cadre
généraliste des formulations indirectes.
5. Rad : Contient l’ensemble des services de post-traitement des résultats,
notamment de rayonnement dans l’espace. Par exemple, des solutions
peuvent être calculées sur le maillage surfacique initial, mais aussi sur
un maillage volumique quelconque fourni par l’utilisateur, ainsi que
dans toutes les directions d’un rayonnement infinitésimal.
6. Draw : Contient l’ensemble des outils de visualisation graphique, en
domaine fréquentiel et temporel.
Parmi l’ensemble des traitements proposés par MyBEM, trois librairies externes
interfacées avec Matlab ont été utilisées :
– FMM : Librairie Fortran de L. Greengard [88], pour le calcul de produits
matrices-vecteurs approchés. La routine d’interaction ponctuelle
hfmm3dpart de L. Greengard est couplée aux matrices d’intégrations de
Galerkin calculées par MyBEM pour obtenir une formulation éléments
finis P
1
. Cette librairie est utilisable pour les maillages conséquents,
lorsque l’assemblage matriciel des opérateurs n’est plus envisageable.
Elle est nativement parallèle.
– NUFFT : Librairie Fortran de L. Greengard [95], pour le calcul de
transformées de Fourier non uniformes, de une à trois dimensions. La
routine nufft3d3 intervient dans la SCSD. Bien que déjà très performante,
elle est néanmoins non parallèle, ce qui impacte les temps
de calcul lors des résolutions itératives. De plus, de nombreux pré-
calculs pourrait être réalisés, toujours en vue de minimiser les temps
de chaque itération. C’est pourquoi le développement d’une nouvelle
librairie NUFFT est actuellement envisagé.
– OpenTSTOOL : Librairie C++ de C. Merkwirth [98], pour le calcul
rapide de distances au sein d’un nuage de points. La routine range_
search est utilisée par la SCSD pour rechercher et calculer les interactions
ponctuelles dont la distance est inférieure au rayon Rmin. Cette
librairie n’est pas parallèle, mais son usage est très localisé donc peu
impactant. Par ailleurs, la fonction rangeSearch est aussi proposée par
MathWorks dans la Statistics Toolbox, mais celle-ci n’était pas à disposition
lors de la création de MyBEM.
134Avant de clore cette brève présentation, il n’est pas inutile de préciser que
l’interface graphique MyUI (fig. 4.1) interagit par callback avec chacune de
ces structures. C’est pourquoi, les différentes étapes de résolution liées à ces
objets ont été identifiées par couleurs : en bleu la gestion de maillage, en
jaune la création des opérateurs, en rouge la résolution du problème et en
vert le post-traitement. Seuls les éléments finis ne sont pas visibles, puisque
leur paramétrisation n’est pas nécessaire et requiert une certaine expertise.
4.2 Validations
Un protocole de validation analytique de la librairie MyBEM a été mis
en place dès l’obtention des premiers résultats numériques. Celui-ci permet
d’assurer le bien-fondé des solutions obtenues, ainsi qu’une assurance de nonrégression
lors des fréquentes mises à jour. Lors de ces tests, les divers temps
de calcul sont aussi comparés, ce qui permet l’élaboration d’algorithmes toujours
plus rapides, avec une précision maîtrisée. Par ailleurs, des résultats
similaires sont discutés dans [22] et peuvent être confrontés à ceux présentés
ici. Enfin, tous les résultats de cette section ont été calculés sur une machine
disposant de 8 cœurs cadencés à 3.3 Ghz, de 128 Go de mémoire vive et de
la version R2013a de Matlab.
Lorsqu’une onde plane (3.3) est diffractée par une sphère, des solutions
explicites peuvent être calculées analytiquement à l’aide d’une décomposition
en harmoniques sphériques [23]. En effet, pour des conditions de Dirichlet au
bord de la sphère (3.13), le système :
−(∆u + k
2u) = 0 dans Ω
e
,
u = uD = −e
−ik·x
sur S
2
,
r (∂ru + iku) → 0 quand r → +∞,
possède des solutions analytiques, données en coordonnées sphériques par :
uref (r, θ, φ) = X∞
n=0
i
n
(2n + 1)κnh
(2)
n
(kr)Pn(cos(γ)). (4.1)
γ représente l’angle d’incidence avec la direction k de l’onde plane et la
constante κn est définie par :
κn = −
jn(k)
h
(2)
n (k)
, (4.2)
135Figure 4.2 – Champ total issu de la diffraction d’une onde plane par
une sphère unité, à la fréquence f = 300 Hz. Représentation en décibel
(20 log |u|). (Haut) Solutions analytiques. (Bas) Solutions numériques calculées
par MyBEM, pour une sphère à 1000 inconnues. (Gauche) Problème de
Dirichlet. (Droite) Problème de Neumann.
136avec jn la fonction de Bessel sphérique et h
(2)
n
la fonction de Hankel sphérique
de seconde espèce. Cette solution décrit exactement l’évolution du champ
diffracté pour tout r ≥ 1 et la série converge suffisamment rapidement pour
être estimée avec une bonne précision. Par ailleurs, pour un problème de
Neumann, le système :
−(∆u + k
2u) = 0 dans Ω
e
,
∂nu = uN = −∂ne
−ik·x
sur S
2
,
r (∂ru + iku) → 0 quand r → +∞,
a pour solution (4.1), avec une nouvelle constante κn :
κn = −
j
0
n
(k)
h
(2)0
n (k)
. (4.3)
À titre d’exemple, des solutions analytiques de problèmes de diffraction sphé-
riques de Dirichlet et Neumann ont été représentées en haut de la figure 4.2
(respectivement à gauche et à droite). Des solutions numériques issues de
MyBEM, sur un maillage de sphère à 1000 inconnues, sont quant à elles visibles
en bas de cette même figure. Toutes ces représentations sont données
en décibel (20 log |u|).
Même si les résultats concordent à première vue, la décroissance du rayonnement
en 1
r
complique l’utilisation d’une mesure objective de l’erreur commise
dans l’espace. C’est pourquoi la solution en champ lointain, indépendante
de la distance r, a été préférentiellement choisie :
u
∞
ref (θ, φ) = i
k
X∞
n=0
(−1)n
(2n + 1)κnPn(cos(γ)). (4.4)
Comme cette solution est symétrique par rapport à l’incidence k, l’évaluation
pour γ dans [0, 2π] est suffisante, voire préférable pour la lisibilité des résultats.
Par ailleurs, l’équivalent numérique de (4.4), noté u
∞, est donné par
le rayonnement des potentiels de champ lointain (3.22) et (3.23). Ce rayonnement
a donc été ajouté dans les fonctionnalités proposées par MyBEM,
avec une évaluation rapide par NUFFT type-III. L’analyse des résultats est
réalisée à la fois par superposition graphique des deux solutions et par l’intermédiaire
des normes quadratiques et infinies du rapport signal sur bruit
137(Signal/ Noise Ratio), définies par :
SNR2 =
vuuut
1
Nγ
X
γi∈[1,Nγ]
20 log 10
u∞(γi)
u∞
ref (γi)
!2
, (4.5)
SNR∞ = max
γi∈[1,Nγ]
20 log 10
u
∞(γi)
u∞
ref (γi)
!
. (4.6)
Les résultats de validation présentés dans les différents tableaux de la
figure 4.3 ont été obtenus en utilisant les formulations Brackage-Warner des
problèmes de Dirichlet et Neumann préconditionnés. Ce choix découle essentiellement
de la forme bien posée issue du prolongement de Robin, qui
assure l’existence et l’unicité de la solution quelque soit la fréquence. Les
différentes méthodes d’assemblage proposées dans MyBEM sont comparées
(BEM, FMM et SCSD), en précision (SNR2 et SNR∞), mais aussi en
temps d’assemblage des parties proches (tpsP ) et temps de résolution (tpsR).
Le nombre d’itérations des résolutions approchées est précisé (Niter), ce qui
donne une estimation du temps passé dans un produit matrice-vecteur. Pour
tous les problèmes étudiés, les sphères unités sont maillées à l’aide de grilles
uniformes de Fibonacci, de 103 à 106 points. Étant donné que MyBEM est
programmé en formulation variationnelle approchée par éléments finis de
frontière P
1
, les N inconnues correspondent exactement aux sommets du
maillage. Par ailleurs, comme 3 points de Gauss ont été utilisés par élé-
ments, le calcul des interactions ponctuelles pour l’assemblage des différents
opérateurs a donc lieu entre les 6N points de gauss. De plus, pour qu’une
longueur d’onde soit représentée au minimum par 6 inconnues, la fréquence
f a été ajustée pour chaque grille, en fonction de la taille de la plus grande
arête amax (kamax ≈ 1). Enfin, la précision des méthodes approchées a été
fixée à 10−3
, au même titre que celle du solveur GMRES [76] utilisé pour
les résolutions itératives de la FMM et de la SCSD. En complément de ces
données, les figure 4.4 et 4.5 offrent une représentation graphique des rayonnements
analytiques u
∞
ref , superposés aux solutions numériques u
∞ obtenues
par SCSD.
Il apparaît d’une part que les rapports signal sur bruit (SNR) sont
stables, et montrent une grande précision pour tous les résultats. En effet,
l’écart entre les solutions numériques et analytiques sont de l’ordre de
10−2 dB en norme quadratique et 10−1 dB en norme infinie. Ces performances
se retrouvent dans les représentations graphiques des figures 4.4 et
4.5, puisque les solutions numériques et analytiques sont trait sur trait, en
échelle logarithmique (dB). Les temps de calcul totaux, somme des temps
d’assemblage des parties proches tpsP et des temps de résolution tpsR, sont
138DIRICHLET BEM FMM SCSD
N f (Hz) krmax SNR2 SNR∞ SNR2 SNR∞ SNR2 SNR∞
103 300 5 0.017 0.032 0.033 0.067 0.016 0.032
104 1000 19 0.002 0.008 0.017 0.060 0.009 0.024
105 3200 118 - - 0.011 0.039 0.019 0.073
106 10000 368 - - 0.021 0.120 0.014 0.090
NEUMANN BEM FMM SCSD
N f (Hz) krmax SNR2 SNR∞ SNR2 SNR∞ SNR2 SNR∞
103 300 5 0.050 0.161 0.052 0.159 0.047 0.158
104 1000 19 0.021 0.134 0.026 0.201 0.019 0.179
105 3200 118 - - 0.015 0.093 0.017 0.110
106 10000 368 - - 0.025 0.214 0.013 0.061
DIRICHLET BEM FMM SCSD
N f (Hz) krmax tpsP tpsR tpsP tpsR Niter tpsP tpsR Niter
103 300 5 1.78 0.13 0.74 1.02 5 0.96 0.71 5
104 1000 19 140 22.4 3.21 12.5 7 4.49 3.58 7
105 3200 118 - - 23.4 174 9 56.7 39.1 9
106 10000 368 - - 235 2460 12 782 618 12
NEUMANN BEM FMM SCSD
N f (Hz) krmax tpsP tpsR tpsP tpsR Niter tpsP tpsR Niter
103 300 5 1.78 0.13 0.74 2.83 5 0.96 0.84 5
104 1000 19 140 24.2 3.21 34.8 6 4.49 4.59 6
105 3200 118 - - 23.4 479 7 56.7 47.0 7
106 10000 368 - - 235 6324 9 782 740 9
Figure 4.3 – Tableaux comparatifs de la précision et des temps de calculs de
MyBEM pour un problème de diffraction sphérique de 103 à 106
inconnues.
Tous les temps sont donnés en secondes et les SNR sont données en décibel
(20 log |u|).
139Figure 4.4 – Représentations en décibel des diagrammes de rayonnement
en champs lointains des solutions analytiques (u
∞
ref ) et numériques, obtenues
par MyBEM en SCSD (u
∞
SCSD). (Gauche) Problèmes de Dirichlet. (Droite)
Problèmes de Neumann.
140Figure 4.5 – Représentations en décibel des diagrammes de rayonnement en
champs lointains des solutions analytiques (u
∞
ref ) et numériques, obtenues par
MyBEM en SCSD (u
∞
SCSD). (Haut) Problèmes de Dirichlet. (Bas) Problèmes
de Neumann.
141favorables à la méthode SCSD. En effet, bien qu’assez performante dans
son assemblage, la BEM ne peut pas résoudre des problèmes d’une taille
supérieure à 25 000 inconnues, puisque le stockage mémoire des opérateurs
explose de façon quadratique. D’autre part, la FMM est globalement moins
rapide que la SCSD, à précision équivalente. Néanmoins, ces résultats sont
à nuancer par les nombreuses différences intrinsèques aux deux algorithmes
(niveau de langage, parallélisme de la FMM mais pas des NUFFT, accessibilité
aux différentes étapes de construction, etc.), qui rendent hasardeuse
toute conclusion objective. De nouvelles études sont donc à prévoir, ainsi que
divers benchmark, mais il apparaît déjà que MyBEM, l’interface FMM de L.
Greengard et la nouvelle méthode rapide SCSD semblent prometteurs pour
réaliser du calcul intégral haute performance sous Matlab.
4.3 Applications au calcul de HRTF
La validité des calculs de la librairie intégrale MyBEM étant désormais
établie, des exemples d’applications plus concrètes sont présentés dans cette
dernière section. Pour ne pas s’écarter du but initial, des simulations sur des
maillages de têtes et d’oreilles ont été effectués. Néanmoins, par manque de
temps, la construction d’une HRTF complète n’a pas encore été réalisée et
fera l’objet de travaux futurs, en vue d’une confrontation finale aux mesures
réelles.
Dans un premier temps, des maillages de calcul ont été générés en trois
étapes (fig. 4.6). Tout d’abord, un maillage initial d’une tête artificielle Neumann
KU100 [91] a été réalisé par balayage optique, à l’aide de la Kinect [90]
et du kit de développement Microsoft. Ce maillage n’étant pas utilisable en
l’état (trous, intersections d’éléments, abérations géométriques, etc.), l’oreille
gauche en a été extraite. Ensuite, un maillage paramétrique de "tête" a été
créé sous Matlab, à partir d’une grille sphérique de Fibonacci, déformée en
ovoïde. Pour finir, les deux maillages ont été fusionnés sous Matlab, puis corrigés
et rééchantillonnés à l’aide d’outils comme MeshLab [92], Remesh [97],
VTK [99], etc. Trois maillages de tête ont ainsi été générés, comptant respectivement
4 000, 15 000 et 50 000 sommets, pour des fréquences optimales
de 5 000, 10 000 et 20 000 Hz. En complément, l’oreille tirée du maillage
initial a été fermée par un demi-ovoïde, pour disposer d’un maillage d’étude
de petite taille, fonctionnel sur toute la bande de fréquence audible. Ce dernier
maillage ne comte que 6 000 sommets, ce qui autorise l’assemblage BEM
exact avec résolution directe.
À partir de ces maillages, une première application de MyBEM a consisté
à calculer des modes de résonance du pavillon auditif, notamment pour tes-
142Figure 4.6 – Balayage de la tête artificielle Neumann KU100 par mesures
optiques Kinect, et création de maillages de calcul. (Haut) Système de mesure
de la tête Neumann et tête de Timothée. (Bas, gauche) Maillage obtenu avec
le kit de développement Microsoft. (Bas, droite) Maillage final par fusion de
l’oreille gauche sur un ovoïde.
143Figure 4.7 – (Gauche) Excitation par onde plane de l’oreille fermée.
(Droite) Modes de résonances du pavillon obtenus par BEM. (Haut) 5 000
Hz. (Milieu) 10 000 Hz. (Bas) 20 000 Hz.
144Figure 4.8 – (Gauche) Modes de résonances du pavillon obtenus par FMM.
(Droite) Modes obtenus par SCSD. (Haut) 5 000 Hz. (Milieu) 10 000 Hz.
(Bas) 20 000 Hz.
145Figure 4.9 – Modes de résonance du pavillon avec diffraction par une tête
ovoïdale. (Gauche) Assemblage BEM et FMM en bas. (Droite) Assemblage
SCSD uniquement. (Haut) 5 000 Hz. (Milieu) 10 000 Hz. (Bas) 20 000 Hz.
146ter les trois méthodes d’assemblage (BEM, FMM et SCSD) sur un cas
concret difficile. Pour chaque fréquence (5 000, 10 000 et 20 000 Hz), le problème
de Neumann homogène a été résolu, modélisant mathématiquement la
rigidité de la peau [50]. Les formulations en Brackage-Werner ont été choisies
pour assurer l’existence et l’unicité de la solution, préconditionnées par
identités de Calderón et décomposition LU, et toutes les précisions ont été
fixée à 10−3
. Les solutions sont représentées sur les figures 4.7, 4.8 et 4.9, en
décibel (20 log |u|), avec les temps suivants :
OREILLE BEM FMM SCSD
f (Hz) tpsP tpsR tpsP tpsR Niter tpsP tpsR Niter
5 000 58.0 7.10 2.34 41.6 14 5.75 5.80 14
10 000 56.5 7.26 2.42 44.7 15 5.95 5.55 15
20 000 57.2 7.07 2.36 52.4 17 5.73 6.17 17
TÊTE BEM FMM SCSD
f (Hz) tpsP tpsR tpsP tpsR Niter tpsP tpsR Niter
5 000 19.6 2.45 1.84 17.5 8 5.00 2.49 8
10 000 454 77.8 5.28 101 12 15.4 10.9 12
20 000 - - 14.8 434 18 46.8 50.2 18
D’une part, pour un cas non trivial (résonances dans plusieurs cavités de
tailles diverses), la concordance entre toutes ces figures montre bien que l’ensemble
des méthodes d’assemblage implémentées dans MyBEM donnent des
résultats tout à fait comparables. En considérant la BEM comme la référence
(assemblage et résolution exacte), les méthodes approchées semblent donc relativement
robustes. D’autre part, la SCSD montre des temps totaux plus
rapides que les deux autres méthodes, pour un nombre d’itérations identique
aux FMM.
Pour terminer, un embryon de calcul HRTF a été pratiqué sur un maillage
de tête réelle (fig. 4.10). Fourni par P. Frey [89], ce maillage présente 15 000
sommets et autorise les calculs jusqu’à 5 000 Hz. La méthode consiste à placer
une source ponctuelle au creux du pavillon auditif (étoile cyan, fig. 4.10),
puis résoudre le problème de Neumann homogène associé avant de faire rayonner
les solutions obtenues sur la sphère unité (e.g. [49], [50], [39]). D’après
le principe de réciprocité, les déformations spectrales causées par la morphologie
sont alors bien prises en compte [87]. Pour valider la démarche, ce
147Figure 4.10 – Maillage de tête à 15 000 sommets, réalisé par P. Frey.
(Gauche) Vue de face. (Droite) Vue de profil, avec une étoile bleue au creux de
l’oreille droite, correspondant à la source ponctuelle pour le calcul de HRTF
par réciprocité.
problème a aussi été résolu sur un maillage sphérique de rayon a = 8.74
cm [58], avec une source ponctuelle placée à la surface en lieu et place de
l’oreille droite. Comme il existe une solution analytique (eq. 1.5, [25]), les
résultats numériques peuvent s’y référer. Pour ces derniers calculs, la formulation
Brackage-Werner préconditionnée a de nouveau été utilisée et la
précision fixée à 10−3
. Les figures 4.11 et 4.12 représentent en décibel les solutions
obtenues par BEM, FMM et SCSD, à 1 mètre de distance et 5 000 Hz.
Les temps de calcul sont résumés dans le tableau suivant :
SPHÈRE TÊTE
Méthode tpsP tpsR Niter tpsP tpsR Niter
BEM 29.9 4.38 - 805 70.1 -
FMM 1.28 18.4 6 8.24 85.6 11
SCSD 2.18 2.52 6 22.1 9.85 11
Tout d’abord, il apparaît que les rayonnements de la méthode exacte et
des méthodes approchées sont bien concordants dans le cas sphérique, et ces
résultats semblent coïncider avec le modèle de Duda (fig. 1.18). Néanmoins,
il existe quelques écarts entre les méthodes approchées et la méthode exacte,
visibles sur la tête réelle pour les gains relativement faibles (variations des
échelles de couleurs). Ceci peut s’expliquer par la finesse de ce problème, à
148Figure 4.11 – HRTF sphérique du modèle de Duda de rayon 8.74 cm, calculée
par MyBEM à 5 000 Hz, représentation en décibel sur la sphère unité.
(Haut) Assemblage BEM. (Bas, gauche) Assemblage FMM. (Bas, droite)
Assemblage SCSD.
149Figure 4.12 – HRTF du maillage de P. Frey calculée par MyBEM à 5 000 Hz,
représentation en décibel sur la sphère unité. (Haut) Assemblage BEM. (Bas,
gauche) Assemblage FMM. (Bas, droite) Assemblage SCSD.
150savoir le rayonnement en champ proche d’une source ponctuelle dans une
cavité, où des différences minimes peuvent générer des perturbations consé-
quentes. Mais vu l’ordre de grandeur relatif de ces écarts, il est possible qu’ils
soient inaudibles.
Aussi, ces calculs montrent que MyBEM est prêt pour la génération numérique
de HRTF par méthodes intégrales, que ce soit en BEM, FMM ou
SCSD. Pour générer une HRTF complète, il ne reste désormais plus qu’à
boucler sur les fréquences, en raffinant éventuellement le maillage de calcul.
151DÉFI IDIOT MAIS RÉUSSI : " Salut tout le monde ! Je suis désormais
en pleine phase de rédaction du manuscrit de thèse, c’est donc le moment de
m’envoyer votre liste de mots à caser (en français). Le principe de ce jeu est
le suivant, pour chaque mot soumis présent dans le manuscrit final, vous me
payez une bière de votre choix. Si le mot est jugé de façon impartiale mal
adapté au contexte, c’est moi qui régale... A vos plumes !"
– ADRIEN : platokaolinophile.
– ALAIN : zygomatique, xérodermie et yttrialite.
– ANTOINE : lama.
– BENJAMIN : courgette, pornographique.
– CAROLINE A. : érythème, eczéma, petit-jama, cromalin.
– CAROLINE F. : Tchoupi.
– CLAIRE A. : coelioscopie.
– CLAIRE Ette : formication et kyphonisme
– EMILIE : on ne vit pas dans le monde de oui-oui ! !
– FRANCOIS : procrastination, turlututu, François Fromont.
– FREDERIQUE : prurit.
– GUILLAUME : canal de Nidus, rage quit, GG.
– JULIE : priapisme.
– SOPHIE : ratatouille, sapristouille.
– STEPHANE : phugoïde.
– STEVEN : swag, "c’est aussi rébarbatif que de placer une béchamel
dans un micro-ondes soviétique pour la rendre déliquescente".
– THIBAULT : 1=0 ;
– TIMOTHÉE : censuré.
– VICTOR : immixtion, cristallisation, Canaan, prophète, Hypokhâgne,
Zoé, Django Reinhart, pronosthud.
– VINCENT : soviétique, rébarbatif, déliquescent, micro-ondes, béchamel.
– XAVIER : pachydermique.
ATTENTION : L’auteur de ce manuscrit n’est en rien responsable du
contenu de cette page et décline toute responsabilité quand au vocabulaire
employé ici.
152Conclusion
Pour conclure, l’ensemble des travaux présenté dans ce manuscrit offre des
perspectives réellement prometteuses. D’une part, la Décomposition par Modèle
Morphologique propose une nouvelle voie pour étudier les HRTF. Au lieu
de construire des filtres basés sur des considérations arbitraires, des mesures
réelles sont déconvoluées par des fonctions de transferts issues de modèles
morphologiques paramétriques, obtenus analytiquement ou par simulation.
Le résidu de cette décomposition peut alors être analysé, pour valider la
bonne correspondance au modèle considéré. Cette démarche a prouvé son
efficacité et de nombreuses applications industrielles en ont découlé (interpolation
haute qualité, micro-variations de sources, déraffinement spatial de
bases de données, individualisation des HRTF, etc.). D’autre part, la Décomposition
Creuse en Sinus Cardinal permet la convolution rapide par un noyau
de Green. Initiée par une démarche essentiellement expérimentale, une nouvelle
théorie a vu le jour et les premiers tests de performances ont démontré
l’efficacité de cette approche.
Des développements logiciels ont toujours accompagné les problèmes rencontrés,
pour mieux cerner les idées visibles, comme les subtilités cachées.
Cette méthode de travail a engendré la création de prototypes innovants et
fonctionnels, directement exploitables par le milieu industriel. Deux librairies
indépendantes regroupent l’essentiel de ces codes. D’une part, PifPaf3D
propose de nombreuses technologies pour la spatialisation sonore en temps
réel, comme la synthèse binaurale, la captation-restitution en High Order
Ambisonics, ou encore la réverbération de salles en trois dimensions. De multiples
logiciels créés par la société Digital Media Solutions, à l’initiative de
cette thèse CIFRE, en sont issus. D’autre part, MyBEM résout les équations
intégrales de l’acoustique par éléments finis de frontières, incluant diverses
méthodes d’assemblage et de résolution (BEM, FMM et SCSD). Ce code est
aujourd’hui capable de traiter des problèmes de l’ordre du million d’inconnues
relativement rapidement, avec une très bonne précision.
Ainsi, tous les outils dédiés à l’individualisation numérique de la spatialisation
sonore sont réalisés et fonctionnels. Il ne reste désormais plus qu’à
153générer des HRTF par équations intégrales pour "écouter" des mathématiques
appliquées par synthèse binaurale. En effet, le formalisme de la Décomposition
par Modèle Morphologique est particulièrement adapté au couplage
entre les mesures réelles et les résultats de simulation numérique.
Par ailleurs, d’autres applications, qui dépassent largement le cadre de
cette thèse, sont aussi envisageables pour l’acoustique, comme la simulation
numérique architecturale ou la détection sonar. Enfin, d’un point de vue mathématique,
nous sommes persuadés que la SCSD a un potentiel qu’il faudra
exploiter dans les années à venir. Par exemple, il est fortement envisagé de
l’utiliser pour résoudre des problèmes de très grandes tailles par équations
intégrales, dans des domaines aussi variés que l’acoustique, la gravitation,
l’élasticité linéaire, l’électromagnétisme, la mécanique des fluides, etc.
154Bibliographie
[1] Acton, F. S. (1990). Numerical methods that usually work. Washington,
DC : Mathematical Association of America.
[2] Allen, J. B., & Berkley, D. A. (1979). Image method for efficiently simulating
small-room acoustics. The Journal of the Acoustical Society of
America, 65(4), 943-950.
[3] Algazi, V. R., Duda, R. O., Thompson, D. M., & Avendano, C. (2001).
The cipic hrtf database. In Applications of Signal Processing to Audio
and Acoustics, 2001 IEEE Workshop on the (pp. 99-102).
[4] Algazi, V. R., Duda, R. O., Duraiswami, R., Gumerov, N. A., & Tang,
Z. (2002). Approximating the head-related transfer function using simple
geometric models of the head and torso. The Journal of the Acoustical
Society of America, 112(5), 2053-2064.
[5] Alouges, F., Aussal, M. (2014) The Sparse Cardinal Sine Decomposotion
and its application for fast numerical convolution.
[6] HRTF database from Acoustic Research Institute, www.kfs.oeaw.ac.at
[7] Armelloni, E., Giottoli, C., & Farina, A. (2003, October). Implementation
of real-time partitioned convolution on a DSP board. In Applications of
Signal Processing to Audio and Acoustics, 2003 IEEE Workshop on. (pp.
71-74).
[8] Aussal, M., Alouges, F., & Katz, B. F. (2012, March). ITD interpolation
and personalization for binaural synthesis using spherical harmonics. In
Audio engineering society UK conference. New York, UK (p. 04).
[9] Aussal, M., Alouges, F., & Katz, B. (2013, June). A study of spherical
harmonics interpolation for HRTF exchange. In Proceedings of Meetings
on Acoustics (Vol. 19, No. 1, p. 050010). Acoustical Society of America.
[10] Begault, D. R. (1994). 3-D sound for virtual reality and multimedia (Vol.
955). Boston etc : AP professional.
[11] Bertet, S., Daniel, J., & Moreau, S. (2006, May). 3d sound field recording
with higher order ambisonics-objective measurements and validation
155of spherical microphone. In Audio Engineering Society Convention 120.
Audio Engineering Society.
[12] Begault, D. R., Wenzel, E. M., & Anderson, M. R. (2001). Direct comparison
of the impact of head tracking, reverberation, and individualized
head-related transfer functions on the spatial perception of a virtual speech
source. Journal of the Audio Engineering Society, 49(10), 904-916.
[13] Bensoam, J. (2003). Représentation intégrale appliquée à la synthèse sonore
par modélisation physique (Doctoral dissertation, PhD thesis, Université
du Maine).
[14] Blauert, J. (1994). La technologie binaurale : bases scientifiques et domaines
d’application génériques. Le Journal de Physique IV, 4 (C5-11).
[15] Blauert, J. (1997). Spatial hearing.
[16] Bonnet, M. (1999). Boundary integral equation methods for solids and
fluids. Meccanica, 34(4), 301-302.
[17] Cheng, C. I., & Wakefield, G. H. (1999, September). Introduction to
head-related transfer functions (HRTFs) : Representations of HRTFs in
time, frequency, and space. In Audio Engineering Society Convention 107.
Audio Engineering Society.
[18] Chaillat, S., & Bonnet, M. (2014). A new Fast Multipole formulation for
the elastodynamic half-space Green’s tensor. Journal of Computational
Physics, 258, 787-808.
[19] Craven, P. G., & Gerzon, M. A. (1977). U.S. Patent No. 4,042,779.
Washington, DC : U.S. Patent and Trademark Office.
[20] Daniel, J. (2000). Représentation de champs acoustiques, application à
la transmission et à la reproduction de scènes sonores complexes dans un
contexte multimédia (Doctoral dissertation, Ph. D. Thesis, University of
Paris VI, France).
[21] Daniel, J., Moreau, S., & Nicol, R. (2003, March). Further investigations
of high-order ambisonics and wavefield synthesis for holophonic sound
imaging. In Audio Engineering Society Convention 114. Audio Engineering
Society.
[22] Darbas, M., Darrigrand, E., & Lafranche, Y. (2013). Combining analytic
preconditioner and fast multipole method for the 3-D Helmholtz equation.
Journal of Computational Physics, 236, 289-316.
[23] Durufle, M. (2006). Intégration numérique et éléments finis d’ordre élevé
appliqués aux équations de Maxwell en régime harmonique (Doctoral dissertation,
ENSTA ParisTech).
156[24] Dutt, A., & Rokhlin, V. (1993). Fast Fourier transforms for nonequispaced
data. SIAM Journal on Scientific computing, 14(6), 1368-1393.
[25] Duda, R. O., & Martens, W. L. (1998). Range dependence of the response
of a spherical head model. The Journal of the Acoustical Society of
America, 104(5), 3048-3058.
[26] Duda, R. O., Avendano, C., & Algazi, V. R. (1999, March). An adaptable
ellipsoidal head model for the interaural time difference. In Acoustics,
Speech, and Signal Processing, 1999. Proceedings., 1999 IEEE International
Conference on (Vol. 2, pp. 965-968).
[27] Duraiswaini, R., Zotkin, D. N., & Gumerov, N. A. (2004, May). Interpolation
and range extrapolation of HRTFs [head related transfer functions].
In Acoustics, Speech, and Signal Processing, 2004. Proceedings.
(ICASSP’04). IEEE International Conference on (Vol. 4, pp. iv-45).
[28] Evans, M. J., Angus, J. A., & Tew, A. I. (1998). Analyzing head-related
transfer function measurements using surface spherical harmonics. The
Journal of the Acoustical Society of America, 104(4), 2400-2411.
[29] Farina, A. (2000, February). Simultaneous measurement of impulse response
and distortion with a swept-sine technique. In Audio Engineering
Society Convention 108. Audio Engineering Society.
[30] Fiala, P., Huijssen, J., Pluymers, B., Hallez, R., & Desmet, W. (2010,
September). Fast Multipole BEM modeling of head related transfer functions
of a dummy head and torso. In ISMA 2010 Conference, Leuven,
Belgium.
[31] Fischer, M., Gauger, U., & Gaul, L. (2004). A multipole Galerkin boundary
element method for acoustics. Engineering analysis with boundary
elements, 28(2), 155-162.
[32] Foster, S. (1986, April). Impulse response measurement using Golay
codes. In Acoustics, Speech, and Signal Processing, IEEE International
Conference on ICASSP’86. (Vol. 11, pp. 929-932).
[33] Gerzon, M. A. (1985). Ambisonics in multichannel broadcasting and video.
Journal of the Audio Engineering Society, 33(11), 859-871.
[34] Greengard, L., & Rokhlin, V. (1987). A fast algorithm for particle simulations.
Journal of computational physics, 73(2), 325-348.
[35] Greengard, L. (1988). The rapid evaluation of potential fields in particle
systems. MIT press.
[36] Greengard, L., & Lee, J. Y. (2004). Accelerating the nonuniform fast
Fourier transform. SIAM review, 46(3), 443-454.
157[37] Gumerov, N. A., Duraiswami, R., & Tang, Z. (2002, May). Numerical
study of the influence of the torso on the HRTF. In Acoustics, Speech,
and Signal Processing (ICASSP), 2002 IEEE International Conference on
(Vol. 2, pp. II-1965).
[38] Gumerov, N. A., & Duraiswami, R. (2005). Fast multipole methods for
the Helmholtz equation in three dimensions. Elsevier.
[39] Gumerov, N. A., O’Donovan, A. E., Duraiswami, R., & Zotkin, D. N.
(2010). Computation of the head-related transfer function via the fast multipole
accelerated boundary element method and its spherical harmonic
representation. The Journal of the Acoustical Society of America, 127(1),
370-386.
[40] M.A. Hamdi, An integral equation variational formulation for the resolution
of the Helmholtz equation including mixed boundary conditions.
Comptes Rendus de l’Académie des Sciences. Paris. 192 (1981) 17–20
[41] Hannay, J. H., & Nye, J. F. (2004). Fibonacci numerical integration on a
sphere. Journal of Physics A : Mathematical and General, 37 (48), 11591.
[42] Hamasaki, K., Hiyama, K., & Okumura, R. (2005, May). The 22.2 multichannel
sound system and its application. In Audio Engineering Society
Convention 118. Audio Engineering Society.
[43] Hackbusch, W. (2009). Hierarchische matrizen. Algorithmen und
AnalysisSpringer-Verlag, Berlin.
[44] Hamming, R. (2012). Numerical methods for scientists and engineers.
Courier Dover Publications.
[45] Hartung, K., Braasch, J., & Sterbing, S. J. (1999, March). Comparison of
different methods for the interpolation of head-related transfer functions.
In Audio Engineering Society Conference : 16th International Conference :
Spatial Sound Reproduction. Audio Engineering Society.
[46] Hesse, K., Sloan, I. H., & Womersley, R. S. (2010). Numerical integration
on the sphere. In Handbook of Geomathematics (pp. 1185-1219). Springer
Berlin Heidelberg.
[47] Hill, P. A., Nelson, P. A., Kirkeby, O., & Hamada, H. (2000). Resolution
of front–back confusion in virtual acoustic imaging systems. The Journal
of the Acoustical Society of America, 108(6), 2901-2910.
[48] Jot, J. M. (1997, September). Efficient models for reverberation and
distance rendering in computer music and virtual audio reality. In Proc.
1997 International Computer Music Conference.
[49] Kahana, Y. (2000). Numerical modelling of the head-related transfer
function (Doctoral dissertation, University of Southampton).
158[50] Katz, B. F. (2001). Boundary element method calculation of individual
head-related transfer function. I. Rigid model calculation. The Journal of
the Acoustical Society of America, 110(5), 2440-2448.
[51] Kahana, Y., & Nelson, P. A. (2006). Numerical modelling of the spatial
acoustic response of the human pinna. Journal of Sound and Vibration,
292 (1), 148-178.
[52] Kahana, Y., & Nelson, P. A. (2007). Boundary element simulations of
the transfer function of human heads and baffled pinnae using accurate
geometric models. Journal of sound and vibration, 300(3), 552-579.
[53] K-V. Nguyen, T. Carpentier, M. Noisternig, O. Warusfel, Calculation
of the head related transfer function in the proximity region using spherical
harmonics decomposition : comparison with measurements and evaluation.
Proc. of the 2nd International Symposium on Ambisonics and
Spherical Acoustics - Paris, 2010.
[54] Kechroud, R., Soulaimani, A., Saad, Y., & Gowda, S. (2004). Preconditioning
techniques for the solution of the Helmholtz equation by the finite
element method. Mathematics and Computers in Simulation, 65(4), 303-
321.
[55] Kirkup, S. (1998). The boundary element method in acoustics (Vol. 129).
Heptonstall : Integrated sound software.
[56] Kreuzer, W., Majdak, P., & Chen, Z. (2009). Fast multipole boundary
element method to calculate head-related transfer functions for a wide
frequency range. The Journal of the Acoustical Society of America, 126(3),
1280-1290.
[57] Larcher, V., & Jot, J. M. (1997, April). Techniques d’interpolation de
filtres audio-numériques, Application a la reproduction spatiale des sons
sur écouteurs. In Proc. CFA : Congres Français d’Acoustique.
[58] Larcher, V. (2001). Techniques de spatialisation des sons pour la réalité
virtuelle (Doctoral dissertation).
[59] Laborie, A., Bruno, R., & Montoya, S. (2003, March). A new comprehensive
approach of surround sound recording. In Audio Engineering Society
Convention 114. Audio Engineering Society.
[60] Lebedev, V. I., & Laikov, D. N. (1999). A quadrature formula for the
sphere of the 131st algebraic order of accuracy. In Doklady. Mathematics(Vol.
59, No. 3, pp. 477-481). MAIK Nauka/Interperiodica.
[61] Lee, J. Y., & Greengard, L. (2005). The type 3 nonuniform FFT and its
applications. Journal of Computational Physics, 206(1), 1-5.
159[62] HRTF database from listen project, www.recherche.ircam.fr/
equipes/salles/listen
[63] Lokki, T., & Pätynen, J. (2011). Lateral reflections are favorable in
concert halls due to binaural loudness. The Journal of the Acoustical
Society of America, 130(5), EL345-EL351.
[64] Majdak, P., Balazs, P., & Laback, B. (2007). Multiple exponential sweep
method for fast measurement of head-related transfer functions. Journal
of the Audio Engineering Society, 55(7/8), 623-637.
[65] Majdak, P., Iwaya, Y., Carpentier, T., Nicol, R., Parmentier, M., Roginska,
A., ... & Noisternig, M. (2013, May). Spatially Oriented Format for
Acoustics : A Data Exchange Format Representing Head-Related Transfer
Functions. In Audio Engineering Society Convention 134. Audio Engineering
Society.
[66] Messonnier, J. C., & Moraud, A. (2011, May). Auditory Distance Perception
: Criteria and Listening Room. In Audio Engineering Society
Convention 130. Audio Engineering Society.
[67] Middlebrooks, J. C. (1999). Individual differences in external-ear transfer
functions reduced by scaling in frequency. The Journal of the Acoustical
Society of America, 106(3), 1480-1492.
[68] Møller, H. (1992). Fundamentals of binaural technology. Applied acoustics,
36(3), 171-218.
[69] J.C Nédélec, Acoustics ans Electromagnetic equations. Integral representations
for harmonic problems. Applied Mathematics Science, 144, Springer
Verlag, New-York (2001).
[70] Nicol, R. (1999). Restitution sonore spatialisée sur une zone étendue :
application à la téléprésence. PhD these, Université Du Maine, France.
[71] Nicol, R., & Emerit, M. (1999, March). 3D-sound reproduction over an
extensive listening area : A hybrid method derived from holophony and
ambisonic. In Audio Engineering Society Conference : 16th International
Conference : Spatial Sound Reproduction. Audio Engineering Society.
[72] Otani, M., & Ise, S. (2003). A fast calculation method of the head-related
transfer functions for multiple source points based on the boundary element
method. Acoustical Science and Technology, 24(5), 259-266.
[73] Pulkki, V. (1997). Virtual sound source positioning using vector base
amplitude panning. Journal of the Audio Engineering Society, 45(6), 456-
466.
[74] Rayleigh, L. (1907). XII. On our perception of sound direction. The
London, Edinburgh, and Dublin Philosophical Magazine and Journal of
Science, 13(74), 214-232.
160[75] Romblom, D., & Cook, B. (2008, October). Near-field compensation for
HRTF processing. In Audio Engineering Society Convention 125. Audio
Engineering Society.
[76] Saad, Y., & Schultz, M. H. (1986). GMRES : A generalized minimal residual
algorithm for solving nonsymmetric linear systems. SIAM Journal
on scientific and statistical computing, 7(3), 856-869.
[77] Salles, N. (2013). Calcul des singularités dans les méthodes d’équations
intégrales variationnelles (Doctoral dissertation, Université Paris SudParis
XI).
[78] Shaw, E. A. G., & Teranishi, R. (1968). Sound Pressure Generated in an
External-Ear Replica and Real Human Ears by a Nearby Point Source.
The Journal of the Acoustical Society of America, 44(1), 240-249.
[79] Steinbach, O., & Wendland, W. L. (1998). The construction of some
efficient preconditioners in the boundary element method. Advances in
Computational Mathematics, 9(1-2), 191-216.
[80] Stan, G. B., Embrechts, J. J., & Archambeau, D. (2002). Comparison of
different impulse response measurement techniques. Journal of the Audio
Engineering Society, 50(4), 249-262.
[81] Takemoto, H., Mokhtari, P., Kato, H., Nishimura, R., & Iida, K. (2010).
A simple pinna model for generating head-related transfer functions in
the median plane. Proc. 20th Int. Congr. Acoust.(ICA’10).
[82] Terrasse, I., & Abboud, T. (2007). Modélisation des phénomenes de propagation
d’ondes. (Modeling of wave propagation phenomena), Ecole Polytechnique.
[83] Mercier, D. (2002). Le livre des techniques du son-Tome 1-3. Dunod.
[84] Wightman, F. L., & Kistler, D. J. (1999). Resolution of front-back ambiguity
in spatial hearing by listener and source movement. The Journal
of the Acoustical Society of America, 105(5), 2841-2853.
[85] Woodworth, R. S., & Schlosberg, H. (1962). Experimental psychology.
Holt, Rinehart and Winston.
[86] Zotkin, D. N., Hwang, J., Duraiswaini, R., & Davis, L. S. (2003, October).
HRTF personalization using anthropometric measurements. In Applications
of Signal Processing to Audio and Acoustics, 2003 IEEE Workshop
on. (pp. 157-160).
[87] Zotkin, D. N., Duraiswami, R., Grassi, E., & Gumerov, N. A. (2006).
Fast head-related transfer function measurement via reciprocity. The Journal
of the Acoustical Society of America, 120(4), 2202-2215.
161[88] Voir http ://www.cims.nyu.edu/cmcl/fmm3dlib/fmm3dlib.html
[89] Voir https ://www.ljll.math.upmc.fr/frey
[90] Voir http ://www.xbox.com/fr-FR/Kinect
[91] Voir http ://www.neumann.com
[92] Voir http ://meshlab.sourceforge.net
[93] Voir http ://www.mathworks.com/matlabcentral/ fileexchange/25135-
nufft–nfft–usfft
[94] Voir http ://web.eecs.umich.edu/ fessler/code/index.html
[95] Voir http ://www.cims.nyu.edu/cmcl/nufft/nufft.html
[96] Voir http ://www-user.tu-chemnitz.de/ potts/nfft
[97] Voir http ://remesh.sourceforge.net
[98] Voir http ://www.physik3.gwdg.de/tstool
[99] Voir http ://www.vtk.org
162Noname manuscript No.
(will be inserted by the editor)
The Sparse Cardinal Sine Decomposition and its
application for fast numerical convolution
Fran¸cois Alouges · Matthieu Aussal
Received: date / Accepted: date
Abstract Fast convolution algorithms on unstructured grids have become a
well established subject. Algorithms such as Fast Miltipole Method (FMM),
adaptive cross approximation (ACA) or H-matrices for instance are, by now,
classical and reduce the complexity of the matrix-vector product from O(N2
)
to O(N log N) with a broad range of applications in e.g. electrostatics, magnetostatics,
acoustics or electromagnetics. In this paper we describe a new
algorithm of which we would like to explore the potential. Based on the Non
Uniform FFT algorithm, it is at the same time simple, efficient and versatile.
Keywords Quadrature · Non Uniform FFT · Fast convolution · Fast
Multipole Method
Mathematics Subject Classification (2000) 65T50 · 65Z05
1 Introduction
In many areas of computational physics appears the problem of solving a
PDE via the convolution of a distribution with an explicit Green kernel. This
is for instance the case in electrostatics, magnetostatics or gravitation where
a Coulombian interaction is used. In order to fix the ideas we set the problem
as computing for N given punctual masses (fk){1≤k≤N} located at the points
F. Alouges
CMAP - Ecole Polytechnique, Route de Saclay, 91128, Palaiseau Cedex, France.
Tel.: +33-1-69334631
Fax: +33-1-69334646
E-mail: francois.alouges@polytechnique.edu
M. Aussal
CMAP - Ecole Polytechnique, Route de Saclay, 91128, Palaiseau Cedex, France and Digital
Media Solutions, 45 Grande All´ee du 12 F´evrier 1934, 77186 Noisiel, France.
E-mail: matthieu.aussal@gmail.com2 Fran¸cois Alouges, Matthieu Aussal
(xk){1≤k≤N} in ❘3
, the Coulombian potential at the same points defined by
∀k ∈ {1, · · · , N}, gk =
X
N
l=1
fl
4π|xk − xl
|
. (1)
The previous problem is easily solved with the O(N2
) algorithm by computing
straightforwardly the potential generated by each source at each target. However
for big values of N (e.g. a million or a billion), the above formula is too
slow to be used. Techniques already exist to speed up this computation, the
most famous of which being certainly the FMM (for Fast Multipole Method)
developed by Greengard and coauthors (see the seminal book [9] for instance).
We hereafter would like to present a different method that is based on a sparse
Fourier representation.
2 Principle of the method
Introducing the N × N matrix A whose entries are Akl =
1
4π|xk−xl|
, we recast
the problem as storing A and computing the matrix-vector product G = AF
, where G = (g1, · · · , gN )
t and F = (f1, · · · , fN )
t
. A fast algorithm is at hand
if we are able to write A as a sum of a small number of rank one matrices1
A =
X
n
CnRn ,
where Cn and Rn are respectively column and row vectors of size N. Indeed,
the matrix vector product is computed in this case as
AF =
X
n
CnRnF =
X
n
Cn(R
t
n
· F), (2)
and each term in the sum is computed in O(N) operations.
Notice that such a decomposition is formally given by writing the Fourier
transform of the kernel 1
4π|x|
in ❘3
F
1
4π|x|
=
1
|ξ|
2
.
Indeed, this enables us to write
1
4π|x − y|
=
1
(2π)
3
Z
❘3
e
i(x−y)·ξ
|ξ|
2
dξ ,
1 This is by the way the basis of the principle of H−matrices, see [11].Title Suppressed Due to Excessive Length 3
while coming back to the problem (1), we deduce
X
N
l=1
1
4π|xk − xl
|
fl =
1
(2π)
3
X
N
l=1
Z
❘3
e
i(xk−xl)·ξ
|ξ|
2
dξ
fl
=
1
(2π)
3
Z
❘3
e
ixk·ξ
X
N
j=1
e
−ixl·ξ
|ξ|
2
fl
dξ. (3)
This latter formula is exactly under the desired form (2) with
Cξ =
1
(2π)
3
(e
ix1·ξ
, · · · , eixN ·ξ
)
t
and Rξ =
(e
−ix1·ξ
, · · · , e−ixN ·ξ
)
t
|ξ|
2
,
except that the finite sum indexed by n is now replaced by an integral over
ξ ∈ ❘3
. We can thus produce a formula of the desired form if we can derive a
quadrature formula that approximates the integral. For efficiency reasons, it is
also desirable to have the smallest possible number of terms in this quadrature
formula2
. In order to proceed, we pass in spherical coordinates, and further
transform (3) into
gk =
X
N
l=1
1
4π|xk − xl
|
fl
=
1
(2π)
3
Z +∞
0
Z
❙2
e
iλxk·ξ
X
N
l=1
e
−iλxl·ξ
λ2
fl
!
λ
2
dξ!
dλ
=
1
(2π)
3
Z +∞
0
Z
❙2
e
iλxk·ξ
X
N
l=1
e
−iλxl·ξ
fl
!
dξ!
dλ. (4)
The basis of our method thus consists in finding numerical quadratures for
the integrals in λ and ξ. This would eventually permit us to approximate the
above formula by
X
N
l=1
1
4π|xk − xl
|
fl ∼
X
S
s=1
ωse
iλsxk·ξs
X
N
l=1
e
−iλsxl·ξs fl
!
=
X
S
s=1
ωse
ixk·ζs
X
N
l=1
e
−ixl·ζs fl
!
,
having set ζs = λsξs ∈ λs❙
2
. Afterwards, the convolution can be done in two
passes :
• Compute ηs =
PN
l=1 e
−ixl·ζs fl from the (fl)1≤l≤N for all 1 ≤ s ≤ S ;
• Compute gk =
PS
s=1 e
ixk·ζs (ωsηs) knowing the previously computed (ηs)1≤s≤S
.
2 Notice that similar ideas are already used in [2] and [8], though in a different context.4 Fran¸cois Alouges, Matthieu Aussal
Both steps can be realized using a (direct and inverse) type-3 Non Uniform
FFT (NUFFT) algorithm [4, 15, 16]. We will be more explicit on this point
later.
Afterall, the method is not surprising and simply relies on the fact that a
convolution is a product in Fourier space. The difficulty however stands in the
fact that one needs, to make the method of practical use, a good quadrature
which is both precise and efficient (i.e. that possesses a small number of points).
It turns out that this is feasible to a very reasonable cost, and at the end
gives a quite powerful numerical method that we have called Sparse Cardinal
Sine Decomposition (SCSD). Maybe the originality of the present approach lies
in the fact that, having written the integral in spherical coordinates permits
us furthermore to decouple the approximation problem (in λ and ξ), and treat
them separately. The aim of the paper is to give such a method and estimate
its complexity through the following Proposition.
Proposition 1 Assume that the original points are uniformly distributed in a
ball then the SCSD algorithm has a global complexity which scales as O(N log N).
If instead, the points are spread uniformly on a regular surface in ❘3
, then the
complexity is O(N6/5
log N).
The paper is divided as follows. Section 3 addresses the problem of finding
a good quadrature in λ, by introducing a so-called sparse cardinal sine decomposition.
Section 4 explain the spherical quadrature. Actually, a classical
Gauss-Legendre quadrature is used whose parameters are thoroughly studied
(see [10] for instance). Eventually Section 5 explains how to take into
account the close interactions, while Section 6 details how to choose the parameters
of the method. Other kernels are treated in Section 7 and numerical
results are provided the last Section. In particular, we compare the timings
obtained to compute the convolution using either a FMM routine provided by
Leslie Greengard on CMCL website [18] or the abovementionned quadrature
and NUFFT approach where the (type-3) NUFFT routine is also taken from
the same website [17]. (Another implementation, which in particular uses the
FFTW package, is also available in the NFFT project of D. Potts [19] but the
type 3 NFFT does not yet have a Matlab interface.).
3 The Sparse Cardinal Sine Decomposition
In order to decouple the problem in spherical coordinates we notice that the
formula (4) can be rewritten under the form
X
N
l=1
1
4π|xk − xl
|
fl =
1
(2π)
3
Z +∞
0
X
N
l=1
Z
❙2
e
iλxk·ξ
(e
![[TXT]](http://www.audentia-gestion.fr/icons/text.gif){kind=icon}
